V2Ray 協定與核心比較指南

01 / Configuration layers

節點設定的四個層次

用戶端清單中的一筆節點資料，實際上是由幾組設定組合而成。伺服器位址與連接埠決定連到哪裡；VMess、VLESS、Trojan 或 Shadowsocks 決定如何表示代理請求與驗證身分；TCP、WebSocket 等傳輸方式決定資料如何傳送；TLS 或 REALITY 則負責連線安全保護。把這些內容一概稱為某種協定雖然方便，卻容易選錯：兩筆同樣標示 VLESS 的資料，可能因安全機制和傳輸方式不同，而有截然不同的連線條件。

代理協定不等於傳輸協定

代理協定必須告知遠端目標位址，有時也要提供使用者身分、請求類型和資料編碼方式。傳輸層則負責將這些資料送到遠端。同一種代理協定可以搭配不同的承載方式，但核心與伺服器端不一定支援所有組合。查看節點詳細資料時，應分別記錄協定類型、傳輸類型、安全類型與附加欄位，不要只憑節點名稱中的縮寫判斷。名稱是訂閱維護者填寫的標籤，並非能限定實際連線行為的技術定義。

例如，WebSocket 會透過 HTTP 升級程序建立連線，通常也需要設定路徑和請求主機；直接使用 TCP 承載時，則不會自動具備這些欄位。選用 WebSocket 無法取代代理協定的使用者驗證，也不代表連線一定經過加密。反過來說，啟用 TLS 也不會自動將一般代理請求轉換成另一種代理協定。用戶端介面把這些選項放在相鄰位置只是方便編輯，不代表它們屬於同一技術層次。

分別檢查安全機制與流量入口

本機入口是瀏覽器等應用程式連入用戶端的位置；遠端出口才是本手冊主要比較的對象。常見的本機 SOCKS 或 HTTP 監聽連接埠，並不是節點伺服器的連接埠。系統代理通常會將應用程式導向本機 HTTP 入口；支援 SOCKS 的應用程式也可以個別指定入口。流量進入核心後，路由規則還可能讓部分請求直接連線。因此，看到系統代理已啟用，只能確認入口設定有所變更，不能據此認定所有連線都經過目前選取的節點。

還要分清身分驗證與傳輸保護。使用者識別碼、密碼等欄位用來判斷是否允許使用服務；憑證驗證則用來確認 TLS 對端身分是否可信。這兩類驗證失敗時的記錄與修正方式不同。身分欄位填錯，不應靠關閉憑證檢查處理；憑證名稱不符，也不該反覆更換使用者識別碼。先確認問題發生在哪個層次，才能避免同時變更多個參數，導致無法比對。

建立方便核對的設定清單

比較節點前，可以先在本機記下這四層資訊，並補充使用的核心與用戶端。不必抄錄敏感欄位的實際內容，只要確認欄位是否存在、來源是否一致即可。若訂閱提供完整設定，應優先保留原有組合，不要憑印象改成另一種傳輸方式。伺服器端不會因用戶端的下拉選單變更就自動切換設定；即使位址和身分正確，路徑或安全機制錯誤也足以造成交握失敗。

這種分層方式也適用於查閱術語與記錄。看到交握、驗證、路徑或路由命中等訊息時，先找出對應層次，再檢查該層參數。可在術語表補充入口、出口與分流的定義；接下來的章節則會說明這些設定為何有不同組合，以及實際需要針對哪些差異做選擇。

02 / Proxy protocols

VMess 與 VLESS 的設計取捨

VMess 是 Project V 生態系中較早發展的代理協定，具備完整的使用者身分驗證、請求標頭與資料保護機制。VLESS 的設計方向不同：精簡代理層的額外處理，將更多連線保護交由外部安全機制負責，並保留後續擴充空間。不能只按名稱的新舊排序，更不能以為把節點類型從 VMess 改成 VLESS 就算完成升級。伺服器端必須提供對應入口，用戶端也必須保留相符的身分、傳輸與安全參數。

VMess：留意驗證模式與時間條件

VMess 設定通常包含使用者識別碼和安全相關選項。舊資料常提到額外識別數量等歷史欄位，現代設定則多採用 AEAD 驗證機制。匯入舊節點時，最重要的是確認伺服器端實際使用的驗證方式，以及目前核心是否仍支援，而不是照著舊截圖逐項補齊所有曾出現過的欄位。對於訂閱產生的現代設定，任意加入歷史參數可能造成相容性問題；參數較多不代表設定更完整。

