TCPing 用來確認節點入口是否能建立 TCP 連線；真實連線延遲用來確認代理連線能否存取指定測試目標；下載速度測試則用來觀察持續傳輸能力。本文適用於 v2rayN、v2rayNG 或 v2flyNG 使用者，依序說明測試範圍、選單操作、結果記錄與故障排查，並整理出先確認連線、再比較回應速度、最後測試傳輸效能的節點篩選流程。
三種測速方式各自涵蓋哪些連線環節
只有採用相同測試方式時，用戶端清單中的毫秒數才適合互相比較。TCP 連線成功，不代表 VMess 或 VLESS 驗證也成功；測試頁面回應迅速，也不代表大型檔案能持續高速傳輸。先確認選單執行的是哪種測試，再判讀結果欄位。
TCPing：檢查入口連線
向節點位址和連接埠發起 TCP 連線，通常會測量建立連線所需的時間。這和系統 ping 使用的 ICMP 不同，也不會完整驗證代理協定、帳戶參數或節點出口。
適用情境：批次排除入口連接埠無法連線的設定，縮小後續測試範圍。
真實連線延遲：檢查代理請求
推薦透過受測設定和核心向指定目標發出請求。耗時可能包含連線至節點、代理握手、目標解析及目標回應；實際計時範圍取決於用戶端的實作方式，不能直接視為網路往返時間。
適用情境：日常篩選可瀏覽網頁的節點，確認協定參數和請求連線可正常使用。
下載速度測試：檢查持續傳輸效能
透過受測設定下載測試內容，再依傳輸資料量和耗時計算速度。結果會受到下載來源、線路壅塞、伺服器限速、測試時間及裝置處理能力影響。
適用情境：比較少數可用節點傳輸大型檔案的能力。
例如，節點入口使用 TCP 443 連接埠，TCPing 成功只表示當下能連上該位址的 443 連接埠。即使 UUID 填錯或 WebSocket 路徑不符，入口仍可能顯示很低的毫秒數。若設定使用非 TCP 傳輸方式，也不能只憑 TCPing 失敗就判定整個設定無法使用。
v2rayN 與 Android 用戶端的測速操作
先更新訂閱，再挑選少數設定進行測試。不同版本和介面的選單文字可能略有差異，以下以常見的中文介面為例；請以實際顯示的「Tcping」、「真實連線延遲」、「速度」等動作名稱為準，別假設所有用戶端都提供相同的測速功能。
- v2rayN：選取設定。進入伺服器清單，按住 Ctrl 選取 3～5 個節點。按右鍵開啟選單，先執行「測試伺服器延遲 Tcping」並查看結果，再對同一批節點執行「測試伺服器真實連線延遲」，等待整輪測試完成。
- v2rayN：比較速度。保留真實連線測試成功的 2～3 個候選節點，按右鍵執行「測試伺服器速度」。此時不要執行其他大量傳輸工作，也別一次對數百個節點進行下載測試。
- v2rayN：統一測試參數。開啟「設定」→「參數設定」，確認目前版本提供的測速項目，包括延遲測試網址、下載測試網址和逾時時間。若版本未提供其中某項，記錄預設行為即可，不必為了找選項而修改節點協定。
- v2rayNG：批次測試真實連線。在設定清單右上角開啟選單，選擇「測試所有設定的真實連線」。若要檢查目前節點，先選取該設定、啟動服務並完成 Android VPN 授權，再點選底部的連線狀態區域測試目前連線。
- v2flyNG：依實際選單操作。在設定清單選單中，尋找目前版本提供的連線測試功能，並記錄測試類型。測試前確認設定屬於 V2Fly 核心支援的範圍；若使用依賴 Xray 功能的 VLESS + REALITY 設定，應改用支援該功能的用戶端與核心。
以相同條件比較延遲與波動
以下是用來說明計算方式的假設紀錄，並非節點實測排名。假設在同一台裝置、同一個 Wi-Fi 網路和同一個測試目標下，逐一測量節點 A 五次。TCPing 結果為 31、34、35、37、52 毫秒；真實連線結果為 168、175、182、194、620 毫秒。
將五次結果由小到大排列，第三個數值就是中位數。相較於單次最低值，中位數更能代表這組測試的典型表現，但五次樣本仍不足以反映長期穩定度。620 毫秒表示這輪出現明顯波動，應再次測試，而不是直接判定該節點長期不穩定。
| 記錄項目 | 節點 A | 節點 B | 判斷方式 |
|---|---|---|---|
| TCPing 中位數 | 35 ms | 68 ms | 只比較入口連線建立速度 |
| 真實連線中位數 | 182 ms | 146 ms | B 對此測試目標的回應較快 |
| 真實連線成功次數 | 5 / 5 | 5 / 5 | 本輪請求皆成功 |
| 平均下載速度 | 8 MB/s | 5 MB/s | A 對此下載來源的傳輸效能較佳 |
結論：依實際用途保留兩個候選節點
依據這組假設結果，瀏覽網頁可先試用節點 B，傳輸大型檔案則可先試用節點 A。請分別開啟目標網站確認，並在常用時段再次測試；不要直接把入口延遲最低的節點設為所有用途的首選。
請單獨記錄測試逾時情況，例如「4 次成功、1 次逾時」，不能把逾時當成 0 毫秒，也不應只計算成功結果的平均值而略過失敗次數。應用程式層的逾時可能發生於解析、握手或目標回應階段，不能直接換算成底層網路的封包遺失率。
下載速度的單位、測試時間與流量成本
寬頻標示速度通常使用 Mbps，用戶端則常顯示 MB/s 或 MiB/s。以十進位單位換算，8 MB/s 約等於 64 Mbps；若顯示 8 MiB/s，則約為 67.1 Mbps。比較不同工具前先確認單位，數值相同不代表速度相同。
- 使用固定的測試來源。同一個節點連至不同下載來源，測試結果可能差異很大。來源站的並行連線限制、內容快取，以及節點出口至來源站的線路都會影響傳輸效能。
- 使用固定的測試時間。若工具允許設定，可統一測試 10～15 秒，並記錄平均速度和後半段的表現。只看剛開始的峰值，容易把短暫快取或突發頻寬誤當成持續速度。
- 估算流量。以 8 MB/s 連續下載 15 秒，單一節點的內容流量約為 120 MB；連續測試 5 個節點約為 600 MB，實際用量還可能包含額外的協定開銷。
- 控制並行測試數量。逐一測試有助於比較單一節點的效能。多個節點同時下載會共用本地網路頻寬，測得的是頻寬競爭下的結果。
延遲很低卻無法開啟網頁：依失敗環節排查
先保留失敗當下的記錄，再一次只調整一項設定並重試。若同時更換 DNS、路由模式、傳輸協定和測試目標，就很難判斷成功或失敗的原因。記錄中若包含伺服器位址、帳戶識別資訊或訂閱資料，分享前請先遮蔽相關欄位。
TCPing 只有 30 毫秒，為什麼真實連線總是逾時？
開啟該節點的編輯視窗，對照服務提供者的參數，確認位址、連接埠、UUID、傳輸類型和安全性選項。若使用 WebSocket，還要確認路徑和 Host；若使用 TLS，則要確認伺服器名稱。入口可連線不代表這些參數正確，請勿以關閉憑證驗證來掩蓋設定錯誤。
真實連線測試成功，瀏覽器為什麼還是無法開啟網頁？
先確認目前使用的節點就是受測節點。桌面版請檢查系統代理或 TUN 是否如預期啟用，以及瀏覽器是否另行設定代理；Android 則確認 VPN 服務已啟動，目標應用程式沒有被分流規則排除。接著開啟實際目標網站，並查看記錄中的出站與錯誤訊息。
所有節點都顯示逾時，是訂閱失效了嗎？
先確認本地網路可正常使用，再檢查核心是否成功啟動及記錄中的錯誤。若所有節點都只有在同一個測試目標上失敗，可在「設定」→「參數設定」提供的測速項目中改用其他可控制的目標重測。測試目標異常和帳戶失效應分別確認。
測速很快，晚上下載卻很慢，該換協定嗎？
先在晚上使用相同的下載來源和測試時間重新測試，並暫停其他下載。如果多個節點都變慢，請進一步檢查本地網路和共用頻寬；若只有特定節點變慢，再比較其他節點。改用 VMess 或 VLESS 不會自動解決出口壅塞或伺服器限速。
若只有部分網域無法連線，請再檢查 DNS 和路由。測試工具可能會為每個候選設定建立獨立的測試出站連線，但瀏覽器流量仍依照目前的路由規則處理；兩者不一定走相同路徑。請參閱路由分流說明和DNS 設定說明，確認目標請求實際經過的路徑。
建立可重複執行的節點篩選流程
將初次篩選和日常複測分開。初次篩選是為了找出少數可用的設定；日常複測則是確認這些設定在實際使用時段仍然合適。別為了追求低一毫秒的數值，反覆對整份訂閱進行大量流量測試。
測試計畫：初次篩選與日常複測
初次匯入後
- 更新訂閱，確認設定欄位完整。
- 使用 TCPing 輔助篩選適用的 TCP 入口。
- 挑選 3～5 個候選節點，各進行 5 次真實連線測試。
- 從中挑選 2 個候選節點，逐一進行短時間下載測試。
日常使用前
- 固定裝置、網路和測試目標。
- 記錄成功次數、中位數和明顯波動。
- 在常用的晚間時段重新測試同一組節點。
- 開啟實際網站或檔案，確認服務是否正常。
先確認請求成功，再比較回應時間；只有需要持續傳輸時，才進行下載速度測試。
記錄時至少保留測試時間、網路連線、用戶端名稱、核心、測試類型和目標。v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心；也應記錄 v2rayN 使用的核心。比較協定或核心時，若節點出口、目標和測試時段都不同，就不能將所有差異歸因於核心。
- 先確認成功率。經常連線失敗的節點，即使偶爾測出低延遲，也不適合直接作為主要節點。
- 再比較回應速度與波動。綜合多次真實連線測試結果，選擇符合實際存取目標的候選節點。
- 最後比較傳輸效能。依實際下載需求比較持續速度，並保留一個已驗證可用的備用設定。