VPN 速度實測比較的重點是固定測試條件，而不是追求最高分。先建立本地網路基準，再以相同裝置、目標和測試方式比較線路，最後在實際使用的應用程式中驗證。單張下載速度截圖，無法說明視訊會議是否穩定，也無法證明尖峰時段能否正常使用。

關鍵指標：除了下載速度，還要看什麼

完整的連線路徑包含本地網路、線路入口、出口及目標伺服器。測速結果反映的是測試期間整條路徑的表現，並非某個節點永遠不變的效能。先了解各項指標，才能判斷該換線路，還是該檢查無線網路。

常見測速指標與實際使用體驗的對照
指標 意義 主要觀察項目 容易誤解之處
往返延遲 從送出請求到收到回應所花的時間，通常以 ms 表示。 會議互動、遠端桌面、網頁請求。 延遲低，不代表大型檔案一定下載得快。
抖動 連續延遲測量值的變化程度。 語音是否斷續、畫面速度是否忽快忽慢。 不同工具的計算方式可能不同，不宜直接比較。
封包遺失 測試封包未依工具的判定方式收到回應。 持續遺失是否伴隨卡頓、重新傳送或斷線。 裝置可能會限制探測封包，需搭配應用程式實際測試。
下載與上傳吞吐量 單位時間內實際傳輸的資料量，常以 Mbps 表示。 下載檔案、上傳附件、傳送會議畫面。 測速峰值不等於整段傳輸期間都能維持相同速度。
負載下延遲 上傳或下載占用網路時測得的回應時間。 傳送檔案時，其他互動是否明顯變慢。 閒置時延遲正常，網路忙碌時仍可能發生排隊。

記錄速度時，請保留單位。測速網站常用 Mbps，下載軟體可能顯示 MB/s，不能只比較前面的數字。也別把用戶端清單中的「延遲」直接當成實際服務延遲：有些用戶端測試的是伺服器連線，有些則會連到指定網址，測試目標和請求過程都不相同。

挑選工具：先確認測量的是哪段路徑

瀏覽器測速適合觀察整條連線路徑的吞吐量。可使用 Speedtest 或其他會顯示測試目標的工具，但請手動固定同一台伺服器。自動選擇伺服器時，可能因出口改變而連帶換了測試終點；切換線路後，結果便混入目標距離和伺服器負載的差異。

系統內建的 ping 適合檢查基礎網路的往返回應，但通常會傳送 ICMP 封包。只啟用系統代理時，這類封包通常不會經過應用程式代理；啟用 TUN 後是否會被接管，則取決於用戶端的實作。因此，終端機顯示的低延遲不一定來自目前使用的代理線路。用戶端的 HTTP 探測較接近網頁請求，但仍應確認探測目標和分流規則。

若要測試持續吞吐量，可使用 iperf3，但應連線至自己有權使用的伺服器。公用伺服器的壅塞和限制都會影響結果，不適合作為判斷線路效能的唯一依據。一般使用者不必特別架設測試環境：固定瀏覽器測速目標，再觀察實際會議或檔案傳輸，通常更容易重現測試結果。

測速前，先確認測試流量確實經過所選線路。可根據用戶端連線記錄中的匹配規則、出口位址和測試目標判斷，別只看用戶端是否顯示已連線。連線記錄可能包含造訪目標，分享前請遮蔽敏感資訊。

建立基準：排除本地網路干擾

先暫停雲端硬碟同步、系統更新和背景下載。固定裝置位置與連線方式；若條件允許，使用有線網路，避免無線訊號變動。測試期間不要同時開啟多個測速頁面，否則它們會爭用頻寬，測出的只是彼此競爭後的結果。

關閉代理後，選擇本地網路可直接連線的目標，觀察基礎延遲和持續傳輸是否正常。如果直連也反覆卡頓，應先檢查路由器、無線干擾和網路連線。這裡的基準是用來找出本地問題，不代表中國大陸本地直連測速和國際代理測速可以直接分出高下：兩者經過的路徑不同。

  • ✅ 記錄裝置、作業系統、用戶端版本與連線方式，後續比較時保持一致。
  • ✅ 確認方案狀態、剩餘流量和訂閱更新正常，避免把狀態異常誤當成線路效能問題。
  • ✅ 記錄系統代理或 TUN 模式、分流規則及目前節點，確認測速流量的實際路徑。
  • ✅ 關閉其他會占用網路的工作，測完目前項目再開始下一項。
  • ❌ 不要直接用不同裝置、不同無線網路位置或不同測速伺服器的截圖排名。

訂閱連結是用戶端取得設定檔的憑證，不是測速網址。匯入後請先更新設定，再選擇線路；不要將完整訂閱連結交給不明測速網站，也不要放進公開截圖。用戶端下載與匯入訂閱的方式，可參閱使用教學。

