同一個節點可能顯示 ping 38 ms、實際連線延遲 112 ms，下載速度卻達到 92 Mbps；另一個節點 ping 為 80 ms，網頁開啟速度反而更快。這不是測試失效，而是三項指標觀察了不同鏈路。只有先確認測試傳送了什麼流量、經過哪些協定階段，數值才具備比較意義。
本文適合需要在 v2rayN、v2rayNG 或 v2flyNG 中篩選節點的使用者。核心結論是：ping 用於檢查基礎網路，實際連線延遲用於判斷互動回應，下載測速用於評估持續吞吐量；選擇日常節點時優先查看實際連線延遲與穩定性，再用下載測速確認頻寬。
三種測試實際測量了什麼
ICMP ping 會向目標位址傳送回應請求，再記錄回應返回所需的往返時間。它通常只經過本機網路、電信業者線路與目標主機，不會執行 VMess 或 VLESS 驗證，也不會建立 WebSocket、gRPC、TLS 或 REALITY 工作階段。伺服器可能限制 ICMP 回應，因此 ping 逾時不能直接推論代理連接埠無法使用。
實際連線延遲會透過用戶端目前的出站設定發起一次實際請求。測試過程至少包含與伺服器連接埠建立 TCP 連線；使用 TLS 時還要進行安全握手，使用 VMess、VLESS 等協定時也涉及代理工作階段建立。部分用戶端會繼續請求指定的 HTTP 測試位址，並以成功收到回應標頭或第一批資料所需的時間作為結果。
下載測速則會維持連線並傳輸一段足夠大的資料。它測量單位時間內可傳送多少位元組，結果主要受線路頻寬、伺服器出口、壅塞控制、並行連線數與測試檔案大小影響。一個節點可能首次回應時間較長，但建立連線後仍能維持較高吞吐量。
ICMP ping
測量網路層的往返時間，不驗證代理連接埠、協定驗證與傳輸設定。
適合：檢查基礎可達性、觀察封包遺失與線路抖動
實際連線延遲
推薦經過代理握手與實際請求，更接近開啟網頁和呼叫介面時的等待時間。
適合：篩選日常主力節點、比較互動回應
下載測速
持續傳輸資料並計算吞吐量，重點反映頻寬，不等同於回應速度。
適合：大檔案傳輸、影片緩衝與持續下載
- 查看線路是否暢通：使用 ping，同時記錄平均值、最大值與封包遺失率。
- 查看網頁回應是否快速：使用實際連線延遲，並連續測試至少 3 次。
- 查看持續傳輸能力：使用下載測速，測試時間不應短於 10 秒。
為什麼三個結果經常互相矛盾
第一類原因是目標不同。ping 測到的位址可能是伺服器 IP，實際連線測試造訪的卻是外部 HTTP 網站，下載測速又連線到另一台測速伺服器。後兩項除了經過代理伺服器，還包含代理伺服器到測試目標的出口鏈路。三個目標不一致時，數值不能放在同一欄直接排序。
第二類原因是協定開銷不同。ICMP 封包很小，不包含應用層握手。VLESS 搭配 TCP 與 REALITY、VMess 搭配 WebSocket 與 TLS，都會執行不同數量的往返流程。實體線路往返時間為 60 ms 時，多一次串行握手就可能增加接近一個往返時間；DNS 查詢未命中快取時，還會增加解析等待時間。
第三類原因是網路會對不同流量採取不同策略。部分主機優先處理正常業務連線，卻限制 ICMP；也可能出現 ICMP 很快，但代理連接埠所在路徑壅塞的情況。無線網路中的瞬間干擾還會造成重傳，使一次實際連線測試從 90 ms 跳到 300 ms，下一次又恢復正常。
| 現象 | 較可能的原因 | 下一步檢查 |
|---|---|---|
| ping 低，實際連線延遲高 | TLS 或代理握手耗時、伺服器負載、出口繞行 | 連續測試 5 次，並查看核心日誌中的連線錯誤 |
| ping 逾時，代理仍可正常使用 | 伺服器限制 ICMP 回應 | 改用 TCP 連接埠測試與實際連線測試 |
| 實際連線快，下載速度低 | 出口頻寬有限、晚間尖峰壅塞、單一連線受限 | 在不同時段執行超過 15 秒的下載測試 |
| 下載快，網頁首次開啟慢 | DNS、握手或第一個位元組等待時間較長 | 檢查 DNS 路由與實際連線延遲 |
結論：先依測試路徑拆解矛盾數值
不要用 38 ms 的 ICMP 結果取代 112 ms 的實際連線結果。前者表示基礎線路較短，後者才包含實際代理握手；需要改善網頁回應時，應繼續檢查協定、DNS、伺服器負載與出口路由。
建立可重複的延遲測試方法
比較節點時必須控制變因。更新訂閱後，同一地區可能同時出現不同伺服器、不同傳輸協定與不同入口連接埠。若一邊測試 VLESS over TCP，另一邊測試 VMess over WebSocket，結果同時包含線路與協定差異，無法判斷真正的瓶頸。
- 固定本地環境。關閉佔用頻寬的下載工作，優先使用有線網路；只能使用無線網路時，保持裝置位置與頻段不變。
- 固定測試目標。同一輪實際連線測試使用同一個 HTTP 目標，下載測速使用同一個檔案與相同的持續時間。
- 執行多輪取樣。每個節點至少測試 5 次，捨棄第一次可能受 DNS 與連線預熱影響的結果，再觀察中位數。
- 記錄抖動與失敗。不要只記錄最低值。112、118、109、460、115 ms 表示存在一次明顯尖峰，穩定性弱於始終維持在 130 至 145 ms 的節點。
- 分時段重新測試。中午與晚間各測一輪。跨區域線路在晚間尖峰可能出現頻寬下降，單次上午結果不能代表全天。
Windows 可以使用 ping -n 20 伺服器位址 收集 20 次 ICMP 結果；macOS 與 Linux 可使用 ping -c 20 伺服器位址。記錄平均往返時間與封包遺失率即可，不要把命令列 ping 當成代理協定測試。
節點 A
ICMP：38 / 40 / 39 / 41 / 38 ms
實際連線：112 / 118 / 109 / 121 / 115 ms
15 秒下載：89 / 92 / 90 Mbps
節點 B
ICMP：61 / 63 / 60 / 62 / 61 ms
實際連線：84 / 87 / 86 / 85 / 89 ms
15 秒下載：54 / 57 / 55 Mbps在這組受控記錄中，節點 A 更適合持續下載，節點 B 更適合網頁瀏覽、終端機連線與頻繁短請求。若只按 ping 排序，會選中 A；若只按下載速度排序，也會選中 A；但對互動操作而言，B 的實際連線延遲低約 27 ms，判斷會完全不同。
在 v2rayN、v2rayNG 與 v2flyNG 中如何測試
用戶端選單名稱會隨版本調整，但測試入口的功能可以依流量類型辨認。v2rayN 7.x 中，可先在伺服器清單選取設定，再使用「伺服器」→「測試伺服器實際連線延遲」。此操作會呼叫目前設定建立實際連線，不等同於清單中的基礎 ping 或 TCP 探測。
Android 上的 v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心。更新訂閱並選取節點後，可從右上角選單進入延遲測試；批次測試時，應確認執行的是「實際連線」類測試，而不是只檢查伺服器連接埠。測試前先連線一次，讓本地 VPN 接管、DNS 與路由規則處於與日常使用相同的狀態。
若透過本地代理手動測試，先在 v2rayN 的「設定」→「參數設定」中確認本地監聽連接埠。常見混合代理連接埠為 10808，但使用者修改後應以目前設定為準。測試工具必須明確使用該代理連接埠，否則請求可能直接連線至目標，取得的並不是節點實際連線結果。
- 更新訂閱後先檢查節點位址、連接埠、協定與傳輸方式是否發生變化。
- 批次測試期間不要切換系統代理、TUN 模式或無線網路。
- 結果全部為負值、逾時或固定為同一數值時，先檢查測試位址是否可存取。
- 日誌出現連線遭拒時，優先檢查伺服器連接埠，不要繼續用下載測速判斷。
如何用指標選擇節點與協定
日常瀏覽與即時請求優先選擇實際連線延遲較低、連續測試波動較小的節點。兩條線路分別為 95 ms 和 110 ms 時，15 ms 的差距通常不如穩定性重要；若前者每五次出現一次 500 ms 尖峰，後者始終處於 105 至 120 ms，後者更適合作為主力。
下載、影片緩衝與大檔案同步更依賴持續吞吐量。此時應比較 10 至 30 秒區間的平均速度，並觀察中途是否降速。開始瞬間顯示 150 Mbps、隨後穩定在 35 Mbps 的節點，其有效能力接近 35 Mbps，而不是峰值數字。
- VMess
- 包含驗證與加密處理，常與 TCP、WebSocket、TLS 等傳輸方式組合。延遲取決於完整組合，不應只歸因於協定名稱。
- VLESS
- 輕量驗證協定，常與 TLS、REALITY、TCP 或 gRPC 組合。握手次數、伺服器距離與出口品質共同影響實際連線延遲。
- TUN
- 透過虛擬網路介面卡接管流量。啟用後，測試請求還會經過系統路由與 DNS 設定，結果更接近日常全域接管環境。
- 路由分流
- 依網域、IP 或程序決定直連與代理出口。測速目標被直連時，用戶端顯示的資料不能代表代理節點。
比較 VMess 與 VLESS 時，應盡量選擇同一台伺服器、同一個入口網路與相近的傳輸條件。若 VLESS 節點位於鄰近區域，而 VMess 節點跨越更遠線路，延遲差異主要來自實體距離。協定選擇應結合伺服器支援、傳輸安全方案與用戶端相容性，而不是依據一次最低延遲。
結論：主力節點看中位數，備用節點看路徑差異
主力節點選擇 5 次實際連線測試的中位數，並排除頻繁逾時；備用節點應優先選擇不同伺服器或不同出口路徑，避免兩組設定在同一個壅塞點同時失效。
延遲測試常見問題
測試結果異常時，先區分「測試沒有經過代理」與「代理經過了不同路徑」。前者通常與本地連接埠、系統代理或分流規則有關；後者則需要結合 DNS、伺服器出口與測試目標判斷。以下問題涵蓋最常見的操作誤區。
ping 全部逾時，節點為什麼仍能連線？
目標伺服器可能沒有回應 ICMP。改用用戶端的實際連線測試，並檢查代理連接埠是否能建立 TCP 連線；不要只憑 ping 逾時就刪除訂閱節點。
實際連線延遲第一次總是特別高？
首次測試可能包含 DNS 查詢、TLS 工作階段建立與連線預熱。連續執行 5 次，記錄後 4 次的中位數，同時保留第一次結果以判斷冷啟動體驗。
延遲只有 1 ms，結果可信嗎？
公網遠端節點通常不應長期顯示 1 ms。檢查測速請求是否被路由規則設為直連，或測試目標是否指向本機。查看連線日誌，確認請求進入所選代理出站。
下載速度高，為什麼開啟網頁仍然很慢？
高吞吐量無法抵消 DNS、協定握手與第一個位元組等待時間。先測試實際連線延遲，再檢查 DNS 設定與路由分流；短請求較多的情境優先選擇波動較小的節點。
批次測試中延遲最低的節點就是最佳節點嗎？
不是。至少重新測試 5 輪，並結合逾時率、晚間尖峰表現與下載吞吐量。最低值只代表一次樣本，中位數與波動範圍更適合長期選擇。
最後可以將三項指標放回各自用途：ICMP ping 檢查基礎線路，實際連線延遲判斷完整代理路徑的回應，下載測速評估持續傳輸能力。測試目標、路由模式與本地網路保持一致後，三個數值不再互相否定，而是共同描述一條節點鏈路。