時間也是 VMess 疑難排解時容易忽略的條件。某些驗證流程依賴時間範圍，系統時鐘明顯不準可能導致驗證失敗。應檢查裝置實際日期、時間與自動同步狀態，而不只是介面選取的時區。變更時區但維持相同的正確絕對時間，通常不會造成驗證時間偏差。若所有 VMess 節點同時失敗、其他協定正常，可以將時間同步列入檢查項目，但仍須配合記錄確認，不能只憑協定名稱下結論。

VMess 的資料保護會增加一定的處理負擔，但實際資源占用也受演算法實作、處理器效能、外部 TLS、連線數量與流量模式影響。若節點另外套用 TLS，安全保護便不只來自 VMess 本身。是否保留這種組合，應由伺服器端設計與相容需求決定。一般使用者不應為了少一次加密而自行關閉既有安全機制，因為協定能否連線與部署是否妥當，是需要分別驗證的問題。

VLESS：精簡不代表能獨立完成加密

VLESS 負責表示代理請求與驗證使用者身分，但傳統設定本身不會加密應用程式資料。常見介面中的 encryption 為 none，是這類設定的正常欄位值，不代表外層 TLS 或 REALITY 已關閉。應繼續查看安全類型，而非只截取這一行就判斷連線是否受到保護。透過不可信網路連線時，應依伺服器端要求使用適當的安全機制；不要把缺乏保護的設定當成通用部署建議。

VLESS 常搭配 Xray 的擴充功能，例如 flow 欄位中的 Vision。flow 不是可任意填寫的速度模式，而是具有協定語意與實作要求的設定。若伺服器端未啟用對應流程、傳輸組合不符要求，或使用的核心沒有實作該功能，填入相同值也不會得到相同效果。保留訂閱提供的原始值，並確認用戶端實際選用的核心，比盲目追求某個欄位名稱更重要。

如何在用戶端選擇

如果現有 VMess 設定長期穩定，且服務提供者仍維護該入口，繼續使用通常比手動改造穩妥。若新設定明確提供 VLESS 及相符的 TLS 或 REALITY，則可依完整組合使用。比較時應盡量讓兩個節點位於相同伺服器地區、使用相近網路線路，並在相同時段測試；否則測出的差異很可能來自網路路徑，而非代理協定本身。也應將連線失敗率與重新連線表現納入評估，而不只看下載速度。

在 v2rayN 中，先透過節點編輯視窗核對協定與安全設定，再查看該設定實際呼叫的核心；在 v2rayNG 中，也要確認匯入後是否保留附加欄位。若目標組合超出目前實作支援範圍，應改用能完整解析設定的用戶端或核心，而不是清除不認識的欄位。兩種核心的具體差異，可接著閱讀核心相容性章節。

03 / Alternative designs

Trojan 與 Shadowsocks 的適用範圍

Trojan 與 Shadowsocks 常出現在同一份節點清單中，但兩者處理身分驗證與資料保護的方式不同。Trojan 通常以 TLS 作為連線安全基礎，並在其中承載代理請求與密碼驗證；Shadowsocks 則以輕量代理和預先共用金鑰建立自身的資料保護機制。選擇時應先確認實際協定版本、演算法與傳輸組合，再比較網路表現。只看到 Trojan 或 SS 的簡稱，不足以判斷完整相容性。

Trojan：TLS 參數與密碼同樣重要

Trojan 常見設定需要伺服器位址、連接埠、密碼，以及與 TLS 相關的伺服器名稱。密碼正確無法彌補憑證驗證失敗；能建立 TCP 連線，也不代表 TLS 和後續驗證都已完成。若連線記錄停在憑證階段，應檢查伺服器名稱、憑證鏈與裝置時間。若 TLS 已完成但遠端拒絕請求，再核對密碼和伺服器端入口。依階段檢查，通常比反覆更換連接埠有效。

伺服器位址與伺服器名稱在設定中可能扮演不同角色：前者決定網路連線的目的地，後者則參與 TLS 交握與憑證名稱驗證。位址欄位使用 IP，不代表伺服器名稱也應改成相同的 IP。訂閱提供的名稱應完整保留。驗證憑證失敗時，啟用略過驗證會改變信任界線，不應當成一般修正步驟；應優先排除名稱填寫錯誤、系統時間不準或伺服器端憑證設定有誤等問題。

