VPN 測速：先確認要比較什麼
VPN 測速實測比較的關鍵，是固定測試條件，再依用途解讀結果。下載速度快，不代表視訊會議穩定；用戶端顯示節點延遲低，也不代表目標網站載入快。測試前先確認需求：下載檔案、觀看影片、遠端辦公，還是即時互動。
一次完整的連線會經過本機裝置、家用網路、電信業者接取網路、代理線路和目標服務。測速結果呈現的是這條特定路徑當下的表現，無法單獨證明其中某一段的能力。更換測速伺服器、網路接取方式或分流規則後，結果可能就不具可比性。
判斷原則：先測本地基準，再測代理路徑，最後驗證實際應用。可持續重現的表現，比偶然出現的峰值更具參考價值。
如何解讀頻寬、延遲、抖動與封包遺失
測速頁面通常會把下載速度放在最醒目的位置，但不同用途的瓶頸並不相同。先了解指標與使用體驗的關聯，才不會拿不相關的數字來做選擇。
| 指標 | 代表什麼 | 相關使用情境 | 容易誤解之處 |
|---|---|---|---|
| 下載吞吐量 | 單位時間內實際接收的資料量 | 下載檔案、影片緩衝 | 多連線測速的峰值，不等於單一檔案的持續傳輸速度 |
| 上傳吞吐量 | 單位時間內實際傳送的資料量 | 雲端備份、會議影像上傳 | 下載快，不代表上傳也快 |
| 往返延遲 | 從送出請求到收到回應所需的時間 | 遠端桌面、互動操作 | 只代表到受測目標的往返時間 |
| 抖動 | 連續測量期間延遲的變動程度 | 語音、即時視訊、遊戲 | 不同工具的計算方式可能不同 |
| 封包遺失 | 依工具的計算方式統計，未抵達或未收到回應的情況 | 即時傳輸、連線穩定性排查 | 探測封包未收到回應，不一定代表實際傳輸的資料遺失 |
| 負載時延遲 | 下載或上傳占用線路時的往返延遲 | 一邊傳送檔案，一邊開會 | 閒置時延遲低，忙碌時仍可能明顯變慢 |
頻寬指的是線路容量，測速實際測得的通常是吞吐量。工具常以 Mbps 顯示速率，下載軟體則可能顯示 MB/s，兩者單位不同，不能直接比較數值大小。比較時也要留意工具顯示的是平均值、即時值還是峰值。
抖動也不是「最高延遲減最低延遲」的通用名稱。有些工具依相鄰樣本的變化計算，有些則採用其他統計方式。比較線路時，請使用相同工具和設定；不同工具測得的抖動，不宜混在同一份排名表中。
測速工具：搭配通用測試與實際應用驗證
瀏覽器測速工具
可使用 Speedtest 或 Fast.com 等常見工具觀察吞吐量，但這些工具連線的伺服器和測試機制各不相同。若支援手動選擇伺服器，比較不同線路時應固定同一個目標；若由工具自動選點，則要記錄實際選到的伺服器。自動挑選的近端伺服器，不一定能代表連線至工作網站時所經過的路徑。
瀏覽器擴充功能代理、系統代理和通道模式涵蓋的流量範圍不同。即使測速網頁能正常開啟，也要確認測速連線確實經過待測節點。可搭配用戶端連線紀錄、規則命中資訊和出口 IP 位址檢查，避免將直連結果誤記為代理速度。
系統探測與實際應用
系統內建的 ping 可用來觀察目標回應的變化，但主要使用 ICMP，不能假設它會遵循瀏覽器使用的系統代理。只啟用系統代理時，ping 仍可能直接連線。部分目標也會限制或忽略探測請求，因此逾時不代表線路一定無法使用。
驗證實際應用同樣重要：下載時觀察傳輸是否持續，會議中留意聲音和畫面是否連貫，播放影片時則確認緩衝是否穩定。瀏覽器開發人員工具也能協助區分網域名稱解析、建立連線和等待回應等階段；不過，單次請求的等待時間也會受目標伺服器的處理速度影響。
用戶端的「延遲測試」可能是探測節點入口，也可能是透過節點向指定網址發出請求。先查看用戶端說明，再判斷結果代表路徑中的哪一段；不同用戶端測出的數值，不宜直接互相比較排名。
實測步驟：固定條件後再切換線路
以下步驟適用於電腦，也適用於行動裝置。使用行動裝置時，應額外記錄使用的是無線區域網路還是行動數據，測試期間不要切換接取方式。
- 整理本地環境。暫停雲端同步、系統更新和背景下載，並保持裝置位置與網路接取方式一致。若電腦環境允許，可使用有線連線，減少無線訊號波動造成的干擾。
- 測量直連基準。在不經過代理的情況下，使用目前網路可連線的固定測速目標，記錄吞吐量和延遲。若直連時無法連上目標，請註明缺少可比較的基準，不要把失敗結果當成零速。
- 記錄用戶端設定。記下節點名稱、協定、代理模式、規則和測速伺服器。確認連線穩定後再開始測試，不要把切換節點時短暫中斷的情況算進結果。
- 重複測試並保留波動。不要只挑最好看的結果。保留每一輪的原始紀錄，觀察常見表現與異常波動；情況允許時，交錯安排各節點的測試順序，降低時段變化造成的偏差。
- 驗證實際使用情境。使用相同網站、同類型檔案或相同畫質設定，檢查速度是否持續、互動是否順暢。不要只憑網頁成功開啟一次，就當作完整的使用體驗測試。
- 一次只變更待比較的因素。若要比較協定，盡量保持地區、目標和模式一致；若同時更換節點、協定和規則，就只能比較整套設定，不能將差異歸因於協定。
若需要遠端測速伺服器，請使用已獲授權的測試端點，不要持續向不明伺服器傳送大量流量。瀏覽器測速也可能消耗大量流量；若依流量計費，更應避免一再追求峰值。
測試時段與紀錄方式
選擇平常經常使用的時段，並加入相對空閒的時段作為對照。值得測試晚間尖峰時段，但「尖峰時段」並非所有地區都有統一的固定時間：本地接取網路、節點所在區域和目標服務都有各自的負載變化。記下實際日期與時間，比只寫「晚上」更有參考價值。
比較時，盡量交錯測試待選線路，不要把某條線路全安排在離峰時段，另一條卻全安排在繁忙時段。遇到異常結果時，先確認本地是否有人正在上傳檔案，再重新測試。若要比較不同日期的結果，也應備註網路環境的變化。
- ✅ 記錄網路環境：裝置、接取方式、本地電信業者，以及是否有背景工作。
- ✅ 記錄代理條件：節點、協定、用戶端模式，以及測速流量是否符合代理規則。
- ✅ 記錄測試目標：工具、伺服器位置、實際使用情境，以及測試日期和時間。
- ✅ 保留原始結果：下載、上傳、延遲、波動情況，以及卡頓或斷線備註。
- ❌ 不要將出口位置不明、伺服器不同或單位不一致的結果直接放在一起排名。
整理結果時，可用中位數描述常見表現，同時保留偏低的結果和波動範圍。對視訊會議、遠端桌面等用途來說，偶爾出現的明顯停頓也應納入結論，而不是讓亮眼的平均速度掩蓋問題。樣本有限時，請將結論限定為「在本次環境與時段下」，不要延伸成長期保證。
速度異常：區分線路、規則與目標
測速很快，網頁卻很慢
先確認問題是出現在所有網站，還是只集中於某項服務。測速工具可能採用多條並行連線；網頁載入則會受到網域名稱解析、建立連線、內容傳遞網路選點和伺服器回應等因素影響。分流規則也可能讓測速流量走代理、目標網站卻走直連，因此出現看似矛盾的結果。
也要確認 DNS 處理方式是否符合預期。DNS 洩漏關注的是解析請求是否送往預期以外的解析器，不只是「解析很慢」。這與隱私及內容傳遞網路的節點選擇有關，但不能只因網頁載入緩慢就判定發生洩漏；應搭配用戶端的 DNS 設定、規則和實際解析路徑進行排查。
延遲低，下載卻很慢
低延遲只表示到某個目標的往返時間較短，不代表路徑具有足夠的吞吐能力。節點出口、目標限速、本地接取網路和裝置處理能力，都可能成為瓶頸。先換用同類型的下載目標驗證，再與直連基準比較，避免一開始就頻繁更動所有設定。
協定或線路名稱能預測結果嗎？
Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 是不同的代理協定或方案，在傳輸方式、實作和執行條件上各有差異，不能只憑名稱判定哪一種一定更快。不同傳輸方式對網路限制和封包遺失的反應尤其不同；比較時應確認用戶端與伺服器端的設定相容。
直連、中轉和 IEPL 專線描述的也不是同一層面的效能指標。中轉會增加轉送環節，但可能改善路由；直連路徑較直接，仍會受到公網互連影響。IEPL 是專用乙太網路連線服務，實際連線還會涉及後續出口和目標路徑。名稱有助於了解架構，實際體驗仍須在相同條件下驗證。
依照用途整理自己的選擇結論
下載和雲端傳輸，應優先看持續吞吐量以及長時間傳輸是否中斷；播放影片則應搭配實際畫質和緩衝表現評估；視訊會議與遠端桌面則應更重視抖動、封包遺失跡象，以及負載時的延遲。不要為了測速排名好看，犧牲真正需要的穩定性。
測試後，保留適合日常使用的設定，以及表現不同的備用線路。網路或用戶端設定變更後，再重新確認重要用途即可。線路涵蓋數量只代表選擇範圍，並不能證明速度；X5VPN 的線路資訊可至線路列表查看，流量規則與計費方式則可在方案價格頁確認。
聯絡客服回報問題時，提供測試日期、節點名稱、接取方式、用戶端模式和異常情況，通常比只說「很慢」更容易找出原因。可透過控制台客服單提交必要資訊；提供截圖前請遮住訂閱連結、密碼和存取權杖，不要為了說明問題而公開帳戶憑證。