v2rayN 測速原理:Tcping、真實連線延遲與下載速度差異

為什麼同一節點的測速結果差這麼多?本文說明連線握手、透過代理發送實際請求與下載速度測試的差異,並教你判讀結果。

本文重點

Tcping 用來初步檢查伺服器連接埠,真實連線延遲用來檢查代理連線,下載速度測試則觀察持續傳輸能力。本文適合依延遲排序,卻發現網頁使用體驗與排名不一致的使用者。讀完後,你可以建立固定的測試順序,分辨是節點、測試目標還是本地網路出了問題,而不是只挑延遲最低的節點。

三種測速方式:測量範圍各不同

先說結論:三種結果不能互相取代。Tcping 延遲低,不代表代理驗證成功;真實連線延遲低,不代表大型檔案下載很快;下載速度快,也不保證每次開啟網頁都很迅速。三者分別測量連線建立、完整請求與持續傳輸,測量單位與範圍都不一樣。

v2rayN 是圖形化用戶端,由用戶端協調測速工作,部分測試需要呼叫選用的核心。Xray 與 V2Fly 支援的協定及設定欄位不盡相同。測速前應確認目前的核心能正確載入節點;連接埠可連線,不代表協定相容。

Tcping:初步檢查連接埠

嘗試連線至節點設定中的伺服器位址與 TCP 連接埠,可快速篩掉明顯無法建立 TCP 連線的項目,但通常不會驗證代理憑證或出口連線能力。

適合:訂閱節點很多,先快速初步排查

真實連線延遲:日常可用性檢查

推薦

透過節點代理連線向測試位址發送請求。這項結果較能反映日常瀏覽體驗,但仍會受到測試目標、請求方式及用戶端版本影響。

適合:從可連線的節點中挑選日常瀏覽候選

下載速度測試:檢查持續傳輸能力

透過代理讀取測試資源,並統計一段時間內的傳輸量。這較接近持續下載的使用情境,但測試會消耗流量,也可能受到伺服器限速影響。

適合:複核少數候選節點的傳輸速度

Tcping:建立連線,不驗證完整代理連線

Tcping 不是一般的 ICMP Ping。它通常以建立 TCP 連線所需的時間作為結果,測試目標是節點的伺服器位址與連接埠。例如,節點設定使用 443 連接埠,測試的就是這個連接埠,而非任意選取的網頁連接埠。若節點使用網域名稱,還需要先解析位址;解析時間是否計入顯示數值,則視實際實作而定。

即使 TCP 連線成功,代理服務仍可能因 UUID、密碼、TLS 服務名稱或其他參數錯誤而拒絕連線。若節點經過反向代理或內容傳遞網路,Tcping 可能只能證明前端入口可連線,無法確認後端代理服務是否正常。入口距離本地很近,也不代表出口距離目標網站很近。

真實連線延遲:測試目標也會影響結果

真實連線延遲較接近「透過這個節點完成一次指定請求需要多久」。整段路徑通常包括本地連上代理入口、代理協定交涉、節點出口連線至測試目標,再將回應傳回本地。依設定與實作而定,過程中也可能涉及網域名稱解析、TLS 交握、連線重複使用與重新導向。這並非單純測量本地與節點伺服器之間的距離。

「真實連線」也不代表完整模擬網頁載入。網頁可能包含數十個網域、指令碼與圖片;延遲測試通常只會發送一個小型請求。不同版本判斷請求完成的方式可能不同,例如以收到回應標頭、特定狀態碼或請求完成為準。因此比較結果時,應使用相同的測試位址與用戶端版本。

環節可能影響排查方式
代理入口與驗證連接埠可連線,但參數錯誤導致請求失敗檢查節點參數與核心記錄檔,不要先修改 DNS
測試網域解析解析失敗、位址家族不同,或解析路徑變慢記錄 DNS 設定,確認實際使用的解析方式與流量出口路徑
出口至測試目標目標網站限流、拒絕存取,或網路路徑繞遠改用另一個小型測試目標複核,不要同時更換節點與位址
TLS 與連線狀態新建連線與重複使用連線所需時間不同使用相同流程重新測試,記錄首次與後續結果

若測試位址回傳 204,通常表示回應沒有本文,適合用來檢查小型請求;但不能因此假設所有 v2rayN 版本都只接受這個狀態碼。請使用用戶端支援的位址與成功判定方式。開啟系統代理也不代表內建測速必然成功:內建測試可能使用專用的測試設定,不一定完全沿用日常路由。

下載速度測試:分開觀察傳輸速度與延遲

下載速度測試關注一段時間內讀取了多少資料,而不是收到第一個回應需要多久。結果會同時受到本地網路頻寬、無線網路、代理出口容量、伺服器限速、壅塞控制、測試時間與並行方式影響。如果下載測試目標與真實連線測試目標不同,排名不一致是正常的。

先看單位。MB/s 是每秒百萬位元組,Mbps 是每秒百萬位元。以十進位單位換算,8 MB/s × 8 = 64 Mbps;實際使用時還會有協定額外負擔。以下數字僅供說明,並非本站實測,也不代表任何節點服務的效能。

42 ms
範例節點 A:Tcping
310 ms
範例節點 A:真實連線延遲
8 MB/s
範例節點 A:平均下載速度

