TCPing、實際連線延遲與下載速度測試有何不同？看懂用戶端測速結果

三種測速有何不同：連接埠、代理請求與持續傳輸量

先確認測試對象，別只比較數字大小。TCPing 通常會嘗試連線到節點地址的指定 TCP 連接埠；實際連線延遲通常是透過選定節點向測試網址發出請求；下載速度測試則透過代理讀取一段回應資料，觀察單位時間內接收的位元組數。三者測試的連線路徑不同，不能用同一套排名解讀。

v2rayN 是用戶端，實際代理連線由選用的核心處理。v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心。不同用戶端介面上名稱相近的測試，不保證採用完全相同的計時方式；跨用戶端比較前，應先確認測試網址與測試方法。

TCPing 數值很低，為什麼網頁還是打不開？

以節點入口使用 TCP 443 連接埠為例：TCP 連線成功，只能代表當下有設備在該地址與連接埠接受連線。對方可能是代理服務，也可能是前置反向代理或其他入口。後續的 TLS 交握、代理驗證與目標網站存取仍可能失敗。

1. 檢查節點參數。VMess 或 VLESS 的身分參數與傳輸方式必須和伺服器一致；啟用 TLS 時，也要確認伺服器名稱等安全參數。切勿為了讓測試通過而直接關閉憑證驗證。
2. 檢查傳輸設定。使用 WebSocket 時，路徑或 Host 設定錯誤，可能在 TCP 連線成功後才收到錯誤回應。入口延遲正常，不代表這些欄位設定正確。
3. 檢查伺服器出口。節點能接受連線，不代表它能解析或連上目標網域。出口網路異常或目標網站限制存取，都可能導致實際連線測試失敗。
4. 檢查本機流量入口。內建測試可能會自行啟動測試連線；瀏覽器則依賴系統代理、應用程式代理或 TUN。測試成功，不代表瀏覽器也經過相同路徑。

系統 ping 也有類似限制：ICMP 回應可能遭到限制，但 TCP 服務仍正常；反過來，收到 ICMP 回應也無法證明代理連接埠已開放。排查時請記錄「哪一種測試失敗」，不要一概稱為「ping 不通」。

實際連線延遲：確認測試網址、逾時設定與路由

實際連線延遲涵蓋的環節通常比 TCPing 多，可能包括本機測試入口、節點交握、伺服器對外連線、目標網域解析，以及 HTTP 或 HTTPS 請求。但哪些環節會計入最終毫秒數、是否重複使用連線，都取決於實作方式，因此不能直接將結果解讀為兩地間的實際往返延遲。

• 固定測試網址。比較節點時使用相同網址，避免一個請求連到近端網站，另一個卻連到遠端網站。測試網站本身若故障，也可能讓多個正常節點同時顯示逾時。
• 固定逾時上限。例如統一設為 5 秒。超過上限只表示該請求未能及時完成，不代表連線延遲剛好是 5000 毫秒。
• 查看回應結果。部分測試要求特定狀態碼或回應格式；收到網頁內容，不一定符合測試工具的成功條件。
• 區分測試路由與日常路由。批次測試節點時，可能會暫時為每個候選節點建立測試通道；瀏覽器則依目前的路由規則連線。不能想當然地認為兩者路徑相同。

在 v2rayN 中，可以先從節點清單的右鍵選單尋找名稱包含「實際連線延遲」的測試項目；測試網址、逾時等設定可至「設定」→「參數設定」查看。不同版本的選單名稱與位置可能有所調整，請以目前介面為準。v2rayNG 則可從主畫面的選單尋找連線測試相關選項，別把設定清單中的測試結果和目前 VPN 通道狀態混為一談。

下載速度測試：看清單位與測試條件

下載速度測試衡量的是傳輸量，不是「更精確的延遲」。連線建立稍慢的節點，下載大型檔案時可能更快；延遲很低的節點，也可能因出口限速或尖峰時段壅塞而只有很低的傳輸量。短時間下載也容易受到連線暖機與瞬間頻寬影響。

以下為教學範例，並非本站實測結果或效能保證：假設某節點的 TCPing 為 48 毫秒、實際連線延遲為 280 毫秒，並在一次下載中於 4 秒內接收 20 MiB 資料。平均傳輸速度為 5 MiB/s，約等於 41.9 Mbps；這三個數字並不矛盾。

測速會產生實際流量。以上範例一次就接收了 20 MiB；如果 30 個節點各測一次，光是回應資料就約有 600 MiB，還不包含通訊協定額外負荷。使用流量計量方案時，請先縮小候選範圍，不要持續對整份訂閱清單進行下載速度測試。

可重複執行的節點挑選流程：先確認可用，再看穩定度，最後比較速度

建議在同一台裝置、相同網路與相近時段進行比較。先挑出 3 個候選節點，逐一進行實際連線測試，每個測 5 次，記錄成功次數與成功樣本的中位數。失敗樣本也要另外計數，不能刪除失敗結果後只呈現好看的平均值。

1. 確認本機狀態。暫停大型檔案下載，檢查系統時間，並確認核心已正常啟動。更新訂閱後，重新確認所選設定，避免測試已失效的舊節點。
2. 先確認入口。適用於 TCP 的節點可執行 TCPing，並記錄拒絕連線或逾時的情況；不要只保留延遲最低的一次結果。
3. 驗證代理請求。保持測試網址不變，逐一進行 5 次實際連線測試。若某節點只有 2 次成功，即使最低延遲只有 100 毫秒，也不應優先於每次都能連線成功的候選節點。
4. 少量測試下載。只針對剩下的 2～3 個候選節點進行下載速度測試，並固定測試目標、連線數與時間，避免同時測試多個節點而占用本機頻寬。
5. 回到實際應用情境。開啟常用網站、播放目標影片或下載實際檔案。如果主要在晚間使用，就在晚間再測一次，不要只依賴清晨的結果。

瀏覽器無法連線時：明確指定本機代理後再驗證

如果內建測試成功，但瀏覽器無法開啟網頁，可以用命令列明確指定代理入口，確認問題是「節點無法使用」還是「應用程式未使用代理」。請先在用戶端設定中確認本機監聽地址、連接埠與入站類型。以下僅假設 127.0.0.1:10808 是已啟用的 HTTP 或混合代理入口；此連接埠只是操作範例，並非所有版本的預設值。

curl --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 --output response.html --write-out "HTTP=%{http_code} total=%{time_total}s\n" https://v2rayalpha.com/

Windows 環境可使用 curl.exe，避免部分命令列環境將 curl 解讀為其他命令。此範例會將回應儲存至目前目錄的 response.html，並輸出狀態碼與總耗時；用途僅是確認請求是否完成，不適合用來測量最大下載頻寬。

• 一開始就提示無法連線至本機連接埠：檢查用戶端是否正在執行、監聽連接埠是否一致，以及該入口是否支援 HTTP 代理。
• 能連上本機入口，但請求逾時：查看核心記錄，檢查節點連線、TLS 與目標網站存取環節，別只調整瀏覽器設定。
• 命令執行成功，但瀏覽器仍無法連線：檢查 v2rayN 的系統代理狀態、瀏覽器本身的代理設定，以及路由規則是否讓兩者使用不同出口。
• 收到 403 等狀態碼：代表已收到 HTTP 回應，但不等於服務存取成功；還需進一步確認是目標網站限制，還是中間環節回傳的回應。

常見測速問題：逾時、波動與頻寬高但體驗不佳