某些實作會為 Trojan 疊加不同傳輸方式，此時路徑、主機名稱與傳輸參數同樣會影響連線。不能把某種用戶端匯出的擴充組合，直接視為所有支援 Trojan 的實作都能使用。評估相容性時，要確認目標核心是否支援這組特定組合，而不只是類型選單裡有沒有 Trojan。若匯入後傳輸方式自動恢復預設值，應在連線前核對，避免把解析資訊遺失誤判為節點失效。

Shadowsocks：演算法名稱是必要設定

Shadowsocks 的重要欄位通常包括位址、連接埠、加密方式與密碼。傳統 AEAD 方法與後續的 2022 系列方法採用不同規範，金鑰要求與實作支援也不完全相同。名稱相似不代表可以互換；一端選用某種方法，另一端就必須依相同規範運作。尤其不能把任意長度的一般密碼直接套用到對金鑰長度與編碼有特定要求的設定，再將失敗歸咎於網路品質。

舊文件中的傳統串流加密方法不應作為新設定的預設選項。實際使用時，應採用服務提供者明確維護且雙方核心都支援的方法，而不是為了相容舊截圖退回過時設定。部分訂閱也會附帶額外傳輸擴充資訊，這些擴充並非 Shadowsocks 基礎協定的一部分。目標用戶端即使能辨識位址與密碼，也可能無法解析擴充欄位，因此匯入成功後仍須檢查詳細資料。

不要只憑「輕量」推斷使用體驗

Shadowsocks 的基礎處理流程可能較簡潔，但不代表每個實際節點都更快、更省電。加密演算法是否支援硬體加速、網路封包遺失、伺服器負載，以及用戶端維持連線的策略，都可能影響結果。Trojan 依賴 TLS，也不代表每次請求都要重新負擔完整交握成本；連線重用和工作階段恢復都會影響實際開銷。應將設計特點視為分析線索，而不是取代實測的固定排名。

如果服務提供者同時提供這兩類節點，應優先選擇用戶端能完整解析、日常應用也能穩定使用的組合。需要 UDP 的應用，還要另外確認用戶端、核心、伺服器端與目前模式是否支援，不能因為網頁能開啟就推定可用。綜合評估回應時間、地區距離與流量倍率，可參考節點選擇與測試方法，並將協定因素放回完整網路條件中考量。

04 / Security layers

TLS、REALITY 與傳輸方式

REALITY 常與 VMess、VLESS、Trojan 並列出現在行銷標籤或節點名稱中，但從設定層次來看，它並不是能獨立表示代理請求的同類協定。常見組合是 VLESS 搭配 REALITY，由代理層處理目標請求，再由安全機制保護連線並驗證對端。TLS 則是用途更廣的安全協定。比較時應列出完整組合，避免把不同層次混為一談，誤以為「VLESS 和 REALITY 二選一」。

TLS：連線名稱、憑證與應用協商

TLS 可為連線提供加密、完整性保護與對端驗證。用戶端必須依設定的伺服器名稱檢查對端憑證，並確認憑證鏈與有效期限。網路連線位址、TLS 伺服器名稱和 WebSocket 請求中的主機欄位可能相同，也可能分別設定。不能只因為看起來都是網域名稱，就把三處欄位統一替換。伺服器端如何配置憑證、接收傳輸與處理請求，才決定哪些欄位必須一致。

ALPN 用來協商應用層協定，不是選擇地區或加速的參數。若傳輸方式依賴特定應用協定，用戶端與伺服器端的協商結果就必須符合要求。指紋設定可能影響 TLS 交握的呈現方式與實作相容性，也不是越特殊越好。若訂閱已提供這些欄位，應先照原值測試；若未提供，不宜直接套用其他節點的參數。不同伺服器入口的要求可能完全不同，複製部分設定往往會破壞原本可用的組合。

REALITY：依配套參數理解驗證機制

REALITY 由 Xray 生態系實作，採用不同於一般憑證鏈驗證的配套驗證機制。用戶端通常需要伺服器名稱、公鑰相關參數、短識別碼及指紋等資訊，實際介面名稱會隨實作演進而改變。這些參數必須來自同一份有效設定，不能從不同節點拼湊。公鑰用來驗證配對的伺服器端，短識別碼也必須符合伺服器端允許的值；它們不是可以隨意省略的裝飾欄位。

