TCPing 用來初步檢查伺服器連接埠，真實連線延遲用來確認節點能否完成代理請求，下載測速則用來觀察持續傳輸能力。本文適合遇到「延遲很低卻打不開網頁」或「延遲偏高但下載很快」的 v2rayN 使用者：先統一測試條件，再分層排查，最後依實際用途挑選節點。
三種測速分別測量哪一段連線
瀏覽網頁不只是「連上伺服器」這一步。本機要先連到節點入口，再由代理核心完成協定驗證與傳輸協商，接著由節點連上目標網站，最後才會收到回應資料。TCPing、真實連線延遲和下載測速測量的環節各不相同，不能把數值放在同一欄直接排名。
| 測試方式 | 主要測量項目 | 可以判斷什麼 | 無法直接判斷什麼 |
|---|---|---|---|
| TCPing | 本機與節點位址、連接埠之間的 TCP 連線 | 入口連接埠是否可連，以及大致的連線耗時 | UUID 是否正確，以及代理能否連上網站 |
| 真實連線延遲 | 透過受測節點向測試 URL 發出請求 | 代理連線路徑與該測試目標是否可用 | 所有網站的回應速度或大型檔案的傳輸量 |
| 下載測速 | 透過節點持續接收測速位址傳來的資料 | 該時段、該測試目標的傳輸速度 | 長期最低頻寬、遊戲延遲或所有應用程式的使用體驗 |
真實連線測試通常會使用資料量很小的 HTTP 回應，例如回傳狀態碼 204 的網址。這是在執行一次實際的代理請求，並非載入整個網頁；計時終點、連線重複使用方式與逾時處理，則視用戶端和核心的實作而定。因此，不能簡單解讀成「瀏覽器完整開啟網頁要多久」。
TCPing 數值很低，為什麼節點還是不能用？
TCPing 通常會嘗試連上節點設定中的伺服器位址與連接埠。如果節點使用網域名稱，還需要先解析出位址；是否將 DNS 解析時間納入顯示耗時，則視實作方式而定。TCPing 不是 ICMP Ping，也不需要伺服器回應 ICMP。即使伺服器停用一般 Ping，TCP 連接埠仍可能正常連線。
例如，入口使用 TCP 443 連接埠的 VLESS 節點，TCPing 顯示 45 ms，只能表示入口接受了 TCP 連線。後續的 TLS 或 REALITY 協商、VLESS 驗證，以及節點連往目標網站的外連，都無法由這個數值證明。
- 驗證錯誤：VMess 或 VLESS 的 UUID 不符，TCP 仍可能連得上，但代理請求會失敗。
- 傳輸參數錯誤：WebSocket 路徑、Host 或 TLS 的
serverName不符，問題可能會等到 TCP 連線建立後才顯現。 - 安全層參數錯誤：REALITY 公鑰、
shortId或相關設定不符時，應檢查核心記錄，而不是一再重新整理 TCPing 結果。 - 測到的是入口：使用 CDN 的節點可能先連到距離較近的邊緣入口；入口延遲低，不代表回源或後續外連也快。
真實連線延遲：先確認請求成功，再比較毫秒數
真實連線測試會透過受測節點送出測試請求。過程通常包括本機連上節點、處理代理協定、節點連上測試目標，以及收到回應。若測試網址使用 HTTPS，也會包含與目標進行 TLS 握手；實際耗時則會受到 DNS 快取、連線重複使用方式與測試機制影響。
因此，TCPing 為 45 ms、真實連線為 260 ms 並不矛盾。兩者的時間差並不是可以精確拆解的「伺服器處理延遲」，不能簡單相減後就歸因於節點負載。測試目標的位置、節點出口路徑和握手次數都可能影響結果。
TCPing 初步篩選
先檢查入口是否連通，快速找出整批節點是否有明顯的網路或連接埠問題。不要只憑最低毫秒數決定日常主力節點。
適用情境：節點數量多，需要快速排查入口故障
真實連線延遲篩選
推薦使用同一個測試 URL 重複測量，優先保留請求穩定成功、延遲起伏較小的節點，再透過實際網站確認。
適用情境：瀏覽網頁、呼叫 API、日常挑選節點
下載測速複核
針對少數候選節點測試持續接收資料的能力。配合流量用量與實際需求，不必對整份訂閱反覆進行滿速測試。
適用情境：傳輸大型檔案、評估影片緩衝能力
真實連線逾時不代表節點整體失效。測試位址本身無法連線、目標限制某類出口，或 DNS 解析失敗，都可能造成測試失敗。先保留原位址的測試記錄，再換成另一個穩定、回應資料量小的位址重測；每輪比較時不要任意更換目標，否則排名就缺少一致的基準。
下載測速怎麼看：MB/s、Mbps 與瞬間峰值
下載測速觀察的是一段時間內接收到的資料量。瓶頸可能在家用寬頻、無線網路、節點共用頻寬、出口連線，也可能在測速檔案伺服器。測得的是整條傳輸路徑的結果，不是單獨測試節點伺服器的效能。
先確認單位。以十進位計算，1 MB/s 等於 8 Mbps；寬頻方案常以 Mbps 標示，應用程式的下載介面則可能使用 MB/s 或 MiB/s。以下是教學用範例記錄，並非本站實測結果，也不代表任何節點的效能保證，用來說明三項指標可以同時成立。
- 低延遲、低傳輸速度：短請求回應很快，但長時間連線可能受到限速或共用頻寬影響。
- 高延遲、高傳輸速度：遠距離連線的往返時間較長，但建立連線後仍可能維持較高的傳輸速度。
- 一開始很快，之後變慢：可能與突發頻寬、網路壅塞或伺服器端策略有關；應觀察穩定區間，不要只記錄瞬間峰值。
假設平均速度為 8 MB/s，持續測試 15 秒，接收資料約為 120 MB，尚未計入協定額外負擔。測試多個節點會累積消耗流量。尤其是按流量計費的訂閱，建議先用真實連線縮小範圍，再測試兩三個候選節點。
在 v2rayN 中建立可重複的測試流程
以下依照節點清單的操作方式說明。不同版本的右鍵選單可能會顯示「測試伺服器延遲 Tcping」、「測試伺服器真實連線延遲」或類似名稱，設定項目也可能調整分類；請以目前介面為準。測試前記下用戶端與核心版本，升級前後的結果不要直接混在同一批資料中比較。
- 固定網路條件：暫停其他下載、雲端同步與系統更新。先選定有線網路或同一個 Wi-Fi 網路，測試期間不要切換。
- 確認測試設定：開啟「設定」→「參數設定」，查看目前版本提供的延遲測試位址、測速位址、逾時和並行數相關設定。記錄實際值；如果設定位於獨立的測速分類，請前往相應分類查看。
- 小批量初步篩選：在節點清單中選取要測試的節點，按右鍵執行 TCPing。接著對同一批節點執行真實連線測試，分開記錄結果，不要用一種延遲欄位代替另一種。
- 重複測試三輪：使用同一個測試目標，分別記錄成功次數與延遲。例如三次結果為 180、185、620 ms，其中位數為 185 ms，但 620 ms 的波動也應保留記錄。
- 單獨測試傳輸速度：只對候選節點逐一執行下載測速。記錄測試時段、持續時間和平均速度，避免多個下載工作同時占用本機頻寬。
- 回到實際用途確認：將節點設為目前使用節點後，開啟平常使用的網站或服務。內建測試成功，不代表系統代理、應用程式代理和路由設定都已正確。
分兩輪驗證：區分節點品質與使用環境
受控測速環境
- 固定測試 URL、網路與測試時間。
- 先小批量測試延遲，再逐一進行下載測速。
- 記錄三輪結果，不要只取最低值。
日常使用環境
- 恢復日常使用的系統代理與路由設定。
- 確認目標應用程式確實透過所選節點連線。
- 在常用時段重新測試網頁、影片或下載工作。
受控測試用來比較節點，日常驗證則用來確認設定與實際體驗，兩者不能互相取代。
內建測試成功，瀏覽器仍然很慢：檢查代理路徑
v2rayN 的節點測試與瀏覽器連線，不一定使用完全相同的設定路徑。節點測試通常會為受測節點建立測試連線；日常使用的應用程式還會受到系統代理、應用程式本身的代理設定、routing 規則和 DNS 行為影響。若某個網站依規則改走直連，切換節點也可能不會改善連線速度。
若要單獨複核，可以明確指定本機 SOCKS 入口。以下指令假設已確認 127.0.0.1:10808 是目前可用的 SOCKS 或相容的混合入站，且已在介面中選好目標節點；10808 只是範例連接埠，不保證適用於所有安裝環境。如果本機監聽的連接埠不同，請先修改指令中的位址。
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --output /dev/null --silent --show-error --write-out "HTTP=%{http_code} total=%{time_total}s\n" https://www.example.com/- 此指令適用於已安裝
curl的 Linux、macOS 終端機。Windows PowerShell 可使用curl.exe，並將輸出目標/dev/null改為NUL。 socks5h表示將目標網域交由 SOCKS 代理端解析，可減少本機目標網域解析差異；實際的後續解析位置仍取決於核心與路由設定。time_total是這次指令從開始執行到傳輸結束的總耗時，不等同於 v2rayN 的真實連線延遲欄位，也不是單獨的伺服器處理時間。- 範例目標僅供檢查請求使用。要比較結果，請固定使用同一個穩定目標；不要用小型網頁的回應速度推算大型檔案的下載頻寬。
明確指定代理入口，可排除系統代理是否生效的疑慮，但不會自動略過核心的 routing。如果仍不確定請求的連線路徑，請在存取時比對記錄中的目標、符合的規則與出口標籤。分享記錄前，請遮蔽訂閱網址、驗證資訊和其他敏感內容。
測速常見問題：依症狀縮小排查範圍
TCPing 只有幾十毫秒，真實連線卻逾時，要換節點嗎？
先在節點清單中重新執行一次真實連線測試，再查看對應時間的核心記錄。若出現驗證或握手錯誤，請確認 UUID、TLS、REALITY 與傳輸參數；若只有測試位址連不上，請換成穩定的目標重測後再判斷。
所有節點同一時間都測不出來，是訂閱失效了嗎？
先將測試範圍縮小到一個已知可用的節點，並降低並行數。檢查本機網路、測試 URL 與核心是否正常啟動；確認原因前，不要反覆刪除並重新匯入整份訂閱。
下載速度很快，為什麼開啟網頁還是很慢？
傳輸大型檔案與多次短連線是不同的負載。先觀察真實連線多輪測試的波動，再檢查瀏覽器的 DNS、路由和網站第三方資源。請使用同一個頁面重新測試，不要拿不同網站的載入時間比較節點。
顯示 -1 或逾時，是延遲特別高的意思嗎？
通常應將這類結果視為測試未成功，而不是負延遲。檢查逾時設定和記錄後再單獨重測；不同版本顯示失敗的方式可能不同，請搭配狀態文字判斷，不要與正常的毫秒數一起計算平均值。
應該一直選延遲最低的節點嗎？
先比較成功率與波動，再依用途挑選。瀏覽網頁可優先保留真實連線穩定的節點；傳輸大型檔案時，再比較持續傳輸速度。至少在常用時段重新測試一次，並保留一個已確認可用的備用節點。
實用的節點挑選順序是：請求能成功、結果穩定、實際服務可用，最後才比較個別數值高低。將測試目標、網路、時段和單位記錄下來，才能判斷速度變慢究竟是節點、目標伺服器，還是本機環境造成。