本文適合需要比較 V2Ray 節點品質的使用者，拆解 ICMP ping、實際連線延遲與下載測速的測試路徑，並提供遊戲、網頁、影片與大型檔案情境下的選擇方法。讀完即可判斷低延遲數字是否真的代表連線更快，也能依固定順序重新測試異常節點。
三個數字測量的不是同一段連線
節點清單中同時出現 35 ms、118 ms 和 76 Mbps，並不代表結果矛盾。毫秒表示一次往返或請求所需的時間，Mbps 表示單位時間內傳輸的資料量。前兩者關注等待時間，後者關注持續吞吐量，單位與用途都不同。
ICMP ping 通常由系統直接向伺服器位址傳送回應請求。封包抵達伺服器網路介面並收到回覆後，測試就結束了。它能反映本地網路到伺服器位址的基礎往返時間與封包遺失情況，但通常不會經過 VMess、VLESS、傳輸層封裝、TLS 交握，以及透過代理出口存取內容。
ICMP ping
測量本機到伺服器位址的基礎網路往返時間。執行速度快，適合初步篩選地理距離、路由繞行與明顯封包遺失。
適合：批次排除高延遲或沒有回應的位址
實際連線延遲
推薦透過用戶端核心、節點協定與代理出口請求測試目標，更接近日常開啟網頁時的等待過程。
適合：選擇日常互動與網頁瀏覽節點
下載測速
在一段時間內持續傳輸資料，依據總位元組數與耗時計算吞吐量，結果通常以 Mbps 或 MB/s 顯示。
適合：影片播放、大型檔案下載與持續傳輸
實際連線延遲涵蓋的連線路徑比 ping 更長。以 v2rayN 搭配 Xray 核心為例，請求會經過本地代理入口、節點協定交握、TCP 或其他傳輸連線、可選的 TLS 協商，再由伺服器出口存取測試位址。測試目標的回應速度、DNS 解析與出口線路都會反映在結果中。
下載測速會進一步測量持續傳輸能力。結果不只取決於往返時間，也會受到伺服器限速、出口頻寬、本地寬頻、跨網壅塞、TCP 壅塞控制與測試檔案來源影響。一個節點可能有 160 ms 延遲，卻能維持 100 Mbps 吞吐量；也可能只有 45 ms 延遲，但持續下載時只能達到 8 Mbps。
結論：日常選節點先看實際連線延遲
需要快速開啟網頁或頻繁發出短請求時，優先選擇實際連線延遲穩定且失敗率低的節點。只有在影片與大型檔案情境下，才應將持續下載速度放在更高優先順序。
為什麼 ping 很低，實際連線延遲卻很高
最常見的原因是兩項測試的終點不同。ping 在伺服器位址回應 ICMP 後就結束，實際連線測試還要從伺服器存取外部目標。伺服器入口線路良好，不代表伺服器出口到測試目標的路徑同樣順暢。
協定交握也會增加固定開銷。TCP 建立連線通常需要一次往返，TLS 首次協商還會繼續交換資料。若節點使用 WebSocket 和 TLS，實際連線測試需要完成的步驟會比單純 ICMP 回應更多。VLESS、VMess 本身的處理時間通常不是主要瓶頸，跨區域往返、TLS 與出口壅塞更容易拉開差距。
以上資料來自同一網路環境下的一組說明性紀錄：Windows 11 24H2、v2rayN 7.12.5、Xray-core 25.6.8，本地混合代理連接埠為 10808。78 Mbps 約等於 9.75 MB/s，但瀏覽器或下載工具顯示的實際數值還會受到取樣週期與協定開銷差異影響。這組數字用於說明單位關係，不代表節點效能基準。
| 現象 | 常見原因 | 複查方式 |
|---|---|---|
| ping 低，實際連線高 | 出口繞行、TLS 交握緩慢、測試目標回應速度慢 | 更換測試目標，連續執行 3 輪實際連線測試 |
| ping 高，下載仍快 | 距離較遠但線路穩定、可用頻寬充足 | 觀察超過 30 秒的持續下載速度與波動 |
| ping 沒有回應，代理仍可用 | 伺服器或上游網路未回應 ICMP | 改用實際連線測試，不要因逾時就直接刪除節點 |
| 實際連線低，網頁仍然很慢 | 本地路由分流、DNS 或目標網站個別壅塞 | 檢查系統代理、路由規則與核心記錄 |
如何完成一輪可比較的節點測試
可比性比單次數字更重要。不要在清晨測試一個節點，再拿結果與晚間尖峰時段的另一個節點比較。測試時應固定裝置、連線網路、用戶端版本、核心、測試目標與時段，並暫停會佔用頻寬的同步或下載工作。
在 v2rayN 7.x 中，可以先選取要比較的節點，再使用「伺服器」→「測試伺服器實際連線延遲」。若要查看基礎網路狀態，可使用「伺服器」→「測試伺服器延遲」。不同小版本的選單文字可能略有調整，但應區分「延遲」與「實際連線延遲」，不要將兩欄結果視為同一項指標。
- 先在「設定」→「參數設定」中確認本地監聽連接埠沒有衝突，並記錄目前使用的核心類型。
- 選擇 3 至 5 個候選節點，連續執行 3 輪實際連線延遲測試，每輪間隔約 10 秒。
- 忽略第一次可能受到 DNS 快取尚未建立與 TLS 首次協商影響的異常尖峰，記錄後兩輪的中位數。
- 選出連線中位數較低的兩個節點，分別持續下載同一個測試檔案 30 至 60 秒。
- 在晚間尖峰時段再測試一次。如果延遲與速度都明顯惡化，應將時段壅塞納入判斷。
推薦方案：分開測量互動延遲與持續吞吐量
網頁與即時請求
- 主要查看實際連線延遲中位數
- 記錄逾時次數與結果波動
- 對照相同協定與相同傳輸方式
影片與大型檔案
- 持續測速至少 30 秒
- 同時觀察最低速度與平均速度
- 在實際使用時段重新測試
先用實際連線延遲縮小候選範圍，再用持續下載決定最終節點，可以減少短時間測速偶然值造成的誤判。
測試期間也要固定路由模式。若瀏覽器下載位址被規則判定為直連，測到的會是本地寬頻速度，而不是節點吞吐量。可以在 v2rayN 的核心記錄中確認請求是否命中代理出站，也可以暫時使用全域代理模式進行對照，完成後再恢復原有分流設定。
平均值、抖動與封包遺失應如何一起判讀
只看最低值，容易選到偶然表現很快的節點。一次 48 ms 不代表後續請求都能維持 48 ms。如果連續結果是 48、51、236、55、420 ms，平均值會被尖峰拉高，而中位數仍接近 55 ms。此時中位數描述一般狀態，最大值與離散程度則反映卡頓風險。
互動應用程式對抖動相當敏感。網頁載入由多次連線與請求組成，延遲偶爾跳到數百毫秒，就會表現為某些資源遲遲無法載入。影片緩衝可以吸收部分抖動，因此更依賴持續吞吐量；即時語音與遠端操作則更重視穩定延遲與封包遺失。
- 中位數：將多次結果排序後取中間值，適合表示節點在目前時段的典型延遲。
- 抖動：觀察相鄰結果的變化。多數結果相差不超過 15 ms，通常比在 40 至 300 ms 之間反覆跳動更穩定。
- 封包遺失：10 次 ping 中遺失 1 次就是 10% 封包遺失。即使平均延遲較低，明顯的封包遺失也會觸發重傳並降低實際速度。
- 逾時率：實際連線測試連續出現逾時，表示完整代理連線路徑存在失敗，參考價值高於單次成功時的最低值。
結論：記錄中位數與失敗次數
每個候選節點至少測試 3 輪。若兩個節點的中位數只差 10 ms，但其中一個出現 2 次逾時，應優先選擇沒有逾時且波動較小的節點。
ICMP 封包遺失也不能直接等同於代理資料封包遺失。部分網路會限制 ICMP 回應的優先順序，但 TCP 流量仍可正常傳輸。遇到 ping 遺失封包而實際連線穩定時，應繼續觀察下載與實際存取狀況，不要只根據 ICMP 單項結果下結論。
不同使用情境應優先看哪個數值
網頁瀏覽、搜尋與 API 請求由大量短連線或短交易組成，等待時間占比很高。實際連線延遲從 300 ms 降到 100 ms，通常比下載速度從 80 Mbps 增加到 100 Mbps 更容易感受到。這類情境應先排除逾時節點，再比較實際連線延遲中位數。
高畫質影片與大型檔案傳輸更依賴穩定吞吐量。只要延遲沒有高到頻繁觸發逾時，180 ms、80 Mbps 的節點可能比 60 ms、12 Mbps 的節點更適合持續下載。換算時要注意，8 Mbps 理論上約等於 1 MB/s，80 Mbps 理論上約等於 10 MB/s，實際速度會因協定開銷而略低。
- 一般網頁：優先看實際連線延遲，其次觀察波動與逾時率。
- 遠端終端機：優先考量穩定延遲，持續頻寬需求通常較低。
- 影片播放：優先看持續下載速度，同時觀察晚間尖峰時段的最低速度。
- 大型檔案傳輸：優先看平均吞吐量，測試時間應延長至 60 秒以上。
- 訂閱批次初篩：先用 ping 快速排查，再對候選節點執行實際連線測試。
節點協定也要維持可比性。一個 VLESS 節點與一個 VMess 節點可能位於不同地區，使用不同的傳輸方式與出口，數字差異不能簡單歸因於協定名稱。協定負責連線格式與功能，實際延遲仍主要受到實體距離、電信商路由、壅塞與伺服器負載影響。
v2rayNG 的測試結果同樣會受到 Android 裝置目前網路狀況影響。無線網路訊號變化、行動網路切換與背景下載都會改變結果。桌面版 v2rayN 與 Android 版 v2rayNG 即使使用同一份訂閱，也應分別測試，不要將一台裝置上的毫秒數直接套用到另一台裝置。
常見延遲測試問題
ping 顯示逾時，節點是不是已經失效？
不一定。先在 v2rayN 中執行「伺服器」→「測試伺服器實際連線延遲」。如果實際連線有結果，且實際網頁可以開啟，通常只是伺服器或中間網路沒有回應 ICMP。
為什麼第一次實際連線測試總是比較慢？
第一次可能包含 DNS 查詢、核心啟動、TCP 首次建立連線與 TLS 首次協商。連續測試 3 輪並查看中位數，不要只保留最低值，也不要只依第一次結果排序。
延遲只有 40 ms，下載為什麼仍然只有 2 MB/s？
40 ms 只代表請求往返速度較快，2 MB/s 約等於 16 Mbps，瓶頸可能出現在伺服器限速、出口頻寬、跨網壅塞或測試來源。連線到另一個節點下載同一個檔案，才能確認瓶頸是否會隨節點改變。
測速時需要開啟系統代理嗎？
使用 v2rayN 內建的實際連線測試時，用戶端會透過對應節點執行測試。使用瀏覽器或下載工具測速時，需要確認系統代理已開啟，並從核心記錄核對測試請求確實進入代理出站。
訂閱更新後應該依哪個數字排序？
先批次執行實際連線延遲測試，刪除或停用持續逾時的設定，再從低延遲候選中進行持續下載測試。日常網頁使用依穩定的實際連線延遲選擇，大型檔案情境則依實際吞吐量選擇。
最終判斷應回到實際使用的連線路徑。ping 是快速診斷工具，實際連線延遲用於衡量完整代理請求的等待時間，下載測速用於衡量持續傳輸能力。三者分別回答「基礎網路距離有多遠」、「代理請求要等多久」與「長時間能傳輸多少資料」，沒有任何一個數字可以取代另外兩個。