VPN 速度實測怎麼做：自己客觀測速的方法、工具與時段

想知道 VPN 速度實測怎麼做，先接受一個前提：單次測速只是一個樣本，不是結論。同一條線路，上午和晚間尖峰可能給出完全不同的數字；換一個工具、換一個測速伺服器，結果又會差出一截。要判斷一條線路能不能滿足自己的使用情境，需要固定變數、分時段重複，並且同時看延遲、抖動、封包遺失和吞吐量四項指標。下面這套流程不需要專業知識，用系統內建指令和幾個常見工具就能跑完。

先分清四個指標：延遲、抖動、封包遺失、吞吐量

測速頁面上最顯眼的那個數字只是吞吐量，它回答不了「為什麼看影片會卡」。四項指標各有分工，缺一項都可能誤判：

• 延遲（RTT）：一個封包從裝置到目標伺服器再返回所需的時間，單位毫秒。掛上代理後，這段往返包含「裝置 → 出口節點 → 目標」兩段，天生比直連大一些，所以只在同一目標、同一工具之間橫向比較。
• 抖動：連續多個封包延遲的波動幅度。影片卡不卡、語音斷不斷，抖動比平均延遲更關鍵——平均延遲不高但抖動大，體感會比穩定略高的延遲更差。
• 封包遺失：送出的封包裡沒有到達的比例。少量封包遺失就會觸發重傳，吞吐量隨之下降；基於 QUIC 的協定對封包遺失的處理方式與 TCP 不同，表現也不一樣。
• 吞吐量：單位時間內實際傳輸的資料量。要區分單執行緒與多執行緒：單執行緒更接近單一檔案下載、單一影片串流的體驗，多執行緒更接近測速網站的跑分。

測速前先固定變數：裝置、協定與連線方式

測速結果裡最容易混進來的不是線路差異，而是你自己的變數。同一個節點，換台裝置、換個協定、換成無線，數字可能差出一大截。測試之前，先把下面幾項固定住：

• 裝置與網路：同一台裝置、同一條網路，優先有線；用無線時固定頻段與位置，中途不換。
• 背景流量：關閉系統更新、雲端硬碟同步與雲端備份，其他裝置暫停大流量任務。
• 協定：Shadowsocks、VMess、VLESS、Trojan 走 TCP；Hysteria2、TUIC 基於 QUIC 走 UDP。同一節點上不同協定的表現可能不同，國際鏈路出現封包遺失時差異更明顯。比較節點時，不要一邊換節點一邊換協定。
• 多路複用（mux）：把多條連線複用進一條 TCP 連線，遇到封包遺失時容易受隊頭阻塞影響，單執行緒吞吐量會偏低。一律統一關閉或統一開啟，別混著比。
• 規則模式：分流模式下，如果測速目標命中了直連規則，你測到的其實是直連速度。測試前確認目標走的是代理。

常用工具與它們各自適合測什麼

工具不在於多，而在於每一項指標都有對應的測法。下面這些涵蓋了從延遲到吞吐量的檢查項，選兩三個組合使用就夠：

時段怎麼選：尖峰與離峰時段各測幾輪

跨境鏈路的負載有明顯的時段特徵。平日 20:00–23:00 通常是晚間尖峰，國際出口最擁擠，延遲抬升、封包遺失更容易出現；上午 9:00–11:00 與下午 14:00–16:00 相對離峰，數字更接近線路本身的上限。每個時段至少測 3 輪，每輪間隔幾分鐘取中位數，並且至少跨兩天——平日與週末各測一輪。只測一次得到的好數字，說明不了任何事。

一套可重複套用的測速流程

先把測前清單過一遍，再按順序執行。整輪測試建議控制在 15 分鐘以內，避免拖到時段邊界上：

• ✅ 用網路線，或固定在 5GHz 頻段，測試全程不換位置、不切換網路。
• ✅ 關閉系統更新、雲端硬碟同步、雲端備份與正在進行的下載任務。
• ✅ 整輪測試只用同一節點、同一協定、同一 mux 設定。
• ✅ 確認規則模式與測速目標，別讓「直連」混進代理結果裡。
• ❌ 不要在公共 Wi-Fi 或手機熱點上做對比，這類鏈路本身就有額外限制。
• ❌ 不要把一次測出的最高值當成線路水準。

1. 測基準：不掛代理，對同一個測速伺服器跑一輪，記下延遲與吞吐量。
2. 連上節點後連續 ping 100 個封包，記錄延遲區間與封包遺失情況。
3. 跑一次 mtr（或 tracert），觀察國際段是否持續封包遺失。
4. 用同一個測速伺服器跑多執行緒吞吐量，再用單執行緒下載跑一次，兩個數字都記下來。
5. 回到真實情境：打開常用的影片或雲端硬碟，實際傳輸 1–2 分鐘，觀察是否降碼率。
6. 晚間尖峰時段重複第 2–5 步，把兩輪結果放在一起對比。
7. 連續記錄 3 天，用中位數而不是最高值作為該節點的代表數字。

# Windows：連續傳送 100 個封包
ping -n 100 1.1.1.1

# macOS / Linux：同樣的封包數
ping -c 100 1.1.1.1

# 單次請求的耗時與下載速度，重複多次取中位數
curl -o /dev/null -s -w "%{time_total} %{speed_download}\n" https://example.com/file

結果怎麼讀：別被單次峰值誤導

幾個常見的「數字虛高」來源，遇到時要在記錄裡備註，而不是直接採信：

• TCP 慢啟動與突發額度：連線剛建立時速度還在爬升，測得太短容易截到爬升段或短暫的突發段。
• 快取命中：反覆測同一個網址，可能命中 CDN 快取，數字好看但不代表出口頻寬。
• 測速伺服器位置：測速點與節點同城同機房時，測到的更接近機房內網速度，而不是你連目標網站的速度。
• 單執行緒與多執行緒的差距：多執行緒跑得滿、單執行緒跑不動，說明瓶頸在單條連線的排程上，下載大檔案時最容易察覺。

常見誤區與換節點的判斷

還有一個常被忽略的點：如果測速數字正常，但打開網頁的第一步特別慢，先排查 DNS。部分用戶端提供「遠端解析 / 本機解析」選項，本機解析會讓網域名稱解析走本地網路，既可能拖慢首次存取，也會造成解析請求沒走隧道（也就是常說的 DNS 洩漏）。這類問題不會體現在吞吐量數字上，要單獨確認。

出現下面這些情況，再考慮換節點，而不是憑一次測速就下結論：

• 晚間尖峰連續多天出現封包遺失，且 ping 與 mtr 都能重現；
• 單執行緒吞吐量長期低於目標情境所需，而多執行緒吞吐量正常；
• 抖動明顯，影片頻繁降碼率、語音斷續。