常見的 VLESS、REALITY 與 Vision 組合，也要求核心實作和傳輸條件相符。用戶端支援 VLESS，不代表它也支援 REALITY；支援 REALITY，也不表示任何 flow 都能與任意傳輸方式搭配使用。應將伺服器端明確支援的組合視為整體。連線異常時，先核對核心、伺服器名稱、驗證參數與 flow，再檢查網路是否可連線，不要只更換單一欄位反覆嘗試。

REALITY 不是用來補救錯誤伺服器位址的工具，也不會自動確保遠端服務品質。安全協商成功只代表該階段條件符合，後續代理驗證、目標連線和路由仍可能失敗。使用者應妥善保存服務提供者給的完整參數，使用支援該組合的核心，並在更新後重新核對解析結果。不要將它當成可忽略時間、忽略身分或繞過所有憑證概念的通用開關。

直接承載與 WebSocket 的額外成本

直接透過 TCP 承載時，中間處理層通常較少；WebSocket 則透過 HTTP 升級和訊息封裝，提供另一種連線方式，常用於已有反向代理或應用程式服務架構的環境。額外封裝會增加開銷，但實際體驗也取決於部署路徑是否合理。不能只憑封裝層數預測傳輸量，更不能為了減少層數，就擅自把伺服器端僅提供的 WebSocket 改成 TCP。這等於更換連線入口，不是用戶端內部最佳化。

另一個常見誤區，是把多路複用當成適用於所有傳輸方式的預設強化功能。多路複用試圖讓多條邏輯連線共用底層資源，但遇到封包遺失、長時間占用流量或特定協定流程時，可能彼此影響；某些組合也有明確限制。是否啟用應以目前核心文件和伺服器端組合為準，並透過實際應用驗證。設定介面出現某個開關，只代表用戶端提供編輯功能，不代表它適用於每種節點。

05 / Performance and battery

連線速度、資源占用與行動裝置耗電

比較協定時，最容易被簡化成一張速度排名表，但缺少測試條件的排名無法重現。應用體驗至少包含首次連線時間、請求回應、持續傳輸量、失敗重試與長時間穩定性。代理協定只是其中一項變因；網路往返距離、DNS 解析、壅塞、伺服器負載和目標網站回應，同樣可能占主導地位。合理的比較應先固定這些條件，再觀察協定組合和用戶端設定造成的差異。

分開測量延遲、交握與傳輸量

用戶端的 TCP 連線測試通常只檢查到節點入口，無法證明代理驗證和目標請求成功。實際請求測試較接近應用程式的使用情境，但也會受到測試位址所在地區、快取與服務狀態影響。持續下載主要反映傳輸量，不等於短請求回應速度快。應先了解測試名稱代表的流程，在相同條件下比較同一指標，不要直接相減不同測試的結果。

首次連線通常還要完成 DNS 解析、傳輸連線與安全交握；之後連到相同目的地的請求，可能受惠於連線重用。測試時既要觀察首次開啟，也要觀察連續使用，避免只比較已完成預熱的一組連線。若節點首次開啟較慢、後續正常，應優先分析交握與解析；若一開始正常、持續傳輸後逐漸變差，則應留意壅塞、封包遺失、伺服器限制與裝置溫度。不同現象的最佳化方向並不相同。

資源開銷取決於實作與工作負載

資料加密會占用處理器資源，額外封裝會增加處理與記憶體複製；連線重用和緩衝策略也會影響記憶體用量。支援硬體加速的演算法可能在某類處理器上表現良好，在其他裝置上卻未必有優勢。用戶端介面程序與代理核心也可能分開執行，觀察系統資源時應區分兩者。不能只因介面程序占用較低，就認定整條代理鏈路的資源消耗也很低。

記憶體用量偏高，有時來自活動連線、快取或緩衝區，不一定代表故障。更值得觀察的是，在相近負載下用量是否持續增加、停止流量後是否趨於穩定，以及是否伴隨系統回收資源或程序退出。頻繁中斷並重新連線，可能比維持少量穩定連線產生更多交握工作；過度積極的連線重用，也可能讓多個請求共用同一條受阻通道。設定應依實際負載調整，而不是一味追求某項資源數值最低。

行動裝置還要觀察無線網路與背景行為

