適合處理網頁載入緩慢、下載速度波動、影片頻繁緩衝或連線延遲突然升高等問題。排查時先固定測試條件，再依序檢查節點、接入線路與本機設定；每一步只變更一個變數，並根據延遲、丟包、吞吐量與日誌結果決定下一步。
先建立可重複的速度基準
直接連續切換節點，很難定位問題原因。當節點、測試時間、目標網站、代理模式與無線網路狀態同時變動時，即使速度恢復，也無法確定是哪項調整生效。開始前先關閉正在同步檔案、更新軟體或占用上傳頻寬的工作，並讓測試裝置保持在同一個網路位置。
判斷速度至少要觀察三個數值：建立連線所需的時間、持續傳輸時的平均吞吐量，以及十分鐘內的波動幅度。延遲低只代表往返回應較快，不代表可用頻寬較大。一個延遲 65 毫秒的節點，可能只能穩定傳輸 8 Mbps；另一個延遲 120 毫秒的節點，卻可能持續達到 45 Mbps。
建議使用同一個大檔案或同一項連續傳輸工作測試三輪，每輪維持 60 秒以上，間隔 30 秒。不要只看開始幾秒的峰值。瀏覽器快取、伺服器瞬間突發流量與用戶端統計更新間隔，都可能讓短時間速度偏高。
| 記錄項目 | 建議樣本 | 判斷用途 |
|---|---|---|
| 實際連線延遲 | 連續測試 5 次，記錄中位數 | 排除偶發的握手波動 |
| 持續吞吐量 | 每輪 60 秒，共 3 輪 | 判斷節點頻寬與線路穩定性 |
| 丟包率 | 傳送 50 至 100 個探測封包 | 辨識接入網路或中間線路問題 |
| 測試時段 | 白天與晚間各測試一次 | 確認是否存在固定的尖峰壅塞 |
記錄提示：同時記下用戶端版本、核心版本、代理模式與目前網路環境。例如「v2rayN 7.x、Xray 核心、系統代理、無線網路、HTTP 連接埠 10809」。版本不必猜測，直接複製用戶端「關於」頁面或日誌開頭顯示的實際值。
第一層：判斷是否為單一節點問題
節點層最容易驗證。選擇同一訂閱群組內、地區相近但伺服器位址不同的兩至三個節點，維持本機網路、協定類型與測試目標不變。v2rayN 可在伺服器清單中選取節點後執行「測試伺服器實際連線延遲」；Android 端則可在 v2rayNG 或 v2flyNG 的節點清單中進行連線測試。
如果只有一個節點持續變慢，而其他節點在三輪測試中都正常，問題通常集中在該節點的伺服器負載、連接埠可達性或出口頻寬。如果同一地區的所有節點在晚間都變慢、白天恢復，較像是線路尖峰；如果所有地區、所有協定都很慢，則應直接檢查接入線路與本機設定。
- 更新一次訂閱，確認沒有繼續使用已調整或停用的舊節點參數。
- 按照「地區相近、伺服器不同」的原則，選出至少 3 個節點。
- 每個節點先測試 5 次實際連線延遲，再進行 3 輪持續傳輸。
- 記下平均速度與最慢一輪的速度，不要依最高瞬間值排序。
- 重新連線至表現最穩定的節點，再測試原本速度較慢的目標應用程式。
| 測試結果範例 | 延遲中位數 | 三輪吞吐量 | 初步結論 |
|---|---|---|---|
| 節點 A | 72 ms | 7、9、6 Mbps | 延遲正常但頻寬偏低 |
| 節點 B | 89 ms | 38、41、39 Mbps | 穩定，可作為對照 |
| 節點 C | 210 ms | 0、18、2 Mbps | 連線品質明顯波動 |
結論：穩定吞吐量比最低延遲更重要
節點 B 雖然比節點 A 多 17 毫秒延遲，但三輪速度差距只有 3 Mbps，更適合下載與觀看影片。節點 C 的峰值並不低，卻有兩輪結果接近無法使用，應先排除線路丟包或伺服器負載。
節點參數也必須完整匹配。VMess 的使用者識別碼、連接埠、傳輸方式與 TLS 設定必須與伺服器端一致；VLESS 還可能涉及 Reality、流量控制與伺服器名稱。參數不匹配通常會導致連線失敗，但某些傳輸層反覆重試時，也可能表現為網頁長時間等待與速度極低。不要為了提升速度而任意修改訂閱下發的協定欄位。
錯誤:context deadline exceeded
原因與解法:連線或請求未能在限定時間內完成——先切換至同地區的其他節點，再檢查目前線路是否有高丟包率。
錯誤:dial tcp: i/o timeout
原因與解法:連往伺服器位址與連接埠的 TCP 連線逾時——核對節點連接埠，換用另一個網路重新測試，以區分節點無法連線與本機線路問題。
錯誤:connection reset by peer
原因與解法:連線遭遠端或中間設備重設——更新訂閱並重新連線；如果多個節點同時出現此問題，請繼續檢查接入線路。
第二層：檢查接入網路與中間線路
多個節點同時變慢時，先不要修改用戶端的進階參數。將同一台裝置從無線網路切換至有線網路，或改用另一條可用的接入網路測試。如果節點設定完全不變而速度立即恢復，問題就在用戶端之前的本機接入或電信業者線路，而不是訂閱內容。
無線網路常見的影響包括訊號衰減、同頻干擾與上傳壅塞。即使測速頁面顯示下載頻寬充足，只要上傳頻寬被雲端同步占滿，TCP 確認封包與代理握手也會延遲。測試時讓裝置靠近存取點，優先使用 5 GHz 頻段，並暫停其他裝置的大量上傳工作。
ping -n 50 1.1.1.1
pathping 1.1.1.1
powershell Test-NetConnection 1.1.1.1 -Port 443這些命令只能協助觀察本機到公共目標的基礎連線能力，不能取代節點測速。在 Windows 中，若 50 次探測的丟包率為 0%，且大多數延遲落在 10 至 30 毫秒，表示本機接入通常穩定；若丟包率達到 3% 以上，或延遲頻繁從 20 毫秒跳至 300 毫秒，應先處理無線干擾、路由器負載或接入線路問題。
- 固定時段變慢：連續三天在 20:00 至 23:00 重新測試，白天正常而晚間下降，通常表示尖峰壅塞。
- 更換網路立即恢復：節點與用戶端設定未變，接入線路應列為優先排查對象。
- 第一個閘道就出現波動：重點檢查無線訊號、網路線、路由器負載與背景上傳工作。
- 基礎網路穩定但節點逾時：繼續比較不同地區與不同伺服器連接埠，不要反覆重新安裝用戶端。
注意：不要把單次命令結果直接視為線路結論。至少在速度正常與異常時各儲存一組資料，並確保兩次使用相同網路、相同裝置與相同測試目標。
第三層：複核系統代理、TUN 與路由分流
節點與接入線路都正常後，再檢查本機設定。第一步是確認目標應用程式確實經過代理。v2rayN 常見的本機 SOCKS 連接埠為 10808、HTTP 連接埠為 10809；實際連接埠應以「設定」→「參數設定」中的目前值為準。瀏覽器使用系統代理時通常會走 HTTP 連接埠；手動設定 SOCKS 的應用程式則要填寫對應的 SOCKS 連接埠。
如果應用程式設定了舊連接埠，連線可能會直接失敗；如果系統中有其他程式占用相同連接埠，核心可能啟動失敗或反覆重試。開啟 v2rayN 日誌，先確認入站監聽成功，再檢查是否出現目標請求。Android 端使用 v2rayNG 或 v2flyNG 時，可先停止連線，再重新啟動一次，以清除舊的虛擬網路工作階段。
錯誤:bind: Only one usage of each socket address is normally permitted
原因與解法:本機監聽連接埠已被占用——關閉占用 10808 或 10809 的程式，或在「設定」→「參數設定」中更換連接埠後重新啟動核心。
錯誤:failed to find an available destination
原因與解法:出口伺服器位址解析失敗——檢查節點位址是否完整，切換 DNS 設定後重新啟動核心並重新連線。
錯誤:no such host
原因與解法:節點網域或目標網域解析失敗——確認系統時間與 DNS 可用性，再更新訂閱以排除舊位址。
路由分流也可能造成「只有部分網站變慢」。規則通常依據網域、IP、程序或入站標籤，將流量交給直連、代理或阻斷出口。如果目標網域誤走直連，應用程式可能不斷等待；如果本機服務誤走代理，則會增加不必要的繞行。暫時切換至全域代理進行對照，能快速判斷是否為規則匹配問題；測試完成後應恢復原本的分流方案。
- 在系統代理模式下測試一次，記錄網頁首次開啟時間與持續速度。
- 關閉系統代理，再單獨啟用 TUN 模式測試，避免兩種接管方式同時干擾判斷。
- 將路由模式暫時改為全域代理；如果特定網站明顯恢復，請檢查該網域命中的規則。
- 恢復原本的路由模式，調整衝突規則的順序，重新連線後再測試。
- 檢查日誌中的入站、路由命中與出口標籤，確認請求確實經過預期路徑。
TUN 模式會接管更多不讀取系統代理設定的應用程式，但也增加虛擬網卡、DNS 與路由表三個檢查點。只有瀏覽器正常、遊戲或命令列工具變慢時，才可用 TUN 作為對照；系統代理已涵蓋目標應用程式時，不必只為測速而強行啟用 TUN。
協定、DNS 與裝置資源如何影響速度
VMess 或 VLESS 只是代理連線的一部分，實際表現還會受到傳輸層、TLS、伺服器入口與線路品質影響。不能只憑協定名稱判斷速度。在相同伺服器、相同線路與相近參數下，不同協定的差距可能很小；一旦傳輸參數錯誤，連線重試與額外握手才會明顯拖慢存取。
DNS 問題通常表現為網頁首次開啟需要等待較久，但建立連線後下載速度正常。可以先觀察日誌中的網域解析是否反覆逾時，再檢查系統 DNS、用戶端 DNS 與路由規則是否互相衝突。修改 DNS 後要重新啟動核心並重新連線，否則舊快取可能繼續影響結果。
| 症狀 | 優先檢查 | 對照操作 |
|---|---|---|
| 首次開啟慢，下載後穩定 | DNS 解析與握手 | 更換 DNS 後重新啟動核心 |
| 所有流量持續偏慢 | 節點負載與線路頻寬 | 更換伺服器位址不同的節點 |
| 速度週期性歸零 | 丟包、無線干擾、裝置負載 | 改用有線網路並暫停上傳 |
| 只有特定應用程式變慢 | 代理來源與路由命中 | 比較系統代理與 TUN 模式 |
| 連線後 CPU 長時間接近 100% | 裝置資源與並行工作 | 關閉並行下載後重新測試 |
結論：依症狀選擇檢查層，不要同時修改協定與路由
首次開啟慢，優先檢查解析；持續變慢，優先檢查節點與線路；只有部分應用程式變慢，則先確認流量入口。每輪只修改一項設定，保留前後資料，才能確認調整是否真正有效。
裝置資源也要納入基準。開啟系統工作管理員，觀察測試期間的 CPU、記憶體與磁碟使用量。如果代理核心的單一程序長時間接近 100%，同時還有解壓縮、同步或安全掃描工作，先暫停其他高負載工作再測試。區域網路內的另一台裝置若能使用同一節點達到 40 Mbps，而目前裝置只有 8 Mbps，則本機資源或網路介面卡的優先級明顯高於節點因素。
常見速度問題的直接處理方法
延遲只有 60 毫秒，為什麼下載仍然很慢？
延遲不等於頻寬。對同一個節點至少進行 3 輪、每輪 60 秒的持續傳輸測試；如果始終低於其他節點，優先更換節點，不要只按照延遲數字排序。
白天正常，晚上固定變慢怎麼辦？
在 20:00 至 23:00 記錄三天資料，並使用另一條接入網路測試同一節點作為對照。更換網路後恢復，表示接入或中間線路壅塞；所有網路都變慢，再考慮節點在尖峰時段負載過高。
瀏覽器快，終端機和遊戲慢是什麼原因？
瀏覽器可能讀取了系統代理，但終端機和遊戲沒有。先確認應用程式是否支援 HTTP 或 SOCKS 代理；不讀取系統代理的應用程式，可以單獨使用 TUN 模式測試。
更新訂閱後速度突然下降，需要重新安裝嗎？
先比較更新前後的節點位址、連接埠、協定與傳輸方式，再切換同一群組的其他節點。重新安裝無法修復節點負載或線路壅塞，進行設定對照更有效。
全域代理快，路由模式慢，該如何處理？
檢查目標網域命中的直連規則與 DNS 群組。調整衝突規則順序後重新連線，再確認日誌中的出口標籤已從直連切換至預期的代理出口。
完整排查順序可以濃縮成一句話：先用三個節點進行受控對照，再用另一條網路排除接入線路，最後檢查連接埠、代理模式、DNS 與路由命中。只有前兩層的資料穩定後，修改進階參數才有意義。
處理完成後保留一份正常狀態記錄，包括用戶端與核心版本、節點地區、實際連線延遲、三輪吞吐量、代理模式與測試時間。下次速度下降時直接套用這組基準，通常可在十分鐘內判斷問題屬於節點、線路或本機設定。