Ping、實際連線延遲與下載測速的差異：v2rayN 延遲測試原理解讀

節點清單中同時出現 35 ms、128 ms、18 MB/s，並不表示三種工具中有兩個測錯了。它們使用不同協定、連線至不同目標，也在回答不同問題：主機是否能快速回應、代理通道能否完成一次真實請求，以及通道持續傳輸資料時能達到多大的吞吐量。只有先釐清問題，數值才有篩選意義。

三種測試測量的不是同一段鏈路

傳統 Ping 通常指 ICMP Echo 請求。系統會向節點伺服器位址傳送一個較小的封包，等待 Echo Reply，再將往返時間記錄為毫秒值。它主要涵蓋本機到伺服器 IP 的網路往返路徑，不會主動完成 VMess 或 VLESS 交握，也不會驗證代理出口能否連線至目標網站。

需要注意的是，客戶端介面中帶有「Ping」字樣的功能未必使用 ICMP。部分環境會改用 TCPing，也就是向伺服器的實際連接埠發起 TCP 連線，以避開網路對 ICMP 的限制。TCPing 能確認連接埠是否接受連線，但仍未完整經過代理協定交握、加密傳輸、路由分流與出口存取流程。

• 入口路徑：本機網路經由電信商鏈路抵達節點伺服器。
• 代理路徑：入口連線完成後，繼續執行 VMess、VLESS 等協定所需的交握與傳輸。
• 出口路徑：節點伺服器再連線至測試目標，目標回應沿代理通道返回本機。
• 持續傳輸：下載測速還會受到伺服器限速、並行連線、壅塞控制與測試檔案大小影響。

為什麼 Ping 很低，實際連線延遲卻很高

最常見的原因是節點入口很近，但出口鏈路並不短。例如伺服器入口位於鄰近地區，ICMP 往返只需 32 ms；節點實際連線至測試目標時卻經過壅塞的上游線路，完整請求可能升至 180 ms。此時 Ping 正確反映入口距離，實際連線延遲也正確反映代理請求成本。

協定交握同樣會放大差異。TCP 連線需要建立工作階段，TLS 傳輸還包含憑證與金鑰協商；WebSocket、gRPC 等傳輸方式也有各自的封裝流程。測試工具是否重複使用既有連線、是否執行網域解析，以及是否等待完整回應標頭，都會改變最終毫秒值。因此，兩個不同版本或不同測試位址得出的結果不能直接橫向排名。

以上數字來自同一區域網路、同一節點的連續測試說明性樣本，不是節點品質基準。34 ms 到 126 ms 的差值可能由代理交握、網域解析、出口距離與測試目標回應共同造成；11.8 MB/s 則表示該通道雖然首個封包較慢，但建立連線後仍具備較高的持續吞吐量。

1. 確認三次測試針對同一個節點，不要在節點自動切換後比較舊結果。
2. 關閉正在進行的系統更新、雲端硬碟同步與大型檔案傳輸，減少本地頻寬競爭。
3. 連續測試三次，記錄中位數，不要以單次最低值作為結論。
4. 若實際連線延遲偶爾跳到 1000 ms 以上，請檢查核心記錄是否出現交握逾時、DNS 逾時或連線重設。

實際連線延遲如何接近一次網頁請求

在 v2rayN 中，實際連線延遲不是單純探測伺服器連接埠。客戶端會先讓所選核心載入節點設定，再透過本地代理連接埠向測試位址傳送請求。請求通常會經過本地監聽、路由判斷、協定封裝、遠端節點接收、出口存取與回應返回，因此能揭露「連接埠開放但代理設定無法使用」這類問題。

以 v2rayN 7.12.x 常見介面為例，可先在節點清單中選取一項，再透過右鍵選單執行「測試伺服器實際連線延遲」。批次篩選時可多選節點後執行相同指令。不同小版本的選單排列可能調整，但測試名稱與節點清單中的延遲結果欄通常保持對應。

本地監聽連接埠也會影響排查。v2rayN 常見的本地連接埠為 10808，舊設定也可能將 HTTP 代理安排在 10809。不要只依常見值修改瀏覽器或系統代理，應在「設定」→「參數設定」中核對目前連接埠，並確認沒有其他程式佔用同一連接埠。如果本地代理入口未啟動，所有節點都可能同時顯示失敗。

範例記錄
客戶端版本：v2rayN 7.12.x
本地代理連接埠：10808
節點 A：92 ms / 98 ms / 95 ms
節點 B：61 ms / 420 ms / 73 ms
判斷：A 較穩定；B 的最低值較低，但波動過大

為什麼下載測速不能取代延遲測試