在 Android 上，耗電不只來自協定運算，也與無線網路活動、應用程式背景請求和喚醒有關。頻繁保持連線、自動測速過於密集，或失敗後持續重試，都可能讓裝置難以進入低活動狀態。訊號較弱時，行動網路傳輸也可能加劇耗電。比較 v2rayNG 或 v2flyNG 的耗電表現時，應固定網路類型、螢幕狀態和應用程式負載，同時檢查是否有自動更新或測試工作。

系統的背景執行限制會影響長時間連線；放寬限制可能改善常駐情況，卻也會改變耗電條件。因此，不能一組測試允許背景執行，另一組維持嚴格限制，最後就把所有差異歸因於核心。建議分別觀察前景使用、螢幕關閉待機和無線網路切換三種情境，記錄連線是否恢復、是否重複建立，以及應用程式是否真的傳輸資料。只測一次螢幕亮著時的下載，無法反映行動裝置的日常體驗。

需要比較時，每次只變更一個變因，選擇相近時段重複測試，並保留原本可用的設定以便還原。不要只用長時間全速下載作為評估標準；這會同時改變裝置溫度、流量和系統排程。日常瀏覽時，短請求能否穩定完成，通常比峰值傳輸量更具參考價值。結論應說明是在特定裝置、網路與設定組合下的觀察，而不是適用所有使用者的協定排名。

06 / Core compatibility

V2Fly、Xray 與用戶端的關係

V2Ray 最初屬於 Project V 生態系。V2Fly 延續相關專案的社群維護，Xray 則以這項技術基礎分支發展，並沿著 VLESS、XTLS 與 REALITY 等方向建立自己的實作。兩者共享部分概念與歷史設定習慣，但已不是可以任意互換的同一套程式。選擇核心時，首要考量是能否實作目標設定，其次才是在特定裝置上的資源表現與維護便利性。

圖形化用戶端與核心負責不同工作

圖形化用戶端負責訂閱管理、節點編輯、系統代理與啟動控制；核心則負責解析執行設定，以及連線、路由和傳輸。v2rayN 是桌面平台的主要管理入口，可依平台與軟體套件狀況管理對應的核心設定。v2rayNG 以 Android 為主，主要採用 Xray 核心；v2flyNG 則提供 V2Fly 核心的替代選項。用戶端名稱本身不是代理協定；同一筆協定資料能否執行，最後仍取決於產生的設定與實際呼叫的核心。

圖形化介面支援某欄位，不一定代表目前執行的核心也支援該欄位。反過來說，核心已具備某項功能，介面也可能還沒有提供相應的編輯方式。疑難排解時，必須同時檢查匯入結果、執行記錄與目前選用的核心。尤其是遷移舊設定或切換核心後，要確認沒有沿用先前的預設項目。介面顯示「已啟動」只表示啟動程序已完成，不能取代實際目標請求測試。

即使支援相同協定，也有設定上的限制

兩種核心可能都支援 VMess、VLESS、Trojan 或某些 Shadowsocks 方法，但具體傳輸、安全擴充、欄位名稱與預設行為仍可能不同。REALITY 與 XTLS Vision 是 Xray 路線的重要功能，不應假設 V2Fly 能原樣解析。若設定依賴這些功能，應選擇相符的實作；刪除重要欄位讓設定通過解析，會改變連線語意，不等於取得相容設定。

JSON 結構相似也是常見的誤導。兩種核心都可能使用入口、出口、路由等結構，但同名欄位的可用值、擴充欄位和 DNS 處理方式，可能因各自實作而異。遷移時應從功能需求出發，逐項核對對應設定，而不是將完整檔案直接交給另一種核心執行。尤其要重新檢查路由標籤是否存在、出口參照是否正確，以及相依資料資源能否載入。

以下只是用來說明路由語意的局部片段，不是可獨立啟動的完整設定。它表示符合指定網域集合時，選擇名稱為 direct 的出口；執行時還必須存在同名出口，並能載入相關網域資料。這個例子也說明，相容性不只涉及代理協定，還包括配套資源與標籤關係。只複製規則物件卻沒有對應出口，不會得到預期的直接連線行為。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

切換核心時應採取小範圍驗證

切換前先保留原本可用的設定，再選一筆明確受目標核心支援的節點進行測試。接著檢查 DNS 解析、常用網站、需要 UDP 的應用程式，以及系統代理是否能恢復。若只有某一類節點失敗，應優先檢查該類協定的擴充欄位；若所有節點都失敗，再檢查核心啟動錯誤、監聽連接埠與設定產生流程。如此可區分「核心未啟動」與「某種協定不相容」，減少誤判。

