VPN速度測試實測比較：自行測出真實網速的方法

VPN 速度測試與實測比較，重點不是找出最高的下載數字，而是在相近條件下確認線路能否持續滿足自己的使用需求。先測本地網路，再固定測速目標，分時段重複測量，最後以實際應用驗證。如此得出的結果，才能協助判斷該更換線路、調整分流，還是先排除本地網路問題。

本文提供的是測試方法，不是線路成績單。網頁測速、用戶端探測和檔案下載觀察的是不同環節，結果不應直接混在一起比較。記錄時一併寫下裝置、連線網路、節點、測速伺服器和代理模式，之後比較才有依據。

先分清延遲、吞吐量與封包遺失

延遲描述請求與回應往返所需的時間，會影響網頁互動、遠端操作和通話回應。吞吐量描述一段時間內實際傳輸的資料量，更能反映大型檔案的下載能力。抖動是延遲的波動程度；即使平均延遲不高，波動明顯也可能影響即時應用的使用體驗。

頻寬通常指連線容量，而測速頁面顯示的下載速度，是當下條件測得的吞吐量。它同時受本地連線、國際路徑、出口資源和測速伺服器影響。別把單次測得的峰值，當成所有網站都能達到的固定速度。

瀏覽器測速的延遲可能來自應用層請求，不等同於系統 ping 使用的 ICMP 往返時間。不同工具測量抖動、封包遺失的方法也可能不同。比較時請固定工具與測試類型，別只因為單位相同，就把結果視為同一種測量。

建立基準，確認流量確實經過線路

正式測試前，先在關閉代理的情況下測試本地網路。優先使用穩定的有線連線；使用無線網路時，保持裝置位置和無線基地台不變。暫停雲端硬碟同步、系統更新和大型檔案下載，並確認同一網路中的其他裝置沒有持續占用上傳或下載頻寬。

基準測試要區分用途：本地可連線的測速目標用來確認網路連線是否正常；同一個國際測試目標則用來觀察啟用線路前後的差異。如果關閉代理時無法連上目標，就記錄「基準無法連線」，不要填成速度為零，也不能據此計算加速比例。

啟用用戶端後，先前往IP 檢測頁確認瀏覽器出口，再檢查測速網站網域命中了哪條分流規則。瀏覽器使用代理，不代表命令列工具也會使用代理；系統代理通常不會接管所有程式。使用 TUN 模式時也要確認用戶端路由設定，不能只看開關狀態。

出口 IP 改變，只能表示目前檢查請求的出口有所變化，不能證明測速流量和所有應用都經過同一條線路。對照用戶端連線紀錄，確認測速網域、目標位址和出站節點，避免測到直連路徑，卻把結果記在線路名稱下。

如何選擇測速工具與目標伺服器

網頁測速適合快速比較，但要手動固定測試伺服器。自動選擇通常會優先挑選距離近、回應快的目標；切換線路後可能改用另一台伺服器，結果便失去可比性。如果工具不支援固定目標，請保留目標名稱，並分組分析不同目標的紀錄。

測速伺服器應符合實際用途。測試出口附近的伺服器，較能反映線路到出口區域的傳輸能力；測試實際服務所在區域，才更接近完整的存取路徑。前者速度快、後者速度慢並不矛盾，中間可能還有跨區互連、內容傳遞節點或目標網站本身的限制。

命令列工具方便重複測量，但應從官方管道取得，並確認代理支援方式。有些工具會讀取代理環境變數，有些需要另外設定參數，也有些連線不受系統代理控制。使用可信任的下載來源觀察持續傳輸時，也要排除檔案快取、伺服器限速和磁碟寫入瓶頸。

多連線測速會同時建立多個傳輸連線，通常能更充分利用線路；單連線測試則較接近某些檔案下載情境。兩者可以互相補充，但不能混成同一組平均值。工具版本、連線模式、單位和測試目標都應保持一致，也別只留下截圖中的最高值而不保留原始結果。

分時段重複實測，保留完整紀錄

國際路徑會受時段和壅塞影響。在自己常用的工作時段、晚間和離峰時段安排測試，比只挑某次網路順暢時測一次更有參考價值。每個時段都要重複測量，並盡量固定裝置、網路、目標和用戶端設定；同一台裝置不要同時執行多個測速工作。

