V2Ray 速度慢怎麼排查：節點、線路、本機設定三層定位法

代理速度突然下降時，直接更換協定、開啟 Mux 或反覆重裝用戶端，通常無法縮短排查時間。下載速度是節點負載、接入線路、跨網壅塞、目標網站回應、本機代理模式與裝置效能共同作用的結果。應先建立可重複的測試條件，再一次只修改一個變數。

先建立測速基準，避免把延遲當成頻寬

延遲和吞吐量不是同一項指標。延遲測試反映一次往返需要多久，適合判斷節點是否容易建立連線；下載速度反映一段時間內能傳輸多少資料，還會受到節點出口頻寬、目標伺服器限速和 TCP 壅塞控制影響。一個延遲 45 ms 的節點可能只有 8 Mbps 吞吐量，一個延遲 130 ms 的節點也可能穩定跑到 120 Mbps。

測試前先暫停雲端硬碟同步、系統更新和瀏覽器背景影片。固定使用同一台裝置、同一個接入網路與同一個目標檔案，並連續測試三次。首次連線可能包含 DNS 查詢與 TLS 交握，建議記錄第二次和第三次結果。若三次分別為 92、95、90 Mbps，節點較穩定；若結果為 88、21、76 Mbps，則應繼續觀察負載與封包遺失，而不是只取最高值。

第一層：判斷節點本身是否壅塞或受限

節點層問題通常有三個特徵：同一個網路下只有少數節點速度慢；全天都慢且多次測試接近同一上限；連線數量增加後延遲迅速升高。先選擇同一地區的不同節點進行橫向比較。若節點 A 三次為 18、20、19 Mbps，節點 B 三次為 86、91、88 Mbps，本機網路和用戶端大多不是主要瓶頸。

延遲清單只能用於初步篩選。v2rayN 的延遲測試會檢查節點回應時間，但不能直接代表下載能力。應先在主介面選取節點，執行延遲測試，再對延遲相近的兩個節點進行實際下載。若一個節點延遲 62 ms、吞吐量 15 Mbps，另一個節點延遲 75 ms、吞吐量 96 Mbps，下載工作應優先選擇後者。

1. 固定測試環境

   關閉其他下載工作，維持相同的有線或無線網路，測試期間不要切換接入方式。每輪測試至少持續 60 秒。

2. 更新節點資訊

   在 v2rayN 7.x 主介面進入「訂閱分組」→「更新全部訂閱」，確認節點位址、連接埠和傳輸參數來自目前的訂閱。

3. 篩選延遲

   對候選節點執行 TCP 延遲測試，先排除持續逾時或波動超過 300 ms 的節點，不要只按最低延遲下結論。

4. 實測吞吐量

   選擇三個候選節點，各完成三輪相同工作，記錄平均速度、最低速度和開始載入所需的時間。

5. 查看日誌

   開啟「說明」→「檢視日誌」，檢查測試期間是否集中出現交握逾時、連線重設或無法連線至目標的訊息。

切換 VMess、VLESS 或不同傳輸方式，只有在伺服器提供相應設定時才有意義。協定不是能由用戶端單方面修改的加速開關。比較協定時應盡量使用同一台伺服器、相同連接埠條件與相近的安全層，否則結果會同時混入裝置效能、入口線路和出口頻寬的差異。

第二層：比較線路、時段與接入網路

線路壅塞往往具有明顯的時間規律。白天穩定在 90 Mbps，晚間 20:00 至 23:00 降至 15 Mbps，同時延遲從 70 ms 升至 220 ms，這類變化更接近尖峰時段壅塞。若更換同一地區的多個節點後仍同步變慢，應繼續比較接入線路，而不是不斷修改用戶端參數。

最有效的對照方式是保留同一個節點，只更換本機接入網路。例如固定節點後，家用寬頻測得 18 Mbps，另一條網路測得 82 Mbps，表示瓶頸更可能位於本地電信網路、路由路徑或家用裝置。若兩條網路都穩定在 18 Mbps，再回頭檢查節點負載和出口限制。

第三層：檢查連接埠、DNS、路由與系統代理

當所有節點在同一台裝置上都很慢，而其他裝置使用同一網路表現正常時，應轉向檢查本機設定。v2rayN 常見的本機入站連接埠為 10808，但實際值以「設定」→「參數設定」中的配置為準。瀏覽器、下載工具和系統代理都必須指向目前的監聽連接埠；舊連接埠即使仍被其他程式占用，也可能造成連線失敗或繞過代理。

