VPN測速怎麼測才準?2026 加速器速度實測方法與工具推薦
宣傳頁上的速度數字不能直接當參考。本文給出自己動手測速的完整方法:選什麼工具、在哪些時段測、看哪幾個指標,以及如何識別被美化的測速截圖。
為什麼宣傳頁上的測速數字不能直接用
VPN 測速怎麼測才準,先給結論:一次測速的結果,是「本地寬頻 → 對外出口 → 跨境線路 → 海外機房 → 測速伺服器」這條鏈路上最慢那一段的表現。宣傳頁上的數字通常只說明某一天、某一條線路、某一個測速伺服器上的結果,換一個伺服器,數字就可能換一個量級。
最常見的干擾來自測速伺服器的位置。測速軟體預設會挑延遲最低的伺服器,如果它選中的是同城節點,你測到的是本地寬頻的數字,整段跨境路徑根本沒有參與進來。想比較線路,必須手動把測速伺服器固定到目標地區。
第二個干擾是單位。測速軟體用 Mbps(每秒百萬位元),下載工具用 MB/s(每秒百萬位元組),兩者相差 8 倍:100 Mbps 約等於 12.5 MB/s。截圖裡出現 100 MB/s,等於 800 Mbps,先做一次換算,再判斷它是否落在自家寬頻的量級之內。
「Mbps」與「MB/s」只差一個字母,數字卻差 8 倍。看到特別漂亮的截圖,先找單位,再做一次除法。
- 8× 1 MB/s 與 Mbps 之間的換算倍數,截圖放大數字最常用的手法
- 3 次 同一時段最少重複次數,取中位數而不是峰值
- 3 檔 白天、晚間尖峰、深夜,至少涵蓋三個時段
- 20–23 台灣時間晚間尖峰所在的小時區間,跨境線路掉速最集中的時段
測速前先固定的五個變數
測速不是打開網頁點一下按鈕,而是一次條件受控的對比。下面五個變數只要有一個變動,前後兩次的數字就不能直接比較。
- 裝置與連線方式 —— 同一台裝置、同一個瀏覽器;能用網路線就不用 Wi-Fi。走 Wi-Fi 時先確認訊號強度,否則測到的是裝置與路由器之間的距離。
- 客戶端與協定 —— Shadowsocks、VMess、Trojan、VLESS 的常見設定走 TCP 傳輸,遇到封包遺失時受壅塞控制影響,速度會明顯下滑;Hysteria2、TUIC 基於 QUIC/UDP,在高封包遺失的鏈路上更容易保住吞吐量,但對電信商的 UDP 策略更敏感。比較數字時,協定必須保持一致。
- 分流模式 —— 全域模式與規則模式的流量走向可能完全不同。規則模式下,測速伺服器的網域可能命中直連規則,這時你測的其實是本地寬頻。
- 測速伺服器 —— 固定同一座城市、同一家電信商的伺服器。換伺服器等於換了一把尺。
- 時段 —— 至少涵蓋白天、晚間尖峰、深夜三檔,並連續記錄幾天,而不是只挑狀態最好的那一刻。
測速前打開我的 IP頁面,確認出口 IP 屬於目標地區。如果顯示的仍是本地 IP,說明流量走了直連,後面的數字與線路無關。
用哪些工具測:瀏覽器、命令列與客戶端內建
工具沒有絕對的好壞,關鍵是知道每個工具在測什麼。頻寬、延遲、封包遺失是三件不同的事,很少有工具能把三件事同時測準。
| 工具 | 類型 | 主要看什麼 | 注意事項 |
|---|---|---|---|
| Speedtest(Ookla)網頁版 / 桌面版 | 多執行緒頻寬 | 下行、上行、延遲、抖動 | 預設自動挑最近的伺服器,必須手動指定目標地區 |
| fast.com | 多執行緒頻寬 | 下行頻寬,可切換上行 | 節點由 Netflix 指定,不能更換,適合做為影片情境參考 |
| Cloudflare Speed Test | 延遲與頻寬 | 閒置與負載延遲、抖動、封包遺失、上下行 | 能看到跑滿頻寬時的延遲變化,不只是一個峰值數字 |
| iperf3 | 裸吞吐量 | 自建伺服器與客戶端之間的上下行 | 需要自備境外伺服器,結果與伺服器位置高度相關 |
| mtr / WinMTR | 路徑品質 | 逐跳延遲與封包遺失 | 只測路徑不測頻寬,用來定位從哪一跳開始劣化 |
| curl / 瀏覽器下載 | 單一連線實測 | 單一 HTTPS 連線的實際吞吐量與首位元組時間 | 最接近打開網頁、下載檔案的實際體驗 |
另外,不少客戶端內建的「測速」按鈕只對節點做一次握手或一次 HTTP 請求,量出來的是延遲,不是頻寬。把它當作挑節點的初篩可以,當作速度結論不行。
看哪幾個指標:延遲、抖動、封包遺失與單執行緒頻寬
頻寬數字最容易看,也最容易誤導。按對體驗的影響排序,依次是封包遺失、抖動、延遲,最後才是頻寬上限。
- 延遲(RTT):資料一個來回的毫秒數,決定點擊之後的反應速度。數值低、波動小才算好。
- 抖動(jitter):連續多次延遲的波動幅度。抖動大的線路,頻寬再高,視訊會議與即時對戰也會卡。
- 封包遺失:跨境鏈路上最傷體驗的一項。TCP 類協定遇到封包遺失會降速重傳,頻寬數字跟著掉;UDP 類協定不重傳,但畫面會花、聲音會斷。
- 下行頻寬:決定下載與影片播放的上限。
- 上行頻寬:通常低於下行,直播推流、雲端硬碟同步、雲端備份更依賴它。
- 首位元組時間(TTFB):從發出請求到收到第一個位元組的時間,受延遲與 DNS 解析共同影響。
還要區分單執行緒與多執行緒。多執行緒測速把多條連線的結果相加,能跑到頻寬上限,卻會掩蓋單一連線的劣化;單執行緒更接近看影片緩衝、下載一個檔案時的真實感受。兩個數字都記下來,差距越大,說明這條線路越依賴並行連線。
# 單一連線實測:看實際吞吐量與首位元組時間(Cloudflare 測速端點)
curl -o /dev/null -s -w 'dns %{time_namelookup}s | connect %{time_connect}s | ttfb %{time_starttransfer}s | speed %{speed_download} B/s\n' \
'https://speed.cloudflare.com/__down?bytes=100000000'
# 路徑品質:連續 50 個探測封包,看逐跳延遲與封包遺失
mtr -rwzc 50 1.1.1.1每次測試記六欄:時間、線路與地區、協定、延遲、抖動、單執行緒下行。多執行緒結果另記一欄,不要拿它和單執行緒數字互相比較。
分時段、分天數記錄:一套可重現的測試流程
下面這套流程不需要額外工具,一台裝置、一張表格就能跑完。它測的不是「最快能到多少」,而是「這條線路在什麼時段、以多大波動提供多少頻寬」。
- 斷開線路,先測基準:同一台裝置、同一個測速伺服器,記錄本地寬頻的延遲與下行。
- 連上線路,把客戶端切到全域模式,或確認分流規則涵蓋了測速伺服器的網域。
- 打開 IP 查詢頁面,確認出口 IP 已經變成目標地區。
- 使用同一個測速伺服器連續測 3 次,記錄每次的延遲、抖動、下行與上行。
- 用 curl 或瀏覽器下載做一次單執行緒測試,記錄實際吞吐量與首位元組時間。
- 用 mtr 跑 50 個探測封包,看從哪一跳開始出現封包遺失。
- 換到下一個時段,重複第 2 至第 6 步,至少涵蓋白天、晚間尖峰、深夜三檔。
- 連續記錄幾天之後,比較各時段的中位數與波動範圍,而不是最好看的那一次。
如何識別被美化的測速截圖
先把線路類型分清楚
直連、中轉與 IEPL 專線的路徑完全不同,數字放在一起比沒有意義。
- 直連:客戶端直接連到境外機房,全程走公網。成本低,晚間尖峰受國際出口壅塞的影響最明顯。
- 中轉:先連到本地中轉伺服器,再由中轉出海。路徑可控、跳數少,通常比直連穩定,瓶頸可能出現在中轉節點本身。
- IEPL 專線:端到端的國際乙太網路專線,不經過公網國際出口,延遲與抖動更穩定,成本也更高。
截圖自檢清單
- ✅ 截圖裡能看到測速伺服器的城市與電信商,以及測試時間。
- ✅ 單位標示清楚是 Mbps 還是 MB/s,而且前後一致。
- ✅ 延遲、抖動、封包遺失與頻寬一起給出,而不是只給一個下行數字。
- ✅ 單執行緒與多執行緒結果分開列出,並註明測試的是哪條線路。
- ❌ 只截峰值那一次,不顯示伺服器、時間與單位。
- ❌ 數字在 Mbps 與 MB/s 之間來回切換,看起來大了一截。
- ❌ 用同城測速伺服器或區域網路 iperf3 的結果,冒充跨境線路速度。
- ❌ 不說明協定與線路類型,把直連、中轉、IEPL 專線的結果混在一張圖裡比較。
常見迷思與結論
- 數字越大越好 —— 頻寬只決定上限,延遲與封包遺失決定下限。
- 測一次就能下結論 —— 跨境鏈路的狀態隨時段變化,單次結果說明不了穩定性。
- 同一個客戶端裡所有線路速度一樣 —— 不同地區、不同線路類型的路徑完全不同,要分別測。
- 延遲低就等於快 —— 頻寬不足時,低延遲也只夠傳文字訊息,影片照樣要緩衝。
- 只盯測速軟體的單一數字 —— 網頁打開慢、影片緩衝,常常來自 DNS 解析或單一連線品質,聚合頻寬的測速結果未必反映得出來。
回到開頭的問題:準確的測速,本質是把變數固定住之後的重複對比。先固定裝置、協定、分流模式與測速伺服器,再分時段記錄延遲、抖動、封包遺失與單執行緒頻寬,最後比較中位數與波動範圍,而不是最好看的那一次。這樣得到的數字,才能用來判斷一條線路是否值得長期使用。