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

三種 V2Ray 測速方式各自測到哪一層

v2rayN 是桌面圖形用戶端，v2rayNG 則是採用 Xray 核心的 Android 用戶端。介面中的測速由用戶端安排，實際連線還會受到核心、節點設定及目標網站影響。不同版本的選單名稱、計時範圍和逾時門檻可能不同，因此適合比較同一欄位中的數值，不宜直接拿不同用戶端的數值排名。

這裡的「建議」是指日常挑選節點時優先參考真實連線延遲，並非它能取代所有測試。播放影片更看重持續傳輸速度與穩定度，互動操作則更在意回應時間；實際應用也可能採用與測試請求不同的路由。

TCPing 數值很低，為什麼真實連線還是逾時？

TCPing 不是傳統的 ICMP ping。假設節點設定使用 TCP 連接埠 443，TCPing 成功通常只能表示本機能與該位址的這個連接埠建立 TCP 連線。連接埠後方可能是代理服務，也可能只是前置轉送或其他監聽程式；必須進一步完成協定交握，才能確認設定是否可用。

1. 確認伺服器連接埠。測試的是訂閱中記錄的連接埠，不是憑經驗固定測 443。若連接埠已變更，但訂閱尚未更新，舊連接埠的測試結果就沒有參考價值。
2. 確認協定與安全性參數。VLESS 的使用者識別碼、TLS 的伺服器名稱、REALITY 的公鑰與短識別碼等設定錯誤，都可能在 TCP 連線建立後才出現。
3. 確認傳輸層參數。WebSocket 路徑、HTTP 主機名稱等若與伺服器設定不一致，底層連接埠仍可能正常接受連線，但後續代理請求會失敗。
4. 確認測試方式是否適用。主要使用 UDP 的傳輸方式，不能只憑 TCP 連接埠探測判斷是否正常。TCPing 失敗，不代表所有類型的代理傳輸都失敗。

同樣地，TCPing 不是封包遺失率測試。連續 5 次連線都成功，只能表示這 5 次探測成功，不能據此宣稱線路完全沒有封包遺失。重測時應一併記錄失敗次數與成功結果的分布。

真實連線延遲包含哪些項目？為什麼每次數值都不同？

真實連線測試會透過代理設定存取測試 URL。若目標是 HTTPS 網址，一次請求可能涵蓋本機或遠端 DNS 查詢、連線至節點、代理認證、目標 TLS 交握及等待回應。實際計入哪些環節，取決於用戶端的實作方式，以及是否重用連線、是否已有 DNS 快取。

因此，它不是「節點到使用者的純網路往返時間」，更不是網頁完整載入時間。常見的小型回應測試頁面只需傳回少量資料；實際網頁還會載入指令碼、圖片和其他網域的內容，使用體驗自然可能不同。

• 固定測試目標。比較節點時使用相同的 URL。若測試網址換了地區、CDN 或回應方式，結果就不再只是節點差異。
• 確認回應是否符合預期。有些探測會檢查狀態碼或有效回應；重新導向、驗證頁面和目標網站的流量限制，都可能導致測試失敗。
• 保留首次與後續結果。首次連線可能較慢，之後 DNS 快取、工作階段恢復或連線重用都可能縮短耗時。不要只記錄最快的一次。
• 檢查測試路由。真實連線測試的目標是測試指定節點，但不同版本的探測設定與 DNS 處理方式可能不同。應搭配日誌確認，不要以瀏覽器直接開啟測試頁面取代代理測試。

下載測速的 MB/s 與 Mbps 如何換算？

延遲以毫秒表示，傳輸速度則通常以 MB/s 或 Mbps 顯示，兩者不能直接換算。延遲 180 ms 的節點可能持續傳輸 12 MB/s，延遲 60 ms 的節點也可能只有 2 MB/s。前者不一定適合低延遲互動，後者也未必適合下載大型檔案。

以下是單位換算範例，並非本站實測結果或線路保證。依十進位單位計算，1 位元組等於 8 位元；若介面明確使用 MiB/s，則應改用二進位單位換算。

標示為 100 Mbps 的網路連線，理論上相當於 12.5 MB/s；實際使用還會受到協定負擔與網路波動影響。下載測速的瓶頸也可能在測試伺服器，而非節點本身；單一連線與多重連線測速不可混為一談。

• 先暫停背景下載、系統更新與雲端同步，避免共用本地頻寬。
• 逐一測試候選節點，不要讓多個下載測速同時占用頻寬。
• 測速前先確認流量額度。長時間測速會產生實際流量，Android 裝置使用行動網路時尤其要留意。
• 觀察速度穩定的區間，不要只看啟動瞬間的峰值；接著再用實際要下載的服務驗證一次。

v2rayN 與 v2rayNG 的重測步驟

先記錄用戶端與核心版本，再檢查測試設定。在 v2rayN 的「設定」→「參數設定」中，查看目前版本提供的測速相關選項，確認測試網址與逾時設定；選單分類依實際版本而異。不要為了追求更低數值而頻繁修改這些條件。

例如，5 次真實連線測試結果為 142、149、151、158、410 ms，中位數是 151 ms，但 410 ms 的波動仍值得記錄。若其中 2 次逾時，就不能只計算其餘 3 次的平均值，然後說連線很穩定。切換訂閱中的節點後，也要確認目前使用的節點確實已變更，以免測的是新節點，瀏覽器卻仍在重用舊連線。

測速成功但網頁無法開啟：逐段排查連線

用戶端內建測試與瀏覽器連線，是兩條需要分別驗證的路徑。內建測試可能透過專用的測試入口發出請求；瀏覽器則還需要系統代理、應用程式代理設定或 TUN 接管。系統代理決定流量如何進入用戶端，路由分流則決定流量進入後採用哪個出口。

1. 檢查本機代理設定。例如目前設定的 HTTP 代理為 127.0.0.1:10809，應用程式就必須使用這個實際監聽位址；10809 只是範例，不是所有版本的預設值，也不要把 SOCKS 連接埠填成 HTTP 連接埠。
2. 檢查路由規則。測試網址走代理，不代表實際使用的網域也走代理。確認網域是否符合直連規則，以及 Android 版的個別應用程式設定是否排除了目標應用程式。
3. 檢查 DNS。節點伺服器位址與實際使用的網域都需要解析。比對日誌中的解析錯誤與連線目標，不要只因瀏覽器能解析某個網域，就排除所有 DNS 問題。
4. 檢查遠端節點與目標網站。能連上回應內容較小的測試網站，不代表所有網站都能連線。若只有某個服務無法使用，請檢查該服務的地區限制、出口限制與具體錯誤訊息。

排查時一次只修改一項，並保存修改前後的結果。若同時重設節點、路由、DNS 與系統代理，即使暫時恢復，也很難找出真正原因。

延遲與測速常見問題