TCPing 檢查連到伺服器連接埠的 TCP 交握時間；真實連線延遲測試透過節點送出的實際請求；下載測速則觀察持續傳輸能力。挑選日常瀏覽用的節點，先確認真實連線能否成功且結果穩定；需要傳輸大型檔案時，再比較下載速度。本文整理 v2rayN、v2rayNG 的操作順序，以及延遲低卻打不開網頁時的排查方式。
三種測試分別測量哪些環節
延遲是從發出操作到取得結果所花的時間，不是線路的固定屬性。測試入口、目標位址及是否重複使用連線，都會影響結果。直接比較不同用戶端介面顯示的毫秒數，可能等於拿不同操作來比較。
TCPing
連線至節點伺服器的位址與連接埠，主要反映這段路徑的 TCP 交握耗時。交握成功不代表代理協定驗證通過，也不代表能連上目標網站。
適用情境：批次排除連接埠無法連線或交握明顯過慢的節點
真實連線延遲
建議優先參考用戶端透過節點向測試位址送出請求。測試涵蓋代理連線建立、目標請求等更多環節，但仍會受到測試位址與逾時設定影響。
適用情境：挑選日常瀏覽用的節點，先確認請求能順利完成
下載測速
持續下載測試檔案，觀察一段時間內接收的資料量。結果也會受到檔案伺服器、裝置效能及同時進行的傳輸影響。
適用情境：比較大型檔案下載與持續傳輸表現
TCPing 並不適用於所有傳輸方式。若節點入口使用的不是 TCP，就不能拿某個 TCP 連接埠的交握時間，代替節點實際的連線時間。真實連線測試也只代表當下對測試位址送出的一次請求；目標網站的 DNS、路由或回應速度改變，測得的毫秒數也可能跟著變動。
結論：先確認測量項目，再比較數值
只在相同用戶端、相同測試位址及相近時間下比較真實連線延遲。TCPing 適合用來初步確認連線狀況，不能用來證明網頁一定開得起來。
為什麼 TCPing 延遲很低，網頁卻打不開？
例如 TCPing 顯示 40 ms，只能表示當下連到伺服器連接埠的 TCP 交握很快。節點的 VMess 或 VLESS 設定仍可能與伺服器端不符；即使代理連線已建立，目標網域解析、路由分流或目標伺服器也可能出問題。網頁無法開啟時，先釐清是「測試位址請求失敗」還是「只有特定網站無法連線」。
以上是用來說明不同測量單位的範例，並非對任何節點的效能保證。40 ms 與 240 ms 並不衝突：前者只測到伺服器連接埠的交握，後者還包含用戶端、代理路徑與測試目標。5.8 MB/s 是傳輸速率，不能換算成網頁等待首位元組的時間；10808 則是本機監聽連接埠，完全不是測速結果。
- 先確認真實連線測試是否成功。若失敗，開啟用戶端記錄，分辨連線逾時、驗證錯誤或目標請求錯誤。
- 確認目前使用的節點就是剛才測試的節點，並檢查系統代理或應用程式內的代理設定是否指向目前的用戶端。
- 確認路由規則是否讓目標網域經由代理連線。同一網域走直連或代理路徑時，故障位置可能不同。
- 若只有少數網站無法連線，請檢查該網域的解析結果與目標網站狀態，不要只憑一次 TCPing 就更換整份訂閱。
如何在 v2rayN 與 v2rayNG 比較節點
先更新訂閱並固定測試條件。測試期間盡量使用同一個網路，暫停會占用頻寬的大型檔案傳輸；同一組候選節點應使用相同的測試位址與逾時設定。不同版本的選單名稱可能略有差異，請以目前用戶端介面顯示的文字為準。
建議流程：先篩選可用節點，再測持續傳輸
桌面版 v2rayN
- 在伺服器清單中選取同一組節點，先執行 TCPing，排除連接埠無法連線的節點。
- 接著使用清單中的「測試伺服器真實連線延遲」功能，記錄成功次數與毫秒數。
- 將候選節點逐一設為目前使用的節點，再以實際網頁請求確認。
Android 版 v2rayNG
- 在設定檔清單中，對候選節點執行連線測試或真實連線測試，並留意失敗訊息。
- 啟用選定的設定檔後，確認系統中的 VPN 連線已啟用。
- 使用同一個網路瀏覽常用網頁，再對有較高傳輸需求的節點進行下載測試。
分別記錄兩台裝置的結果；不要直接拿桌上型電腦的有線網路延遲，和 Android 裝置的行動網路延遲排名。
v2rayN 的真實連線測試通常會直接列在伺服器清單的操作選項中。v2rayNG 的測試入口與批次測試名稱可能隨版本調整；若找不到相同文字，可查看設定檔清單選單中的連線測試項目。兩種用戶端都要留意測試位址：若測試目標回應較慢，所有節點的結果都可能一起變慢。
建議每個候選節點間隔測試三次，記錄成功與否及大致延遲範圍。例如 A 節點依序測得 180、195、188 ms；B 節點則是 90 ms、逾時、310 ms。只看 B 節點的最低值，會忽略一次失敗與較大的波動；日常瀏覽通常應優先選擇請求能穩定完成的節點。
結論：請求穩定完成，比單次最低延遲更重要
先排除真實連線反覆逾時的節點，再比較穩定候選節點的延遲。只有持續下載是主要用途時，才用下載測速決定最後排名。
如何解讀下載測速結果？什麼時候該重測？
下載速度與延遲衡量的是不同表現。真實連線延遲相近時，其中一條線路的長時間傳輸速度可能更快；下載速度相近時，另一條線路開啟小型網頁的回應也可能更快。下載測試應確認檔案夠大且傳輸持續一段時間，不要只看剛開始時的瞬間峰值來判斷整條線路。
| 測試結果 | 優先檢查 | 下一步 |
|---|---|---|
| TCPing 延遲低，真實連線逾時 | 協定設定、節點記錄、測試位址 | 先排除請求失敗，再比較排名 |
| 真實連線穩定，下載速度慢 | 測試檔案來源、並行下載、線路壅塞 | 換用相同的測試檔案，在不同時段重新測試 |
| 下載速度快，網頁還是很慢 | 目標網站回應、網域解析、路由規則 | 分別測試常用網站，不要用傳輸量取代回應時間 |
測試位址本身也會影響判斷。若下載檔案所在的伺服器有限速，測得的是「節點與該檔案伺服器組合」的速度，而不是節點能達到的上限。同樣地，若路由規則將測試位址設為直連，下載數字就無法代表透過代理的傳輸速度。測試前請確認流量確實經過目前使用的節點。
- 重新測試時，固定網路類型、測試目標與檔案大小，並記錄測試時段。
- 分開記錄 MB/s 與 Mbps。以十進位單位粗略換算，1 MB/s 約等於 8 Mbps。
- 一個節點的測速尚未結束前，不要切換至下一個節點；舊連線可能仍在占用頻寬。
常見測試結果與處理方式
節點清單中出現多個低延遲結果時，先確認哪些節點實際完成了請求，再用自己常瀏覽的網站複測。單次結果只是某個時間點的狀況；切換網路、伺服器負載或目標網站狀態改變，都可能使第二次測試的排名不同。
TCPing 是 30 ms，真實連線卻逾時？
先檢查目前節點的位址、連接埠與協定設定，再查看用戶端記錄。TCP 連接埠能連線，只能排除部分網路問題，無法確認 VMess 或 VLESS 代理請求已成功。
真實連線測試成功，為什麼瀏覽器還是打不開網頁？
確認瀏覽器實際使用了系統代理，或正確的手動代理連接埠。接著檢查目標網域的路由規則；測試位址能連線，不代表所有網域都走相同路徑。
v2rayN 和 v2rayNG 測出的延遲差很多？
先確認兩端使用相同節點、測試位址與網路類型，再檢查用戶端核心設定與路由設定。測試條件不一致時，不適合直接按毫秒數比較裝置。
下載測速第一秒很快，接著卻變慢？
記錄整段傳輸的平均速度，並換個時段以相同檔案重測。起始峰值可能受到快取或短時間可用頻寬影響，不宜單獨用來挑選節點。
只挑延遲最低的節點就好嗎？
日常瀏覽時，先排除請求失敗或波動明顯的節點，再比較穩定候選節點的真實連線延遲。傳輸大型檔案則應加做下載測速，並以實際使用時段的結果為準。
選擇節點時應依用途判斷：瀏覽網頁要看請求能否穩定完成，持續傳輸要看一段時間內的速度，排查入口故障則優先看 TCPing。記下測試時間、網路類型與失敗訊息，比只保留最低延遲更有助於下次找出問題。