VMess、VLESS、Trojan、SS 與 REALITY 選型指南

一、協定選型框架：先拆解設定層次

協定名稱不是完整的連線方案

客戶端清單中的 VMess、VLESS、Trojan 或 Shadowsocks，首先描述的是應用層代理協定。一次實際連線還會同時包含位址與連接埠、使用者憑證、傳輸方式、安全層、網域名稱以及可選的路徑等資訊。只比較協定名稱，無法判斷兩個設定是否能互換，也無法直接推斷連線速度。以 VLESS 為例，它可以執行在一般 TCP 之上，也可以與 TLS、WebSocket、gRPC 或 REALITY 組合；這些組合的握手流程、憑證要求、資料封裝與客戶端支援範圍並不相同。

選型時應把一組設定拆成四層。第一層是協定與驗證，例如 VLESS 的 UUID、Trojan 的密碼、Shadowsocks 的加密方法與密碼。第二層是承載資料的傳輸方式，例如 TCP、WebSocket、gRPC。第三層是安全與身分確認，例如標準 TLS 或 REALITY。第四層是客戶端與核心，即由 v2rayN、v2rayNG 或 v2flyNG 將介面欄位轉換為 Xray、V2Fly 可讀取的設定。任一層不相符，都可能表現為連線立即關閉、握手逾時或匯入後欄位遺失。

從既有設定開始，而不是從偏好開始

客戶端使用者通常收到的是參數已確定的分享連結或訂閱。此時正確做法不是先挑一個看似較新的協定，再嘗試改寫原設定，而是先確認伺服器提供的協定與傳輸組合，再選擇能完整識別它的客戶端與核心。伺服器使用 VMess 時，客戶端應按 VMess 匯入；伺服器使用 VLESS 與 REALITY 時，客戶端不僅要支援 VLESS，還要能保存公鑰、短識別碼、指紋與伺服器名稱等 REALITY 欄位。單獨修改客戶端下拉選單不會改變伺服器能力。

如果能同時選擇伺服器與客戶端，則依相容範圍、設定複雜度、裝置效能與維護成本排序。需要跨多種客戶端共用時，優先考慮各端都能穩定解析的組合；希望使用 Xray 專屬能力時，確認所有裝置都執行相容的 Xray 核心；低效能裝置則減少不必要的多層封裝。這裡的「更簡單」是指欄位更少、鏈路層次更少、排錯邊界更清楚，不代表某種協定在所有網路條件下必然更快。

二、VMess、VLESS、Trojan 與 Shadowsocks 的設計取捨

VMess：完整驗證結構與時間一致性要求

VMess 源自 Project V 早期的協定體系，目標是在同一套協定中完成使用者身分識別、請求資訊承載與資料保護。其設定通常使用 UUID 作為使用者識別碼，並包含額外的協定握手結構。VMess 在 V2Fly 與 Xray 家族中都有廣泛的歷史相容基礎，因此大量舊訂閱與既有部署仍在使用。對於需要延續舊設定、伺服器暫時不調整，或多部裝置都已驗證可用的環境，繼續使用 VMess 通常比單純為了追求新名稱而遷移更穩妥。

VMess 驗證流程要求客戶端與伺服器時間的偏差維持在合理範圍內。裝置時間、時區或自動校時異常時，可能出現位址與連接埠都正確但驗證失敗的情況。排查時應先恢復系統自動校時，再核對 UUID、alterId 相容欄位與傳輸參數。現代設定通常不需要依賴舊式 alterId 設計，但匯入歷史訂閱時仍可能看到該欄位。客戶端能顯示欄位，不代表伺服器仍按照相同的舊行為運作；遷移時應以伺服器目前的設定為準。

VLESS：精簡協定職責，將能力交給組合層

VLESS 是 Xray 生態系的重要協定之一，設計重點是減少協定本身承擔的資料加密職責，將傳輸安全交給 TLS、REALITY 或其他明確的安全層。VLESS 使用 UUID 等資訊識別使用者，但不應將其理解為能獨立完成所有安全防護的封閉方案。實際部署必須連同傳輸方式與安全層一併描述，例如 VLESS over TCP with TLS，或 VLESS over TCP with REALITY。

