v2rayN 延遲測試怎麼看？Ping、真實連線延遲與下載速度差異

四種測試：先確認數值測的是哪個環節

v2rayN 是桌面圖形化用戶端，節點設定由選用的核心處理。伺服器清單中的延遲並非節點本身固定不變的屬性，而是由目前網路、測試目標和測試方式共同決定。更換 Wi-Fi、變更測試 URL，甚至同一時段同時測試更多節點，都可能影響排名。

不同版本的選單名稱、測試選項和計時範圍可能不同。操作前先確認指令名稱，別把 TCPing 結果稱為「代理連線延遲」，也別把下載速度欄位當成網頁首屏載入時間。

Ping 與 TCPing：延遲低不代表代理可用

ICMP Ping 不會送出代理協定的驗證資訊，也不會檢查 TLS、WebSocket 路徑或伺服器的對外連線能力。部分伺服器或中間網路會限制 ICMP，因此 Ping 逾時只能表示沒有收到預期回應，不能直接判定代理故障。反過來說，ICMP 正常也不代表伺服器正在監聽代理連接埠。

TCPing 更適合檢查連接埠。例如節點設定使用 TCP 443，就應測試設定中的伺服器位址和 443，而非任意改用另一台主機。即使連接埠接受連線，仍可能在後續驗證、TLS 交握或傳輸路徑比對時失敗。使用 CDN 的節點，TCP 連線也可能只到達邊緣入口，不代表已連上實際代理服務。

• Ping 有回應，但 TCP 連線失敗：優先確認節點連接埠是否填錯、網路是否封鎖該連接埠，以及伺服器是否正在監聽。
• TCP 連線成功，但真實連線逾時：接著檢查協定參數、TLS 服務名稱、傳輸設定和伺服器轉發能力。
• Ping 逾時，但真實連線正常：保留該節點，不要只因 ICMP 沒有回應就刪除。
• 節點使用非 TCP 傳輸：TCPing 無法取代對應傳輸方式的可用性測試，應使用核心實際建立代理連線。

真實連線延遲：測試 URL 與核心都會影響結果

真實連線測試通常會啟動或使用受測設定的代理連線，再存取指定 URL。它涵蓋的環節比單測 TCP 連接埠更多，但「真實連線」並非所有版本都採用相同的計時標準。DNS 解析、代理交握、TLS 連線建立、收到回應等步驟是否完整納入計時，須以目前版本的實作為準。

在 v2rayN 中，可先開啟「設定」→「參數設定」，尋找延遲測試位址、測速位址等選項；伺服器清單的右鍵選單通常會提供包含「真實連線延遲」的測試指令。實際分類和名稱請以安裝版本為準。修改前先記下目前使用的位址，避免更換目標後仍直接比較新舊數值。

如果所有節點突然都對同一個 URL 逾時，先確認該目標是否異常，不要立刻重新匯入所有訂閱。也應檢查系統時間、記錄中的憑證錯誤，以及測試目標是否遭伺服器出口拒絕。一次真實連線測試成功，只能證明該次測試請求成功。

下載測速：分清頻寬、單位與瞬間峰值

延遲描述請求往返所需時間，吞吐量則描述單位時間內傳輸的資料量。兩者可能有關，但並不相同。跨區域節點即使往返較慢，也可能有更高的持續下載速度；距離較近的節點即使連線很快，也可能受共享頻寬和尖峰時段壅塞影響。

以下三項是單位換算範例，不是本站實測結果，也不代表任何節點的效能承諾。小寫 b 代表 bit，大寫 B 代表 byte；以十進位單位換算，1 byte 等於 8 bit。若軟體顯示 MiB/s，還須留意二進位單位的差異。

• 本機上限：寬頻速率、Wi-Fi 訊號、路由器負載和其他下載工作都會拉低測試結果。
• 遠端上限：節點出口、測速資源所在網路、單一連線限速和伺服器負載都會限制吞吐量。
• 測試時間：時間太短可能還沒進入穩定傳輸，太長則會耗用更多流量；比較時應使用相同時間。
• 協定額外負擔：加密、封裝和重傳都會耗用資源，實際使用速度通常不會達到線路標示速率換算後的理論值。

可重現的篩選流程：固定條件，分層記錄

不要一次選取所有節點並同時執行多種測試。並行工作會爭用本機頻寬、連線資源和處理器時間，測試本身就可能造成排隊。較可靠的方式是先初步篩選、縮小範圍，最後再檢查實際應用。

1. 固定環境：暫停系統更新和大型檔案下載，使用相同網路，並記下目前的核心、測試 URL 和測試時間。
2. 初步檢查連接埠：檢查適用的 TCP 節點是否連通。這一步只用來縮小範圍，不要只憑 Ping 結果淘汰節點。
3. 重測真實連線：逐一測試候選節點 5 次，保留成功次數和每次耗時。若成功次數少於 5 次，不要只記錄成功樣本的平均值。
4. 比較中位數：例如五次結果為 180、185、190、210、900 ms，排序後的中位數是 190 ms；也要保留 900 ms 的尖峰紀錄，不能用中位數掩蓋波動。
5. 短時間測試吞吐量：使用相同資源和測試時間，逐一測試兩、三個穩定候選節點。以上數據僅供計算示範，不是實測節點排名。
6. 回到實際應用：切換目前使用的節點，確認系統代理或 TUN 已依預期啟用，再測試常用網頁、影片或檔案傳輸。

測試通過仍無法開啟網頁：檢查實際流量路徑

節點測試和瀏覽器流量不一定經過完全相同的入口與路由。用戶端可以針對指定節點發起測試，但瀏覽器可能沒有使用系統代理，也可能依分流規則直接連線。因此，「伺服器清單測試成功」和「目前應用程式透過該節點連線」是兩回事。

• 系統代理：確認應用程式是否會讀取系統代理設定。命令列工具和部分應用程式不一定會自動使用。
• TUN：確認虛擬網路介面是否成功啟動、權限是否足夠，以及相關路由是否生效，不要只看開關顯示。
• 本機監聽：確認參數設定中的實際連接埠。若自行設為 127.0.0.1:10808，應用程式也必須使用相同連接埠和正確的代理類型；此處僅為設定範例，不保證與目前版本的預設值相同。
• 路由與 DNS：查看目標網域符合哪條規則，以及流量使用哪個出口。能存取測試網域，不代表業務網域也走相同路徑。
• 核心記錄：分辨連線逾時、驗證失敗、憑證錯誤和本機連接埠被占用，再決定要修改哪一層設定。

VMess 和 VLESS 是代理協定名稱，不代表速度等級；更換協定無法取代參數檢查。使用 TLS 的節點應依伺服器要求檢查服務名稱等設定，不要為了讓測試顯示成功就任意關閉憑證驗證。設定與伺服器不符時，TCP 延遲再低也無濟於事。

常見問題：延遲欄位、測速數值與節點選擇