比較 VPN 速度時，先確認「測到的是哪一段路徑」，再看數字。可使用瀏覽器測速、實際檔案下載與連續延遲檢測；測試時段應涵蓋早上、中午與晚上，尤其要記錄平常使用的尖峰時段。只測一次最高速度，無法判斷線路是否適合長期使用。
先固定測速條件，再比較線路
一次連線會經過裝置、本地網路、電信業者、代理入口、跨區傳輸路徑與目標伺服器。任何環節壅塞，都可能拉低測試結果。測速網站顯示的頻寬，是當次測試條件下的端對端表現；它不等於服務商標示的單一線路容量，也不代表所有網站都能達到相同速度。
先在未啟用代理時記錄本地網路基準，確認 Wi-Fi 訊號、寬頻或背景工作是否已成為瓶頸。若直連無法連上某個國際目標，不必勉強測同一目標；可改用能連線的本地測速目標確認網路狀態，但不要把不同目標的結果直接解讀為「代理造成的速度損耗」。
- ✅ 固定裝置、網路連線與用戶端版本；條件允許時使用有線網路，減少無線環境變動。
- ✅ 暫停雲端硬碟同步、系統更新及其他大量傳輸工作，並記錄是否有其他裝置共用網路。
- ✅ 固定測速伺服器、測試模式與代理規則，避免工具每次自動更換目標。
- ✅ 查看用戶端連線記錄，確認測速網域套用的規則、實際出口與所選線路。
- ✅ 記錄失敗、逾時與中斷，不要只留下速度最快的截圖。
比較線路時，盡量只更換所選節點。如果同時更換協定、裝置與測速目標，即使結果明顯改善，也很難判斷真正原因。自動選擇節點或故障切換功能可能在測試期間更換出口，應記錄實際使用的線路，而不只是策略群組名稱。
工具選擇：傳輸速度、延遲與實際任務
不同工具能回答不同問題。瀏覽器測速適合快速檢查頻寬，連續探測適合觀察回應變化，實際下載則更貼近日常使用。至少交叉使用不同類型的工具，避免把測速網站本身的線路優勢當成普遍表現。
| 工具類型 | 主要觀察項目 | 適用情境 | 解讀限制 |
|---|---|---|---|
| Speedtest 等瀏覽器測速 | 下載、上傳、延遲 | 固定伺服器後比較線路傳輸速度 | 自動選擇伺服器及多連線模式會影響結果 |
| FAST 等內容網路測速 | 連至特定內容網路的傳輸速度、負載延遲 | 觀察相關內容分發路徑 | 不能代表所有影音平台與地區 |
| 來自可信來源的實際檔案下載 | 持續傳輸速率、中斷情況、完成狀況 | 確認下載與大型檔案傳輸體驗 | 來源伺服器限速、快取與磁碟也會影響結果 |
| ping 與用戶端延遲檢測 | 往返延遲、波動、探測失敗 | 協助找出本地網路或線路的回應問題 | 探測協定、目標與代理路徑可能不同 |
| 自有伺服器上的 iperf3 | 受控端點之間的傳輸表現 | 具備維運條件時進行指定方向的診斷 | 仍須確認伺服器容量與流量路徑 |
測速網站常使用多個並行連線填滿頻寬，但實際下載檔案可能受單一連線效能限制。因此，「測速很快、下載偏慢」不一定代表結果造假，也可能是連線模式或來源伺服器不同所致。比較時應分別記錄，不要混為同一項成績。
早、中、晚實測：優先測試自己的使用時段
早上、中午與晚上的差別，在於取樣不同的網路負載，而不是某個時段天生更具代表性。尖峰時段的壅塞可能出現在家用寬頻、電信業者互連、服務入口或國際出口。離峰速度快，只能說明當時條件較佳，不能取代晚間測試。
- 選定平常使用的線路與固定目標，先記錄測試時間、本地連線方式及代理模式。
- 在早上、中午與晚上重複相同流程，測試期間避免同時執行其他測速工具。
- 在同一時段輪流測試不同線路，後續測試時交換順序，減少臨時負載變化造成的順序偏差。
- 連續多日保留記錄，遇到異常再重新測試；不要刪除異常樣本後只呈現平均表現。
- 最後回到實際用途，確認影音播放、網頁載入或檔案下載是否同樣穩定。
增加測試次數後，可觀察中位數、表現範圍與失敗情況，而不只是挑最高值。記錄中也要寫明成功與失敗樣本的總數，否則一條經常連線失敗的線路，可能因只留下少數成功結果而看似很快。
一開始不必撰寫複雜指令碼。用試算表記錄日期與時段、網路環境、線路、協定、目標、頻寬、延遲、中斷情況與實際使用感受即可。測速可能耗用不少流量；流量有限時，應優先涵蓋常用時段與候選線路，而非持續循環測到頻寬滿載。
指標解讀：頻寬快不代表回應穩定
下載與上傳頻寬
下載頻寬主要影響大型檔案下載與影音緩衝；上傳頻寬則關係到檔案傳送、雲端備份與視訊會議的上行傳輸。測速網站常以 Mbps 顯示結果，下載軟體則可能顯示 MB/s；前者以位元計量，後者以位元組計量，數值不能直接比較。實際應用也會受到協定額外負荷與伺服器策略影響。
閒置延遲、負載延遲與抖動
閒置時回應快速，不代表下載期間仍然靈敏。頻寬被占滿後，若負載延遲大幅上升，網頁操作、語音通話與遠端控制仍可能卡頓。抖動描述延遲隨時間的變化，但不同工具的計算方式可能不同；跨工具比較前應先確認定義。判斷穩定性時，較適合使用同一工具的連續記錄。
封包遺失、逾時與重傳
持續封包遺失可能觸發重傳，降低有效傳輸速度。不過，探測封包未收到回覆，也可能是目標限制或忽略這類請求，不能直接推定實際流量也有遺失。若連續探測異常，且實際傳輸也發生停頓，判斷依據才較充分。單次逾時只能先記錄為待確認現象，不能立刻歸因於某一段線路。
分流與 DNS：確認測到的是代理路徑
常見誤差是測速網站走直連，目標應用程式卻走代理。規則模式可能依網域、位址與應用程式分配流量；瀏覽器測速與獨立下載程式也可能不採用相同的系統代理設定。請在用戶端連線記錄中查找測速請求，並搭配網路檢測核對出口資訊；不能只看用戶端是否顯示已連線。
排查時，可先了解用戶端功能，再暫時使用統一出口策略進行比較，之後恢復日常規則。不過，「全域模式」不一定會接管所有程式，尤其要確認命令列工具是否經過代理；TUN 模式的涵蓋範圍也取決於路由、權限與設定。測試環境若有變更，應在記錄中清楚標註。
DNS 解析會影響首次連線所需時間與內容分發節點的選擇。DNS 查詢路徑與實際流量出口不一致，是值得確認的訊號，但不能只憑解析器所在地就判定發生 DNS 外洩。應綜合用戶端 DNS 策略、查詢路徑與檢測結果判斷；同樣地，出口位址改變也無法單獨證明 DNS 路徑符合預期。
如果測速網站運作正常，特定網站卻很慢，先檢查該網站套用的規則、DNS 解析結果與連線錯誤，再嘗試固定出口重新測試。不要一次修改大量規則，否則難以判斷改善來自哪項變更。訂閱連結可能包含存取憑證，排查時應遮蔽連結與帳號資訊。
線路與協定：名稱不能取代測量
直連、中轉與 IEPL 專線描述的是傳輸路徑的組織方式。直連通常指用戶端直接連線至境外伺服器；中轉則透過入口轉送；IEPL 專線著重於專用傳輸區段。即使採用專線，家用網路、服務入口與目標網站仍可能成為瓶頸，不能把線路類型視為端對端效能保證。
Shadowsocks、VMess、Trojan、VLESS 屬於不同的代理協定架構；Hysteria2 與 TUIC 則使用以 QUIC 為基礎的傳輸方式。實際表現取決於用戶端實作、設定、裝置負載、網路對 UDP 的處理方式與伺服器條件。不能只憑協定名稱推斷哪個「最快」；即使使用相同協定，不同線路的表現也可能相差甚大。
跨平台比較時，也要考慮流量接管方式：桌面端可能使用系統代理或 TUN，行動裝置則常透過系統提供的網路延伸功能接管流量。同一份訂閱匯入不同用戶端後，規則、DNS 與協定支援未必相同。若要比較線路，應先固定平台與用戶端；安裝及匯入問題可參考使用教學確認。
整理結論：保留測試條件，也保留失敗紀錄
可靠的結論應寫明「在這台裝置、這個網路與這些時段下，某條線路較適合某項任務」，而不是籠統宣稱某項服務永遠最快。記錄測試範圍、保留失敗樣本，並註明未測試的地區、平台與應用程式，日後遇到變化時才有比較依據。
如果所有線路都同時變慢，優先檢查本地網路與共同目標；若只有某條線路異常，再檢查其入口與出口；若只有某個應用程式出現問題，則先確認分流、解析與伺服器限制。依影響範圍逐步縮小問題，比頻繁切換節點更容易找出可重現的原因。
最後，保留適合常用任務的主要線路與備用線路，並定期在常用時段重新確認。測速是選擇線路與排除問題的工具，不等於實際體驗；只要日常任務持續順暢，且失敗情況有清楚解釋，通常不必繼續追求截圖上的更高峰值。