「延遲正常但下載很慢」、「白天能用，晚上只剩幾 Mbps」、「同一份訂閱在電腦上很快、Android 上很慢」，表面看來都是速度問題，實際上可能發生在完全不同的環節。只看用戶端中的延遲數字無法下定論：延遲通常只反映一次短請求的往返時間，不代表持續傳輸能力，也不能直接說明節點出口頻寬、線路封包遺失及本機分流是否正常。
本文適合已能連線至 VMess、VLESS 等節點，但網頁載入、影片緩衝或檔案傳輸明顯偏慢的使用者。先固定測試條件，再依序檢查節點容量、傳輸線路與用戶端設定；每次只變更一個變數，最後即可判斷應更換節點、避開特定時段，或修正本機設定。
先建立可重現的測速基準
排查前不要同時切換節點、修改 DNS、啟用 Mux 及調整路由。一次改變四個變數，即使速度恢復，也無法知道真正原因。正確的起點是記錄直連速度、代理速度、測試時間、節點名稱、用戶端與核心版本，並在同一台裝置、同一個網路及同一個測速目標下重複測試。
完整請求並不是從「節點」直接抵達網站，中間至少會經過應用程式、系統代理、本機核心、接入線路、遠端節點及目標網站。任何一段出現排隊、封包遺失或錯誤分流，最後都會表現為載入緩慢。
上面的數字是一組排查紀錄範例，不是速度標準。重點在於保留可比較的資料。建議連續測試三次，捨棄明顯異常的一次，再記錄其餘兩次的範圍。如果第一次為 92 Mbps、第二次為 89 Mbps、第三次突然只有 8 Mbps，應先懷疑短暫封包遺失或測速目標波動，而不是立刻認定節點限速。
- 關閉正在同步、下載或上傳的程式，確認其他裝置沒有佔滿家用網路。
- 先關閉系統代理測試一次直連，再啟用同一個節點完成代理測試。
- 固定連線方式；不要在直連測試時使用網路線，代理測試卻改用訊號較弱的無線網路。
- 記錄首位元組等待時間、持續下載速度及晚間尖峰表現，不要只記錄用戶端延遲。
- 每輪只修改一項設定，修改後重新啟動核心或重新連線，避免舊連線持續被重複使用。
第一層：判斷節點負載與協定開銷
節點層需要回答兩個問題：遠端伺服器是否繁忙，以及目前的節點參數是否帶來額外開銷。節點延遲低不代表頻寬充足。一台伺服器可以在 80 毫秒內回應探測請求，卻因 CPU、出口頻寬或並行連線達到上限，只能提供很低的持續吞吐量。
最有效的對照不是連續點擊十次延遲測試，而是從同一份訂閱中選擇兩個地區相近、協定參數明確的節點，在五分鐘內分別完成相同任務。如果 A 節點穩定維持 75 Mbps，B 節點只有 9 Mbps，而兩者都經過同一台裝置及本機網路，B 節點的負載或出口品質就更值得懷疑。
| 觀察現象 | 較可能的原因 | 對照動作 |
|---|---|---|
| 延遲 90 ms，持續速度只有 6 Mbps | 節點出口擁擠或伺服器負載偏高 | 在同一地區更換另一個節點，固定目標重複測試三次 |
| 小型網頁正常，大型檔案速度週期性下降 | 持續傳輸壅塞、封包遺失重傳或連線共用造成影響 | 關閉 Mux 後重新連線，再比較一分鐘平均速度 |
| 所有節點都卡在近似速度 | 本機網路、測速目標或統一路由規則造成限制 | 測試直連基準，並檢查是否誤走代理 |
| 單一節點晚間明顯下降，早晨恢復 | 共用節點晚間尖峰負載或線路壅塞 | 在 08:00 與 21:30 各保留一組紀錄 |
VMess 與 VLESS 都只是連線設定的一部分，實際開銷還取決於傳輸層、加密、TLS、封包大小及線路品質。不要因為某個協定名稱看起來「較新」就假定一定更快。參數正確、伺服器支援、鏈路穩定，比單獨比較協定名稱更重要。訂閱節點應依提供者給出的完整參數匯入，不要自行刪除安全設定，或混用不同節點的連接埠與傳輸參數。
- 先透過更新訂閱取得完整設定，再確認測試的是目前選取的節點，而不是舊分組中的同名節點。
- 測試期間保留相同的傳輸參數，只切換節點，避免將節點差異與協定差異混在一起。
- 若只有大量流量任務速度緩慢，請分別測試單一連線與多連線任務，觀察是否存在明顯的單連線瓶頸。
- 若節點剛連線時速度快、幾分鐘後下降，請記錄核心日誌的時間點，並檢查伺服器是否頻繁斷線後重新連線。
第二層：辨識跨網路線路與壅塞時段
多個節點同時變慢，但隔天早晨恢復，通常更接近線路問題。跨網路傳輸會經過多個路由節點，晚間尖峰可能出現排隊、抖動與封包遺失。此時用戶端顯示「已連線」完全正常，因為連線仍然存在，只是每個封包需要更長時間抵達，遺失的資料還必須重新傳送。
線路層排查重視時間對照。建議在 08:00、14:00、21:30 三個時段使用同一個節點測試，並至少記錄延遲、連續下載一分鐘的平均速度及是否出現明顯波動。例如早晨 91 Mbps、下午 84 Mbps、晚間 18 Mbps，比單次描述「節點只有 18 Mbps」更能說明問題。
如果不同地區的節點在晚間都下降，但下降幅度不同，可以優先選擇路由較穩定的地區，而不是只追求地理距離最近。距離會影響理論延遲，卻不能代表實際路徑一定較短。電信商互聯、節點接入網路及中間路由變化，都可能讓較遠的節點獲得更穩定的吞吐量。
從現象區分延遲、抖動與封包遺失
- 延遲升高：頁面首次回應變慢，但穩定下載後速度可能仍可接受。
- 抖動明顯：速度曲線忽高忽低，語音、即時請求及短連線更容易感到卡頓。
- 封包遺失重傳：下載速度呈鋸齒狀，日誌可能伴隨逾時、連線重設或內容作業取消。
- 路徑壅塞：集中發生在固定時段，更換同一地區的節點不一定改善，改走不同線路方向可能有效。
第三層：檢查 Mux、DNS 與路由分流
當同一個節點在另一台裝置上速度正常，本機設定就應成為重點。v2rayN、v2rayNG 和 v2flyNG 都會將應用程式流量交給本機核心處理，但系統代理模式、VPN 模式、路由規則及 DNS 路徑並不相同。複製訂閱不代表兩台裝置最後的輸出路徑完全一致。
先檢查監聽連接埠。以本機混合連接埠 10808 為例，瀏覽器或系統代理必須指向目前用戶端實際監聽的位址與連接埠。舊工具若仍佔用 10808，用戶端可能切換到其他連接埠，或核心啟動失敗。v2rayN 可在「設定」→「參數設定」中核對本機監聽設定；修改後儲存並重新啟動核心，再確認系統代理指向一致。
Mux 不應預設等同於加速
Mux 會讓多個邏輯請求共用連線，可能減少重複握手；但在封包遺失明顯或單一連線受限時，也可能讓多個請求彼此等待。排查時應進行一次嚴格對照：保持節點、時間及測速目標不變，關閉 Mux，完全斷線後重新連線，再測試三次。如果平均速度從 24 Mbps 提升到 57 Mbps，且波動減小，表示目前鏈路不適合原本的共用設定；若差異只有 2% 到 5%，就不應將其視為主要原因。
路由規則會造成「部分網站很慢」
路由分流會依網域、位址範圍或規則集選擇直連或代理輸出。規則順序錯誤時，同一頁面的主文件可能走代理，圖片或影片網域卻走直連；也可能將本應直連的本地服務繞道至遠端節點。表現就是首頁能開啟、資源卻載入很久，或只有特定網站速度緩慢。
- 暫時切換到用戶端提供的基本代理模式，記錄問題是否消失。
- 若基本模式恢復速度，請逐組啟用自訂規則，不要一次恢復整份複雜設定。
- 檢查網域規則是否被較前面的廣泛規則命中，尤其要注意同一項服務使用多個資源網域的情況。
- 修改路由後重新載入設定，並重新開啟測試頁面，避免舊連線沿用先前的輸出路徑。
DNS 緩慢與傳輸緩慢的體感不同
DNS 異常通常表現為點擊後長時間完全沒有回應，但頁面一旦開始載入，後續速度尚可。持續傳輸瓶頸則表現為已經開始下載，卻始終維持低速。測試時可比較首次開啟與重新整理後的差異，並查看核心日誌中網域解析、建立連線及發生逾時的先後順序。
| 本機項目 | 檢查位置或方法 | 合格表現 |
|---|---|---|
| 監聽連接埠 | 在 v2rayN「設定」→「參數設定」核對 10808 | 用戶端、系統代理與應用程式填寫一致 |
| Mux | 關閉後斷線重連，完成三輪相同目標的測試 | 清楚記錄啟用與停用時的平均值 |
| 路由分流 | 暫時恢復基本模式，再逐組啟用規則 | 能定位到具體規則組，或排除路由因素 |
| Android 背景限制 | 在系統設定中允許 v2rayNG 或 v2flyNG 持續執行 | 鎖定螢幕及切換應用程式後連線不中斷 |
結合核心日誌排除假性速度問題
有些「速度慢」其實是連線反覆失敗後重新嘗試。頁面最後仍能開啟，容易讓人以為只是頻寬不足；但日誌可能顯示 DNS 解析失敗、撥號逾時、遠端重設或本機連接埠衝突。排查時先記下測速開始的準確時間，再查看同一分鐘內的錯誤紀錄，避免受到更早的歷史日誌干擾。
錯誤：failed to dial WebSocket
原因與解法：用戶端未能在限定時間內建立傳輸連線，可能是節點無法連線、路徑壅塞或參數不相符。先更新訂閱並核對位址、連接埠及傳輸設定，再更換同一地區的節點進行對照。
錯誤：i/o timeout
原因與解法：連線或讀寫操作超過等待時間，常見於線路封包遺失及目標回應過慢。比較早晚時段，若晚間尖峰集中出現，應優先從線路層處理。
錯誤：connection reset by peer
原因與解法：對端或中間鏈路主動重設連線。確認節點仍然有效，關閉 Mux 完成一次對照，並觀察是否只發生在單一節點。
錯誤：context canceled
原因與解法：請求在完成前被取消，可能來自切換節點、重新載入設定、應用程式主動中止或上游連線失敗。若在測速期間頻繁出現，請先停止自動切換及重複更新設定。
單一錯誤不能直接證明是頻寬問題。例如切換節點時出現一次 context canceled，是可以解釋的事件；如果每隔幾秒重複出現，並伴隨速度歸零，就需要繼續追查前一筆連線失敗紀錄。判讀日誌應結合發生頻率、節點範圍及時間規律，而不是看到英文錯誤就立即更換全部設定。
- 只有一個節點持續逾時：優先檢查節點參數、狀態及遠端負載。
- 所有節點在同一個網路中逾時：檢查線路、本機 DNS、防火牆及監聽連接埠。
- 電腦正常但 Android 反覆斷線：檢查 v2rayNG 或 v2flyNG 的背景執行限制及 VPN 授權狀態。
- 更新訂閱後才變慢：確認目前選取的節點、路由分組及自訂參數沒有沿用舊值。
常見測速疑問與最終判斷
完成三層對照後，應能將問題歸入「單一節點異常」、「固定時段線路壅塞」或「單一裝置本機設定」其中一類。仍無法判斷時，不要繼續疊加最佳化參數，而應退回最簡單的可用設定：一個確認能連線的節點、基本路由、預設 DNS 路徑，以及關閉 Mux 的對照狀態。
延遲只有 80 毫秒，為什麼下載還是很慢？
延遲是短請求的往返時間，不代表持續頻寬。固定同一個測速目標下載至少一分鐘，再與另一個同地區節點比較；若只有該節點速度低，優先判斷節點負載。
晚上慢、白天快，需要修改用戶端設定嗎？
先保留 08:00 與 21:30 使用同一節點、同一目標的資料。如果直連穩定，而多個節點在晚間同時下降，看起來更像線路壅塞；反覆修改 DNS 或連接埠通常無法解決。
啟用 Mux 一定會更快嗎？
不一定。在其他條件不變的情況下，分別啟用與停用 Mux 測試三次，再以平均速度及波動幅度判斷。在封包遺失的鏈路上，共用連線可能讓多個請求一起等待。
訂閱中有很多節點，逐一測速最可靠嗎？
先依地區選擇三到五個代表性節點，在同一時段完成持續傳輸測試。只測延遲會放大偶然結果，也無法反映節點出口容量。
電腦快但 Android 慢，應該先查什麼？
確認兩端選取的是同一個節點，再檢查 v2rayNG 或 v2flyNG 的 VPN 授權、背景執行限制、分應用程式代理及路由設定。使用同一個無線網路與同一個目標重新測試。
一份可執行的收尾清單
- 確認直連測速正常後，再開始代理排查。
- 同一地區至少比較兩個節點，不要用單次延遲取代持續速度。
- 記錄早晚時段；固定時段集中下降時，歸入線路層處理。
- 單一裝置異常時，核對 10808 等實際監聽連接埠及系統代理。
- 關閉 Mux 進行一次完整對照，不要憑經驗決定是否啟用。
- 恢復基本路由，逐組找出造成繞路的分流規則。
- 依測速時間查看核心日誌，區分低頻寬與反覆重新連線。
- 每次只修改一項，重新啟動核心後儲存新一輪資料。
排查速度問題的核心不是尋找某個「最快設定」，而是建立因果關係。只有單一節點變慢，就處理節點；多個節點依時段同步變慢，就觀察線路；只有一台裝置變慢，就回頭檢查連接埠、Mux、DNS、路由及背景策略。完成這套分層測試後，再決定是否更新訂閱、切換節點或調整用戶端，通常比連續隨機修改設定更快。