這種職責分離讓 VLESS 更容易組合 Xray 的 flow 等能力，也減少某些重複處理。代價是選項之間存在明確限制：伺服器未設定 flow 時，客戶端不能自行加入；使用 REALITY 時，需要同時提供公鑰、短識別碼與伺服器名稱；使用標準 TLS 時，則要依憑證身分核對網域。VLESS 的優勢主要體現在 Xray 功能組合與清晰的協定分層，而不是只做出「選擇 VLESS」這個動作就能自動改善所有鏈路。

Trojan：以密碼驗證搭配標準 TLS

Trojan 通常以密碼作為使用者憑證，並依賴 TLS 建立安全連線。其概念模型相對直接：客戶端連線至 TLS 服務，接著在協定層提交驗證與目標資訊。設定時最重要的不是密碼欄位本身，而是網域、伺服器名稱、憑證驗證與連接埠必須彼此一致。直接將位址替換成另一部主機、保留原伺服器名稱，或關閉必要的安全選項，都可能破壞原有的身分驗證邏輯。

Trojan 在多個核心生態中都有支援基礎，適合已有標準 TLS 設定且希望維持清晰參數結構的情境。它不等於任意 TLS 服務，也不能把一般 HTTPS 位址直接當作 Trojan 節點。客戶端匯入後應確認安全項仍為 TLS、SNI 沒有遺失、密碼未被截斷。若訂閱轉換工具只保留「位址、連接埠、密碼」而遺漏傳輸層欄位，產生的項目即使出現在清單中，也不能代表原始設定。

Shadowsocks：輕量結構與加密方法一致性

Shadowsocks 常簡稱為 SS，其核心欄位是伺服器、連接埠、加密方法與密碼。相較於組合層次較多的 VLESS 或 VMess 設定，基礎 Shadowsocks 項目欄位較少，通常較容易理解。效能表現取決於所選加密方法、具體實作、處理器指令集能力與鏈路品質。較新的 AEAD 加密方法能提供明確的資料機密性與完整性語義，但客戶端與伺服器必須使用完全相同的方法名稱與密碼。

Shadowsocks 生態存在不同的擴充功能與外掛組合。基礎 SS 支援不代表核心支援某個特定擴充功能；訂閱匯入成功也不代表擴充欄位已被保留。使用 v2rayN 或 Android 客戶端時，應在編輯項目中檢查加密方法、外掛參數與傳輸附加項。若目標是在三款客戶端之間轉移設定，基礎欄位通常較容易保持一致；帶有特定外掛的項目則應逐端驗證。選擇時應將「協定相容」與「擴充相容」分開記錄。

三、傳輸方式、TLS 與 REALITY：組合關係與欄位界線

TCP、WebSocket 與 gRPC 如何承載資料

傳輸方式決定協定資料如何放入底層連線。TCP 通常附加封裝較少，參數也相對集中；WebSocket 在 HTTP 升級流程之上承載雙向資料，設定中常見路徑與 Host；gRPC 以 HTTP/2 語義為基礎，常見欄位是服務名稱與多路複用相關設定。三者不是只靠客戶端偏好就能切換的「速度檔位」，伺服器必須監聽相同傳輸並使用一致參數。將 WebSocket 項目改成 TCP，通常不會得到等價設定。

傳輸層對效能的影響來自握手次數、封裝開銷、連線複用方式與中間網路設備行為。對短連線密集的情境而言，建立連線的成本更明顯；對持續大量傳輸而言，鏈路品質、壅塞控制與伺服器負載往往更重要。WebSocket 路徑必須逐字元對應，gRPC 服務名稱也不能省略。客戶端中的 Host、SNI 與位址看起來可能相似，但職責不同：位址用於找到伺服器，Host 屬於應用層請求資訊，SNI 用於 TLS 握手中的伺服器名稱。

標準 TLS：憑證身分與伺服器名稱

