面向已經匯入訂閱、但面對一長串節點不知道從哪條開始試的使用者。全文按地區、協議類型、倍率、延遲四個面向給出取捨順序，附 v2rayN 與 v2rayNG 中對應的測試入口、延遲上下波動時的判斷標準，以及一套可以直接照做的日常挑選流程。
先定順序：地區 → 協議類型 → 倍率 → 延遲
節點清單裡的欄位很多，真正影響使用體驗的只有四類：節點所在國家或地區、協議與傳輸組合、流量倍率，以及由前兩者和本地線路共同決定的延遲。把這四項放在同一個層級上反覆比較，只會一直糾結。
更有效的做法是先排除、再排序。地區決定來回時間的物理下限，協議組合決定這條線路在壅塞時是否容易被干擾，倍率決定你為這些流量付出的成本，延遲只是前三項落在你目前網路環境裡的結果。
四個面向可以直接套用的參考數值如下，後文逐項展開。
地區：決定延遲下限，也決定線路品質
物理距離繞不過去。封包從本地出口到對端機房再返回，光在光纖裡的來回時間已經決定了延遲的下限，協議層面的最佳化只能在這個基礎上做加成。
下表是按常見機房位置整理的經驗區間。實際數值會隨本地寬頻出口、電信業者國際線路與晚間尖峰壅塞狀況浮動，同一地區的不同線路之間，差異可能比跨地區差異還大。
| 機房位置 | 來回延遲參考區間 | 適合情境 | 需要注意 |
|---|---|---|---|
| 香港 | 30–60 ms | 網頁瀏覽、影片、日常主力 | 晚間尖峰壅塞明顯，同城市不同機房差異大 |
| 日本 / 韓國 | 60–120 ms | 長連線、穩定性優先 | 直連線路與繞行線路差別明顯 |
| 新加坡 | 80–150 ms | 東南亞服務、備用線路 | 部分電信業者回程繞行 |
| 美國西部 | 150–250 ms | 大頻寬下載、非即時任務 | 互動操作有可感知的卡頓 |
地區的作用是縮小範圍，而不是直接決定最終選擇。先按物理距離把候選分成就近、次近、遠端三組，每組內部再比較具體線路，比較效率會高很多。
結論：先用「地區」把候選壓到 5 條以內
在 v2rayN 裡可以用「訂閱」→「訂閱分組設定」建立地區分組，把不常用的節點移出主清單，每組只留延遲最低的兩三條。候選超過 10 條時，人眼比較的結果基本上等於隨機。
協議類型：先看傳輸層，再看安全層
用戶端清單裡的節點名稱通常包含三段資訊：協議、傳輸方式、安全層，例如 VLESS + TCP + Reality，或者 VMess + WebSocket + TLS。協議決定身分驗證與加密方式，傳輸方式決定封包在網路裡長什麼樣子。
一般使用者不需要理解每種組合的實作細節，只需要判斷三件事：這條線路是否需要自備網域、是否依賴 TLS 憑證，以及在你常用的用戶端裡能不能正常載入。
VLESS + TCP + Reality
推薦不需要自備網域與憑證，握手階段借用真實網站的 TLS 特徵，連接埠通常直接用 443。新部署的節點優先考慮這種組合。
適合：新節點、對握手特徵有要求的線路
VMess + WebSocket + TLS
出現時間早、相容性最廣，可以放在 CDN 後方轉發。欄位較多，任何一個欄位填錯都會出現連線建立成功卻無法上網的情況。
適合：舊訂閱、需要 CDN 中轉的情境
VLESS + TCP + TLS
結構最直接，額外開銷最小，在本地線路本身乾淨的情況下延遲表現最好，但依賴一個可用的網域與有效憑證。
適合：線路品質好、有獨立網域的自建節點
三種組合在正常網路下的速度差距通常小於 10%，真正拉開差距的是線路在晚間尖峰或跨網時的穩定性。協議類型適合用來排除明顯不合適的組合，不適合用來精挑細選。
判斷一條節點屬於哪種組合，看訂閱裡的分享連結參數最快：
security：安全層，取值none/tls/reality，決定握手方式。type：傳輸方式，取值tcp/ws/grpc/http。flow：流控方式，xtls-rprx-vision僅在 VLESS + TCP + Reality 或 VLESS + TCP + TLS 下有效。sni：握手時使用的目標網域，Reality 與 TLS 都依賴它。path與host：WebSocket、HTTP 傳輸專用，缺少時會出現連上卻無法轉送流量的情況。
倍率：把流量成本算清楚再排序
倍率是伺服器端對流量的計費係數。1.0× 表示實際傳輸 1 GB 就在方案裡扣 1 GB，2.0× 表示同樣傳輸 1 GB 要扣掉 2 GB。倍率與速度沒有必然關係，高倍率線路不一定更快。
把倍率乘進日常用量，判斷會直觀很多。假設每月上下行合計 60 GB：
- 1.0× 線路：消耗 60 GB 方案流量。
- 1.5× 線路：消耗 90 GB 方案流量。
- 2.0× 線路：消耗 120 GB 方案流量。
- 3.0× 線路：消耗 180 GB 方案流量。
結論是把倍率 2.0× 以上的節點當作緊急備用，日常主力留在 1.0× 與 1.5× 之間。看影片、下載大檔案這類高流量任務優先選低倍率；網頁瀏覽、即時通訊這類小流量任務，倍率之間的差異幾乎可以忽略。
注意
倍率由伺服器端下發，用戶端只負責顯示。訂閱裡的節點名稱如果沒有標註倍率，以服務商的方案說明為準，不要根據節點名稱裡的數字猜測。
延遲：測什麼、測幾次、波動多少算異常
用戶端裡能測的延遲有兩種。一種是 TCP 握手延遲，只驗證到節點伺服器的連接埠是否可達；另一種是真連線延遲，會在節點上實際發起一次請求並把結果返回。前者數值更小，後者更接近真實體驗，挑選節點時以後者為準。
在 v2rayN 裡，選取節點後按右鍵選擇「測試真連線延遲」，主畫面會按結果重新排列；在 v2rayNG 裡，點右上角 ⋮ 選擇「測試全部配置延遲」，清單右側會逐條回填數值。跨境線路上預設的逾時時間可能偏短，可以在「設定」→「參數設定」→「基礎設定」裡調大後重新測試。
單次結果不要直接採信。同一個節點連續測三次，取中位數，再和相鄰節點比較。判斷標準可以按下面四條執行。
- 三次結果都在 80 ms 以內：可以設為日常主力。
- 三次結果波動超過 30%，或中間出現一次逾時：說明線路抖動，降為備用。
- 真連線延遲明顯高於 TCP 延遲，例如高出一倍以上：節點伺服器負載偏高或回程繞行，換同地區的其他節點。
- 所有節點同時變慢：問題通常不在節點，先關閉代理確認本地網路本身是否正常，再回來重新測試。
還有一種情況值得單獨記錄：某個節點白天穩定、晚間尖峰必然抖動。這屬於線路壅塞而不是節點故障，把它留在備用分組裡，比直接刪除更有價值。
結論：延遲用來排序，不用來淘汰
一條 120 ms 但三次結果都穩定的線路，實際體驗通常好於 60 ms 但每次都不一樣的線路。後者在視訊通話和長時間下載裡會不斷重新連線，反而更浪費時間。
實作：兩端共用一份挑選結果
桌面端與 Android 端使用同一條訂閱連結時，節點清單、分組與排序保持一致，挑選只需要做一次。兩端的差別主要在測試入口和日常使用方式上。
推薦做法：一條訂閱，兩端同一份候選
桌面端（v2rayN）
- 「訂閱」→「訂閱分組設定」按地區拆組
- 按右鍵「測試真連線延遲」，三次取中位數
- 本地監聽連接埠 10808（SOCKS）與 10809（HTTP）
Android 端（v2rayNG）
- ⋮ →「測試全部配置延遲」批次回填數值
- 「設定」→「分應用程式代理」決定哪些應用程式走代理
- 把 v2rayNG 加入系統省電白名單，避免背景被清除
兩端節點清單始終來自同一份訂閱，換裝置不需要重新挑節點，只需要重新測一次延遲。
把這套順序固化成習慣：新訂閱匯入後先按地區拆組，排除倍率 2.0× 以上的節點，剩下的每條測三次真連線延遲，按中位數排序，取前三條作為常用節點。之後每次更新訂閱時重新測試一次即可。
需要說明的是，節點品質會隨時間變化，一次挑選的結果不是長期結論。同一個機房在不同時段的表現可能完全不同，定期重新測試比一次性精挑更有意義。