核心更新與用戶端更新也可能分開進行。更新後若出現異常，應先查看變更是否涉及協定、設定解析或預設行為，再以原本可用的資料進行比對，不要立刻重建所有訂閱。本網站的安裝套件頁面依平台整理三款用戶端的下載入口；如需深入了解不同核心家族，可參考Xray-core 與 V2Fly-core 比較文章。選擇標準始終是實際設定需求，不應將分支關係當作品質排名。

07 / Subscription formats

訂閱格式、分享連結與遷移檢查

訂閱是發佈設定的方式，不是新的代理協定。訂閱網址通常會傳回一組節點資料，再由用戶端解析成內部記錄；分享連結則常用來表示單一節點。兩者都可能使用編碼包裝，但編碼不等於保密。訂閱網址和節點中的驗證欄位應視為敏感資訊妥善保管，不宜放進公開截圖、論壇貼文或完整記錄。疑難排解時，只需說明欄位是否存在，不必公開實際內容。

成功取得內容不代表完整解析

更新訂閱包含網路請求、內容辨識、欄位解析與記錄寫入等階段。請求有回應，不代表回傳內容就是用戶端能理解的節點清單；有時收到的可能是登入頁面、錯誤訊息或另一種設定格式。更新後沒有節點時，應先分辨是請求失敗還是解析失敗。前者檢查網址是否有效，以及請求使用的網路路徑；後者則確認服務提供者輸出的格式是否相容於目標用戶端，不要只是不斷按下更新。

常見分享格式包括 VMess、VLESS、Trojan 與 Shadowsocks 各自的連結規範，但即使前綴相同，擴充欄位的表示方式也可能不同。傳輸路徑、伺服器名稱、flow、指紋及 REALITY 驗證參數，可能在某個解析器中被完整辨識，在另一個解析器中卻遭忽略。因此，即使匯入數量看起來正確，也應抽查節點詳細資料。最容易被忽略的情況往往不是匯入完全失敗，而是重要欄位遺失後，仍產生看似正常的記錄。

節點清單不可與完整執行設定混用

一組節點清單通常只提供出口連線資訊；完整設定還可能包含入口、DNS、路由與策略。一般的訂閱匯入入口未必接受完整設定；完整設定入口也不一定會套用介面中的所有選項。應先判斷匯入的是哪種資料，再選擇對應功能。如果完整設定已接管路由，使用者仍反覆切換介面預設，可能會看到設定似乎變更、實際行為卻沒有改變；這不是協定本身的故障。

從 v2rayN 遷移到 v2rayNG 或 v2flyNG 時，應優先使用服務提供者明確提供的相容訂閱或分享格式。複製桌面版產生的執行設定，不一定能保留行動版所需的入口與執行環境。行動裝置接收應用程式流量的方式、檔案路徑和背景限制都與桌面不同；即使出口協定相同，也不能假設整份設定都能直接使用。遷移時應保留節點設定的語意，而不是強行保留所有平台相關欄位。

更新策略應考量覆寫行為與網路路徑

訂閱群組通常能協助用戶端辨識哪些節點來自同一來源；更新時，可能會取代、刪除或重建相關記錄。直接修改訂閱節點的設定，下次更新後可能不會保留。若要暫時比較參數，應先使用用戶端提供的複製功能或建立獨立記錄，並確認複製後是否仍與原訂閱連動。保留原始群組，有助於判斷問題是來自服務提供者變更，還是本機修改。

更新請求透過直接連線或代理傳送，會影響連線能力；但「透過代理更新」也可能形成依賴：目前節點失效時，用戶端便無法透過它取得新設定。遇到這種情況，應改用可用的網路路徑或原本獨立可用的節點完成更新，不要無限重試。自動更新間隔也不宜過短；更新頻率應配合服務提供者的變更速度和裝置背景執行條件。頻繁請求不會自動提升節點效能。

完成遷移後，先選一個節點進行驗證，再檢查群組、路由與日常應用，不必一次修改所有設定。若更新時間正常但欄位缺失，可告知服務提供者目標用戶端、協定類型與缺少的欄位名稱，不要傳送完整驗證資料。更新失敗的詳細處理方式可參考訂閱更新疑難排解文章；常見概念問題則可回到使用指南的匯入步驟，並區分取得、解析與執行三個階段。