TLS 為上層協定提供加密通道與伺服器身分驗證。設定中的伺服器名稱通常需要與憑證可驗證的名稱一致，而連線位址可以是網域，或在特定設定下使用其他位址。客戶端預設進行憑證驗證時，會檢查憑證有效期、信任鏈與名稱是否相符。遇到憑證錯誤時，應優先核對系統時間、SNI、網域拼寫與伺服器憑證設定，不應把關閉驗證當作一般修復方式，因為這會改變原設定的身分確認條件。

ALPN 用於 TLS 握手時協商上層協定，例如 HTTP/2 或 HTTP/1.1。是否需要手動填寫此欄位，取決於傳輸組合與伺服器設定。訂閱提供 ALPN 時應保留原值；沒有明確要求時，不宜為了「參數越多越好」而隨意新增。客戶端允許多選不代表伺服器接受所有組合。同樣地，指紋選項描述 TLS 客戶端握手特徵，屬於連線實作細節，必須與所用核心及伺服器方案相容。

REALITY：Xray 安全層及其必要參數

REALITY 是 Xray 體系中的安全層能力，通常與 VLESS 等設定組合。它不是獨立的代理協定，因此在客戶端建立項目時，協定類型仍可能顯示為 VLESS，安全項則選擇 REALITY。常見參數包括伺服器名稱、公鑰、短識別碼與客戶端指紋；某些組合還會使用 flow。公鑰用於客戶端驗證 REALITY 伺服器身分，短識別碼用於匹配伺服器設定，伺服器名稱參與握手語義。任何欄位在訂閱轉換過程中遺失，都可能導致握手無法完成。

公鑰與 UUID 負責不同職責。UUID 屬於 VLESS 使用者驗證，REALITY 公鑰屬於安全層身分確認，兩者不能互換。短識別碼通常是規定格式的十六進位字串，其長度與可選值由伺服器決定；客戶端應原樣保存，不要自行補零或改變大小寫結構。伺服器名稱也不是備註名稱，必須符合伺服器設定。使用 v2rayN 編輯 REALITY 項目時，應依序檢查協定、位址、連接埠、使用者 ID、security、SNI、publicKey、shortId、fingerprint 與 flow。

{
  "protocol": "vless",
  "address": "server.example.com",
  "port": 443,
  "id": "00000000-0000-4000-8000-000000000001",
  "network": "tcp",
  "security": "reality",
  "serverName": "www.example.com",
  "publicKey": "請替換為伺服器提供的公鑰",
  "shortId": "1a2b3c4d",
  "fingerprint": "chrome",
  "flow": "xtls-rprx-vision"
}

上面的片段用於展示欄位之間的層次，不是可以直接連線的節點。實際值必須來自對應的伺服器設定。客戶端介面可能使用中文欄位名稱，也可能將這些內容分布在「傳輸設定」、「TLS 設定」或「REALITY 設定」面板中，但欄位語義不變。分享連結中的參數名稱還可能使用縮寫，例如 pbk 對應公鑰、sid 對應短識別碼、fp 對應指紋。手動比對時應先建立欄位對應，再判斷是否遺漏。

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

協定開銷只是總耗時的一部分

使用者感受到的連線速度由網域解析、網路往返時間、握手流程、伺服器負載、線路壅塞、傳輸封裝與本機處理共同決定。協定只影響其中一部分。兩組設定採用不同協定，伺服器位置、出口負載與鏈路品質也不同時，測速結果不能單獨用來證明協定優劣。可靠的比較需要盡量保持伺服器、連接埠鏈路、測試時間、目標資源與客戶端版本一致，並重複觀察連線建立時間、持續傳輸與失敗重試情況。

基礎 TCP 傳輸通常具有較少的應用層封裝，但不保證在所有環境中都能獲得最低延遲。WebSocket 與 gRPC 增加相應的協定層處理，同時也改變連線複用與中間鏈路行為。TLS 與 REALITY 都涉及握手與密碼學計算，現代桌上型處理器通常能快速完成；在低功耗行動裝置上，頻繁斷線重連比維持穩定連線更容易放大耗電。因此，減少無效重試、保持系統時間正確與避免錯誤的網域解析，往往比爭論單次加密操作更有實際價值。

