面向同時管理多個節點的使用者,拆解 ping 與 Tcping、真連線延遲、下載測速三種數值各自的測量對象、誤差來源與量級差異,給出「日常選節點」與「線路排障」兩類情境的判斷順序,並列出四類最常見的誤讀。讀完可以照著固定順序篩節點,不再憑感覺隨手切換。
三種數值各自在測什麼
ping 測的是本機到目標伺服器的一次 ICMP 往返時間,Tcping 測的是同一條路徑上的一次 TCP 往返時間。兩者只涵蓋「本機到伺服器」這一段鏈路,不涉及代理協議,也不判斷伺服器端有沒有正常轉發流量。
真連線延遲測的是完整鏈路:建立 TCP 連線、完成 TLS 握手、跑完 VMess 或 VLESS 的協議握手,直到收到第一個有效回應位元組。這個數值包含伺服器端處理時間,所以它比 ping 大屬於正常現象,而不是節點出了問題。
下載測速測的是吞吐量,單位是 MB/s 或 Mbps,衡量單位時間內能搬運多少資料。它和延遲不是同一個維度:一個 40 ms 的節點可能只有 3 MB/s,一個 180 ms 的節點可能跑到 20 MB/s,兩種情況都很常見。
| 數值 | 測量對象 | 涵蓋範圍 | 常見量級 | 主要誤差來源 |
|---|---|---|---|---|
| ping / Tcping | 一次網路往返 | 本機到伺服器 IP | 10~300 ms | ICMP 限速、握手佇列排隊 |
| 真連線延遲 | 握手到首位元組 | 本機到連線建立完成 | 比 ping 高 30~150 ms | 伺服器端負載、TLS 協商、協議握手 |
| 下載測速 | 單位時間吞吐量 | 整條鏈路可用頻寬 | 1~50 MB/s | 測速檔案位置、單執行緒限制、本機頻寬上限 |
ping 與 Tcping 的測量邊界
Tcping 比 ICMP ping 更貼近實際使用情境,因為代理連線本身就建立在 TCP 上。ICMP 在許多線路上被限速或降低優先權,甚至被直接丟棄,所以出現「ping 不通但節點可用」並不矛盾。
反過來也成立:ping 數值低不代表節點可用。伺服器可能只開放了 443 埠,ICMP 與其他埠全部無回應,此時 Tcping 443 有結果、ping 無結果,屬於正常設定而非故障。
- 能回答:本機到這台伺服器的鏈路往返時間、是否封包遺失、是否持續抖動。
- 能回答:伺服器對應埠是否在監聽、TCP 握手是否被中途攔截。
- 不能回答:伺服器端程式是否正常轉發、協議握手能否成功。
- 不能回答:節點的實際吞吐能力、是否被伺服器端限速。
真連線延遲
推薦涵蓋握手到首位元組的完整流程,最接近日常開啟網頁、載入 API 時的真實體感。
適合:日常選節點、判斷節點能否正常使用
ping / Tcping
只看鏈路層往返,數值乾淨、測量快,用來定位線路問題最方便。
適合:排查本機網路與伺服器之間的鏈路品質
下載測速
衡量單位時間吞吐量,反映的是頻寬而不是回應速度,測一次會消耗真實流量。
適合:大檔案下載、影音情境的頻寬篩選
真連線延遲為什麼比 ping 高一截
真連線延遲至少包含三次往返:TCP 三次握手一次,TLS 握手一到兩次(啟用 TLS 1.3 後通常一次),協議握手與首位元組一次。每一次往返都要疊加鏈路 RTT,因此鏈路本身 100 ms 時,真連線延遲落在 250~400 ms 屬於常見範圍。
判斷標準不是絕對值,而是同一批節點裡的相對排序,以及同一節點多次測量之間的波動幅度。跨地區節點之間比較絕對值意義有限,同一城市的兩台伺服器才適合直接對照。
推薦做法:兩端各用哪套測速入口
桌面端(v2rayN)
- 節點列表按右鍵 → 「測試伺服器 Tcping 延遲」
- 右鍵 → 「測試伺服器真連線延遲」
- 速度測試項目或工具列「測試速度」執行下載測速
Android 端(v2rayNG)
- 節點右側選單 → 「測試真連線延遲」
- 選單內可一次測試全部節點
- 頻寬篩選回到桌面端做,減少流量消耗
兩端測出的真連線延遲量級接近,相差 10~30 ms 屬於正常範圍,不必追求兩端數字完全一致。
下載測速的三個前提
下載測速最容易出現偏差。預設測速檔案大多在海外,如果本機寬頻只有 100 Mbps,測出來的上限就是 12.5 MB/s,再快的節點也頂不上去。測速前先用本機直連跑一次基準,才知道瓶頸在節點還是在本機。
v2rayN 的測速檔案位址可以在「設定」→「參數設定」裡替換成離自己更近的位址,測速結果會更接近真實可用頻寬。測速時用的節點會真實轉發資料,這一點和延遲測試完全不同。
注意
下載測速每執行一次都會真實傳輸測速檔案大小的流量。10 MB 的測速檔案乘以節點數量,以流量計費的方案幾分鐘內就會跑掉幾百 MB。篩選節點優先使用真連線延遲,只對最後保留的兩三個節點做下載測速。
- 先用本機直連測一次基準頻寬,把數值記下來作為對照。
- 對候選節點逐一執行下載測速,單執行緒結果不達標再試多執行緒。
- 把測速檔案換成附近可存取的位址,減少跨境鏈路帶來的干擾。
- 結果達到直連基準的 70% 以上,即可視為這條線路的合格吞吐。
判斷順序:從封包遺失到頻寬
三類數值的使用有固定順序,順序顛倒會得出完全相反的結論。例如先看下載測速,會把頻寬大但延遲高的節點排在前面,日常瀏覽反而更慢,於是又來回切換節點。
- 先看 Tcping 封包遺失率。遺失超過 5% 的節點直接排除,延遲數字不再參考。
- 再看真連線延遲的波動。同一節點重測三次取中位數,波動超過 50% 的降為備選。
- 按真連線延遲中位數排序,取前三個進入下一輪。
- 對前三個做下載測速,按用途取捨:網頁與 API 選延遲低的,大檔案與影音選吞吐高的。
- 連線後如果網頁仍慢,先檢查 DNS 與路由規則,而不是繼續更換節點。
結論:先看封包遺失,再比延遲,最後才測頻寬
封包遺失率超過 5% 的節點,延遲數字再低也不可用;真連線延遲波動小於 20% 的節點才值得進入下載測速環節。三步順序序顛倒,篩選結果幾乎一定會反過來。
四類常見誤讀
| 常見誤讀 | 實際情況 |
|---|---|
| ping 低就等於快 | ping 只涵蓋本機到伺服器這一段,不包含協議握手與轉發耗時 |
| 下載測速快就適合瀏覽網頁 | 吞吐與延遲是兩個維度,網頁載入更依賴延遲與 DNS 解析 |
| 只看最小值,不看波動 | 最小值常出現在網路空閒的一瞬間,中位數才代表常態 |
| 開著系統代理測速更真實 | 用戶端內建的測速不經過系統代理,開著代理只影響瀏覽器內的測速 |
這四類誤讀的共同點,是把不同維度的數值混在一起排序。只要記住「鏈路、握手、吞吐」三個層次各自對應一種數值,選節點時就不會再被單一數字帶偏。
結論:同一節點測三次,看中位數而不是最小值
最小值往往出現在網路空閒的一瞬間,不代表常態。三次測量取中位數,再與同批節點橫向比較,篩選結果才穩定,也更容易在下次重現。
測速常見問題
為什麼真連線延遲比 ping 高出一大截?
真連線延遲包含 TCP 握手、TLS 握手與協議握手,額外 1.5~3 次往返都會疊加鏈路 RTT,高出 30~150 ms 屬於正常範圍。差值長期穩定,說明伺服器端處理正常。
同一節點重測兩次延遲差很多,正常嗎?
波動在 ±20% 以內屬於正常;超過 50% 或頻繁逾時,先查本機網路,再考慮線路壅塞。這種情況把該節點降為備選,不要當作主力節點。
下載測速很快,網頁開啟還是慢?
吞吐與延遲是兩個維度。開啟網頁更依賴握手延遲與 DNS 解析,換成真連線延遲更低的節點,並確認網域名稱解析沒有繞遠路。
測速時要不要先關掉系統代理?
不需要。v2rayN 與 v2rayNG 內建的測速由用戶端自行發起,不經過系統代理;只有用瀏覽器開啟測速網站時,結果才會受代理影響。
測速會消耗節點流量嗎?
會。Tcping 與真連線延遲只做握手,流量消耗可以忽略;下載測速會真實傳輸測速檔案,10 MB 一次,以流量計費的節點建議只測最後保留的兩三個。