遇到「延遲很低卻打不開網頁」或「測速逾時但瀏覽器能用」，先分辨入口連接埠、代理連線與下載速度。本文說明四種指標的測試範圍，整理 v2rayN 操作步驟、可重現的記錄方式及逾時排查方法，適合已匯入訂閱、需要篩選日常使用節點的使用者。
分辨四種測試：各自測到哪一段
節點的狀況不能只用毫秒數描述。一次網頁請求可能經過本機代理連接埠、節點入口、協定交握、節點出口與目標網站。ICMP ping 和 TCPing 通常只測到入口附近；真實連線延遲會進一步確認代理請求；下載速度測試則觀察持續傳輸能力。由於測試終點不同，不能把數值直接排成同一份「快慢排名」。
| 測試方式 | 主要測量範圍 | 無法單獨證明的事項 |
|---|---|---|
| ICMP ping | 本機至目標主機的 ICMP 往返時間與回應狀況 | 節點服務連接埠已開啟、代理驗證設定正確 |
| TCPing | 本機連上節點指定 TCP 連接埠所需的時間 | VMess 或 VLESS 設定正確，且出口能連上網站 |
| 真實連線延遲 | 透過待測節點向測試網址送出請求所需的時間 | 所有網站都能連線，且長時間傳輸穩定 |
| 下載速度測試 | 透過節點持續接收指定資源時的傳輸速率 | 網頁首位元組時間短、遊戲 UDP 表現良好 |
ICMP 不使用 TCP 連接埠。若節點服務監聽在 443，一般 ping 並不會測試這個連接埠。伺服器也可能限制 ICMP，因此「ping 不通」不代表代理無法使用。若節點位址前方還有中轉或內容傳遞網路，測到的也可能只是前端入口，而非最終出口主機。
TCPing 成功只代表某個 TCP 端點接受了連線，尚未驗證代理協定。即使連接埠回應很快，使用者識別資訊、TLS 伺服器名稱、傳輸路徑或其他協定參數設定錯誤，後續請求仍會失敗。若設定使用非 TCP 傳輸，TCPing 更不能取代實際傳輸測試。
如何選指標：先測可用性，再看傳輸速度
真實連線延遲
建議優先日常挑選節點時，先用它確認代理請求能否完成，再比較多次測試結果。測試網址與實際使用的網站仍可能經過不同路徑，建議再實際瀏覽確認。
適用情境：瀏覽網頁、辦公應用與日常節點初選
TCPing
快速確認節點入口的 TCP 連接埠是否連得上。真實連線失敗時，可用來縮小問題範圍；不建議只憑最低數值挑選主要節點。
適用情境：檢查入口連線與分層排查故障
下載速度測試
觀察一段時間內的傳輸速率，並留意檔案大小、測試時間與流量用量。資源伺服器限速也會拉低測試結果。
適用情境：傳輸大型檔案、評估影片緩衝表現
真實連線延遲不一定等於完整網頁載入時間。不同版本可能採用不同的測試請求計時範圍、連線重用方式與成功判定條件；HTTPS 請求也可能涉及 DNS、代理協定、TLS 與目標網站回應。比較時應固定用戶端版本、核心、測試網址與網路環境，不要直接拿兩台裝置的單次結果下結論。
判斷方式：先排除持續失敗的節點，再比較穩定度
先連續測試真實連線 5 次，記錄成功次數與中位數；再從全部成功的候選節點中，依實際網站使用體驗與下載需求篩選。不要因一次特別低的 TCPing 數值，就忽略反覆逾時的情況。
在 v2rayN 執行一輪可供比較的測試
先更新訂閱並確認節點設定完整，再暫停系統更新、雲端同步與其他大量傳輸工作。以下以 v2rayN 常見的中文介面說明；不同版本的選單文字可能略有差異，右鍵選單中的「Tcping」、「真實連線延遲」、「速度」等項目代表不同測試，請勿混用結果。
- 記錄測試條件。在「說明」→「關於」或版本資訊頁記下版本號，同時記錄使用的核心、Wi-Fi 或有線網路，以及測試時間。測速時不要同時更改多項設定。
- 挑選少量候選節點。在節點清單選取 3～5 個節點，按右鍵執行名稱含「Tcping」的測試，先確認入口連接埠。避免一次同時測試大型訂閱中的所有節點。
- 執行真實連線測試。保持選取節點，按右鍵選擇名稱含「真實連線延遲」的測試項目。若測試失敗，先記錄逾時情況，不要立刻將逾時時間無限調長。
- 固定測試網址。前往「設定」→「參數設定」，找出與速度或延遲測試相關的設定，記錄目前的測試網址與逾時設定。若該版本使用獨立設定頁，請以實際介面為準；每輪測試都使用同一個目標。
- 重複取樣。每輪間隔約 10 秒，共測試 5 輪。逾時次數另外計算，成功值排序後取中位數；不要把逾時記成 0 毫秒後納入平均。
- 逐一測試下載速度。對保留下來的節點分別執行速度測試，或使用可信且允許測速的下載資源觀察約 20～30 秒。先確認訂閱流量餘額，再決定是否繼續。
看懂範例：低延遲與高速度為何看似矛盾
以下數據僅用來示範判讀方式，並非本站實測結果或節點效能保證。假設節點 A 的 5 次真實連線測試結果為 176、184、181、179、180 毫秒，下載期間平均速度為 8.0 MB/s；測試條件固定，且沒有其他下載工作。
42 毫秒與 180 毫秒並不矛盾：前者只反映連上入口 TCP 連接埠所需的時間，後者則包含更多代理請求流程。兩者相減也無法精確算出「節點處理時間」，因為測試使用的連線、路由與計時範圍都不相同。
| 範例節點 | TCPing | 真實連線 | 下載速度 | 判讀結果 |
|---|---|---|---|---|
| A | 42 ms | 5 次皆成功，中位數 180 ms | 8.0 MB/s | 可列入日常使用候選 |
| B | 18 ms | 3 次成功、2 次失敗，成功值中位數 290 ms | 1.2 MB/s | 入口連線快，但完整請求不穩定 |
| C | 96 ms | 5 次皆成功，中位數 240 ms | 15.0 MB/s | 適合下載大型檔案；互動延遲另行評估 |
節點 C 的傳輸速度高於 A，不代表開啟每個網頁都會更快。網頁需要多次請求、執行指令碼並等待資源伺服器回應；大型檔案下載則較容易在連線建立後持續充分利用頻寬。單位也要一致：以十進位換算，8.0 MB/s 約為 64 Mb/s；這是應用程式測得的資料傳輸速率，不必然與寬頻標示的速度完全相同。
排查逾時：從入口、協定到目標網站逐步檢查
遇到逾時，先確認是哪一種測試失敗。若把所有失敗都當成「節點故障」，很可能只是不斷更換訂閱，卻沒處理本機連接埠遭占用、測試網址無法連線或路由走直連等真正原因。
TCPing 數值很低，為何真實連線一直逾時？
開啟用戶端記錄，先查看驗證失敗、TLS 交握錯誤或連線遭中斷等訊息。核對訂閱中的位址、連接埠、使用者識別資訊與傳輸參數，並檢查系統時間。TCP 入口可連線，不代表代理協定交握已完成。
瀏覽器能開啟網頁，為何真實連線測試卻逾時？
確認內建測試目標是否無法單獨連線，再確認瀏覽器是否確實經過待測節點，而非直接連線或使用其他節點。固定一個可連線的測試目標重新測試，並查看記錄中的實際出口選擇。
真實連線測試成功，為何下載速度只有幾百 KB/s？
先暫停其他傳輸工作，單獨測試一個節點，再換用另一個允許下載的資源交叉比對。如果只有某個資源速度慢，可能是來源網站限速，或連往該網站的路線有問題；若所有資源都慢，再檢查本機網路與節點壅塞狀況。
ping 不通但網頁正常，還需要更換節點嗎？
不必只因 ICMP 測試結果就更換節點。伺服器可能不回應 ICMP；請繼續觀察真實連線成功率與實際網頁瀏覽狀況。若要檢查封包遺失，應搭配持續請求或對應傳輸方式的診斷，不能把 ICMP 無回應直接視為代理流量遺失。
VMess 與 VLESS 是協定名稱，不代表效能等級。某個節點速度較快，可能是因為入口較近、出口頻寬較充足，或中轉路線不同，不能只看兩個延遲數值就推斷某種協定一定比較快。更換協定時若也更換了伺服器，就不再是單一變因的比較。
確認瀏覽器的連線路徑：明確指定本機代理連接埠
在 Windows 上，可使用系統內建的 curl.exe 補充檢查。以下假設已在 v2rayN「設定」→「參數設定」中確認本機 HTTP 或混合代理連接埠為 10808，並已將候選節點設為目前使用的節點。連接埠僅為本例條件；若介面顯示不同連接埠，請先依實際設定修改命令。純 SOCKS 連接埠不能直接當作 HTTP 代理連接埠使用。
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --output NUL --silent --show-error --write-out "http=%{http_code} start=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/- 確認請求目標：以下使用範例網域示範命令格式。實際比較時，請使用自己能連線、獲准測試且內容穩定的 HTTPS 網頁，並固定使用同一個網址。
- 了解輸出結果：
http是 HTTP 狀態碼；start是從送出請求到收到第一個位元組的累計時間；total是本次傳輸的總時間。這些數值不能直接取代 v2rayN 的真實連線欄位。 - 先排除本機問題：若顯示無法連線至
127.0.0.1，先檢查用戶端是否正在執行、連接埠是否正確，以及核心是否已啟動，不要立刻判定遠端節點失效。 - 分辨狀態碼與連線狀況：收到 403 等回應，代表已收到 HTTP 回應，但目標可能限制存取；不能把「收到狀態碼」一律視為服務可正常使用。
明確指定代理可減少「應用程式沒有使用系統代理」的疑慮，但仍須檢查核心路由：該網域可能依規則經由直連出口。若要驗證候選節點，應查看記錄確認請求經過對應的代理出口，並留意 TUN 與其他網路軟體是否改變底層連線路徑。
依使用情境保留主要與備用節點
挑選方式：分開評估互動體驗與持續下載
瀏覽網頁與日常辦公
- 優先保留 5 輪真實連線測試全數成功的候選節點。
- 比較中位數，並記錄最慢一次是否明顯偏高。
- 開啟兩個實際使用的網站，確認登入與資源載入狀況。
- 保留一個入口或路線不同的備用節點。
影片與大型檔案
- 確認連線可用後，再逐一觀察持續下載表現。
- 固定資源、測試時間與速度單位，避免同時測速。
- 在常用的晚間時段再測一次，確認尖峰時段是否壅塞。
- 記錄流量用量，不要反覆讓頻寬滿載。
先確保穩定可用，再依用途挑選節點；主要與備用節點不必分別拿下延遲排名第一和第二。
若用途是即時語音或遊戲，還需要確認對應應用程式的 UDP 連線能力、抖動與持續封包遺失狀況。TCPing、HTTP 真實連線與下載速度都不能直接取代這些指標。測試記錄至少應保留日期、網路、節點、測試目標、成功次數與速度單位；下次遇到問題時，才能判斷是本機網路、目標網站改變，還是節點路線在尖峰時段變得不穩定。