系統代理和 TUN 模式的流量入口不同。系統代理只接管遵循系統代理設定的應用程式；TUN 模式會在更底層擷取流量。排查時不要同時疊加多個入口。先關閉 TUN，只啟用「自動設定系統代理」完成基準測試，再視需要單獨測試 TUN，才能判斷差異來自擷取方式還是節點。

1. 核對核心

   進入「設定」→「參數設定」→「Core 類型」，確認所選核心能處理目前訂閱中的 VMess、VLESS 與傳輸設定，然後重新啟動核心。

2. 檢查連接埠

   在「設定」→「參數設定」中查看本機監聽連接埠。若為 10808，瀏覽器或下載工具也應使用 127.0.0.1:10808。

3. 統一代理模式

   透過狀態列「系統代理」→「自動設定系統代理」建立測試環境。暫時關閉其他會修改系統代理的程式。

4. 簡化路由

   進入「設定」→「路由設定」，暫時使用容易判斷的基礎規則，確認目標請求究竟經由代理、直連，還是遭到阻擋。

5. 重新測試 DNS

   清除系統 DNS 快取並重新啟動核心。若日誌顯示解析等待時間過長，分別測試本地 DNS 與代理端解析，保留較穩定的方式。

測試條件：Windows 11 24H2，v2rayN 7.x
本機位址：127.0.0.1
本機連接埠：10808
單輪時間：60 秒
測試次數：3 次
記錄項目：TCP 延遲、首個封包時間、平均 Mbps、最低 Mbps、錯誤日誌

路由分流會直接改變實際路徑。若某個下載網域被誤判為直連，測速結果測到的就是本地網路，而不是代理節點；原本應直連的區域網路或中國大陸服務若全部送入遠端節點，也會增加繞路。檢查規則時先查看命中順序，因為前面的規則通常會先決定出站，後續規則不會再接管已經匹配的請求。

Mux 與協定切換何時有效

Mux 會將多個邏輯連線多工到較少的底層連線中。它可能減少大量短連線的建立成本，例如同時開啟多個小型網頁資源；但對單一大型檔案下載不一定更快。底層連線發生封包遺失時，多個邏輯流量可能一起等待，反而讓高頻寬、高封包遺失率線路的速度波動更明顯。

要判斷 Mux 是否適合目前環境，應在相同節點上分別關閉和開啟，測試網頁首屏與大型檔案下載。若關閉時平均 94 Mbps、開啟後 61 Mbps，而網頁使用感受差異很小，就應維持關閉。若大量短連線的首屏時間從 2.8 秒降至 1.7 秒，而大型檔案吞吐量沒有明顯下降，則可以保留。

• 單一檔案下載慢：先關閉 Mux 進行對照，觀察持續吞吐量，不要只看開始幾秒的峰值。
• 網頁小型資源很多：記錄完整載入時間，比較開啟前後的首個封包與總耗時。
• 線路封包遺失明顯：優先解決節點或路徑問題，多工無法補回遺失的頻寬。
• 準備切換協定：只使用訂閱提供且與伺服器相符的 VMess、VLESS 設定，不要在用戶端單方面修改驗證和傳輸參數。
• REALITY 設定：伺服器名稱、公鑰、短識別碼與流量控制參數必須彼此匹配，成功連線本身不代表線路一定更快。

依固定順序完成最終定位

排查的目標不是找到一個瞬間最快的數值，而是確定瓶頸屬於哪一層。節點層看橫向差異，線路層看時間與網路對照，本機層看裝置間差異和設定命中。完成這三層後，大多數「能連線但速度慢」的問題都能縮小到一個可驗證的範圍。

1. 記錄原始結果

   保存目前節點三輪延遲與吞吐量，註明日期、時段、接入網路和代理模式，避免依賴模糊的使用感受。

2. 橫向更換節點

   在同一網路下測試至少三個節點。只有少數節點速度慢，歸類為節點負載、出口或設定問題。

3. 縱向更換時段

   在同一節點分別於非尖峰時段和 20:00 至 23:00 測試。多個節點同步下降，應重點檢查線路壅塞。

4. 更換接入網路

   維持節點與裝置不變，只切換網路。速度隨網路明顯變化時，優先檢查原接入線路和路由設備。

5. 還原本機設定

   核對 10808 等實際連接埠，簡化路由，分別測試系統代理與 TUN，並關閉 Mux 進行對照。

6. 保留穩定設定

   選擇連續三輪波動較小的組合。平均 80 Mbps 且穩定，通常比峰值 140 Mbps、最低 12 Mbps 更適合日常使用。

Android 端也可以沿用相同方法。v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心；先維持訂閱節點和接入網路一致，再分別檢查路由模式、DNS 與日誌。不同核心支援的具體設定能力可能不同，成功匯入後仍應確認協定與傳輸參數已正確識別。