VPN速度測試實測比較：工具、時段與指標怎麼選才不被誤導

VPN 速度測試實測比較的重點，不是找出最高的下載數字，而是確認在相同裝置、相同目標及相近時段下，線路能否持續滿足實際用途。測速工具測得的是某一段特定路徑，並非服務的固定速度。本文提供可實際操作的對照方法，不提供虛構的線路測試成績。

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

一次網路請求會經過本機裝置、路由器、網路接取、服務線路和目標伺服器，任何環節都可能成為瓶頸。下載吞吐量高，不代表網頁首屏載入快；閒置延遲低，也不代表上傳檔案時視訊會議依然流暢。判斷前，先將指標與使用情境對照。

速度單位也要統一。測速工具常用 Mbps，下載軟體可能顯示 MB/s，兩者分別代表位元和位元組的速率，數值不能直接比較。通訊協定額外負擔、重傳及應用程式處理也會影響檔案下載結果。記錄時保留原始單位，不要把下載軟體顯示的數字直接當成測速頁面的頻寬。

網頁開啟速度還包括 DNS 查詢、建立連線、TLS 交握及伺服器處理。即使線路吞吐量足夠，解析失敗或目標網站回應緩慢，仍會拖長載入時間。因此，遇到「測速很快但網頁很慢」時，應繼續檢查連線各階段，而不是只換另一個測速站反覆測試。

工具選擇：綜合測速與實際應用分開測

Speedtest 這類工具適合觀察多連線下載、上傳和延遲。自動選擇伺服器方便日常檢查，但不適合直接比較不同出口：切換線路後，工具可能改連到另一座城市或另一家電信業者的測試端。若工具支援，應手動固定伺服器，並記錄伺服器名稱及所在地。

Fast.com 用於測試與 Netflix 網路相關的傳輸，可作為觀看情境的輔助參考；但測試成績無法證明帳號能存取特定地區的片庫，也不代表播放特定影片時的持續速度。串流影音的驗證還要檢查地區判定、實際播放、畫質變化及緩衝情況。

系統內建的 ping 可觀察目標的 ICMP 往返回應；mtr 或路徑追蹤工具則可協助定位路徑異常。但本機終端的探測未必會經過代理用戶端，尤其只開啟系統代理時更是如此。先確認探測流量的路由，再判斷結果屬於直連還是代理線路。

不可省略實際應用測試。視訊會議要觀察語音是否斷續、畫面是否凍結；檔案傳輸要注意是否中斷；網頁則比較首次開啟與再次造訪的差異。用常用應用程式補充綜合測速，才能避免把某個測試伺服器的亮眼成績當成所有網站的實際體驗。

測試環境：確認流量確實經過目標線路

先固定裝置和網路接取方式。可以使用有線網路時，優先用有線建立基準；使用 Wi-Fi 時則保持位置不變。暫停雲端硬碟同步、系統更新和其他下載，並確認同一網路中的其他裝置沒有持續占用頻寬。裝置過熱、省電限制及用戶端處理能力，也可能降低吞吐量。

用戶端的「系統代理」、「規則模式」和 TUN 模式並不相同。系統代理通常只影響遵循代理設定的應用程式；規則模式依網域或位址決定直連或代理；TUN 模式接管的範圍則取決於實作方式和設定。即使啟用 TUN，也應核對排除項目與路由，不能只憑模式名稱就認定所有流量都經過線路。

開啟用戶端的連線記錄，確認測速網域符合預計測試的線路。接著用同一個瀏覽器造訪IP 位址檢測頁面，協助確認出口是否符合預期。出口位址變化只能說明該次請求的路徑有所變更，不能證明其他應用程式也經過相同路徑。

訂閱連結會將節點及相關設定提供給用戶端，本身並不是連線通訊協定。更新訂閱後，節點內容、規則或選擇結果可能改變。測試前先完成更新並固定節點，同時記錄用戶端版本、代理模式和通訊協定名稱；不要在同一組對照測試中途更新設定。

DNS 也應分開檢查。網域解析可能由本機系統、用戶端或瀏覽器的加密 DNS 功能處理。所謂 DNS 洩漏，是指 DNS 查詢流量經過的路徑不符合預期的隱私界線，不能只因看到不同地區的解析器就下定論。應結合用戶端 DNS 設定、瀏覽器設定和實際請求記錄進行判斷。

可重現的實測步驟與時段安排

