TCPing 適合初步檢查伺服器連接埠，真實連線延遲適合檢驗代理連線，下載測速則用來評估持續傳輸能力。本文適合已匯入節點，卻不確定該依哪個數值排序的使用者：先釐清各項測試的範圍，再以相同目標、相同網路和多次測試挑選常用節點，最後找出「延遲很低卻無法開啟網頁」的原因。
一、三種測試測量的連線範圍不同
v2rayNG 使用 Xray 核心處理代理連線，但清單中的 TCPing 通常只會對設定中的伺服器位址和連接埠發起 TCP 連線。它不是系統的 ICMP Ping，也不會完成 VMess 或 VLESS 代理驗證。伺服器若填入網域名稱，測試前還需要解析位址；解析所花時間是否會計入顯示數值，取決於實作方式，因此不能把測得的數值當成純粹的網路往返時間。
TCPing：檢查伺服器連接埠是否可連線
檢查手機能否與節點連接埠建立 TCP 連線。假設節點使用 TCP 443，測得 45 ms 只代表連接埠連線速度快，無法證明 UUID、TLS 的 serverName 或 Reality 參數設定正確。
適用情境：大量節點初步篩選、檢查位址與連接埠是否可連線。
真實連線延遲：透過代理連線至測試目標
推薦透過待測設定向測試 URL 發出請求，計時可能涵蓋代理交握、目標網域解析、TLS 連線與 HTTP 回應等環節。這比探測連接埠更接近日常瀏覽網頁的情況，但結果只適用於該測試目標。
適用情境：確認設定是否可用、挑選日常瀏覽的候選節點。
下載測速：評估持續傳輸能力
透過代理持續下載資料，觀察單位時間內接收的資料量。結果會受到節點限速、網路壅塞、目標伺服器頻寬及測試時間影響，無法單靠一次延遲測試推算。
適用情境：播放影片、下載大型檔案、檢查尖峰時段的傳輸速度。
建議優先參考真實連線延遲，但不代表永遠選擇毫秒數最低的節點。測試 URL 和實際使用的網站可能位於不同地區；節點連上測試站很快，連到實際服務仍可能繞路。若主要使用 UDP，TCPing 和一般 HTTPS 下載也無法驗證 UDP 轉送能力。
二、在 v2rayNG 中依固定順序測試
先保留現有設定，不要一邊測速一邊修改路由、DNS 和傳輸參數。v2rayNG 不同版本的選單譯名可能略有差異，以下以常見的 TCPing、真實連線測試選項為例；若找不到相同名稱，請依功能辨認，也不要把清單底部的目前連線測試當成所有節點的測試。
- 暫停其他傳輸。停止應用程式更新、雲端硬碟同步和影片下載，固定使用同一個 Wi-Fi 或同一張行動網路 SIM 卡。記下測試時間與網路類型，兩輪測試之間不要切換網路。
- 批次檢查連接埠。開啟主畫面右上角的「⋮」，選擇「測試所有設定 TCPing」或相應的 TCPing 選項。先標記測試失敗的節點，保留成功的節點，不必急著刪除設定。
- 批次檢查代理連線。在同一個選單中選擇「測試所有設定真實連線」或相應選項。若版本在「設定」中提供「測試 URL」或「連線測試 URL」，請記下目前使用的網址；比較期間不要更換網址。
- 再次確認目前連線。選取候選節點，點選右下角的連線按鈕，並確認已授予 Android VPN 權限。若畫面底部提供連線狀態測試，點選後確認目前設定仍能完成請求。
- 只對候選節點測試傳輸速度。使用確認會透過代理連線的瀏覽器，開啟固定的測速頁面，或下載同一個頻寬充足的測試檔案。不要同時測試多個節點，以免彼此搶用本機頻寬。
批次真實連線測試和目前連線測試的執行方式不一定相同，尤其是用戶端自行啟動暫時測試核心時。比較結果時，也應記錄使用的是「批次測試」還是「目前連線測試」，不要將不同選項測得的數值混在同一組資料中。
三、透過多次測試區分低延遲與高傳輸速度
以下是用來說明測試數值的範例，並非本站實測結果，也不代表任何服務的速度保證。假設三個節點使用相同的測試 URL、下載檔案和網路，每個節點測試真實連線三次，下載速度則取穩定階段的平均值。
| 候選節點 | TCPing | 真實連線測試三次 | 平均下載速度 | 判斷 |
|---|---|---|---|---|
| A | 38 ms | 310 / 920 / 460 ms | 1.2 MB/s | 連接埠速度快，但完整請求的波動明顯 |
| B | 82 ms | 205 / 218 / 211 ms | 8.0 MB/s | 請求穩定，適合作為常用候選節點 |
| C | 65 ms | 三次測試皆逾時 | 未測試 | 先檢查設定，不納入傳輸速度比較 |
A 的 TCPing 最低，但三次完整請求的中位數是 460 ms；B 的中位數為 211 ms，而且三次數值相近。此時優先試用 B 較合理。三次測試只能用來快速初篩，無法據此計算可靠的封包遺失率，也不能只憑一次逾時就認定網路封包遺失。
請注意，MB/s 與 Mbps 相差八倍，MiB/s 使用的位元組計量方式也不同。測速頁面顯示 64 Mbps，而下載程式顯示約 8 MB/s，通常並不矛盾。平均速度為 8 MB/s、持續 15 秒的測試約會使用 120 MB 資料，多次測試前請留意行動網路流量。
結論：先排除反覆失敗的節點，再比較中位數與穩定下載速度
不要因為 A 的延遲只有 38 ms 就將它設為常用節點。先確認 C 失敗的原因，再讓 A、B 分別實際使用一輪；若 B 持續穩定，就將 B 設為常用節點、A 留作備用。
四、TCPing 延遲很低，為什麼真實連線仍會逾時？
連接埠可連線，只能確認連線入口的一部分。代理驗證失敗、傳輸層參數錯誤，以及節點無法連上測試站，都可能發生在 TCP 連線建立之後。依照以下順序檢查，可避免把設定錯誤誤判為伺服器頻寬不足。
「TCPing 只有 40 ms，為什麼真實連線一直逾時？」
開啟節點編輯頁面，確認位址、連接埠、UUID 和傳輸設定。VLESS + Reality 設定也要確認公鑰、shortId 和 serverName；WebSocket 設定則要確認 path 和 Host。接著查看主畫面的「記錄」中的連線或交握錯誤，不要藉由關閉憑證驗證來掩蓋問題。
「真實連線顯示 -1，是不是延遲太高？」
負數通常代表測試失敗，不是負延遲；具體提示請以目前版本的畫面為準。先對同一個節點重新測試，再查看記錄中是否有解析失敗、連線逾時或 TLS 錯誤。若所有節點都同時失敗，請優先檢查測試 URL、本機網路和系統時間。
「真實連線測試結果很好，為什麼某個網站還是很慢？」
使用同一個瀏覽器測試兩個不同目標，確認是否只有其中一個網站速度慢。接著確認該網域是否透過代理路由，以及 DNS 是否回傳合適的位址。真實連線測試只驗證測試 URL，無法證明所有網站的 DNS 解析和出口路徑都正常。
「下載一開始很快，之後速度一直下降？」
將測試延長至至少 15 秒，觀察穩定階段，而非只看峰值。暫停其他傳輸後，重新測試同一個檔案；若速度仍持續下降，再比較另一個節點。短時間突發頻寬、伺服器限速和網路壅塞都可能造成這種曲線，只測一次無法確定原因。
若設定主要使用 UDP 傳輸，即使 TCPing 失敗，也不能單憑這點判定節點失效，因為相同位址和連接埠可能根本沒有提供 TCP 服務。請先確認節點的傳輸類型，再使用用戶端支援的真實連線測試或實際服務進行驗證。
五、瀏覽網頁與下載檔案，挑選節點的方式不同
瀏覽網頁通常會發出多次小型請求，因此更容易受到連線建立時間、DNS 解析時間和延遲波動影響；下載大型檔案則更仰賴穩定的傳輸速度。不要所有用途都套用同一份「延遲由低到高」排行榜，也不要只憑協定名稱推測速度。
建議做法：依實際用途設定常用與備用節點
瀏覽網頁、訊息與 API 請求
- 先確認真實連線連續三次都成功。
- 比較中位數，並檢查最高值是否明顯偏高。
- 實際開啟常用網站，觀察首次載入和連續請求的狀況。
- 保留一個使用不同出口的備用節點，以因應目標網站異常。
播放影片與下載大型檔案
- 先通過真實連線測試，再進行持續下載。
- 比較相同檔案、相同測試時間下的平均速度。
- 在平常使用的晚間時段重新測試，避免只看離峰時段的結果。
- 檢查是否有卡頓或連線中斷，不要只記錄最高速度。
常用節點依實際用途挑選，備用節點則以可用性為優先；切換網路後請重新驗證，不要沿用舊的排序。
v2rayN 桌面版也能沿用這套判斷順序，但不同用戶端的測試目標、並行數量、逾時門檻和計時範圍可能不同。手機測得 200 ms、電腦測得 150 ms，不一定代表電腦使用的節點較快。請先統一測試條件，再比較結果。
六、保存可供日後查核的測速記錄
只截取一個綠色的毫秒數值，事後很難判斷為什麼換網路後表現不同。記錄不必複雜，但應包含網路類型、時間、測試方式和目標。以下清單足以應付日常檢查，也能協助找出尖峰時段的網路壅塞或單一目標異常。
- 環境：記下 Wi-Fi 或行動網路、測試日期與時間，並註明是否正在充電、是否啟用省電限制。
- 用戶端：從「關於」頁面記下實際版本號，註明使用的是 v2rayNG 還是 v2rayN；升級後請重新建立基準。
- 測試條件：記下測試 URL、下載目標、單次測試時間，以及分應用程式代理和路由模式是否有變更。
- 結果：記錄 TCPing、三次真實連線的原始數值、失敗次數和穩定階段的下載速度，並統一使用相同單位。
- 實際使用情況：補充常用網站能否開啟、影片能否連續播放，再決定是否設為常用節點。
建議固定依照以下順序挑選：連接埠初步篩選 → 真實連線驗證 → 多次測試 → 依需求進行下載測速 → 實際使用確認。這樣既能減少不必要的大量下載測試，也能分別處理「設定無法連線」、「測試目標異常」和「傳輸速度不足」等問題。
安裝用戶端並首次連線
依作業系統選擇 v2rayNG 或 v2rayN；首次使用請先完成匯入與連線，再依照本文順序測試節點。