CPU、記憶體與連線數量

資源占用不能只依協定名稱排序。核心需要維護連線狀態、路由規則、DNS 快取、日誌與可選的 TUN 網路堆疊；客戶端介面還會執行訂閱更新、清單繪製與統計顯示。大量並行連線、複雜正規表示式規則、過於詳細的日誌等級與頻繁健康檢查，都會提高 CPU 喚醒次數與記憶體使用量。基礎 Shadowsocks 設定通常欄位較少，處理路徑容易理解；VLESS 搭配簡潔傳輸也能維持較低額外開銷；多層傳輸與複雜路由則需要更多狀態管理。

觀察桌面端資源占用時，應區分 v2rayN 圖形程序與 Core 程序。介面記憶體增加不一定表示協定核心有問題，反之亦然。先停止自動更新與額外檢查，再使用同一組設定重新測試，可以判斷背景工作是否造成影響。日常使用時建議保留必要的日誌資訊，排錯時暫時提高詳細程度，完成後再恢復。持續記錄完整存取日誌會增加磁碟寫入與處理負擔，也會讓真正的錯誤行更難定位。

Android 裝置的電量判斷

在 Android 上，v2rayNG 或 v2flyNG 通常需要透過系統 VPN 介面接管流量。耗電不僅來自加密，也來自網路維持、應用程式流量總量、無線網路狀態切換、DNS 請求與背景喚醒。螢幕關閉後若連線頻繁重建，應先檢查系統對客戶端背景執行的限制、網路切換與訂閱自動更新頻率。單純替換協定但保留不穩定鏈路，通常無法解決重連造成的耗電。

TUN 或 VPN 的接管範圍也會影響處理量。裝置上所有應用程式流量都進入客戶端時，核心需要處理更多連線；依系統能力與實際需求減少不必要的背景應用程式流量，可以降低總工作量。路由規則過於龐大或包含大量需要網域解析的規則，也會增加判斷成本，但在一般規模下通常不是首要瓶頸。更有效的排查順序是：確認連線是否持續穩定，觀察是否存在循環重試，再檢查日誌等級、自動更新、DNS 與路由，最後才比較協定組合。

協定選擇最終應以穩定性、相容性與維護成本為優先，效能資料作為相同條件下的補充證據。若一組現有 VMess 設定長期穩定，遷移至 VLESS 並非緊急操作；若需要 REALITY 或特定 Xray flow，則應將核心升級與全端相容性檢查納入遷移計畫。遇到異常資源占用時，可結合幫助中心的故障分類進行排查，不要同時修改協定、DNS、路由與系統代理，以免失去可比較的基準。

五、V2Fly 與 Xray 核心家族的關係

共同來源與獨立演進

V2Fly 與 Xray 都繼承了 Project V 生態中的設定理念與多協定代理能力，因此在 VMess、部分 VLESS、Shadowsocks、路由規則與出站結構上能看到相近概念。兩者後來形成獨立的維護方向，功能增加、欄位含義與實作細節不會始終同步。共同來源可以解釋為何許多基礎設定結構相似，但不能推導出兩套核心對所有擴充功能都能完全互換。

Xray 更集中發展 REALITY、XTLS Vision 等能力，並在 Xray 客戶端生態中形成相應欄位。V2Fly 則維持自己的發布、協定實作與功能路線。對一般使用者而言，最重要的結論是：基礎 VMess、Shadowsocks 或標準傳輸設定可能具有良好的跨核心遷移性；帶有 Xray 專屬安全層、flow 或特定擴充欄位的設定，應明確選擇 Xray Core。設定檔能被解析，只代表語法層面可能成立，不保證執行語義一致。

三款客戶端與核心定位