這組結果並不矛盾:連上入口的速度較快,但完成完整請求還得經過更多環節;連線建立後,仍可能有不錯的持續傳輸速度。若範例節點 B 的真實連線延遲為 180 ms、下載速度只有 2 MB/s,B 可能較適合小型請求,A 則可能較適合持續傳輸。最後仍應在實際使用的應用程式中複核。

判斷方式:依使用情境篩選,不要只看單一排名

瀏覽網頁時,先比較真實連線延遲的穩定度;下載時再比較平均傳輸速度。只對最後留下的兩三個候選節點進行下載測速,避免反覆測試整份訂閱而消耗流量。

固定測試流程:先初步篩選,再複核

在 v2rayN 節點清單中選取節點,開啟右鍵選單並執行所需的測試項目。常見項目包括 Tcping 延遲、真實連線延遲與伺服器速度;不同桌面版的實際名稱可能略有差異。可前往「設定」→「參數設定」尋找測試參數,實際分類請以目前介面為準。先記下原有設定,不必為了測速複製不熟悉的設定。

  1. 排除干擾:暫停背景下載,固定使用同一個本地網路,並記錄用戶端與核心版本、測試位址及時段。不要拿無線網路和有線網路的結果直接比較。
  2. 初步檢查入口:執行 Tcping,保留可連線的項目。若傳輸方式不適合用 TCP 初步檢查,請直接進行相應的代理請求測試。
  3. 複核可用性:對候選節點進行三輪真實連線測試,每輪間隔約 10 秒。記錄失敗次數,並取成功結果的中位數,不要只保留最好的一次。
  4. 限制下載測試範圍:只測試兩三個候選節點,並逐一測試。若介面可設定測試時間,請統一設為 15 秒;若無此選項,則使用預設值並記錄實際時間。
  5. 檢查實際使用情況:選好候選節點後,開啟常用網站確認實際流量出口是否符合預期。若測試成功但應用程式無法使用,請優先檢查路由、系統代理或 TUN 接管狀態。

例如三次真實連線測試結果為 180、195、420 ms,中位數是 195 ms;若另一個節點的結果為 160 ms、逾時、逾時,不能只根據成功的那一次就認定它比較好。逾時也是可用性資訊,應另外記錄,不要直接忽略或任意換算成零。

測試方式:分辨日常回應與持續傳輸

網頁與小型請求
  • 使用固定的小型測試目標。
  • 比較三輪測試的中位數與失敗次數。
  • 在常用網站確認首次開啟的體驗。
大型檔案與持續讀取
  • 使用相同的下載目標。
  • 固定測試時間與並行方式。
  • 觀察平均速度,並區分瞬間峰值。

兩種測試方式都應逐一測試節點;同時測速會搶占本地頻寬,讓結果難以比較。

結果異常:先找出問題發生的環節

延遲欄顯示負值、空白或逾時,通常代表測試失敗,而不是「負延遲」。實際意義取決於用戶端版本,請搭配記錄檔確認。排查時每次只變更一個條件,否則無法判斷是更換節點、測試位址還是修改 DNS 造成影響。

Tcping 有數值,真實連線卻一直逾時?

先確認目前的核心能否啟動並載入該節點,再檢查驗證參數、TLS 服務名稱與用戶端記錄檔。若記錄檔顯示無法連上目標,請保持節點不變,改用另一個用戶端支援的小型測試位址複核。連接埠可連線,不代表節點設定一定正確。

真實連線測試成功,瀏覽器還是無法開啟網頁?

確認瀏覽器流量是否經過 v2rayN。檢查系統代理或 TUN 模式,並查看記錄檔中的實際目標與流量出口。內建測試可能採用專用代理路徑,瀏覽器卻可能因路由規則而直接連線,兩者不能直接畫上等號。

延遲很低,為什麼下載速度只有幾百 KB/s?

暫停其他下載,逐一測試候選節點,並使用第二個下載目標交叉驗證。若只有一個目標速度慢,優先考慮目標服務或出口至該目標的路徑;若所有節點都慢,再檢查本地網路與測試設定。

晚上測速變慢,需要重新安裝用戶端嗎?

先使用相同節點、位址與測試時間,在不同時段各測三輪。若多個候選節點都只有晚上傳輸速度下降,較可能是共享頻寬或網路壅塞所致。先保留測試記錄,再判斷是否需要更換節點或調整網路。

桌面版的測試結果可以直接套用到 Android 嗎?

可以先用來整理候選清單,但仍須在目標裝置上重新測試。v2rayNG 使用 Xray 核心,v2flyNG 使用 V2Fly 核心;裝置效能、無線網路與測試實作都可能不同。請先確認節點協定相容,再於相同網路條件下比較使用體驗。

保存測試記錄:讓下次比較有所依據

節點名稱相同,不代表入口、出口或後端線路一直不變。更新訂閱後,應重新簡單測試常用候選節點。日常記錄不必保存訂閱位址或驗證憑證,只需保留測試條件與結果。

若要進一步檢查流量路徑,請參閱DNS 設定說明與TUN 模式說明。如果問題出在訂閱更新而非測速,請參閱訂閱更新疑難排解。先釐清故障發生的環節,再決定要修改哪項設定。

下載v2rayN查看平台與安裝套件