下載測速關注單位時間內收到多少資料。它會建立代理連線並持續傳輸，因此同時受本地接入頻寬、節點伺服器出口、測試來源限速、單一連線效能、協定開銷與壅塞控制影響。一個延遲 180 ms 的節點仍可能達到 20 MB/s，因為連線建立後可以讓大量資料持續在鏈路中傳輸。

反過來，延遲 55 ms 的節點也可能只有 2 MB/s。原因可能是節點限制單一使用者速率、尖峰時段壅塞，或測試目標限制了單一連線。低延遲只表示請求往返快速，並不代表鏈路容量大。網頁與小型介面請求更依賴首個封包時間，大型檔案下載與高位元率影片則更依賴持續吞吐量。

測速時還應區分 MB/s 與 Mbps。1 Byte 等於 8 bit，因此客戶端顯示 12 MB/s，大致相當於 96 Mbps，尚未計入協定與鏈路開銷。如果寬頻上限是 100 Mbps，看到約 10 至 11.5 MB/s 已接近實際可用範圍；不能把 12 MB/s 誤讀成 12 Mbps。

• 先確認本地寬頻未被其他裝置佔滿，再解讀節點速度。
• 同一節點至少測試兩輪，避開測試來源的短暫波動。
• 不要同時對數十個節點執行下載測速，以免結果互相爭搶頻寬。
• 訂閱標示的流量倍率會影響實際扣費，速度高不代表適合長期作為預設使用。

協定、路由分流與 DNS 如何改變結果

VMess 與 VLESS 是代理協定，不是延遲等級。協定類型本身不能直接推斷哪個節點較快，伺服器位置、線路品質、傳輸層設定與負載通常更關鍵。同一台實體伺服器上的兩個設定，即使協定不同，也可能只有些微差距；不同線路上的同一協定節點，延遲與速度則可能相差數倍。

路由分流會決定測試請求最終前往何處。如果測試網域被規則判定為直連，取得的可能是本地網路連線至測試來源的結果，而非所選節點的代理效能。執行測試前，應確認 v2rayN 目前的路由模式與規則集，並在核心記錄中檢查該請求使用代理出站還是直連出站。

• 網域解析位置：本地 DNS 與遠端 DNS 可能回傳不同位址，測試目標的實際距離也會隨之改變。
• 路由規則：網域、IP、連接埠與程序規則可能將測速請求導向不同出站。
• 傳輸設定：TCP、WebSocket、gRPC 等傳輸方式的連線建立成本不同。
• 連線重用狀態：重用既有連線可能降低後續請求時間，但不能代表首次開啟網頁的成本。
• 核心實作：客戶端版本、Xray 核心版本與設定參數的變化可能影響測試表現。

v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心。即使匯入同一份訂閱，Android 端與桌面版 v2rayN 的本地網路、DNS 策略、核心版本與測試實作也可能不同，因此跨裝置數值只能觀察趨勢，不能要求毫秒值完全一致。判斷實際體驗時，應在各自裝置上獨立篩選。

一套可重現的節點篩選流程

可靠篩選的核心不是追求最低數字，而是固定條件、分層測試。先更新訂閱並確認節點設定有效，再關閉佔用頻寬的工作。測試期間維持同一個網路入口，不要在有線、無線與行動熱點之間切換，也不要一邊測速一邊變更路由模式。

1. 更新設定：在訂閱群組中執行更新，確認節點位址、連接埠與協定欄位已載入。
2. 檢查本地入口：進入「設定」→「參數設定」，核對本地監聽連接埠，例如 10808，並確認核心正常啟動。
3. 批次測試實際連線：對節點執行實際連線延遲測試，先剔除逾時、交握失敗與持續高於 1000 ms 的項目。
4. 重複測試候選項目：每個候選節點測試三次，記錄中位數與最大值，不只保留最低結果。
5. 依情境測速：網頁用途優先觀察延遲穩定性；影片與下載用途再執行持續下載測速。
6. 檢查實際路由：開啟核心記錄，確認請求透過預期的代理出站，沒有被分流規則改為直連。
7. 保留備用節點：除了主要節點之外，保留兩個不同入口或不同線路的設定，方便在尖峰時段切換。

一個實用的日常門檻可以是：實際連線延遲低於 200 ms，且三次最大差值不超過 80 ms，作為網頁瀏覽候選；持續下載達到本地寬頻可用上限的 60% 以上，作為大流量候選。門檻應依所在地區與接入網路調整，不能機械套用到所有線路。

最終應將三個指標理解為分工關係：Ping 用於快速觀察入口路徑，實際連線延遲用於驗證代理請求與互動體驗，下載測速用於確認持續傳輸能力。三者不要求數值方向完全一致，也不存在單一指標能概括所有使用情境。固定測試條件、關注多次結果的穩定性，再結合實際用途進行選擇，通常比追逐清單中的最低毫秒值更可靠。