v2rayN 是本站桌面端首選客戶端，支援 Windows、macOS 與 Linux，提供伺服器清單、訂閱分組、路由設定、系統代理與 Core 類型管理等圖形化入口。面對含 REALITY 的 VLESS 設定，應在 v2rayN 中選擇支援該能力的 Xray Core，並確認匯入後的安全欄位完整。桌面端需要同時管理多組訂閱、細分路由與系統代理時，v2rayN 的集中式設定結構更適合作為主要管理端。

v2rayNG 是 Android 上採用 Xray 能力路線的客戶端，適合與桌面 v2rayN 共用 VLESS、REALITY 等 Xray 設定。v2flyNG 則以 V2Fly 核心家族為主要定位，適合使用相應核心支援的 VMess、Shadowsocks 與其他相容設定。兩者名稱相近，但不能只憑介面欄位相似就判斷功能一致。伺服器項目依賴 Xray 專屬欄位時，優先使用 v2rayNG；明確需要 V2Fly 行為或已有 V2Fly 設定基準時，再選擇 v2flyNG。

設定相容性的三個層次

判斷相容性應分為語法、功能與行為三個層次。語法相容表示 JSON 欄位或分享連結能被識別；功能相容表示核心真正實作對應的協定、傳輸與安全層；行為相容表示相同設定在 DNS、路由、連線複用與錯誤處理上達到預期結果。許多遷移問題都發生在把第一層誤認為第三層，例如匯入工具成功產生項目，卻忽略不受支援的欄位，直到連線時才暴露問題。

遷移設定檔還要注意出站標籤、路由引用與 DNS 結構。協定節點本身可用，不代表原有路由規則能直接複製。規則中的 outboundTag 必須指向實際存在的出站標籤；DNS 查詢策略與網域解析模式也可能影響分流判斷。使用圖形化客戶端時，優先透過客戶端介面建立或匯入設定，讓客戶端產生與目前 Core 相符的結構。只有需要定位具體欄位時，再匯出設定並進行唯讀比對。

xray run -test -config ./config.json

上面的測試指令用於讓已安裝的 Xray Core 檢查設定語法，不會取代實際連線測試。指令成功表示設定能通過基礎解析，不表示位址可達、憑證正確或安全層握手必然成功。v2rayN 使用者通常可直接查看日誌中的 Core 啟動結果；手動指令更適合定位未知欄位、JSON 結構或標籤引用錯誤。測試時應使用客戶端實際產生的暫存設定副本，避免修改正在執行的設定檔。

六、訂閱格式、分享連結與欄位相容性

訂閱是設定容器，不是協定

訂閱位址用於返回一組節點或客戶端設定，訂閱本身並不是 VMess、VLESS 等代理協定。一個訂閱可以同時包含多種協定項目，也可以採用特定客戶端能識別的結構。使用者看到「訂閱更新成功」，只表示客戶端完成請求與基礎解析；還需要檢查項目數量、協定類型、備註、傳輸方式與安全欄位是否完整。若清單為空，應區分位址存取失敗、返回內容為空、格式不受支援與分組篩選錯誤。

常見分享連結以協定方案開頭，例如 vmess://、vless://、trojan:// 或 ss://。不同方案的參數組織方式不同。VLESS 與 Trojan 連結通常可在查詢參數中攜帶傳輸、安全層、SNI、指紋等資訊；VMess 歷史格式常將一組 JSON 欄位編碼後放入連結；Shadowsocks 連結則重點保存加密方法、密碼、位址與連接埠，並可能附加外掛參數。複製時任何截斷、跳脫變化或 QR Code 識別遺漏，都可能造成欄位遺失。

通用訂閱與客戶端專用格式

所謂通用訂閱通常是多行分享連結或經編碼的連結集合，優勢是結構直觀，容易在多款客戶端之間傳遞；限制是難以完整表達複雜路由、DNS 與客戶端專屬策略。客戶端專用設定可以包含分組、規則與介面選項，但遷移到另一個客戶端時，往往只能保留節點主體。選擇訂閱格式時，應先確定共用目標：只同步伺服器項目，還是連同路由與 DNS 策略一起遷移。

