測 VPN 速度時，重點不是找出最高下載速度，而是固定測試條件，確認流量確實經過目標線路，再觀察延遲、封包遺失與實際使用情況。以下整理可重複操作的自測流程，並比較不同工具能測量什麼、又無法證明什麼。
本文不會發布虛構的線路實測排名，也不會把工具示意畫面當成測試結果。「實測比較」的重點，是讓你在自己的裝置與網路上進行對照：同一條線路，瀏覽器測速、用戶端延遲和影片播放可能各有不同結果，原因往往是測量的對象不同。
先分清測速指標與實際體驗
測速頁面顯示的下載數值，反映裝置與測試伺服器之間的傳輸表現，不代表連上任何網站都能達到相同速度。網頁開啟、影片緩衝和遠端會議也會受到網域解析、建立連線、目標網站負載及應用程式自身策略影響。
| 指標 | 主要反映 | 判讀限制 |
|---|---|---|
| 下載吞吐量 | 持續接收資料的能力，影響下載與影片緩衝 | 受測試伺服器、並行連線及本地頻寬限制 |
| 上傳吞吐量 | 傳送檔案、同步資料與會議上傳能力 | 下載速度快，不代表上傳也快 |
| 往返延遲 | 請求與回應往返所需的時間 | 必須同時說明測試目標與探測方式 |
| 抖動 | 延遲的波動程度，影響即時影音的連續性 | 不同工具的統計方式可能不同 |
| 封包遺失 | 探測時未收到預期回應的情況 | 須排除探測封包遭限速或過濾的可能 |
| 負載下延遲 | 下載或上傳占用網路時的回應變化 | 也可能反映本地路由器的排隊問題 |
不宜用統一的「合格延遲」取代情境判斷。遠距線路會有傳播延遲，適合傳輸大型檔案的線路，也未必適合互動式會議。先確認自己的任務是否順暢，再用指標解讀現象。
建立本地基準，確認分流路徑
測試前暫停雲端硬碟同步、系統更新和其他下載，並關閉正在執行的測速工作。盡量維持裝置、連線方式與位置不變；若條件允許，使用有線連線以排除無線干擾。無法使用有線連線時，也應記錄無線環境，不要直接比較靠近路由器與隔著牆使用時的結果。
先在未啟用代理的情況下，測試可正常連線的目標，確認本地網路是否已經壅塞。這份基準只用來辨識本地瓶頸：若基準測試與代理測試使用不同伺服器，兩者不能直接相除，得出所謂的線路損耗。
接著啟用用戶端，記下所選節點與運作模式。規則分流可能讓測速網站直接連線，即使用戶端顯示已連線，也不能據此認定測試流量經過代理。請查看用戶端連線記錄，確認測速網域符合的規則、出口策略及實際節點。測試期間暫時切換到方便核對的模式，可減少變因；完成後再恢復日常規則。
確認出口不等於確認所有流量：查詢網頁顯示的出口位址，只能說明該次查詢所走的路徑。測速資料可能使用其他網域或連線，仍須確認相關連線是否符合預期規則。系統的 ping 指令也可能繞過只處理瀏覽器流量的代理。
測速工具比較：依測量目標選擇
不同工具測出不同結果並不罕見。瀏覽器測試可能透過多條並行連線填滿頻寬，實際下載檔案時卻可能只使用較少連線；自動選擇的伺服器也可能隨出口地區改變。比較線路時，建議固定使用同一工具與測試伺服器，並記下伺服器名稱，避免把伺服器變動誤認為線路變動。
| 工具或方法 | 適合觀察 | 使用時注意 |
|---|---|---|
| Speedtest | 固定伺服器後的吞吐量與延遲比較 | 保留伺服器資訊；網頁與應用程式的測試路徑可能不同 |
| Fast.com | 連至 Netflix 測試基礎設施的傳輸表現 | 無法證明帳戶能播放特定地區的內容 |
| Cloudflare Speed Test | 下載、上傳、延遲及負載變化 | 結果反映通往其測試基礎設施的路徑 |
| 用戶端延遲測試 | 快速檢查節點是否有回應 | 可能使用 TCP 連線或 URL 探測，請參閱用戶端說明 |
| ping / mtr | 支援觀察探測路徑上的延遲與回應情況 | ICMP 不一定會經過代理；中間節點未回應不代表服務流量有封包遺失 |
| 實際應用程式與檔案傳輸 | 目標任務的可用性與持續表現 | 受目標服務限速、快取及帳戶規則影響 |
較穩妥的做法是：用瀏覽器工具觀察頻寬與負載變化，用戶端記錄核對路徑，再以目標應用程式驗證實際體驗。不要同時執行這些測試，因為它們會互相占用頻寬，測試結果也就不再獨立。測速會消耗方案流量，尤其是持續高速傳輸時，不宜反覆自動執行。
可重複操作的實測步驟與記錄方式
- 記下測試環境。記錄裝置系統、用戶端版本、連線方式、電信業者、當地時間，以及是否有其他明顯的網路使用情況。
- 測量本地基準。確認基本網頁與本地網路運作正常；若基準本身波動明顯，先排查連線環境。
- 固定目標線路。暫時避免自動切換策略造成干擾，確認實際連線的節點，不要只看策略群組名稱。
- 確認測速路徑。查看連線記錄，確認測試流量經過該節點，再記下測速工具與伺服器。
- 等網路閒置後再測。保留每次結果及波動範圍，不要只記下最高值；中斷或失敗也應一併記錄。
- 驗證實際任務。播放目標影片、上傳常用檔案或進行會議預檢，觀察啟動等待時間、持續緩衝情況與聲音是否連貫。
- 在常用時段複測。盡量維持其他條件一致，比較離峰時段與晚間尖峰時段的變化，再決定主要與備用線路。
可直接使用下方文字進行記錄。請勿將帳戶憑證或完整訂閱網址貼進測速筆記；向他人求助時，也應先移除截圖中的敏感資訊。
當地日期與時段：
裝置系統與用戶端版本：
本地網路與連線方式：
所選節點、實際節點與運作模式：
測速工具與測試伺服器：
測速連線符合的規則：
下載、上傳、閒置延遲與負載下延遲：
抖動或封包遺失的探測方式：
重複測試的波動與失敗情況：
目標應用程式的實際表現：比較不同節點時，交替測試比先測完一條線路、再長時間測另一條更能減少時段差異的影響。仍無法完全排除網路變化，因此結論應寫成「在這個環境與時段較合適」，而不是替線路貼上永久的快慢標籤。
尖峰時段、協定與線路類型如何影響結果
避開尖峰時段，只能測出網路較空閒時的表現，無法得知晚間是否順暢。若主要在晚間使用，就應將尖峰時段納入測試，並與當地其他時段分開記錄。本地網路、線路入口、跨境傳輸及目標服務都可能壅塞，單次速度下降不足以判斷問題出在哪個環節。
IEPL 專線通常指由電信業者提供、以乙太網路專線承載的服務；中轉表示流量經由中間伺服器轉送；直連一般指用戶端直接連至境外入口。這些詞描述的是承載方式或網路拓撲的不同層面，也可能搭配使用。標示專線不代表從裝置到目標網站的全程都有相同保障，更不能取代本地實測。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC 屬於不同的代理協定體系，具體實作與傳輸設定會影響連線行為。Hysteria2 與 TUIC 使用以 QUIC 為基礎的傳輸方式，網路對 UDP 的處理可能影響實際表現；其他協定也不能只憑名稱判斷速度。只比較服務實際提供、用戶端明確支援的設定，避免同時更換協定、地區與伺服器後，將結果差異歸因於協定。
同一份訂閱在桌上型電腦與行動裝置上的表現不同，也可能是用戶端核心、系統代理涵蓋範圍、TUN 或系統網路延伸功能、省電限制及無線連線差異所致。匯入訂閱後，先確認節點與規則已更新；不要為了追求測速數字，隨意安裝來源不明的設定。
下載很快卻不好用：依症狀排查
- ✅ 網頁第一次開啟很慢：檢查網域解析與連線建立。DNS 設定、快取和規則比對都可能影響首次開啟；下載頻寬高也無法排除這些問題。
- ✅ 下載時會議卡頓：比較閒置與負載時的延遲，暫停大量傳輸工作後再試。問題可能出在本地上傳排隊，而非節點吞吐量不足。
- ✅ 用戶端延遲低，但網頁載入慢：確認探測目標。連上代理入口很快，不代表從入口連到目標網站也很快。
- ✅ 只有某個平台異常：檢查該平台的可用地區、帳戶要求與分流規則，不能直接推斷整條線路都失效。
- ❌ 看到中間節點未回應，就認定有封包遺失：路由設備可能降低探測封包的優先級，應搭配最終目標的回應與應用程式表現判斷。
- ❌ 只保留最高速度的截圖：這會忽略尖峰時段的速度下降、測試失敗與持續傳輸波動，無法作為日常選線的依據。
DNS 洩漏檢查和速度測試是不同任務。前者關注解析請求是否經過預期路徑，後者關注傳輸效能。解析服務位於某個地區，單憑這點不足以證明有洩漏；應搭配用戶端 DNS 模式、系統設定與預期解析路徑判斷，也不要把出口位址變化當成 DNS 設定正確的證據。
回報問題時，提供發生時段、用戶端版本、節點名稱、目標服務及已隱去敏感資訊的連線記錄，比只說「速度慢」更容易找出原因。基本設定可參考使用教學，常見連線問題請查看說明中心，線路資訊請參閱線路頁面。
結論：準確的 VPN 測速，是一份註明條件的比較記錄，而非單一最高值。先排除本地瓶頸，再確認流量路徑；固定工具與目標，涵蓋常用時段，最後以實際應用驗證。主要線路應優先滿足任務穩定性；備用線路也應在相同條件下實際測試過。