公平比較的原則是一次只改變一個主要因素。比較線路時固定裝置、網路、工具和目標；比較通訊協定時，也要盡量固定出口和線路條件。無法固定的條件應明確記錄，避免把所有差異都歸因於某個品牌或通訊協定。

1. 確認用途。先記下要測的是視訊會議、遠端桌面、下載還是觀看影片，再選擇相應指標。不要測完之後，才挑出對某條線路有利的成績。
2. 記錄直連基準。關閉代理，確認路由已恢復後，再測試本機網路。若直連無法連上國際目標，記錄失敗即可；也可以另外測試本地目標，排查網路接取問題，但不同目標的成績不能直接比較。
3. 連線至固定節點。確認節點名稱、通訊協定、代理模式與出口。在連線記錄中確認測速請求確實連到該節點，待連線狀態穩定後再開始測試。
4. 使用相同工具測試。固定測速伺服器，記錄下載、上傳、閒置延遲及工具提供的其他指標。測試失敗、中斷或結果異常也要留下記錄，不要只保存最高成績。
5. 重複測試並交替順序。每次測試之間留出一段時間，讓網路恢復閒置狀態，並輪流調整候選線路的測試順序。如此可降低背景工作及網路狀況隨時間變化造成的偏差。
6. 補做實際使用驗證。開啟相同的目標網頁、傳輸相同檔案，或進行相同的播放操作。區分首次造訪與快取後的再次造訪，不要把既有快取造成的差異誤認為線路加速。
7. 在常用時段重測。分別記錄工作時段、所在地晚間尖峰及其他實際使用時段的結果。保留日期、當地時間和時區，跨地區比較時尤其重要。

晚間尖峰並非所有網路共同的固定時刻。網路接取業者、線路出口和目標服務各自的負載變化都不同。測試應涵蓋自己常用的時段，而不是只挑容易測出高分的閒置時段。若某條線路在尖峰時段出現異常，重新測試直連基準有助於判斷是否也有本地網路壅塞。

彙整結果時，應關注典型表現和波動範圍，而不只是最大值。保留每次測試結果，並結合中位數表現、持續傳輸及失敗情況來判斷。不同工具計算抖動、封包遺失或負載延遲的方式可能不同，即使指標名稱相同，也不宜直接合併比較。

線路與通訊協定：名稱不能取代測試條件

直連通常指用戶端直接連線至境外伺服器；中轉則會增加入口或轉送環節；IEPL 專線描述的是一種專線傳輸方式，實際接取方式和出口仍須視服務部署而定。路徑較短不一定比較快，多一個轉送環節也不一定比較慢；壅塞、互連品質和目標位置都可能影響結果。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 是不同的代理通訊協定或協定體系，不代表測速等級。實際效能還會受到傳輸方式、實作、加密處理及網路條件影響。VLESS 的安全性須依所採用的傳輸方式和安全層判斷；以 QUIC 為基礎的方案也會受到 UDP 可達性和網路策略影響。

因此，不能拿不同地區、不同線路和不同用戶端的結果，證明某個通訊協定永遠最快。Windows、macOS、iOS、Android 和 Linux 的網路接管方式及背景限制各有不同，行動裝置上的表現應在相應裝置上驗證，不能完全以桌面測試取代。

結果判讀：找出問題所在的具體環節

• ✅ 直連和代理都變慢：先檢查本機網路、背景傳輸、Wi-Fi 和裝置負載，再判斷線路狀況。
• ✅ 綜合測速正常，但只有特定網站很慢：檢查目標服務、DNS、規則比對和出口路徑，避免把網站故障歸咎於整項服務。
• ✅ 下載速度快，但會議仍卡頓：著重檢查抖動、封包遺失與負載延遲，並確認會議應用程式是否經過代理。
• ✅ 只有特定時段變慢：保存相同條件下的重測記錄，確認是否與本地或國際路徑壅塞有關。
• ❌ 只保留最高測速成績：容易掩蓋波動和失敗，無法代表日常使用體驗。
• ❌ 同時更換裝置、節點和工具：無法判斷是哪個因素造成變化，結果也不適合用來排名。

提交故障排查記錄時，請附上測試時間、網路接取方式、用戶端版本、節點名稱、代理模式、目標伺服器和現象描述。截圖請勿包含訂閱連結、帳戶密碼或存取權杖。VPNUG 的聯絡管道是使用者面板的客服工單入口，可用這些記錄說明問題。