對於 v2rayN、v2rayNG 與 v2flyNG，最穩妥的跨端方式是讓訂閱提供每個平台都支援的節點欄位，並在各客戶端分別維護本地路由。桌面端的系統代理模式、Android 的系統 VPN 接管方式與應用程式分流能力並不相同，強行把整套客戶端設定包裝成同一份訂閱，容易產生語義偏差。節點訂閱負責位址、協定與傳輸；裝置本地負責代理接管、DNS 與路由，這種職責劃分更容易排錯。

訂閱轉換的收益與資訊損失

訂閱轉換可以將一種容器格式整理為另一種格式，也可以執行重新命名、篩選或分組。但轉換過程只有在目標格式能表達來源欄位時才是無損的。VLESS REALITY 項目需要保留 security、SNI、publicKey、shortId、fingerprint 與 flow；WebSocket 需要保留 path 與 Host；gRPC 需要保留 serviceName。若轉換後的目標範本沒有對應欄位，工具可能會忽略它們，而不是主動回報錯誤。

驗證轉換結果時，不要只比較節點備註。應隨機選擇每種協定至少一個項目，開啟編輯面板逐項核對協定、位址、連接埠、驗證欄位、傳輸、安全層與擴充參數，再進行連線測試。原訂閱與轉換後的訂閱應放入不同分組，避免同名節點互相覆蓋。確認所有協定類型都能正常運作後，再切換日常使用分組。遇到轉換後 VLESS 可以匯入但 REALITY 失敗的情況，應優先檢查安全層附加參數，而不是反覆更新訂閱。

更新、覆蓋與本地修改

訂閱節點通常由遠端內容管理。使用者直接在客戶端內修改訂閱項目後，下次更新可能會恢復為訂閱原值。需要長期保留的自訂設定，應放在獨立的本地項目或客戶端支援的覆寫規則中。修改前複製項目並更改備註，可以保留比較基準。若只是調整系統代理、路由模式或活動分組，通常屬於客戶端本地狀態，不必修改節點協定欄位。

訂閱更新失敗時，先檢查位址是否完整以及對應分組是否啟用，再查看客戶端日誌中的 HTTP 狀態、解析錯誤或憑證錯誤。不要把訂閱位址貼到「手動新增伺服器」的位址欄位，也不要把單一分享連結誤認為一定能定時更新的訂閱。完整操作流程可參考使用指南中的訂閱匯入步驟；關於清單為空與分組選擇的問題，可繼續查閱幫助中心。

七、在 v2rayN、v2rayNG 與 v2flyNG 中落實協定選擇

v2rayN：先檢查 Core，再檢查節點編輯頁

v2rayN 是桌面端的主要選擇。匯入節點後，先在設定中確認 Core 類型，再開啟伺服器編輯頁核對欄位。VMess 重點檢查使用者 ID、傳輸方式與安全項；VLESS 需要繼續檢查 encryption、flow 與 REALITY 或 TLS 面板；Trojan 檢查密碼、TLS 與伺服器名稱；Shadowsocks 檢查加密方法與密碼。客戶端清單中的備註只用於識別，不參與協定驗證，因此備註顯示正常不能說明設定完整。

啟用連線前，應將節點設定與系統代理設定分開。選擇活動伺服器只決定 Core 使用哪個出站設定；系統代理決定支援系統代理的應用程式是否將請求交給客戶端；路由規則決定連線走代理出站、直連出站或其他已設定的出口。三者是連續但不同的環節。節點測試失敗時先看協定日誌；節點已連線但應用程式未接管時再看系統代理；只有部分網域路徑不符合預期時，才檢查路由。

v2rayNG：核對分享連結中的完整參數

v2rayNG 匯入 VLESS REALITY 連結時，應進入設定詳情確認安全類型、SNI、公鑰、短識別碼、指紋與 flow 都存在。QR Code 識別或從剪貼簿匯入後，如果某個欄位為空，應回到原始分享內容核對，不要隨意從另一個節點複製。不同節點的公鑰與短識別碼分別與各自伺服器綁定，即使外觀相似也不能混用。VMess 項目則需額外注意裝置時間與傳輸參數，Shadowsocks 項目重點核對加密方法。

