節點清單中的毫秒數和下載速度，代表的是不同指標。Tcping 用來確認伺服器連接埠是否可連線，真連線延遲用來判斷代理請求能否完成，下載測速則觀察持續傳輸能力。若遇到「延遲很低卻打不開網頁」或「真連線逾時但連接埠正常」，本文將依測試範圍、結果判讀與排查順序，說明如何挑選可用節點，而非只看單一數值排序。
三種測試各自涵蓋哪些環節
先拆解連線路徑：本機連上節點伺服器，代理核心完成協定與傳輸層交涉，再由節點連線至目標網站。伺服器有回應，不代表身分驗證成功；驗證成功，也不代表能連上目標網站。三種測試涵蓋的範圍不同，結果不能互相取代。
Tcping：伺服器連接埠是否可連線
嘗試連線至節點位址與連接埠，主要測量建立連線所需時間。不會驗證 VMess 或 VLESS 的認證資訊，也不會要求目標網頁。
適用情境：快速排除連接埠無法連線、伺服器位址錯誤等基本連線問題。
真連線延遲：代理請求是否可用
推薦透過待測節點向指定測試位址發出請求，涵蓋代理協定交涉及節點對外連線。這比 Tcping 更接近日常瀏覽網頁的情境，但結果只適用於該測試目標。
適用情境：日常挑選節點時，先篩出能完成代理請求的候選節點。
下載測速：持續傳輸能力
透過待測節點下載測試資料，觀察一段時間內的傳輸速度。結果會受到測試來源、網路壅塞、測速時間與並行數量影響。
適用情境：確認連線正常後，比較下載大型檔案等持續傳輸需求。
在 v2rayN 主視窗選取伺服器後開啟右鍵選單，尋找「測試伺服器延遲 Tcping」、「測試伺服器真連線延遲」、「測試伺服器速度」等項目。不同介面或版本的文字與位置可能不同，請以目前選單為準；不要將特定版本的快速鍵視為通用操作。
Tcping 數值很低，為什麼網頁還是打不開？
Tcping 不等於系統的 ping。一般 ping 常使用 ICMP，而這裡檢查的是 TCP 連接埠。伺服器可能停用 ICMP 回應，但仍接受 TCP 連線；反過來說，主機能回應 ping，也不代表節點使用的連接埠已開放。
若節點填寫的是網域名稱，建立連線前還需要解析出位址。DNS 解析時間是否計入顯示結果，取決於測試的實作方式，因此不能只憑一個 Tcping 數值判斷 DNS 一定正常。若設定的實際傳輸方式不是 TCP，更不能用 TCP 探測取代實際協定測試。
- 連接埠可連線，認證卻錯誤：UUID、密碼或協定參數錯誤時，TCP 連線仍可能成功，但代理請求會失敗。
- 入口可連線，傳輸設定不相符：WebSocket 路徑、Host 或 TLS 伺服器名稱設定不一致，可能在後續交涉階段遭到拒絕。
- 測到前置服務回應：使用反向代理或 CDN 的節點，Tcping 測到的可能是前端入口，而非後端代理服務的完整狀態。
- 對外連線受限：節點接受連線後，仍可能無法解析或連上測試網站，原因包括出口網路故障或目標網站限制等。
判斷方式：確認連接埠可連線後，立即測試代理請求
Tcping 有結果但網頁打不開時，下一步應執行真連線延遲測試並查看核心記錄。不要只因毫秒數偏低，就反覆調整本機系統代理設定。
真連線延遲測量哪些環節？逾時該檢查哪裡？
真連線延遲不只是「本機到伺服器的距離」。一次測試通常涵蓋連上節點、代理協定交涉、節點連線至測試位址，以及等待回應等階段；若使用 HTTPS 測試位址，也會涉及相應的 TLS 流程。實際計時範圍、連線重用方式與成功判定可能隨版本而異，因此不適合直接拿不同工具的結果排名。
先到「設定」→「參數設定」尋找真連線測試位址、測速位址與逾時相關選項。若目前介面分成多個分頁，可查看「測試」或「速度」相關設定。記下實際 URL 後再比較節點。測試位址若回傳空白回應或較小的內容，通常較適合觀察請求延遲；大型檔案位址則較適合測試傳輸速度，兩者用途不同。
- 一次只測一個節點。暫停批次任務，再對同一節點重新測試，避免並行連線占用本機頻寬或觸發伺服器限制。
- 確認節點參數。在伺服器清單中編輯對應項目，依據來源確認位址、連接埠、認證資訊、傳輸方式與 TLS 設定，不要自行猜測或補上欄位。
- 確認系統時間。啟用作業系統的自動校時。時間明顯不準可能影響憑證驗證，也可能影響有時間要求的協定認證。
- 觀察記錄顯示的階段。連線逾時時優先檢查連線狀態；憑證錯誤時檢查時間與伺服器名稱；認證或傳輸錯誤時檢查節點參數。只看到 timeout，無法判定是哪一端發生故障。
- 改用可合法存取的測試目標再次確認。若只有原本的目標測試失敗，請繼續檢查節點出口至該目標的連線，不要直接認定整個節點失效。
下載測速怎麼看：單位、時間與流量
下載測速觀察的是傳輸速度，不是回應延遲。高延遲的線路持續下載時仍可能有不錯的速度；低延遲的線路也可能受出口頻寬或伺服器限速影響。首次請求是否迅速，以及長時間下載是否穩定，應分開判斷。
上方的頻寬數值僅為單位換算示例，並非本站實測結果。請留意大寫 B 與小寫 b：MB/s 是每秒兆位元組，Mbps 是每秒兆位元；若介面顯示 MiB/s，換算基準又與 MB/s 不同。比較前請先統一單位，不能直接用電信業者標示的頻寬減去測速欄位的數字。
- 固定測試來源：同一節點改用不同下載位址，結果也可能不同。測試來源本身的限速、負載與地理位置都會影響結果。
- 固定測試條件：使用相同網路、相近時段與相同測速設定；暫停大型檔案下載、雲端同步及其他占用頻寬的工作。
- 別只看瞬間峰值：短時間測試容易受到建立連線與傳輸加速階段影響。先確認用戶端顯示的是平均值或其他統計值，再解讀結果。
- 留意流量用量：假設以 10 MB/s 持續下載 10 秒，資料量約為 100 MB，另有協定負擔。批次測試多個節點時，流量會繼續累加。
依測試結果安排節點篩選順序
不要一開始就替所有節點執行下載測速。先確認連線狀態，再確認實際請求可用，最後只針對少數候選節點測試傳輸速度。這樣更容易縮小排查範圍，也能減少不必要的流量。下表說明不同結果組合的判讀方式，並非某批節點的效能紀錄。
| 結果組合 | 優先判斷 | 下一步 |
|---|---|---|
| Tcping 成功，真連線逾時 | 入口可連線，後續代理請求未完成 | 檢查協定參數、核心記錄與測試目標 |
| 真連線成功，下載速度偏低 | 基本請求可用，但傳輸速度受限 | 固定測試來源，排除本機頻寬占用後重新測試 |
| 真連線較慢，持續下載速度較快 | 回應延遲與持續傳輸速度表現不同 | 依網頁互動或檔案下載的實際用途選擇 |
| 測試成功，瀏覽器卻無法連線 | 應用程式導流方式或目標路由可能不同 | 檢查系統代理、瀏覽器設定與符合的規則 |
操作建議：保留能穩定完成請求的節點，再比較傳輸速度
對候選節點各執行三輪真連線測試，記錄失敗次數與耗時變化。先排除反覆逾時的項目，再對其餘候選節點執行下載測速；最後使用實際需要存取的網站再確認一次。
三輪結果可由小到大排序，以中間值作為本輪比較參考，同時保留失敗紀錄。不要把逾時記為 0 毫秒後再計算平均，否則會讓失敗節點看起來「更快」。不同時段的結果也應分開記錄，晚間壅塞不應用白天的一次測試結果解釋。
延遲測試常見問題
顯示 -1 或逾時，代表節點完全失效了嗎？
不一定。負值或逾時通常代表測試失敗，不是實際延遲。先單獨重新測試，再確認測試位址與記錄。若多個節點都只在同一個目標上失敗，先更換測試目標確認；若只有一個節點持續失敗，再檢查它的設定與服務狀態。
為什麼剛測完很快，過一會兒又變慢？
清單中的數字是單次測試結果，不是持續監測值。使用相同測試目標分三輪記錄耗時與失敗狀況，並暫停背景下載。若波動集中在特定時段，再比較該時段的實際連線表現，不必因一次速度峰值就立刻更換整套設定。
測試節點前，必須先啟用系統代理或 TUN 嗎？
內建測試通常會為待測節點建立測試路徑，不應把啟用系統代理或 TUN 視為必要條件。先確認核心能正常啟動；測試通過後，再為瀏覽器等應用程式選擇導流方式。若同時使用多種導流方式，請檢查是否造成回環或路徑混淆。
真連線最快的節點，一定最適合下載嗎？
不一定。先用真連線測試篩出可用節點，再從中挑選少數候選節點執行下載測速。下載任務優先看持續速度與穩定性；網頁互動則更重視請求回應速度與失敗率。測試目標與實際使用目標不同，最後仍應在真實使用情境中確認。