VPN 測速怎麼做，重點不在跑出最高數字，而在建立可重複的比較基準。先測量本地網路基線，再連線至指定線路；固定裝置、連線方式、測速工具與目標節點，最後比較延遲、抖動、丟包、下載及上傳表現。只有測試條件一致，結果才適合用來判斷線路。
單次瀏覽器測速很容易受到測速伺服器負載、無線網路干擾、背景下載及電信商路由變化影響。截圖中的峰值只能代表當下那次連線，不能直接反映日常體驗。更可靠的做法是保留測試條件，在平常使用時段與網路繁忙時段分別重測，並將異常結果與正常結果分開記錄。
先釐清 VPN 測速要回答什麼
測速前先寫下要解答的問題。影片卡頓、網頁首次開啟緩慢、檔案下載不穩定、遠端終端機斷續，背後涉及的指標並不相同。如果只看下載頻寬，可能會漏掉更直接的原因。
| 觀察項目 | 主要指標 | 如何解讀結果 | 常見干擾 |
|---|---|---|---|
| 網頁與互動請求 | 延遲、抖動、DNS 回應 | 建立連線與處理小型請求較依賴往返時間，頻寬很高也不代表開啟速度快 | DNS 快取、瀏覽器擴充功能、目標網站回應 |
| 串流媒體播放 | 持續下載、波動、丟包 | 短時間峰值意義有限，持續傳輸是否穩定更重要 | 內容平台調度、快取節點、帳號地區 |
| 視訊會議與語音 | 抖動、丟包、雙向延遲 | 速率足夠後，延遲變化通常比峰值頻寬更影響連貫性 | 無線干擾、上行頻寬占滿、裝置省電策略 |
| 大型檔案傳輸 | 持續下載、持續上傳 | 應觀察一段連續過程，而不是只保留瞬間最高點 | 來源站限速、磁碟寫入、並行連線方式 |
| 遠端終端機與開發連線 | 延遲、抖動、重傳 | 穩定的小型資料封包往返通常比高吞吐量更重要 | 企業網路策略、分流規則、目標主機負載 |
延遲是資料往返所需的時間。地理距離、電信商互聯與線路繞行都會改變延遲。連線至較遠地區後延遲增加屬於可預期現象，判斷重點應放在同一地區不同線路的差異，以及同一線路在不同時間是否出現明顯波動。
抖動表示連續資料封包的延遲是否穩定。平均延遲相近的兩條線路，抖動較小的一條通常更適合語音、會議與即時控制。丟包則可能觸發重傳，表現為畫質下降、下載曲線突然下滑或終端機輸入停頓。瀏覽器測速未必會完整呈現這些資訊，因此需要搭配系統網路工具或用戶端記錄觀察。
建立可重複測試的基線
基線是未連線 VPN 時，在相同裝置與相同網路下測得的結果。它代表目前連線網路可提供的上限與波動範圍。若基線本身不穩定，連線任何線路後的結果都會跟著漂移。
優先使用有線連線。只能使用無線網路時，應保持裝置位置、連線頻段與路由器不變，避免一輪測試靠近路由器，下一輪卻隔著牆。測試期間暫停雲端硬碟同步、系統更新、遊戲更新及其他裝置上的大量流量任務。瀏覽器中正在播放的媒體也應停止。
- ✅ 固定同一台裝置、同一種網路連線方式與同一個測試位置。
- ✅ 關閉會持續占用下載或上傳頻寬的背景任務。
- ✅ 記錄未連線時的延遲、抖動、丟包、下載與上傳結果。
- ✅ 固定測速工具及目標伺服器，不要在比較過程中任意切換。
- ✅ 記錄線路名稱、協定、測試時段與分流模式。
- ❌ 不要將無線網路與有線網路的結果放在同一組直接比較。
- ❌ 不要用一次峰值取代整輪測試，也不要只保留最好看的結果。
測速伺服器也要固定。自動選擇通常會挑選目前探測較快的伺服器，但連線 VPN 後，自動選擇的目標可能改變，導致前後測量的是不同路徑。較穩妥的做法是手動選擇同一個目標，並額外選擇一個接近日常存取地區的目標進行交叉檢查。
如果公開測速工具提供單一連線與多重連線模式，應一併記錄模式。多重連線測試可以更快占滿可用頻寬，但不一定代表單一檔案下載、單一影片串流或遠端工作階段的表現。單一連線結果更容易顯示個別工作階段的壅塞、限速或丟包問題。兩種模式回答的問題不同，不能混為一談。
按照固定流程完成一輪實測
一輪完整測試應包含原始網路、目標線路與複核線路。測試順序保持一致，方便排除裝置溫度、背景任務與網路時段變化的影響。以下流程不依賴特定品牌工具，瀏覽器測速頁面、系統網路指令與用戶端狀態頁都可用來記錄。
- 清理測試環境。停止背景傳輸，確認裝置沒有自動切換網路。記錄目前的連線方式與所在網路。
- 測量原始網路基線。保持 VPN 斷線，使用固定目標記錄延遲、抖動、丟包、下載與上傳表現。
- 連線至指定線路。記錄地區、線路名稱、協定，以及用戶端使用的全域或分流模式。等待連線狀態穩定後再開始。
- 重複同一組項目。仍使用相同測速目標與相同模式，避免因更換伺服器而改變路徑。
- 進行實際任務複核。開啟平常使用的網站、播放常用內容或傳輸一份可重複使用的測試檔案，觀察是否與測速數字一致。
- 斷線後再次測量基線。如果原始網路也變慢，表示這輪變化可能來自本地網路或電信商時段，而不是單一線路。
- 更換候選線路重測。每次只改變一個變數。比較線路時不要同時更換協定、用戶端與網路連線。
系統中的 ping 可用來觀察往返延遲、抖動趨勢與丟包，但部分目標會限制或忽略這類探測，因此「沒有回應」不等於網頁無法存取。traceroute 或 tracert 可以顯示部分路徑節點，但電信商可能隱藏中間跳點，節點名稱也不能作為判斷線路類型的唯一依據。
如果有自行控制的遠端伺服器，可以使用 iperf 類工具測量端到端吞吐量。它適合排查自有連線，不宜直接將結果推及所有網站。實際存取還會經過目標網站的網路、內容傳遞節點與應用層限制。
記錄時不要只抄下最後的數字。保留工具名稱、目標、測試模式、連線協定與時間背景。測速截圖可作為原始記錄，但最好再整理成表格，方便日後發現同一路線在繁忙時段是否反覆出現相似波動。
| 記錄欄位 | 應記錄內容 | 用途 |
|---|---|---|
| 連線環境 | 有線或無線、裝置與系統 | 避免將連線差異誤判為線路差異 |
| 連線狀態 | 未連線、線路地區、全域或分流 | 建立基線並確認實際路徑 |
| 協定 | 用戶端目前顯示的協定名稱 | 協定變化可能改變傳輸方式與額外負載 |
| 測速目標 | 工具、伺服器地區、單一連線或多重連線 | 確保不同輪次測量同類路徑 |
| 品質指標 | 延遲、抖動、丟包、下載、上傳 | 區分互動、即時通訊與持續傳輸問題 |
| 實際任務 | 網頁、影片、會議或檔案傳輸現象 | 核對測速結果能否解釋真實體驗 |
為什麼要涵蓋平常與繁忙時段
國際線路不是靜態的實驗室環境。使用者所屬電信商、連線城市、跨網互聯、出口方向與目標網站都可能隨時段變化。白天順暢不能推論晚間同樣穩定，繁忙時段的一次異常也不能直接表示線路長期無法使用。
合理做法是在實際使用服務的時段重測。如果主要在晚間觀看內容，就應將晚間作為核心觀察時段；如果用途是工作日的遠端會議，則應以會議通常發生的時段為準。測試目的不是尋找統一的「標準時刻」，而是驗證線路能否涵蓋個人的實際使用時段。
每次重測都繼續使用相同目標。若多條線路同時變慢，先檢查本地基線與測速目標；若只有某條線路反覆異常，再考慮節點負載、路徑壅塞或協定適配。若下載穩定但網頁首次開啟緩慢，則應繼續檢查 DNS、分流與目標網站回應，而不是簡單歸因於頻寬不足。
線路類型如何影響測試結果
「直連」、「中轉」與「IEPL 專線」描述的是不同的路徑組織方式，但名稱本身不能取代實測。直連通常指用戶端直接連線至境外入口，不經過服務方設置的境內中轉節點。路徑較簡單，但表現更取決於本地電信商至境外入口的互聯品質。
中轉線路通常先連至較近的接入節點，再由中轉網路送往境外出口。其目的在於調整跨網路徑與出口方向。中轉增加了鏈路環節，不代表延遲必然較高或較低；結果取決於接入節點距離、中轉品質、出口壅塞與目標位置。
IEPL 通常指電信商提供的國際乙太網路專線產品。在面向個人的訂閱服務中，線路標註為 IEPL，通常表示服務方的中間傳輸段使用相應專線資源，不代表使用者裝置到接入節點的本地網路也成為專線。最後一段接入仍可能經過家用寬頻、無線網路或公共網際網路。
因此，比較線路類型時，應選擇相同出口地區與相同測速目標。若將近距離中轉線路與遠距離直連線路放在一起，只憑延遲下結論，這樣的比較本身就不對等。線路標籤適合用於分類，測試記錄才用來判斷目前網路下的實際表現。
如何控制協定差異的變數
Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC 的封裝方式及傳輸特徵不同。它們沒有脫離網路環境的固定速度排名。用戶端實作、伺服器設定、加密方式、底層傳輸、本地系統網路堆疊與中間網路策略都會影響結果。
Shadowsocks 是加密代理協定體系，常見實作可承載 TCP 與 UDP 流量。VMess 與 VLESS 常見於相應代理核心生態，具體表現取決於搭配的傳輸層與用戶端實作。Trojan 透過 TLS 形式建立連線，TLS 交握、憑證設定與傳輸路徑都會反映在測試結果中。
Hysteria2 以 QUIC 相關機制與 UDP 傳輸為基礎，針對存在丟包或頻寬波動的連線提供壅塞控制能力。TUIC 同樣建立在 QUIC 與 UDP 之上。它們在某些網路中可能更能利用波動連線，但如果接入網路限制 UDP，連線與速度也可能受到影響。不能將協定的設計目標寫成適用於所有環境的速度承諾。
比較協定時，只更改協定，其他條件保持不變。使用同一地區、同一出口、同一用戶端版本與同一測速目標。如果訂閱連結為不同協定分配了不同伺服器，那麼這輪測試同時改變了協定與節點，結果不能單獨歸因於協定。
- ✅ 先確認訂閱連結已更新，用戶端顯示的是預期節點與協定。
- ✅ 比較協定時固定線路地區、測試目標與網路連線方式。
- ✅ 同時觀察連線成功率、延遲波動與實際應用表現。
- ✅ UDP 類協定出現異常時，檢查目前網路是否允許相關傳輸。
- ❌ 不要將不同出口、不同伺服器的結果直接稱為協定比較。
- ❌ 不要根據單次下載峰值為協定排出永久順序。
訂閱匯入與用戶端設定也會改變結果
訂閱連結通常用於向用戶端下發節點、協定與連線參數。匯入成功只表示用戶端讀取了設定，不代表所有流量都已按照預期經由所選線路傳輸。測速前應重新整理訂閱、選擇明確節點，並查看連線記錄是否有自動回退、連線失敗或頻繁重連。
不同平台的用戶端運作方式有所差異。Windows 與 macOS 用戶端可能使用系統代理、虛擬網路介面，或兩者組合。系統代理主要影響遵循代理設定的應用程式；虛擬網路介面通常能接管更廣泛的流量，但仍受路由表與分流規則控制。Linux 用戶端通常需要使用者自行確認網路介面、路由與 DNS 設定。
iOS 與 Android 通常透過系統提供的 VPN 介面建立通道。行動系統的省電策略、網路切換與背景限制可能中斷持續測試。裝置從無線網路切換至行動網路後，原本的測試條件已經改變，應重新建立基線，而不是將切換前後的結果接在同一組。
分流規則決定哪些網域或地址經過代理，哪些維持直連。若測速站被規則判定為直連，頁面顯示的可能是原始網路出口；若測速頁面經由代理，而測試資料網域直連，結果還可能出現混合路徑。測試前可先使用全域模式驗證完整通道，再回到日常分流模式重測。
全域模式適合確認線路本身，但不一定是長期使用的最佳設定。日常分流可以讓本地服務維持直連，國際目標則依規則進入線路。最終記錄應註明模式，避免日後將全域結果與分流結果放在同一欄比較。
檢查出口地址、DNS 與分流是否生效
速度正常不等於路徑正確。測速前後應檢查公網出口地址是否從本地電信商出口切換為所選線路出口。出口地區資訊來自地址資料庫，可能存在更新延遲，因此適合與多個檢測來源交叉確認，不宜只憑城市標籤判斷節點實際位置。
DNS 洩漏是指原本應透過通道或指定解析器處理的網域查詢，仍然傳送給本地網路提供的解析器。它可能暴露查詢來源，也可能造成分流判斷、內容調度或地區識別不一致。檢查時要分別觀察連線前後解析器的變化，並結合用戶端的 DNS 模式與路由規則理解結果。
檢測頁面列出本地電信商的解析器，不一定能單獨證明所有請求都繞過通道；部分用戶端會結合使用系統解析、加密 DNS 或遠端解析。相反地，頁面顯示境外解析器也不代表所有應用程式都採用相同路徑。瀏覽器、作業系統與應用程式可能各自維護快取，修改設定後應重新建立連線並再次測試。
瀏覽器中的 WebRTC 檢測還可能顯示本地介面地址。現代瀏覽器顯示本地地址的方式各不相同，看到介面資訊不應直接等同於公網出口洩漏。判斷重點是公網候選地址、實際出口與用戶端路由是否一致。
如何解讀異常結果並定位問題
如果未連線時就出現高抖動或持續丟包，先排查本地網路。可以改用有線連線、暫停其他裝置傳輸、重新啟動網路設備，並向電信商確認線路狀態。此時反覆切換境外節點通常無法解決接入段問題。
如果基線穩定，但所有節點都很慢，應檢查用戶端模式、協定適配、系統資源與測速目標。加密與封裝會帶來處理負載，效能較弱的裝置在高吞吐量情境下可能先達到處理上限。觀察工作管理員或系統監視器中的處理器、記憶體與網路使用量，有助於區分裝置瓶頸與線路瓶頸。
如果只有某個地區速度慢，可能與地理距離、出口方向、目標伺服器位置或該路徑在特定時段的壅塞有關。選擇更接近目標服務的出口，通常比盲目選擇地理距離最近的節點更合理。例如，內容節點可能根據出口地址進行調度，路徑並不只由使用者到入口的距離決定。
如果測速數字正常但影片仍然緩衝，應檢查內容平台本身的調度、畫質自動調整、瀏覽器硬體解碼與帳號地區。若網頁速度慢但檔案下載穩定，則繼續排查 DNS 回應、連線建立時間與分流規則。若遠端工作階段斷續但下載很快，則應重點觀察抖動、丟包，以及上行頻寬是否被其他任務占滿。
最後保留原始記錄。過一段時間以相同流程重測，可以看出問題是偶發、與時段相關，還是持續存在。更換用戶端、協定或線路後也應另建一組記錄，避免新舊條件混在一起。