延遲測試怎麼看：ping、實際連線延遲與下載測速的差異與用法

三種測試測量的不是同一段網路

節點清單裡同時出現 40 ms、120 ms 和 80 Mbit/s 並不矛盾，因為三個數字對應不同任務。ping 通常會向伺服器位址傳送 ICMP 封包，記錄往返時間；實際連線延遲會讓客戶端透過 VMess、VLESS 等節點建立代理連線，再存取測試目標；下載測速則持續傳輸一段資料，觀察可用吞吐量。

ICMP ping 的測量範圍最小。它可以說明本地網路到目標位址的基本往返時間與封包遺失情況，卻不會驗證節點連接埠是否開放，也不會執行 TLS、WebSocket、gRPC、Reality 或代理協定握手。即使位址的 ping 是 38 ms，連線 TCP 443、完成 TLS 協商並建立 VLESS 通道後，第一個網頁請求仍可能超過 150 ms。

實際連線延遲更接近日常開啟網頁的等待時間。v2rayN 這類客戶端通常會啟動本地代理，透過指定節點請求測試位址，並統計建立連線及取得回應所需的時間。結果可能包含本地 SOCKS 入站、核心處理、代理協定握手、伺服器端出站、目標網站回應和部分網域解析時間，因此比 ping 更能反映節點是否真正可用。

為什麼 ping 很低，網頁仍然開得很慢

最常見的原因是 ping 跳過了代理建立流程。假設伺服器位址的 ICMP 往返為 45 ms，TCP 建立連線至少還需要一次往返；如果使用 TLS，還要增加協商流程；WebSocket 需要完成 HTTP 升級；代理核心之後才會向目標網站建立出站連線。每個步驟都可能增加等待時間。

第二個原因是 ping 的目標與網頁目標不同。ping 測量的是客戶端到節點入口，開啟網頁還包含節點到目標網站的線路。某個節點距離本地很近，但其伺服器端到目標網站需要繞路，實際連線延遲仍可能偏高。相反地，入口 ping 稍高的節點如果伺服器端出口穩定，網頁載入和下載可能更順暢。

第三個原因是 ICMP 的處理策略與 TCP、UDP 流量策略並不一致。伺服器可能限制 ICMP 回應頻率，也可能完全不回應，但 443 或其他節點連接埠仍能正常運作。因此 ping 逾時只能表示這次 ICMP 測試沒有收到回應，不能單獨判定 VMess 或 VLESS 設定失效。

• VMess 與 VLESS 的協定名稱不能直接決定延遲，伺服器位置、傳輸層、壅塞情況和出口路由通常更關鍵。
• WebSocket、gRPC 與一般 TCP 的握手流程不同，不應只用一次測試結果替傳輸方式排序。
• 啟用路由分流後，要確認測試位址確實經過目前節點，否則測到的可能是直連結果。

實際連線延遲與下載速度應該怎麼一起看

實際連線延遲回答的是「多久開始收到回應」，下載測速回答的是「建立連線後每秒能傳輸多少資料」。瀏覽簡單網頁、API 請求和即時互動更在意前者；下載大型檔案、載入高位元率內容則更依賴後者。一個節點可以在 110 ms 內完成請求，但持續下載只有 3 MiB/s；另一個節點第一個封包需要 180 ms，卻能穩定達到 12 MiB/s。

以下是一組在同一台電腦、同一條有線網路、同一個測試檔案下的範例記錄。測試前關閉其他下載工作，v2rayN 本地 SOCKS 連接埠為 10808、HTTP 連接埠為 10809；實際連線延遲連續執行 3 次並取中位數，下載部分則在連線穩定後記錄 30 秒平均值。

這組資料中，代理下載達到直連基準約九成，表示頻寬利用情況良好；實際連線延遲比 ping 多出 67 ms，屬於代理握手與節點到測試目標線路共同造成的差值。這裡不能把 67 ms 全部歸因於某一種協定，因為目標網站回應、網域解析快取和連線重複使用狀態都會影響結果。

換算單位時也要保持一致。客戶端或瀏覽器常用 MiB/s 顯示下載速度，網路頻寬則常用 Mbit/s；粗略換算需要乘以 8，但 MiB 與 MB 的定義仍有差異。11.5 MiB/s 約等於 96.5 Mbit/s，不能把 11.5 直接與「100 Mbit/s」比較。

推薦測試順序：先排除環境，再篩選節點

正確順序比反覆點擊測速更重要。測試期間如果訂閱正在更新、瀏覽器正在下載、系統代理模式不斷切換，得到的數字就沒有可比性。桌面端可以先開啟 v2rayN，在「設定」→「參數設定」中確認本地監聽連接埠，再檢查目前的系統代理模式和路由模式。

1. 建立直連基準。暫時停止代理工作，使用同一條網路記錄目標檔案的直連速度和一般網頁回應。如果直連本身持續波動，應先處理本地網路。
2. 核對訂閱設定。更新訂閱後確認節點位址、連接埠、VMess 或 VLESS 協定、傳輸方式與 TLS 參數都已完整載入。
3. 執行 ping 粗略篩選。查看是否存在明顯高延遲或連續封包遺失。單一節點不回應 ICMP 時先保留，繼續進行實際連線測試。
4. 執行實際連線測試。在 v2rayN 中選取候選伺服器，透過右鍵選單執行「測試伺服器實際連線延遲」。每個節點測試 3 次，捨棄第一次快取狀態不一致的結果，再比較後兩次或取三次的中位數。
5. 手動開啟目標網頁。切換到候選節點後重新建立連線，造訪實際要使用的網站，確認路由規則沒有讓測試流量直連。
6. 最後測試下載。使用同一個 HTTPS 檔案、相同持續時間和單一連線條件，對 2 至 3 個候選節點比較吞吐量。
7. 增加不同時段的複測。白天與晚間各記錄一輪。若晚間速度從 10 MiB/s 降到 2 MiB/s，而本地直連穩定，節點負載或跨網路線更值得關注。

測試路由分流時還要注意舊連線。修改規則後，瀏覽器可能繼續重複使用已建立的連線，導致新規則沒有立即反映在結果中。關閉對應頁面、等待連線釋放後再測；必要時重新啟動客戶端核心，並從記錄確認目標網域命中了代理出站還是直連出站。

常見誤判與排查解答

延遲清單適合縮小範圍，不適合直接取代實際使用。一次測試可能遇到網域解析快取、伺服器端短暫繁忙或測速目標限流。可靠判斷至少需要相同環境、重複測試和實際目標驗證這三項條件。

最終選擇可以依任務拆分：網頁與遠端互動優先選擇實際連線延遲穩定、連續測試離散程度小的節點；大型檔案任務優先選擇持續速度接近直連基準的節點；兩項都不穩定時，先排查本地網路和分流規則，再判斷訂閱節點本身。