Android 的連線按鈕會啟動系統 VPN 接管，但不會改變節點協定。連線後若所有應用程式都無法上網，應先觀察日誌中的 Core 是否啟動、設定是否通過解析，以及握手是否完成；若只有特定應用程式表現不同，再檢查系統層級限制與應用程式分流。頻繁切換多個協定項目會讓日誌交錯，排錯時應固定一個已核對的節點，清空或記錄目前日誌時間，再執行一次明確的連線操作。

v2flyNG：依 V2Fly 功能範圍選擇項目

v2flyNG 適合作為 Android 上的 V2Fly 核心客戶端。匯入前應先判斷設定是否依賴 Xray 專屬功能。基礎 VMess、受支援的 Shadowsocks 以及 V2Fly 已實作的協定傳輸，可依實際設定逐項核對；帶有 REALITY 或特定 Xray flow 的 VLESS 項目，不應只因協定名稱可見就認定相容。若同一份訂閱混合多類項目，可以建立獨立分組，只把經過驗證的相容節點用於 v2flyNG。

在兩個 Android 客戶端之間比較時，應使用同一組基礎相容設定，並讓 DNS、路由與網路條件盡量接近。若其中一端匯入後欄位遺失，結論應記錄為格式或功能不相容，而不是簡單歸因於網路。客戶端選擇的目標是匹配核心能力，不是讓每部裝置強制使用同一個應用程式。Xray 設定優先使用 v2rayNG，V2Fly 設定優先使用 v2flyNG；這種明確分工比反覆轉換更容易維護。

從日誌定位設定層級

日誌中的錯誤通常可以按階段分類。設定解析階段會出現未知欄位、格式錯誤、出站標籤不存在等資訊；DNS 與連線階段會出現名稱解析失敗、連線遭拒或逾時；TLS 與 REALITY 階段會出現憑證名稱、金鑰或握手問題；協定驗證階段則與 UUID、密碼或伺服器使用者設定有關。先確定失敗階段，再回到對應欄位，效率高於逐項隨機切換。

排錯過程中每次只改變一個變數。例如先維持協定與傳輸不變，只修正 SNI；再次測試後再檢查公鑰。不要同時更換 Core、節點、DNS 與路由模式，因為成功後無法確認真正原因，失敗後也會擴大範圍。若需要向他人描述問題，應記錄客戶端名稱、Core 家族、協定、傳輸、安全層、錯誤階段與日誌中的主要錯誤類別，憑證部分則應隱藏。

尚未安裝對應客戶端時，可在客戶端頁依 Windows、macOS、Android 或 Linux 選擇軟體包。桌面環境優先使用 v2rayN；Android 再依 Xray 與 V2Fly 核心需求選擇 v2rayNG 或 v2flyNG。安裝完成後的訂閱匯入、系統代理與連線驗證屬於使用指南範圍，本章只負責將協定選型結果對應至客戶端設定。

八、依使用情境選型、遷移與故障回退

既有設定穩定：維持協定，優先減少變更

已經穩定使用的 VMess、Trojan 或 Shadowsocks 設定，沒有必要只因協定名稱變化就立即遷移。先記錄目前的客戶端、Core、傳輸、安全層、DNS 與路由基準，之後再評估遷移能解決什麼具體問題。若目標只是更換裝置，可以在新裝置匯入同一設定並核對欄位；若目標是使用 REALITY 或 Vision，則屬於伺服器與客戶端共同變更，應安排獨立測試項目，而不是覆蓋原節點。

穩定設定的價值在於提供可比較的基準。新項目測試失敗時，可以切回舊項目確認本地網路、系統代理與客戶端整體仍可運作。若舊項目也同時失敗，問題可能不在新協定本身。遷移期間保留原訂閱分組、原 Core 設定紀錄與關鍵欄位清單，可以快速判斷變化發生在哪一層。待新設定在所有目標裝置完成驗證後，再逐步停止使用舊項目。

桌面多平台：以 v2rayN 與共同能力為中心

