VPN 速度怎麼測:工具、時段與指標的自測方法

VPN 速度怎麼測,決定結論的不是測速網站的介面,而是你測的是哪一段鏈路、在什麼時段測、連測了幾次。同一台裝置、同一份訂閱,換一個測速節點、換一個小時,結果可以差好幾倍——這不是線路在騙人,而是兩次測量回答的根本不是同一個問題。下面把測量拆成三層、四項指標和一套可以重複執行的流程,讓不同線路之間的比較真正有意義。

先把基準定下來:四項指標各管什麼

日常說的「網速慢」至少對應四種不同的量。延遲、抖動、封包遺失屬於鏈路品質,吞吐量屬於傳輸結果。四項指標裡任何一項變差,體感都可能表現為「卡」,但處理方式完全不同:封包遺失要換線路,抖動要避開尖峰,吞吐量上不去可能只是單執行緒的問題,跟線路好壞無關。

頻寬和吞吐量不是一回事。頻寬是鏈路標稱的上限,吞吐量是你在終端上實際拿到的量,中間隔著協定開銷、伺服器端限速、單一連線的視窗限制,以及同線路其他使用者的占用。所以看到 Mbps 這個單位時,先確認它說的是頻寬還是吞吐量,再決定要不要把它當成比較依據。

工具:分三層測,別用一個網頁跑分定論

把測量分成三層,每層用一個合適的工具,結論才立得住。層級混著用,數字就會互相打架。

網頁測速網站大多跑多執行緒 HTTP,適合看這條線路的上限。它預設挑離你近的節點,給出的數字回答的是「到最近測速伺服器有多快」,而不是「到你要用的那個服務有多快」。這兩個數字可以同時成立,一個很高一個很低,誰都沒錯。

iperf3 適合點對點驗證,可以指定並行連線數和測試時間長度,排除瀏覽器與測速網站的干擾,代價是兩端都得有可控的節點。日常自測更實際的做法是:多執行緒測速網站看上限,單執行緒下載看下限,兩個數字都記下來。

時段與次數:讓兩次測量具備可比性

單次測量只是一個樣本。國際線路的負載有明顯的時間規律,晚尖峰和凌晨的差距,往往比兩條線路之間的差距更大。所以跨時段比較要看趨勢,同一時段內的橫向比較才有排序意義。

• 尖峰與離峰各測一輪,分別記錄兩個時段的中位數。
• 同一條線路連測三次,取中位數,不取最大值。
• 每次記錄:日期、線路名、協定、客戶端版本、單執行緒還是多執行緒。
• 換線時只改一個變數,裝置、客戶端、測速節點都保持不變。
• 測之前先更新訂閱,確認節點清單沒有變化。

指標怎麼讀:從數字到結論

拿到一組數字後,按固定順序讀,比憑感覺判斷可靠得多。

1. 先看封包遺失。持續不為零的遺失,優先換線路,不要在客戶端參數上折騰,調 MTU 也救不回來。
2. 再看抖動。抖動接近延遲本身,說明鏈路在排隊,通常是中轉段壅塞或共享頻寬被占滿。
3. 然後看吞吐量。延遲正常、抖動也小,但吞吐量上不去,多半是單執行緒受限、伺服器端限速或協定開銷。
4. 最後看體感。首位元組時間、影片起播、遊戲內的操作回饋,是前三項的綜合結果,也是唯一值得長期追蹤的指標。

高延遲鏈路還有一個容易被忽略的機制:單條 TCP 連線的吞吐量受頻寬延遲乘積限制。延遲越高,單一連線越難跑滿高頻寬,需要多條並行連線才能吃滿。所以「多執行緒能跑滿、單執行緒跑不滿」是正常現象,不一定是線路出了問題。

協定與線路類型會改變結果

協定差異主要在兩處

