VPN 速度實測比較：工具、時段及指標

進行 VPN 速度實測比較時，應先確認測到的是哪條路徑，再看速度。用戶端顯示已連線，不代表測速網站一定經過所選線路。本文提供可實際操作的測試流程，不捏造線路排名，也不以單次峰值代表長期表現。

最有參考價值的不是一張漂亮的截圖，而是在同一裝置、本地網路和測試目標下，觀察線路於常用時段的表現。下載是否穩定、網頁回應是否即時、通話是否斷續，都應分開記錄。這些情況涉及不同指標，不能用單一總分概括。

測速前，先確認流量路徑

先記下裝置、用戶端、目前使用的網路、所選節點和分流模式。暫停雲端硬碟同步、系統更新及其他下載，並盡量維持裝置位置與供電狀態一致。使用無線網路時，訊號變化及同一網路上其他裝置爭用頻寬都可能影響結果，不能直接將這些波動歸咎於線路。

接著確認測速工具是否經過代理。瀏覽器測速可能遵循系統代理設定，也可能被用戶端規則判定為直連；命令列工具則未必會讀取系統代理設定。TUN 模式通常能接管更多應用程式的流量，但仍會受到路由、排除規則和用戶端實作方式影響。不要只憑模式名稱推斷實際路徑。

可以先查詢公網出口，再查看用戶端的連線記錄，確認測速網域實際套用哪條規則、使用哪個出站。出口查詢只能證明該次查詢請求的路徑；測速服務可能使用不同網域，因此也要核對測試期間的連線記錄。如果記錄中沒有測速請求，先排除路徑問題，不必急著比較成績。

各種測速工具能看出什麼

依照測試目的搭配工具即可，不必一味增加工具。Speedtest 適合觀察連往指定測試伺服器的傳輸量；Fast.com 更貼近其內容傳遞網路的下載路徑；瀏覽器開發人員工具則適合檢查實際網頁請求。各工具使用的伺服器、連線方式和負載都不同，分數不能直接混在同一份排行榜比較。

用戶端節點清單中的「延遲」也要看測試方式。有些只探測伺服器連接埠，有些則透過代理連線至指定網址；兩者未必涵蓋完整的服務路徑。只有測試方法和目標相同，節點清單上的數字才適合互相比較。

測試前也要確認計量單位。頻寬工具常使用 Mbps，下載軟體可能顯示 MB/s；單位不同，數值不能直接比較。保留原始單位即可，不必為了讓結果好看而換算後省略單位。

分開看延遲、抖動和頻寬

互動體驗要看回應速度與波動

延遲表示一次往返需要的時間，抖動則表示延遲隨時間的變化。網頁點擊、遠端操作和語音通話都很重視回應是否穩定。平均延遲看似平穩，但若過程中常出現長時間等待，實際體驗仍可能不佳，因此要一併觀察波動與失敗情況。

閒置時的延遲和下載期間的延遲也不一樣。上傳或下載塞滿線路後，封包排隊可能讓回應變慢。如果下載時網頁明顯變卡，應查看工具是否提供負載延遲，並留意本地路由器、網路連線及線路中的排隊問題，而非只看下載峰值。

持續傳輸要看吞吐量和中斷情況

頻寬測試反映特定目標在特定時間的有效傳輸能力，會受到本地網路連線、國際路徑、出口、目標伺服器及裝置處理能力共同限制。多連線測速容易填滿線路；單一檔案以單一連線下載，可能達不到相同結果，這不代表其中一方必然失真。

解讀丟包也要謹慎。ICMP 探測未收到回應，可能是實際丟包，也可能是目標限速或過濾所致。如果網頁、下載和通話都正常，只有某個探測目標沒有回應，還不足以判定服務連線也有同等程度的丟包。應搭配實際應用程式的重試、連線中斷及連線失敗情況判斷。

在相同時段進行可重現的比較

測試時段應涵蓋自己實際使用網路的時間：平時較空閒的時段，以及經常看影片、辦公或通話的尖峰時段。不要用凌晨的測試結果代表夜間體驗，也不要直接比較不同日期、不同網路下的截圖。測試不同線路時，最好在相近時段輪流測試，並在後續測試中調整順序，減少時段變化造成的偏差。

