本文適合面對多個 VMess、VLESS 節點，卻不知道該看哪項測速結果的使用者。核心判斷是：ping 用來觀察基礎網路路徑，真實連線延遲用來判斷一次代理請求能否快速完成，下載測速用來估算持續傳輸能力；選擇節點時應依實際用途綜合比較三項資料，而不是只挑數字最小的一欄。
三種測速測量的並不是同一段連線
測量解讀
ping、真實連線延遲與下載測速經常同時出現在節點清單中，但它們對應的是三個不同層級。ping 通常會傳送 ICMP Echo 請求，只確認本機到伺服器位址之間的網路往返時間。它不會啟動 V2Ray 或 Xray 代理工作階段，也不會驗證 VMess、VLESS 的驗證資訊、TLS 交握、傳輸路徑與代理出口。
測量解讀
真實連線延遲會讓用戶端透過指定節點發起一次實際的代理請求。以 v2rayN 7.x 常見的運作方式為例，用戶端需要啟動核心、讀取節點設定、建立 TCP 或其他傳輸連線、執行協定驗證，並存取測試位址。因此，測試成功後顯示的毫秒數，更接近開啟網頁前第一個請求的等待時間。
測量解讀
下載測速則會在建立連線後持續接收一段資料。它不只受往返延遲影響，也會受到伺服器出口頻寬、線路壅塞、TCP 壅塞控制、封包遺失重傳、本地網路及測試檔案大小影響。一個節點的真實連線延遲可能是 180 ms，但仍可跑到 150 Mbps；另一個節點的真實連線延遲只有 80 ms，卻可能因出口限速只能達到 12 Mbps。
| 測試方式 | 主要測量對象 | 是否經過代理協定 | 適合回答的問題 |
|---|---|---|---|
| ICMP ping | 本機到伺服器位址的網路往返 | 否 | 基礎路徑是否可達、抖動是否明顯 |
| 真實連線延遲 | 建立連線、交握、驗證與代理請求 | 是 | 網頁第一個請求需要等待多久 |
| 下載測速 | 建立連線後的持續吞吐量 | 是 | 大檔案與影片傳輸速度如何 |
為什麼 ping 很低，節點仍可能很慢
測量解讀
最常見的誤判，是依 ping 從小到大排序後直接選擇第一項。假設某台伺服器的 ICMP 往返時間是 24 ms，這只代表它的伺服器位址距離目前網路較近。代理請求還可能經過 TLS、WebSocket、中轉入口或不同的出口線路，實際存取目標服務時採用的路徑未必與 ICMP 完全相同。
測量解讀
部分網路會限制或降低 ICMP 請求的優先順序，也有伺服器會直接不回應 ICMP。此時 ping 顯示逾時，不代表 VMess 或 VLESS 連接埠無法連線。反過來說，ICMP 能穩定回應，也不代表訂閱中的連接埠、UUID、傳輸路徑、Server Name 或 Reality 參數正確。只有真實連線測試能涵蓋這些設定項目。
測量解讀
低 ping 也無法反映封包遺失後的速度下降。持續下載仰賴大量資料封包連續抵達，1% 到 3% 的封包遺失就可能觸發重傳與壅塞視窗縮小。短暫的 ICMP 樣本可能看起來只有 30 ms，但持續傳輸時速度會從 80 Mbps 週期性降到 15 Mbps；網頁體感則是首屏開啟很快，圖片和影片載入卻很慢。
結論：節點排序應優先參考真實連線結果
需要瀏覽網頁、使用即時通訊或頻繁建立短連線時，先排除真實連線逾時的項目，再從延遲接近的節點中比較抖動與下載速度；單獨最低的 ICMP 數值不能作為最終選擇依據。
真實連線延遲具體包含哪些耗時
測量解讀
真實連線延遲不是單一的網路往返時間，而是多個階段累積後的結果。網域節點首先要完成 DNS 解析；接著建立與伺服器連接埠的連線；使用 TLS 或 Reality 時，還要完成相應的交握；核心再執行 VMess 或 VLESS 驗證，最後透過代理出口請求測試資源。任何一段發生重試，最終數值都會明顯增加。
測量解讀
不同傳輸組合的固定開銷也不相同。VLESS 與 VMess 是代理協定，TCP、WebSocket 等屬於傳輸設定，TLS 與 Reality 則負責相應的交握與連線特徵。不能只根據協定名稱推測快慢，實際結果仍取決於伺服器負載、路徑品質、設定是否相符與測試時段。
VLESS + TCP + Reality
- 主要開銷
- TCP 與 Reality 交握
- 驗證階段
- VLESS 使用者識別驗證
- 測試重點
- 連續三次真實連線結果
- 異常訊號
- 逾時或數值跳動超過 100 ms
匯入訂閱後，應保留伺服器名稱、連接埠、Flow、Server Name、公鑰與短識別碼之間的對應關係。
VMess + WebSocket + TLS
- 主要開銷
- TCP、TLS 與 WebSocket 建立連線
- 驗證階段
- VMess 使用者資訊驗證
- 測試重點
- 首次與後續結果的差異
- 異常訊號
- 路徑錯誤或 TLS 交握失敗
網域、連接埠、Host、路徑與 TLS 參數必須互相配合，任何一項錯誤都可能表現為真實連線逾時。
測量解讀
第一次測試有時會比後續測試慢，因為首次執行可能包含 DNS 查詢、核心啟動與連線預熱。較可靠的做法，是對候選節點連續測試三次，忽略明顯的首次啟動開銷，再比較中位數。例如三次結果為 210、126、132 ms，可以把約 132 ms 視為更具代表性的結果，而不是直接記錄 210 ms。
在 v2rayN 與 Android 用戶端中如何測試
測量解讀
桌面端適合批次比較節點。匯入訂閱並更新群組後，先確認本地網路穩定，再執行真實連線測試。測速期間不要同時下載大檔案或進行系統更新，否則本地頻寬競爭會讓結果失真。若測試目標本身回應不穩定，多次結果也會一起波動。
- 在 v2rayN 7.x 主視窗中選取同一訂閱群組內的候選伺服器，可先選擇 5 至 10 個節點，避免一次測試過多造成並行干擾。
- 開啟「伺服器」選單，使用「測試伺服器真實連線延遲」。不同小版本也可能要從伺服器清單的右鍵選單找到同名測試項目。
- 等待延遲欄更新，先刪除或暫時忽略顯示逾時、連線失敗的節點，再對數值較低的三個項目重複測試兩次。
- 進入「設定」→「參數設定」，核對真實連線測試位址與逾時時間。測試位址應回傳體積很小且回應穩定的 HTTP 狀態，避免把檔案下載時間混入延遲。
- 選取候選節點並設為使用中的伺服器，開啟系統代理後，再用實際瀏覽器存取網站與執行下載任務進行最後驗證。
測量解讀
v2rayN 常見的本機 SOCKS 監聽連接埠是 10808，部分設定會讓 HTTP 入口使用 10809，實際值請以「設定」→「參數設定」中的本機監聽設定為準。連接埠只負責讓本機應用程式接入代理，並不是節點伺服器連接埠；修改本機連接埠不會降低遠端節點延遲。
測量解讀
在 Android 上，v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心。兩者都可在節點清單中執行延遲測試，但選單名稱與測試方式會隨版本調整。行動網路在 Wi-Fi 與行動數據連線之間切換時，舊連線可能失效，因此切換網路後應重新啟動目前設定再測，不要沿用切換前的數值。
- 測試前關閉其他持續佔用頻寬的工作，保持螢幕喚醒，避免系統暫停背景網路活動。
- 同一節點至少測試三次，記錄中位數；20 ms、180 ms、24 ms 這組資料表示出現過一次明顯抖動。
- 比較用戶端時，請使用相同網路、相同節點與相同時段，不能直接把家用寬頻結果和行動網路結果放在一起比較。
- 若桌面端成功而 Android 端逾時，先確認兩端訂閱是否更新至相同版本，再檢查核心記錄中的交握與 DNS 資訊。
下載測速如何換算成實際體驗
測量解讀
下載測速關注的是單位時間內傳輸了多少資料。測速工具通常以 Mbps 表示每秒兆位元，瀏覽器下載欄則常用 MB/s 表示每秒兆位元組。換算時需除以 8：80 Mbps 的理論值約為 10 MB/s，100 Mbps 的理論值約為 12.5 MB/s。協定開銷、重傳與磁碟寫入會讓實際數字略低。
測量解讀
短時間測試容易把連線預熱與瞬間突發速度誤當成長期能力。比較節點時，建議至少持續 20 至 30 秒，並同時觀察平均速度與最低速度。例如某節點前 3 秒達到 160 Mbps，之後穩定在 45 Mbps，它更接近 45 Mbps 節點；瞬間峰值不能代表長時間下載表現。
| 使用情境 | 優先指標 | 參考判斷 |
|---|---|---|
| 網頁與即時請求 | 真實連線延遲、抖動 | 連續三次中位數低，且沒有逾時 |
| 高畫質影片 | 持續下載速度、最低速度 | 觀察 30 秒曲線，不只看峰值 |
| 大檔案傳輸 | 平均吞吐量、封包遺失與穩定性 | 長時間速度不出現週期性歸零 |
| 遠端互動 | 真實連線延遲、抖動、封包遺失 | 穩定的 120 ms 通常優於反覆在 50 至 300 ms 之間跳動 |
測量解讀
還要區分節點頻寬與本地接入頻寬。如果本地寬頻上限是 100 Mbps，而多個節點都測到 92 至 95 Mbps，瓶頸很可能已經在本地線路，不能據此判定節點出口上限。若本地網路閒置時直連測速為 500 Mbps，而代理長期只有 40 Mbps，才有必要繼續排查伺服器出口、線路壅塞或節點限速。
結論：吞吐量看穩定區間，不看單次峰值
將測速時間拉長至 30 秒，並記錄後 20 秒的平均值。若平均 82 Mbps、最低 74 Mbps，比峰值 180 Mbps、後段反覆跌至 8 Mbps 的節點更適合持續下載與影片播放。
一套可重複使用的節點篩選順序
測量解讀
測速的目標不是找出某項數字最低的節點，而是建立可重複的篩選流程。先確認設定可用，再依用途縮小範圍，最後用真實任務複核。如此可避免伺服器短時間負載、測試位址波動與本地網路搶占造成誤判。
- 第一輪看可達性：執行真實連線測試，排除驗證失敗、交握失敗與持續逾時的節點。ping 逾時但真實連線成功的節點可以保留。
- 第二輪看回應：對剩餘節點連續測試三次，比較中位數與最大偏差。中位數相差不到 20 ms 時，不必只為了更低的數字而頻繁切換。
- 第三輪看吞吐量：選前三個候選節點進行 30 秒下載測試，記錄平均 Mbps、最低 Mbps，以及過程中是否出現停頓。
- 第四輪看實際任務：開啟常用網站、播放常用畫質的影片或執行實際下載，觀察至少 5 分鐘。
- 第五輪分時段複測：在工作日尖峰與離峰時段各測試一次。若某節點只在晚間明顯下降，應依使用時間決定，而不是沿用白天結果。
測量解讀
一組實用紀錄可以寫成：節點 A 真實連線中位數 96 ms、30 秒平均 62 Mbps、最低 55 Mbps；節點 B 真實連線中位數 148 ms、平均 118 Mbps、最低 103 Mbps。瀏覽網頁可優先選 A，大檔案下載可優先選 B。所謂「最快節點」取決於任務類型，不存在脫離情境的統一答案。
常見測速問題與處理方式
ping 顯示逾時，但節點可以正常連線？
測量解讀
伺服器或中間網路可能沒有回應 ICMP。請以真實連線測試與實際代理請求為準，同時檢查三次測試是否穩定，不要只因 ping 逾時就刪除節點。
真實連線延遲第一次是 500 ms，後面只有 120 ms？
測量解讀
首次結果可能包含 DNS 查詢、核心啟動與連線預熱。連續測試三次並取中位數；若每輪第一次都異常，再檢查 DNS 設定與核心記錄。
延遲只有 70 ms，下載速度為什麼不到 2 MB/s？
測量解讀
70 ms 只代表請求回應較快。請繼續檢查伺服器出口、本地頻寬、晚間壅塞與封包遺失，並執行至少 30 秒的持續下載測試。2 MB/s 約等於 16 Mbps。
同一個節點在 v2rayN 和 v2rayNG 的結果不同？
測量解讀
先確認兩端使用相同的訂閱項目、網路與測試時段。再核對測試位址、DNS、核心版本及傳輸參數；不同測試目標不能直接比較數值。
批次測速後所有節點一起變慢？
測量解讀
並行測試可能佔滿本地連線，或觸發伺服器短時間負載。將候選節點縮減至 5 至 10 個，停止其他下載工作，間隔 30 秒後分批重新測試。
測量解讀
最後只需記住一個簡單原則：ping 用來觀察基礎路徑，真實連線延遲用來確認完整代理鏈路的回應，下載測速用來衡量持續傳輸能力。三項結果彼此補充，任何一項都不能單獨概括節點品質。使用相同網路、相同測試目標、相同時段與相同持續時間，結果才具備可比性。