一是傳輸層選擇。Shadowsocks、VMess、VLESS、Trojan 主體走 TCP,同時可以轉發 UDP;Hysteria2、TUIC 基於 QUIC,走 UDP。在遺失明顯的鏈路上,QUIC 系的壅塞控制更積極,恢復更快;但如果網路對 UDP 有限速或阻斷,它們的表現會反過來變差,這一點在自測裡很容易被誤判成「協定不行」。

二是握手與開銷。VMess 帶時間戳校驗,裝置時間偏差過大會直接握手失敗;VLESS 本身無狀態,配合 XTLS 可以減少一次 TLS 加解密,高頻寬時 CPU 占用更低;Trojan 依賴標準 TLS,流量形態更接近一般 HTTPS。這些差異在低頻寬下幾乎測不出來,只有在長肥管道上才會體現。

線路類型:直連、中轉、IEPL 專線

• 直連。終端直接連出口,延遲取決於國際出口的壅塞程度,晚尖峰波動最大。
• 中轉。先接入中轉節點再轉發到出口,中轉段的頻寬是否獨享,直接決定尖峰期的表現。
• IEPL 專線。點對點的專線鏈路,不走公網國際出口,延遲和封包遺失最穩,成本也最高。

所以同一個「地區」的節點,線路類型不同,測出來的曲線可以完全不同。比較時把線路類型寫進記錄裡,否則資料沒法重複使用,下週還得從頭再測一遍。

按地區切換線路時,可以對照的事實:覆蓋 100+ 國家、250+ 線路;訂閱不限同時在線裝置數,換裝置複測不需要重新設定;30 天無理由退款,測完覺得不合適可以直接退。

排除誤判:幾個常見干擾項

測速結果失真,大多不是線路的問題,而是下面這幾件事沒做乾淨。

• ✅ 測前更新訂閱,確認測的是同一條線路;節點改名或換 IP 之後,之前的結論直接作廢。
• ❌ 開著分流規則直接測。部分流量走直連,結果裡混進了兩條路徑的表現,誰好誰壞分不清。
• ✅ 檢查網域名稱解析路徑:解析走本地電信業者時,可能拿到就近的 CDN 節點,數字好看但不代表出口品質。
• ❌ 用一次影片播放判斷吞吐量。命中快取之後,播放順暢和鏈路能力沒有關係。
• ✅ 在同一個客戶端裡橫向比較。不同客戶端預設 MTU、UDP 轉發開關和分流策略不同,跨客戶端比數字沒有意義。
• ❌ 把「加速比」「降低多少百分比」當成指標。換算過的數字沒有基準,也無法重現。

一套可重現的自測流程

下面這套流程按順序執行,結果可以橫向比較,也可以隔一週複測一次看穩定性。

1. 固定變數。同一台裝置、同一個客戶端、同一個測速節點,先定下來再開始。
2. 更新訂閱。記下線路名與協定,後面所有記錄都以這一行為準。
3. 測鏈路層。連續 20 個封包看延遲與遺失,再看逐跳路徑,定位問題出在哪一段。
4. 測吞吐層。多執行緒測速一次,單執行緒下載一次,兩個數字分別記錄。
5. 測應用層。開啟你實際要用的那個服務,記首位元組時間和有沒有緩衝。
6. 換下一條線路,重複第 3 到第 5 步,變數保持不動。
7. 彙整成一行記錄,再決定留哪條線路、什麼時段用哪條。

命令列只需要兩條就夠,Windows 下把 ping 換成 ping -n 20、mtr 換成 pathping 即可。這裡用公共解析服務當參考點,它的節點通常就近,延遲低;要判斷真實目標的鏈路,把位址換成你實際存取的網域名稱,同一組對比裡目標必須一致。

# 延遲與封包遺失:連發 20 個封包,看平均延遲和遺失率
ping -c 20 1.1.1.1

# 逐跳路徑:每跳 50 個封包,定位遺失發生在哪一段
mtr -rwc 50 1.1.1.1

常見問題