1. 記錄本地基準。不啟用國際線路，先測試本地網路連線是否正常。基準測試用來找出本地問題，不能直接拿來和不同遠端目標比較線路損耗。
2. 固定共同條件。維持裝置、網路、用戶端版本、分流模式和測試目標一致，並選擇實際會使用的候選節點。
3. 確認出站後再測試。每次切換節點後，都重新核對出口和連線記錄，避免自動選線或故障回退在不知情下改變測試對象。
4. 分開進行各項測試。先測閒置時的回應，再測下載和上傳；不要同時開啟多個測速頁面，讓工具互相爭用頻寬。
5. 加入實際使用情境。開啟常用網站、播放內容、進行通話或下載，記錄載入等待時間、畫質變化和中斷情況。
6. 重複測試並保留異常結果。不要只留下最高成績。記錄一般表現和明顯低谷，測試失敗也應保留原因與狀況。

測速會消耗流量，長時間下載尤其如此。使用有流量額度的方案時，先確認剩餘額度，再決定測試範圍；不必為了追求更高峰值而反覆跑滿下載。方案流量規則可至方案價格頁確認。

記錄表至少應包含：測試日期與時段、本地網路、用戶端和模式、節點名稱、出口地區、工具與目標伺服器、指標原始單位，以及實際使用情境的表現。可以先用文字記錄「持續下載穩定」、「負載時回應變慢」，不必勉強填入沒有的數字。

線路類型與協定不代表速度排名

直連通常是指用戶端直接連線至境外伺服器；中轉則是在路徑中加入轉發環節；IEPL 專線描述的是專用線路資源，不代表從裝置到目標網站的整段路徑都由專人使用。即使使用專線，本地網路連線、出口容量和目標服務仍可能成為瓶頸。中轉可能改善繞行，也可能增加路徑開銷，應在相同條件下測試後再下結論。

Shadowsocks、VMess、Trojan、VLESS 屬於不同的代理協定或協定體系；Hysteria2、TUIC 則採用以 QUIC 為基礎的傳輸設計。實際表現還取決於傳輸設定、實作方式、網路對 UDP 的處理及壅塞情況。光看協定名稱無法判斷「更快」，更不能取代用戶端相容性檢查。

訂閱連結是提供節點和設定給用戶端的入口，不是測速網址。匯入訂閱後，要確認用戶端支援相應格式、協定和傳輸設定；同名節點若在不同用戶端採用不同設定，也不能算是嚴格的同條件比較。初次設定可參考新手指南，線路資訊則請參閱節點說明。

跨平台比較也要考慮作業系統差異。桌面系統的代理設定通常只影響遵循該設定的應用程式；行動裝置則常透過系統提供的 VPN 介面接管流量，但個別應用程式設定、省電限制和背景執行策略都可能改變結果。比較線路時盡量固定用戶端；比較用戶端時，則固定線路和目標。

測速異常時，由近而遠逐步排查

• ✅ 所有節點都很慢：先檢查本地網路、背景傳輸和裝置負載，再更換網路連線複測，避免反覆修改節點設定。
• ✅ 只有某個測速工具很慢：固定測試伺服器，再用另一個工具和實際應用交叉驗證，留意來源伺服器或內容傳遞路徑的差異。
• ✅ 下載速度快但網頁載入久：檢查網域解析、建立連線及等待第一個位元組的時間，區分解析問題、線路回應和網站處理所需時間。
• ✅ 網頁正常但特定應用程式無法使用：檢查該應用程式是否受到直連規則、個別應用程式設定或不支援的傳輸方式影響。
• ✅ 切換節點後結果沒有變化：核對連線記錄和出口，並檢查自動選擇、故障回退策略及是否仍在重用舊連線。

解讀 DNS 結果時也要考慮路徑。解析器所在地區和出口地區不同，不代表 DNS 一定外洩；解析服務可能採用分散式部署。應確認的是：原本應由用戶端處理的查詢，是否繞過預期規則，改由本地網路的解析器處理；以及目標連線是否仍依預期出站。

調整 DNS、分流或模式時，每次只修改一項，再重複相同測試。一次改動多項設定，即使問題解決了，也無法確認是哪一項生效。提交支援單時，可附上已去識別化的時間、節點、用戶端版本、目標網域和錯誤狀況，但不要上傳完整憑證。

如何根據測試結果選擇日常線路

依照用途整理結果，比製作一份總排名更實用。辦公和通話優先看尖峰時段的回應、波動及斷線情況；大型檔案傳輸看持續吞吐量；影片則觀察實際播放是否反覆緩衝。某條線路適合下載，不代表它也最適合互動用途。

最後保留適合日常使用的線路和備用選擇，並註明各自適用的情境。之後若體驗變差，先使用原本的工具、目標和記錄方法複測，再判斷是否真的有所變化。這樣才能留下可供查證的依據，而不是不斷追逐不同測速頁面的最高分。