VPN速度測試，先確認測的是哪一段路徑
VPN 速度測試要怎麼做才準確？先固定裝置、線路、測速伺服器和分流方式，再於常用時段重複測試。下載峰值只是結果之一；判斷網頁載入、影片緩衝和會議卡頓，還要綜合延遲、抖動、封包遺失與持續吞吐量。
一次測速通常會經過裝置、本地網路、電信業者網路、服務入口、出口，最後抵達測速伺服器。任何一段壅塞都可能拉低結果。因此，測速網站顯示的速度並非單一節點的性能標籤，而是整條路徑當下的表現。
尤其要確認測速流量確實經過代理。規則分流可能讓測速網站直接連線，也可能讓瀏覽器走代理、命令列工具卻直接連線。可參考用戶端連線記錄、規則命中資訊，以及在相同工具環境下查到的出口 IP；只在瀏覽器查看 IP，無法證明所有應用程式都走相同路徑。
延遲、抖動與吞吐量要怎麼看
「快」至少包含回應即時與傳輸順暢兩個面向。低延遲適合互動，大吞吐量適合傳輸資料；兩者彼此相關，卻不能互相取代。網頁還要解析網域、建立連線並等待伺服器回應，因此即使下載測速成績不錯，網頁仍可能載入緩慢。
| 指標 | 實際意義 | 主要觀察情境 | 容易誤判之處 |
|---|---|---|---|
| 延遲 | 請求往返指定目標所需的時間，通常以 ms 表示 | 網頁互動、遠端操作、語音通話 | 用戶端測得的延遲不一定等於應用程式的連線延遲 |
| 抖動 | 延遲隨時間變化的程度 | 會議、通話、即時互動 | 平均延遲低，仍可能有明顯的瞬間波動 |
| 封包遺失 | 測試封包未成功送達或未收到回應 | 排查連線中斷、重傳與停頓 | 測試封包遭限速或過濾，不一定代表實際服務也有相同程度的封包遺失 |
| 下載吞吐量 | 單位時間內實際接收的資料量，通常以 Mbps 表示 | 影片緩衝、檔案下載 | 短時間峰值不等於長時間可維持的速度 |
| 上傳吞吐量 | 單位時間內實際傳送的資料量 | 雲端備份、傳送檔案、視訊會議 | 只看下載速度，會忽略上傳不足造成的問題 |
還要區分閒置延遲與負載延遲。線路閒置時回應很快，但下載或上傳佔滿頻寬後明顯變慢，可能與排隊、路由器緩衝或頻寬競爭有關。若只有網路忙碌時延遲升高，不應直接歸因於出口距離。
不同工具計算抖動的方式與取樣方法可能不同，結果不宜直接混在一起比較。下載工具常用 MB/s，測速網站常用 Mbps，也不能只看數字大小下結論。記錄時保留原始單位，必要時再統一換算。
測速工具比較：分開診斷與應用驗證
挑選工具時，先想清楚要回答什麼問題，再看測試結果。想判斷大型檔案的傳輸能力，就測吞吐量；想找出卡頓原因，就觀察延遲與連線過程；想確認目標服務能否順暢使用，最後仍要回到應用程式本身測試。
| 工具或方法 | 適合判斷 | 使用注意事項 |
|---|---|---|
| Speedtest | 指定測速伺服器的下載、上傳與延遲表現 | 固定伺服器與測試模式，避免自動選點改變比較條件 |
| Fast.com | 連線至 Netflix 內容傳遞基礎設施時的傳輸表現 | 不代表所有影音平台的速度，也不能證明能否存取其片庫 |
| ping 與路由追蹤 | 可回應目標的延遲變化，以及部分網路路徑線索 | 一般代理不一定會轉送 ICMP；中間節點沒有回應，不代表線路故障 |
| 瀏覽器開發人員工具 | 網域解析、建立連線、等待回應與載入資源的過程 | 留意快取狀態、頁面資源來源與代理規則 |
| 直接使用目標應用程式 | 播放緩衝、會議品質、下載穩定度 | 也會受到應用程式伺服器、帳戶權限與內容傳遞策略影響 |
自動選取的測速伺服器可能隨出口變更。切換線路後成績變好，原因可能是測試終點較近，而非整條線路的表現提升。若要比較不同線路，應盡量固定終點；若要了解某條線路的日常體驗，則應再測試自己常用的服務。
命令列工具適合重複記錄，但要先確認是否支援代理。有些工具會讀取代理環境變數，有些需要另外設定，也有些流量不會經過系統代理。瀏覽器測試正常、終端機卻失敗時，應先確認路徑，不要急著判定線路有問題。
可重現的實測步驟與記錄方式
一份實用的測試記錄，應讓日後的自己看得懂「當時是怎麼測的」。不必追求複雜的儀表板，記下網路環境、用戶端模式、線路、目標伺服器、時段和使用體驗即可。變動的條件越少，差異就越容易解釋。
- 建立本地基準。暫停雲端硬碟同步、系統更新和其他大量傳輸工作。先確認本地網路連線正常；若能使用有線網路，優先採用有線連線；若使用 Wi-Fi，則保持裝置位置和頻段一致。
- 固定測試條件。使用相同的裝置、用戶端版本和測速工具，並選定同一台測速伺服器。記錄使用的是系統代理、規則分流還是虛擬網卡模式，並確認目標請求確實經過所選線路。
- 觀察閒置與負載狀態。先記錄閒置時的回應，再進行下載和上傳測試。留意傳輸過程是否停頓，以及網路忙碌時互動是否變慢，不要只截取最高速度。
- 重複測試並保留完整結果。在相同條件下重複測試，觀察結果的分布情形。樣本足夠時，可用中位數描述典型表現，同時保留異常和失敗記錄，不要只挑最快的一次。
- 回到目標應用程式測試。播放常看的內容、開啟常用頁面或進行會議測試。記錄是否出現緩衝或長時間等待，並留意應用程式本身的錯誤訊息。
- 再切換一項變數。保持其他條件不變，分別比較線路、網路連線方式或用戶端模式。每次只改變一個因素，才能較容易找出差異來源。
可直接使用以下記錄欄位：日期與時段、網路連線方式、裝置與用戶端、代理模式、線路名稱、測速伺服器、下載與上傳速度、閒置與負載延遲、實際應用體驗。若工具沒有提供某項數據，請標註「未測」，不要憑印象編造數值。
如何選擇測試時段？為什麼要特別觀察尖峰時段
測試時段應配合自己的使用習慣，而不是挑最容易測出高分的時間。白天用於工作、晚上看影片，就分別記錄這兩種情境。不同地區的電信業者與目標服務，負載變化的時間各不相同，沒有適用於所有人的固定壅塞時段。
保持測試條件一致，在常用的忙碌時段和相對空閒時段進行比較，再跨日複測。若晚間吞吐量下降、延遲波動增加，空閒時又恢復，表示路徑可能有時段性的資源競爭；但競爭也可能來自家用網路、本地電信業者、服務入口或目標伺服器。
直連、中轉和 IEPL 專線代表不同的網路架構，不能取代實際測速。中轉會增加路徑環節，但合適的入口與路由也可能改善體驗；IEPL 專線仍可能受到共享資源和出口容量影響。名稱只能協助了解路徑，無法保證端到端的表現。
同樣地，協定名稱不代表速度排名。連線協定、傳輸方式、裝置效能和網路環境都會影響表現；只有在用戶端與伺服器實際支援的設定下測試，結果才有參考價值。不要為了比較而啟用來源不明的設定，也不要把訂閱連結貼到公開的測速報告中。
依照實際狀況排查，不要一再切換節點
- ✅ 所有線路都很慢：先檢查本地網路、背景上傳、Wi-Fi 訊號和裝置負載，再更換網路連線方式複測，確認問題是否隨本地環境改變。
- ✅ 只有某個測速網站很慢：固定測試條件後改用另一個終點，再測試目標應用程式。原因可能是測速伺服器負載較高，或出口至該伺服器的路由不同。
- ✅ 測速成績高，網頁卻很慢：檢查網域解析、連線建立和首位元組等待時間；對照用戶端的規則命中情況，確認頁面所需資源沒有走不同路徑。
- ✅ 影片播放順暢，會議卻卡頓：著重檢查上傳速度、抖動、負載延遲和應用程式的即時傳輸狀況，不要繼續只比較下載峰值。
- ❌ 只因 ping 沒有回應就判定無法使用：測試協定可能遭到過濾，或測試流量沒有經過代理。應搭配實際連線與應用程式請求一併判斷。
DNS 也需要分開理解。DNS 洩漏是解析請求未依預期路徑傳送的問題，不等於「解析速度慢」。只查看出口 IP，無法排除解析路徑不同；應搭配用戶端 DNS 設定、系統設定與檢測結果進行確認。不同作業系統和代理模式的處理方式各異，請依目前使用的用戶端說明調整。
Windows、macOS、Linux 的系統代理和虛擬網卡模式，涵蓋範圍可能不同；行動裝置也可能受到省電設定和背景執行限制。跨平台比較時，應記錄這些差異，不要直接將手機和電腦的結果當成線路優劣的證據。
向客服回報時，提供去識別化的測試條件、時間、線路、工具與錯誤狀況即可。請勿公開訂閱連結、帳戶憑證和完整設定；分享截圖前也要確認其中未包含這些資訊。