Windows、macOS 與 Linux 桌面需要統一操作習慣時，可優先使用 v2rayN 管理訂閱與路由。協定選擇應先確保三套桌面環境都能穩定執行相容的 Core 與傳輸組合，再考慮平台差異。基礎 VLESS 搭配標準安全層、既有 VMess、Trojan 或基礎 Shadowsocks，都應依伺服器參數逐項驗證；使用 REALITY 時，確保每個平台的 v2rayN 都呼叫相容的 Xray Core，並能保存完整欄位。

跨平台同步不等於複製整個客戶端目錄。系統代理實作、憑證儲存、網路介面與開機啟動方式存在平台差異，更適合分別設定。訂閱負責同步節點，路由規則可依業務需求建立易讀的規則集，系統層級設定則留在本機。Linux 桌面部署與自動啟動可參考技術筆記v2rayN Linux 桌面安裝，協定欄位仍依本頁的分層方法核對。

Android 與桌面共用：先確定核心交集

桌面 v2rayN 與 Android v2rayNG 共用設定時，Xray 能力交集通常最清楚，適合需要 VLESS REALITY 的情境。若 Android 端使用 v2flyNG，則應選擇 V2Fly 明確支援的協定與傳輸，不要將 Xray 專屬參數帶入共用設定。一份訂閱可以包含多類節點，但建議用備註或分組標示核心需求，例如「Xray 設定」與「V2Fly 相容設定」，避免只憑協定名稱誤選。

行動端更應關注穩定連線與背景行為。若設定在桌面正常、Android 失敗，先比較匯入後的欄位，再檢查系統 VPN 啟動與裝置網路，不要立即判定伺服器異常。若 Android 能建立連線但耗電明顯，依前文順序檢查重連、網路切換、自動更新與日誌，而不是先替換加密協定。跨裝置選型的目標是參數一致、核心匹配與故障邊界明確。

複雜訂閱：依協定抽樣驗證

訂閱同時包含 VMess、VLESS、Trojan 與 Shadowsocks 時，不應只測試清單第一項。先按協定分類，每類選擇一個欄位完整的項目；再按傳輸分類，至少涵蓋 TCP、WebSocket 或訂閱實際提供的其他方式；最後單獨檢查 TLS 與 REALITY。這樣可以判斷故障是某個節點、某類協定、某種傳輸，還是整個訂閱格式造成。測試結果應記錄在分組或備註中，而不是依賴短期記憶。

若同一協定中只有 REALITY 項目失敗，應檢查 Xray Core 與 REALITY 參數；若所有 WebSocket 項目失敗而 TCP 正常，應比較路徑、Host 與 TLS；若各協定都無法解析，則回到訂閱回應與格式層。依層級分類能減少無關修改。更多協定與客戶端的橫向差異，可閱讀v2rayN、v2rayNG、v2flyNG 怎麼選。

遷移執行清單與回退條件

正式遷移可分為準備、並行驗證、切換與觀察四個階段。準備階段記錄舊設定，不刪除可用分組；並行階段新增項目，在相同網路條件下測試解析、握手、持續連線與常用應用程式；切換階段只變更活動節點，維持 DNS 與路由不動；觀察階段再逐步套用新的路由或系統設定。每個階段都有明確回退點，出現異常即可恢復舊的活動節點，不必重新建立全部設定。

回退條件包括：目標客戶端無法保存必要欄位、Core 未實作所需能力、訂閱更新持續覆蓋本地修正、行動端頻繁重連，或多平台中任一關鍵裝置無法穩定運作。回退不是判斷協定優劣，而是目前組合尚未符合相容要求。保留舊方案後，可以單獨修正伺服器、訂閱格式或客戶端設定，再開始下一輪驗證。

完成協定決策後，可前往使用指南執行訂閱匯入、節點選擇、系統代理與連線驗證。遇到連線失敗、清單為空或路由未生效，可在幫助中心依錯誤階段尋找處理方式。需要進一步設計中國大陸與台灣本地的分流規則時，參考v2rayN 中國大陸與台灣本地分流實戰，將節點協定與路由策略分開維護。