1. 記錄環境。寫下日期、時段、連線方式、用戶端版本、節點名稱、協定與代理模式。節點名稱只是識別資訊，不能取代實際出口檢查。
2. 測量基準。關閉代理，檢查本地可連線的目標和可用的對照目標；若發現網路連線異常，先排除問題再開始比較線路。
3. 連線並確認路徑。確認出口和測速連線紀錄，等待連線穩定，不要在線路切換期間啟動測試。
4. 固定目標並重複測量。記錄延遲、下載、上傳，以及工具提供的抖動和封包遺失數據。未提供的項目請填「未測」，不要用零代替。
5. 交替比較候選線路。避免先測完某條線路，隔很久才測另一條。交替測試有助於減少短時間網路變化造成的偏差。
6. 驗證實際任務。使用平常會用的網頁、會議或下載工作進行驗證，並記錄卡頓、中斷、重新連線及完成情況。

測速本身會耗用流量，尤其是持續吞吐量測試。先確認連線與路徑，再進行必要的傳輸測試，不必長時間反覆刷新。VPNOC 月租方案的流量會在開通日每月重置；流量包用完為止，永久有效。測試耗用的流量也應納入自己的流量預算。

除了平均值，也要看波動與失敗

在相同條件下取得的有效結果，可以分別計算延遲、下載和上傳的算術平均值，也就是各項測量值的總和除以有效測量次數。同時保留中位數、最低值和最高值：平均值方便概括，中位數較不受極端結果影響，數值範圍則能反映表現是否忽快忽慢。

不要把不同伺服器、不同協定或不同網路的結果混在一起取平均。測試失敗也不能從紀錄中刪掉。完整傳輸測試若因中斷而沒有結果，應另外記為失敗，不要任意填寫吞吐量；連線是否可靠，以及連線成功後的速度，應分開評估。

異常值需要說明，不應為了讓結果好看而刪除。如果確認當時發生系統更新、無線網路重新連線或選錯伺服器，可以標記為環境干擾，並保留排除原因。找不到原因的低速紀錄，仍代表實際使用時可能遇到的情況。

測速很快，應用卻很慢？如何排查

先檢查分流。測速網域可能使用國際線路，目標應用卻被規則設為直連；也可能剛好相反。應用還可能使用不同網域、獨立的代理設定或不同傳輸方式。逐一查看連線紀錄，比反覆切換所有開關更容易找出問題。修改規則後需要重新建立連線，既有連線不一定會立即改走新路徑。

接著檢查 DNS。解析緩慢會拖延網頁首次載入，解析結果也會影響內容傳遞節點的選擇。檢查 DNS 有助於確認解析請求是否依預期路徑傳送，但解析器所在地與出口所在地不同，本身並不足以證明有洩漏。應一併檢查用戶端 DNS 設定、加密 DNS 設定和實際請求路徑。

如果測速時的長連線傳輸正常，網頁卻一直無法開啟，也應檢查目標網站狀態、瀏覽器擴充功能、連線建立過程及本地資源使用情況。下載速度正常但上傳速度慢，也可能影響會議、同步和確認回應。比較閒置和負載狀態下的延遲，有助於找出傳輸占滿線路後的排隊問題。

線路類型和協定只能提供排查方向。直連、中轉、IEPL 專線描述的是不同的路徑安排方式；專線不代表到目標網站的端對端速度固定。不同協定也有不同的傳輸取捨，例如 Hysteria2 和 TUIC 以 QUIC 為基礎，表現會受 UDP 路徑條件影響；協定名稱本身不能取代相同條件下的測量。比較協定時，也應盡量固定路徑和出口。

保留一份可供複查的比較結論

最後將紀錄整理成符合自身需求的結論：哪條線路適合互動操作，哪條適合持續傳輸，哪些時段需要備用選擇。若更換連線網路、用戶端設定或目標服務區域，就需要重新驗證原有結果。測速報告應說明適用條件，不應把局部觀察寫成長期保證。

• ✅ 本地網路基準正常，測試期間沒有其他持續傳輸工作干擾。
• ✅ 已確認出口與分流紀錄，知道測速請求實際經過哪條路徑。
• ✅ 同一組結果使用相同的目標、工具、連線模式和單位。
• ✅ 已涵蓋常用時段，並保留平均值、波動範圍與失敗紀錄。
• ✅ 已用實際應用驗證，而非只根據下載峰值選擇線路。
• ❌ 不混算不同測試條件，也不把未測項目或失敗結果填成零。

若要進一步確認用戶端入口與基本設定，可參閱使用教學；想了解線路與協定的差異，可參閱協定參考。先確認路徑，再比較指標，最後以實際任務判斷，才能留下可重現、也能用於排除問題的測速紀錄。