08 / Selection workflow

依使用情境選擇協定並驗證設定

實際選擇時，不必從所有協定中找出永遠最佳的答案；應先確認裝置、用戶端與伺服器端提供哪些有效組合，再從中挑選穩定符合需求的方案。桌面平台優先使用 v2rayN 管理設定；Android 通常可先使用 v2rayNG，明確需要 V2Fly 行為時再考慮 v2flyNG。用戶端只是設定入口，最後決定連線能力的仍是核心與完整參數。不能只憑相同的節點名稱，就認為兩台裝置的執行條件一致。

日常瀏覽與長時間穩定使用

以網頁瀏覽、文件和即時通訊為主時，應優先觀察短請求成功率、首次回應與背景恢復，而不只看全速下載。若現有協定組合穩定，伺服器端持續維護且用戶端能完整解析，就不必為了更新標籤而頻繁遷移。若需要更換，可先在相同網路條件下測試新組合，確認常用目標、DNS 解析與重新連線正常，再設為日常使用項目，並保留原本可用的設定。

頻繁建立連線的小型請求情境，特別需要留意交握與連線重用，但不要將所有回應緩慢都歸因於交握。目標網站本身回應慢、路由誤選直接連線或 DNS 回傳不適合的位址，也會造成類似現象。先確認請求確實經過預期出口，再比較協定差異。否則測得的可能是兩條不同網路路徑，而不是兩種協定處理相同工作負載的表現。

行動網路、持續傳輸與特殊應用

經常在無線網路與行動網路之間切換時，連線恢復能力比單次測試的最低延遲更重要。應觀察切換網路後舊連線是否釋放、新請求是否自動恢復，以及背景限制是否阻止用戶端繼續執行。若只有切換網路後出現異常，可先重新建立連線，檢查 DNS 解析與目前網路，再決定是否更換協定。反覆調整安全參數通常無法解決舊連線未恢復的問題，反而會增加其他變因。

大型檔案傳輸、長時間播放影片等情境，更重視穩定傳輸量與裝置溫度。選擇時應控制伺服器地區和測試時段，觀察持續傳輸是否頻繁中斷，不宜只依某次峰值判斷。需要 UDP 的應用，應明確確認整條連線路徑是否支援：本機接入方式、核心出口、伺服器端與遠端目標都可能形成限制。網頁請求成功只驗證部分能力，不能取代應用程式本身的測試。

資源有限的裝置可優先選擇實作成熟、額外層次較少且雙方明確支援的組合，但這不代表應刪除必要的安全保護。更有效的做法通常是降低自動測速頻率、保留適量記錄、避免重複背景工作，並檢查異常重新連線。若裝置持續發熱，應先區分實際流量、背景更新與連線失敗重試，再比較協定運算開銷，避免把應用程式負載變化錯誤歸因於核心。

依固定順序找出連線失敗原因

第一步確認應用程式是否連入用戶端：系統代理是否指向正確入口、本機監聽是否啟動，以及應用程式是否遵循代理設定。第二步確認路由是否選取預期出口，不要把直接連線失敗誤認為節點故障。第三步確認遠端位址可連線，再依記錄檢查安全交握、代理驗證與目標連線。這個順序從本機逐層往遠端縮小範圍，通常比先更換整套節點設定更容易得出可靠結論。

若記錄顯示設定無法解析，應先處理核心相容性與欄位問題；若安全交握失敗，核對伺服器名稱、時間與配套驗證參數；若驗證失敗，檢查身分欄位及入口類型；若驗證完成但無法連上目標，再檢查 DNS、路由與伺服器端連線目標的條件。測試時一次只修改一項並記錄結果，恢復原值後再檢查下一個項目。如此即使未能立即修復，也能清楚確認已排除哪些原因，避免陷入多項設定同時變動的循環。

路由規則的匹配順序與網域處理方式，可接著參考自訂路由規則語法；用戶端顯示已連線但網頁無法開啟時，可依照系統代理、路由與 DNS 疑難排解清單逐項檢查。需要重新安裝或更換平台時，前往安裝套件頁面選擇對應入口。協定選擇的成果應是一份說明清楚、能夠驗證並可還原的設定，而不是脫離裝置與網路條件的名稱排名。