平時與尖峰時段的實測步驟

選擇平常使用服務的時段進行測試，別只在網路閒置時測。尖峰時段沒有適用於所有地區和電信業者的固定界線，應以當地實際繁忙時段為準。平時與繁忙時段採用相同流程，才能觀察線路在負載變化下的表現。

  1. 固定測試條件。記下測速目標、連線網路、用戶端模式與節點，並確認沒有背景傳輸。
  2. 先觀察閒置時的回應。記錄延遲變化與異常中斷，不要只保留最低值。若工具會顯示封包遺失，請註明使用的探測方式。
  3. 接著測試吞吐量。分別記錄下載、上傳和負載下延遲，留意速度能否維持，而非只有短暫飆高。
  4. 切換待比較的線路。保持目標不變，依相同流程測試。之後再反向調整測試順序，降低時間變化造成的偏差。
  5. 重測異常結果。若出現明顯異常，先檢查本地網路基準，再重複測試同一項目。保留異常紀錄，別只挑最好看的結果。
  6. 回到實際使用的應用程式。開啟平常使用的會議、協作文件或影音平台，觀察互動、緩衝和連續使用情況。

記錄表至少應包含日期與時段、電信業者、連線方式、節點、目標伺服器、測試模式、各項指標及實際體驗。重複測量後，可比較中間值和波動範圍，而非單次最高值。測速會消耗流量，尤其是高吞吐量測試；不必為了刷新峰值反覆測試。

解讀結果：依使用情境判斷，而非單項排名

視訊會議應優先觀察回應是否連續、上傳是否穩定，以及繁忙時段是否出現明顯抖動。遠端桌面更仰賴互動延遲。大型檔案下載則要看持續吞吐量和失敗後的重試情況。觀看影片也會受到平台分配的內容伺服器、帳號狀態和快取影響，不能用測速網站的下載成績取代實際播放測試。

如果下載速度快，但網頁首頁載入緩慢，請檢查 DNS 解析、連線建立和分流設定。DNS 會將網域名稱解析為位址；選用的解析器及解析請求路徑都可能影響結果。所謂 DNS 洩漏，是指解析請求經過非預期路徑，既涉及隱私，也可能影響連線體驗。不能只憑網頁載入緩慢就判定發生 DNS 洩漏，應一併檢查用戶端 DNS 設定和實際解析路徑。

若測速正常，但某個應用程式仍然卡頓，請確認該應用程式是否套用不同規則。瀏覽器可能使用系統代理，其他應用程式卻沒有；TUN 可以接管更多流量，但仍會受到路由、排除項目和用戶端實作影響。排查時請逐項修改並重新測試，避免同時更換 DNS、協定和節點，最後無法判斷是哪項設定造成差異。

線路選擇結論：優先保留在常用時段波動較小、且實際應用程式能正常使用的線路。峰值較高但頻繁停頓的結果，不應只憑下載速度排在穩定線路之前。結論應註明測試網路、目標和時段，不應延伸成適用所有使用者的排名。

線路與協定：測試結果能說明多少

直連通常是本地網路直接連至出口伺服器；中轉則是在路徑中增加轉送環節，表現取決於入口、轉送網路和出口。IEPL 專線描述的是線路傳輸方式，不是應用程式協定，也不代表從使用者裝置到目標網站的每一段都經過專線。即使中間傳輸穩定，本地連線以及出口至目標的路徑仍可能成為瓶頸。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 的傳輸機制與實作各有不同，不能脫離用戶端、伺服器設定和連線網路，給出固定的速度排名。Hysteria2 與 TUIC 以 QUIC 為基礎，仰賴 UDP 路徑；若目前網路限制 UDP，效能可能改變。其他協定也會受到傳輸設定、裝置處理能力和伺服器負載影響。

比較協定時，應盡量固定出口和目標，並註明無法控制的條件。不同平台的系統網路介面、背景策略和用戶端實作也會造成差異。桌上型電腦的結果可用來篩選候選線路，但仍須在行動裝置自己的網路環境下驗證，不能直接照搬結論。

保存紀錄：讓問題能夠重現

最後的紀錄應包含測試條件、原始結果和實際症狀。例如寫清楚「同一個連線網路下，繁忙時段會議上傳畫面停頓，切換線路後改善」，比只說「速度不理想」更有助於排查。若不同線路都變慢，而且直連基準也異常，應先檢查它們共同經過的本地網路。

如需協助，請透過聯絡管道提供用戶端版本、發生時段、線路名稱及已嘗試的檢查步驟。分享截圖前，請遮蔽訂閱憑證、帳號資料和瀏覽內容。更多排查順序請參閱問題診斷。客觀測速不是要證明某條線路永遠最快，而是找出適合目前網路和實際任務、且能持續重新驗證的選擇。