V2Ray 協定手冊與用戶端選擇

建立判斷架構

先釐清代理協定、傳輸方式與安全層

用戶端中的一個節點，其實是多層組合

在 v2rayN、v2rayNG 或 v2flyNG 中看到一個節點時，介面通常會把協定、位址、連接埠、傳輸方式與安全設定放在同一份編輯表單中。它們共同決定一條連線，但負責的工作並不相同。VMess、VLESS、Trojan 與 Shadowsocks 主要描述用戶端如何驗證、如何封裝應用程式流量，以及伺服器如何識別連線；TCP、WebSocket、gRPC 等傳輸項目決定這些資料以何種承載形式送出；TLS 與 REALITY 則位於安全與握手相關層次。若把這些名稱都視為彼此可替換的「協定型號」，很容易得出錯誤比較。例如，VLESS 可以搭配 TCP、gRPC 等傳輸，也可以配合不同安全設定；REALITY 通常不是只填入位址就能運作的獨立代理協定，而是與 VLESS 等入站、出站結構共同使用的安全層方案。

判斷設定時可以由外向內閱讀。先看伺服器位址與連接埠，它們回答「連線要前往哪裡」；再看傳輸方式，它回答「資料如何抵達」；接著看安全層與握手參數，它們回答「連線如何建立受保護的工作階段」；最後看使用者識別碼、密碼或加密方法，它們回答「伺服器如何識別並處理這名使用者的資料」。用戶端匯入訂閱後通常會代為填妥這些欄位，因此日常使用不必逐項修改；但理解各層次，有助於找出匯入不完整、協定類型選錯或參數彼此不相容等問題。

名稱相同，不代表組合完全相同

兩個都標示為 VLESS 的節點，實際表現可能有明顯差異。一個可能使用一般 TCP 與 TLS，另一個可能使用 gRPC 與 REALITY；它們的握手次數、連線複用方式、憑證要求與可用核心都不一樣。反過來，VMess 與 VLESS 雖然驗證結構不同，卻可能使用相同的底層 TCP 或 WebSocket 傳輸，因此網路路徑上的部分行為會相當接近。比較速度時只看協定名稱，往往會把線路品質、伺服器負載、傳輸封裝與安全層差異錯算成協定本身的差異。

選擇協定也不是把所有開關都打開。每增加一層封裝，通常都會帶來額外標頭、緩衝區與狀態管理；每減少一層，又可能失去目前部署所需的握手能力或相容性。正確做法是先由伺服器設定決定可用組合，再從中選擇用戶端核心能完整解析、且裝置負擔合適的一項。用戶端中的協定欄位必須與伺服器一致，不能把 VMess 節點直接改名為 VLESS，也不能只開啟 REALITY 選項卻保留原有 TLS 參數。

延遲、頻寬與穩定性是三個不同指標

用戶端中的延遲測試通常只反映建立某類探測連線所需的時間，不等於持續下載速度。頻寬取決於伺服器出口、網路路徑、壅塞控制與終端效能；穩定性則要觀察一段時間內是否發生封包遺失、重新連線或速度大幅波動。某種協定在一次延遲測試中少了幾毫秒，不能直接證明它更適合長連線、影片傳輸或大量並行請求。選擇時應先確保設定正確，再於相同裝置、相同網路時段與相同路徑下比較，避免把環境變化當成協定差異。

本手冊後續分別使用「代理協定」「傳輸方式」「安全層」「核心」四個詞描述不同職責。只要維持這套分層，用戶端中看似密集的選項就會變成一條可追蹤的連線鏈。遇到新名稱時，也可以先問它位於哪一層、取代了什麼、依賴什麼，而不是先問它是否比另一個名稱更快。

協定背景與界線

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

VMess：完整驗證結構與成熟相容範圍

VMess 是 Project V 生態中較早形成完整用戶端與伺服器協作方式的協定。它會以使用者識別碼與時間相關資訊參與驗證，並在協定層封裝資料。其優點是歷史設定資料豐富，V2Fly 與 Xray 家族都廣泛支援，許多舊版訂閱與既有部署仍以 VMess 為主。對需要維持既有伺服器、讓多個舊版用戶端同時接入的環境而言，VMess 的相容價值通常高於追求最少封裝。

這套完整結構也代表用戶端需要處理更多協定邏輯。系統時間偏差過大時，驗證可能失敗；使用 WebSocket 等傳輸時，還要同時確保路徑、Host 與安全層參數一致。VMess 並不是「開啟後即可自動適配」的通用格式，訂閱缺少傳輸欄位時仍然會連線失敗。新建部署若沒有舊版用戶端相容需求，通常也會評估結構更精簡的 VLESS，但這不表示現有 VMess 節點必須遷移。是否需要調整穩定運作中的設定，應由實際負載、維護成本與用戶端涵蓋範圍決定。

VLESS：分離驗證與加密職責

VLESS 將使用者驗證與傳輸安全職責分開處理，協定本身不再重複承擔一套內容加密邏輯，而是把安全能力交給 TLS、REALITY 等外層。這種設計讓轉送鏈更清晰，也方便 Xray 生態組合不同流控與安全方案。VLESS 常使用 UUID 類型的識別碼辨識使用者，但只有識別碼並不足以構成完整節點；傳輸、安全層、伺服器名稱以及可選流控都必須與伺服器逐項對應。

職責分離的好處是減少不必要的重複處理，並讓不同層可以獨立演進。代價則是設定組合更依賴準確性。用戶端介面可能允許選擇 VLESS，卻不代表目前核心支援訂閱所帶的所有擴充欄位。尤其當節點包含 REALITY、公鑰、短識別碼或特定流控時，應優先使用能完整辨識這些欄位的 Xray 系核心。手動刪除看不懂的參數，通常不會得到「相容模式」，反而會破壞握手。

Trojan：以密碼驗證為核心的簡潔結構

Trojan 使用密碼進行使用者驗證，通常也會搭配 TLS。其參數模型相對直觀：伺服器、連接埠、密碼、伺服器名稱與憑證相關設定構成主要部分。對需要清晰 TLS 部署、希望在多個支援 Trojan 的用戶端之間遷移的人而言，這種結構容易理解。它仍然依賴伺服器憑證、網域與時間環境正常；憑證名稱不符、SNI 填寫錯誤或系統時間異常，都可能在代理驗證前就讓 TLS 握手中止。

Trojan 與 VLESS 並不是簡單的快慢關係。兩者可以經過相近的網路路徑，也可能都使用 TLS。真正的差異更多來自驗證結構、可組合的擴充功能、伺服器實作與用戶端核心。若訂閱提供者已提供穩定的 Trojan 節點，且用戶端能完整匯入，通常沒有必要只因名稱不同就轉換協定。協定不能由用戶端單方面轉換，所謂「改成另一種類型」必須有相應的伺服器設定。

Shadowsocks：輕量資料加密代理

Shadowsocks 常縮寫為 SS，主要參數包括伺服器位址、連接埠、密碼與加密方法。它的結構較輕，用戶端與伺服器實作廣泛，適合設定鏈較短、裝置資源有限或需要傳統相容性的情境。關鍵不只是記住「輕量」，而是確認雙方支援完全相同的加密方法。舊式方法與現代 AEAD 方法在相容性與實作要求上不同，用戶端下拉清單中有某個項目，也不代表伺服器使用同一項。

Shadowsocks 的分享連結通常能容納核心參數，但外掛程式或額外傳輸資訊可能採用不同的擴充寫法。訂閱轉換過程若只保留位址、連接埠與密碼，附加參數就可能遺失。因此匯入後應核對加密方法與外掛程式欄位，而不是看到節點名稱出現就認為設定完整。它與 VMess、VLESS 一樣，效能仍受網路路徑與伺服器實作支配；協定結構較輕，不代表在任何環境都能獲得更高吞吐量。

REALITY：安全握手方案，不是獨立節點類型

REALITY 主要由 Xray 生態使用，處理的是安全握手與身分驗證相關問題。實際設定常見 VLESS 與 REALITY 的組合，因此用戶端清單可能會突出顯示 REALITY，但底層代理協定仍需另外確認。典型參數包括伺服器名稱、公鑰、短識別碼與可選指紋等，這些都是伺服器產生並下發的配套資訊。公鑰或短識別碼少一個字元、伺服器名稱選擇不一致，都可能導致握手直接失敗。

REALITY 的價值在於特定握手與部署模型，而不是取代所有 TLS 使用方式。它需要相容的 Xray 核心與完整準確的訂閱欄位；V2Fly 系核心不會因節點名稱中出現 REALITY 就自動取得相同能力。選用前先確認用戶端實際使用的核心，再確認訂閱是否完整提供參數。若想進一步了解握手負擔與 XTLS Vision 的轉送路徑，可閱讀REALITY 與 XTLS Vision 技術說明。

效能判斷

如何比較連線速度、吞吐量與轉送路徑

握手負擔會影響首次連線，但不完全決定持續速度

開啟新網頁時，終端可能先完成網域解析、與伺服器建立 TCP 或其他傳輸連線、進行安全握手及代理驗證，之後才開始傳送目標請求。協定與安全層主要影響這條鏈中的部分步驟。VMess 需要處理自身驗證與封裝；VLESS 的協定結構較精簡，但若外層使用 TLS 或 REALITY，仍需完成相應握手；Trojan 通常依賴 TLS；Shadowsocks 則依所選加密方法建立資料處理狀態。首次連線的差異通常以毫秒計算，網路往返距離較大時，路徑延遲往往比本地協定處理更顯著。

持續傳輸階段更應關注每個資料區塊經過多少次複製、加密、封裝與緩衝。核心實作、作業系統網路堆疊與傳輸組合都會參與其中。某些流控方案嘗試在特定條件下減少重複加密或資料複製，但只有用戶端、伺服器與外層條件全部吻合時才會生效。只在用戶端勾選某個流控名稱，而伺服器未設定相同能力，結果通常是連線失敗，不會自動退回一般連線。

傳輸方式往往比代理協定名稱更能改變實際表現

一般 TCP 的封裝鏈較短，適合追求直接轉送的設定。WebSocket 增加框架與路徑等欄位，優勢在於能配合相應的 Web 服務部署結構，但額外封裝與中間層會影響吞吐量與延遲。gRPC 建立在 HTTP/2 之上，具備串流與連線管理能力，在合適的伺服器部署中方便組織長連線，但也需要正確的服務名稱與 HTTP/2 支援。比較節點時，如果一個使用 TCP、另一個使用 WebSocket，即使兩者都標示 VLESS，測試結果也不能歸因於 VLESS 本身。

連線複用也需要謹慎理解。複用能讓多個邏輯請求共用較少的底層連線，減少頻繁握手；但底層連線發生壅塞或封包遺失時，多個請求也可能同時受到影響。瀏覽器與現代應用程式本身已使用連線池或 HTTP/2，再疊加代理層複用不一定能持續受益。建議先從預設設定開始，確實存在大量短連線且握手成本明顯時再測試複用，並分別觀察網頁首次開啟、持續下載與多工作業並行，而不是只看一次延遲數字。

建立可重複的比較方法

有效測試需要控制變因。先在相同裝置、相同網路與相近時間測試多個節點；若要比較協定，應盡量選擇相同伺服器位置、相近負載與相同傳輸方式。每個項目至少觀察首次開啟、持續傳輸與網路切換後的復原情況。延遲測試可以篩掉完全無法連線或往返時間過高的節點，但最終仍應以實際應用為準。若結果波動很大，先重複測試並檢查線路時段，不要立即同時修改 Mux、路由、DNS 與協定等多個選項，否則無法判斷是哪項變更造成影響。

v2rayN 的桌面環境通常擁有較充足的處理器與記憶體，可以承受較複雜的規則與並行工作；Android 上的 v2rayNG、v2flyNG 則同時受到電池策略、背景限制與網路切換影響。桌面測試結論不能直接套用到行動裝置。若發現整體速度下降，可依節點、線路、本地設定三個層次檢查，相關步驟請見V2Ray 速度慢的分層排查。先確認問題屬於連線建立、持續吞吐量還是路由選擇，再決定是否更換協定組合。

終端負擔

資源占用、行動裝置電量與背景連線

處理器負擔來自整條資料鏈

協定本身只占資源消耗的一部分。加密演算法、安全握手、傳輸封裝、DNS 查詢、路由規則比對、連線記錄與圖形介面都會使用處理器與記憶體。Shadowsocks 常因結構簡潔而被視為輕量，但實際負擔仍取決於加密方法，以及實作是否利用裝置硬體能力。VLESS 減少協定層的重複處理後，外層 TLS、REALITY 或傳輸仍需進行計算。VMess 多一層協定邏輯，卻不代表在現代桌面裝置上一定會形成可感知的瓶頸。只有在高吞吐量、低功耗裝置或大量並行連線中，差異才較容易顯現。

記憶體占用則與連線數量、緩衝區、路由規則規模及記錄層級密切相關。包含大量網域規則與多組出站的設定，通常比單節點直連設定需要更多記憶體。開啟詳細記錄會記下更多連線事件，也可能增加寫入活動。排錯結束後應將記錄恢復至日常所需的層級，避免長期保留過於密集的記錄。用戶端視窗占用與核心程序占用要分開看；v2rayN 的圖形介面與實際代理核心負責不同工作，介面關閉至系統匣後，核心仍可能繼續處理系統代理流量。

行動裝置電量主要受喚醒頻率與網路狀態影響

Android 裝置的耗電不只取決於「是否加密」。維持長時間連線會讓網路模組週期性活動，頻繁短連線會增加握手與喚醒次數；網路訊號較弱時，無線模組還會提高傳送功率。應用程式在 Wi-Fi 與行動網路之間切換後，舊連線失效並重新建立，也會產生額外消耗。若系統限制 v2rayNG 或 v2flyNG 在背景執行，連線可能被暫停；使用者重新開啟應用程式時集中重連，體感上既不穩定，也可能出現短時間資源高峰。

協定選擇對電量的影響需要在相同流量下觀察。輕量封裝可以減少部分計算，但若節點不穩定而持續重新連線，節省的計算很快會被網路喚醒抵消。長期維持穩定連線的方案，往往比理論上處理步驟較少、實際卻頻繁中斷的方案更省電。連線複用有時能減少底層連線數量，但若共用連線在行動網路切換後復原不佳，也可能造成多項請求一起重試。因此行動裝置建議維持適中的規則集，使用伺服器明確支援的預設傳輸，先穩定運作，再逐項調整。

v2rayNG 與 v2flyNG 的資源差異應連同核心能力一起判斷

v2rayNG 使用 Xray 核心，適合訂閱包含 VLESS、REALITY 或 Xray 擴充能力的情況；v2flyNG 使用 v2fly 核心，更適合以 VMess、Shadowsocks 等 V2Fly 相容設定為主的環境。兩者不能只依安裝套件大小或某次背景占用判斷優劣。若 v2flyNG 無法解析節點所需的 REALITY 欄位，即使閒置占用較低，也無法完成目標連線；反過來，訂閱只有基礎 VMess 時，複雜擴充能力也不會自動改善速度。

觀察行動裝置資源時，至少要涵蓋螢幕亮起、螢幕關閉、網路切換與持續傳輸四種狀態。系統電量統計適合查看一段時間的整體趨勢，不適合用幾分鐘的樣本下結論。還要區分代理產生的流量與特定應用程式本身產生的流量：影片播放、雲端同步與大型檔案更新原本就會大量使用網路，用戶端只是轉送這些資料。若待機耗電異常，先檢查是否有應用程式持續發出請求、節點是否反覆重連、訂閱是否設定過於頻繁的更新，再檢查協定與核心。

降低資源占用的調整順序

先關閉不需要的詳細記錄與重複測速，再減少失效節點、過於頻繁的訂閱更新與過大的路由規則；接著觀察是否存在頻繁重連；最後才比較傳輸與協定組合。每次只調整一項，並維持足夠長的觀察週期。如果裝置只是在閒置時記憶體較高，但系統沒有回收壓力、連線也穩定，不必為了數字好看而頻繁重新啟動核心。現代系統會將可用記憶體用於快取，真正需要關注的是持續增長、卡頓、異常發熱與連線循環。

核心家族

V2Fly 與 Xray 的關係、能力界線與設定相容性

共同來源不代表功能同步

V2Fly 與 Xray 都延續 Project V 生態中的設定模型與多協定轉送思路，因此許多基礎概念相同：入站負責接收本地或外部連線，出站負責把流量送往目標，路由則依網域、位址、連接埠等條件選擇出站。VMess、Shadowsocks、SOCKS、HTTP 等常見結構在兩者之間有高度共通的理解方式。使用者從一個核心轉換到另一個核心時，通常不需要重新學習「入站—路由—出站」這套架構。

不過，兩者已是獨立演進的核心家族。新功能加入時間、欄位名稱、預設值與擴充協定並不保證一致。Xray 方面常見 VLESS、REALITY、XTLS Vision 等組合；V2Fly 方面則依自身路線維護協定、傳輸與設定能力。看到 JSON 外觀相似，不能直接推斷每個欄位都能互換。用戶端能顯示節點，也不代表目前選用的核心能啟動該節點；有些用戶端會先儲存未知欄位，直到真正啟動核心時才回報不支援或解析失敗。

三款用戶端與核心的對應關係

v2rayN 是 Windows、macOS 與 Linux 的桌面用戶端，負責訂閱管理、系統代理、路由編輯與核心呼叫等工作，桌面情境可優先從它開始。它可以依不同核心能力組織設定，但具體節點是否可用仍取決於目前打包與選用的核心。v2rayNG 是 Android 上主要以 Xray 核心為基礎的用戶端，適合使用 VLESS、REALITY 及相關 Xray 設定。v2flyNG 則面向 v2fly 核心，是 Android 上需要 V2Fly 對應能力時的替代選擇。

圖形化用戶端不是協定本身。用戶端負責將訂閱或表單轉換為核心設定、啟動程序並調整系統網路入口；真正解析協定與轉送資料的是核心。遇到「同一節點在一個用戶端可用、另一個不可用」時，應先比較兩邊使用的核心家族與設定欄位，而不是只比較介面名稱。若兩個用戶端使用相同家族但結果不同，再檢查匯入流程、版本支援的欄位與系統網路權限。

設定相容性可分為語法、欄位與行為三個層次

第一層是語法相容性，也就是 JSON 是否能被解析。檔案語法正確，只能表示括號、引號與資料型別基本合法。第二層是欄位相容性，也就是核心是否認得協定名稱與具體鍵值。第三層是行為相容性，也就是同名欄位在兩個實作中的預設值、邊界條件與組合限制是否一致。遷移時只通過第一層檢查遠遠不夠。最穩妥的方法是讓目標用戶端依訂閱重新產生設定，而不是直接複製舊核心的完整執行設定。

以下片段展示 VLESS 出站的基本分層方式，僅用於理解欄位位置。範例位址與使用者識別碼僅供文件展示，不能直接連線。真實節點還需依伺服器要求補齊傳輸與安全設定。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-1111-1111-111111111111",
                "encryption": "none"
              }
            ]
          }
        ]
      }
    }
  ]
}

這裡的 protocol 只決定出站協定，不能取代傳輸與安全層。匯入 REALITY 節點時，還會出現伺服器名稱、公鑰、短識別碼、指紋與流控等資訊。若目標核心不支援這些欄位，不應刪除欄位強行啟動。正確做法是改用支援該組合的 Xray 核心用戶端，或使用伺服器另外提供的相容節點。若需要比較桌面用戶端形態，可繼續閱讀v2rayN 桌面版與 WPF 版差異。

資料交換

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

訂閱是節點清單，不是統一的協定標準

用戶端訂閱通常會從一個位址取得節點清單，內容可能是編碼後的多行分享連結，也可能是某種結構化設定。訂閱解決的是大量分發與更新問題，無法消除不同核心之間的功能差異。同一個訂閱位址可以同時包含 VMess、VLESS、Trojan 與 Shadowsocks 節點；用戶端會逐項辨識，再轉換成自己的資料模型。無法辨識的協定可能被略過，部分辨識的節點則可能保留名稱卻遺失擴充欄位。

因此，「訂閱更新成功」只表示用戶端取得並處理了回應，不代表清單中的每個節點都適用於目前的核心。更新後應確認節點數量是否合理、協定類型是否顯示，以及關鍵參數是否存在。若訂閱原本包含 REALITY 節點，而 v2flyNG 沒有相應能力，這是核心界線，並非反覆更新就能解決。相同訂閱匯入 v2rayNG 後能夠辨識，也進一步說明差異位於核心能力或轉換層。

分享連結能攜帶哪些內容，取決於協定與擴充約定

常見連結會以協定名稱開頭，例如 vmess://、vless://、trojan:// 或 ss://。連結正文會攜帶伺服器、連接埠、身分憑證與部分傳輸參數。VLESS 與 Trojan 常將額外參數放在查詢字串中，節點備註則放在末尾；VMess 的傳統分享形式常將一組結構化欄位編碼後放入連結；Shadowsocks 連結則圍繞加密方法、密碼、位址與連接埠組成。不同用戶端對擴充參數的命名與解碼容錯可能不同。

手動複製連結時，應從協定開頭完整複製到末尾，不能只保留位址與使用者識別碼。連結中的問號、井號、斜線與百分比符號都有結構意義，經聊天工具或文字編輯器處理後可能被截斷或替換。QR Code 也只是連結的圖形表示，掃描成功不代表內容完整。匯入後應開啟節點詳細資料，對照伺服器提供的資訊檢查傳輸、安全層、SNI、路徑、服務名稱、公鑰、短識別碼與流控。

常見欄位如何對應到連線層次

訂閱更新與本地修改的關係

許多用戶端更新訂閱時，會以遠端內容覆蓋同一訂閱群組中的節點。使用者若直接修改訂閱節點，下次更新後變更可能消失。若要長期保留本地調整，應先確認用戶端是否支援複製為本地節點、為訂閱設定獨立規則，或請伺服器端修正來源資料。不要把關鍵修正只留在訂閱節點的暫時編輯中。路由規則、系統代理設定與用戶端偏好通常屬於本地設定，不一定會隨節點更新被覆蓋，但仍應依用戶端介面的實際說明判斷。

訂閱無法更新時，先確認系統時間、網路與訂閱位址是否正常，再檢查用戶端記錄中的 HTTP 狀態與解析提示。節點更新後突然全部失效，應比較更新前後的協定、位址、連接埠與安全欄位，而不是立即重新安裝用戶端。若只有少數節點失效，問題更可能集中在這些節點的參數或伺服器狀態。具體排查順序可參考節點逾時與無法連線的逐項檢查。

跨用戶端遷移應優先使用原始訂閱

從 v2rayN 遷移到 v2rayNG，或在 v2rayNG 與 v2flyNG 之間切換時，優先匯入原始訂閱或完整分享連結，讓目標用戶端依自己的核心產生設定。直接複製某個用戶端匯出的執行 JSON，可能帶入本地連接埠、平台路徑、專用路由與不受支援的欄位。遷移完成後先選一個基礎節點測試，再匯入複雜規則。如此可以分開驗證「節點相容性」與「本地路由相容性」，避免一次引入多個變因。

選擇路徑

依裝置、訂閱能力與使用情境選擇協定

先由伺服器能力劃定可選範圍

協定不能由用戶端單方面決定。伺服器只提供 VMess 時，用戶端把類型改成 VLESS 不會產生可用連線；訂閱沒有 REALITY 公鑰與短識別碼時，也不能透過開啟選項補出這些參數。因此第一步不是在所有名稱中挑選理論上的最佳項目，而是列出伺服器實際提供、目前用戶端核心完整支援的組合。只有位於這個交集中的節點，才值得繼續比較速度、資源與維護成本。

第二步查看是否有舊裝置或多個用戶端共同使用。需要相容既有 V2Fly 環境時，VMess 或雙方都支援的 Shadowsocks 設定通常較容易維持一致。若所有裝置都使用 Xray 核心，伺服器也明確提供 VLESS 與 REALITY，則可以優先測試這類組合。Trojan 適合伺服器已有完整 TLS 設定，且用戶端能正確處理憑證與伺服器名稱的情況。選擇應以現有條件為中心，而不是把協定名稱當成等級。

桌面端優先考慮管理能力與長期穩定性

Windows、macOS 與 Linux 上可優先使用 v2rayN。桌面環境常同時執行瀏覽器、開發工具、通訊軟體與系統更新，需要清楚的系統代理、路由規則與記錄入口。協定選擇方面，若訂閱提供 VLESS 與 REALITY 且目前 Xray 核心完整支援，可將其作為現代組合進行測試；已有 VMess、Trojan 或 Shadowsocks 節點穩定運作時，則可繼續使用，不必只為追逐名稱而遷移。

桌面端還要考慮 TUN 與系統代理的差異。系統代理主要影響遵循系統設定的應用程式，TUN 模式則透過虛擬網路介面接管更廣泛的流量範圍。兩者都屬於本地流量入口，不會改變遠端節點原本的協定。若某個應用程式不經代理，應先檢查入口與路由，而不是更換 VMess 或 VLESS。複雜路由帶來的規則比對與 DNS 行為，也可能比協定差異更影響使用結果。

Android 端先配對核心，再觀察背景穩定性

若訂閱以 Xray 能力為主，包含 VLESS、REALITY 或特定 flow 欄位，優先使用 v2rayNG。若訂閱主要是 V2Fly 支援範圍內的 VMess、Shadowsocks 等節點，並希望使用 v2fly 核心，則可以選擇 v2flyNG。選擇後應觀察螢幕關閉與網路切換後的連線復原情況。若節點在前景正常、背景卻頻繁斷線，先檢查系統背景策略與電池限制，而不是立即判定協定不穩定。

行動裝置不適合長期保留大量失效節點與複雜測試規則。節點清單過長會增加管理成本，自動選擇或測速也可能喚醒網路。保留少量經過驗證的節點，依用途整理訂閱群組，比不斷新增協定類型更有效。下載用戶端時，近年主流 Android 裝置通常選擇 arm64 架構；無法確認架構時可使用通用版。具體檔案入口由下載中心的 Android 分區提供。

不同目標下的建議順序

沒有脫離環境的單一最佳協定

VLESS 的職責分離適合現代 Xray 組合，VMess 具備成熟的歷史相容範圍，Trojan 的密碼與 TLS 結構直觀，Shadowsocks 方便輕量部署，REALITY 則服務於特定安全握手模型。每種方案都在解決不同限制。選擇時依序回答五個問題：伺服器提供什麼；用戶端核心支援什麼；訂閱欄位是否完整；裝置資源與背景條件如何；實際路徑是否穩定。五項都明確後，協定名稱本身反而不再神秘。

若仍難以決定，可以保留兩個用途不同的節點：一個以穩定與相容為主，另一個用於測試新組合。測試節點驗證足夠時間後，再替換主要節點。不要同時修改協定、傳輸、DNS、路由與系統入口。一次只改變一個層次，記錄變更前後的連線建立、持續傳輸與重連表現，得到的結論才可重複使用。

實作檢查

協定遷移、參數核對與故障定位

遷移前先保存可運作的基準

協定遷移最容易出現的問題，是舊節點尚未確認清楚就被新設定覆蓋。開始前應記錄目前可運作節點的用戶端、核心家族、協定、傳輸方式與安全層，並保留原始訂閱位址。也要明確遷移目標：是將舊 VMess 改為伺服器新提供的 VLESS，還是從 v2flyNG 切換到 v2rayNG 以使用 REALITY，或只是將桌面設定移至另一台裝置。不同目標對應不同檢查範圍。

若伺服器同時提供舊節點與新節點，應先將新節點作為獨立項目匯入，不要直接編輯舊項目。連線成功後，依序測試網域存取、持續傳輸、網路切換與常用應用程式，再決定是否替換。即使新參數有誤，也能回到已知可用的基準。若伺服器不再提供舊設定，更應完整保留新訂閱原文，避免在多個用戶端之間反覆轉存而造成欄位遺失。

連線失敗時，依建立鏈反向檢查

第一步檢查網路目標。確認位址沒有多餘空格、連接埠為數字、網域能夠解析，且裝置到目標連接埠具備基本連通性。Windows 可在 PowerShell 中使用以下命令檢查 TCP 連接埠是否能建立連線，範例網域需要替換為實際伺服器位址：

Test-NetConnection example.com -Port 443

macOS 與 Linux 可使用系統內建工具進行同類檢查：

nc -vz example.com 443

連接埠無法連線時，協定驗證尚未開始，應先處理位址、網路路徑或伺服器監聽。連接埠可達但核心回報握手失敗，再檢查系統時間、安全層、SNI、憑證或 REALITY 參數。握手成功後出現驗證失敗，重點核對 UUID、密碼、加密方法與使用者設定。能夠連線但目標無法存取時，再檢查 DNS、路由與本地代理入口。依層次排查可以避免一開始就重新安裝用戶端或隨意切換協定。

不同協定的常見錯誤點

VMess 需要特別注意系統時間、使用者識別碼、alterId 類歷史欄位與傳輸參數是否來自同一份設定。VLESS 常見問題是 UUID 正確，但安全層、flow 或傳輸不相符。Trojan 應核對密碼、SNI 與憑證相關條件。Shadowsocks 則需要確保密碼與加密方法完全一致，附加外掛程式參數也不能遺漏。REALITY 組合需要同時檢查公鑰、短識別碼、伺服器名稱、指紋與 flow，任何一項都不應靠猜測填寫。

記錄中的「解析失敗」與「連線逾時」含義不同。解析失敗通常表示設定語法或欄位不被核心接受；驗證失敗表示已進入相應協定處理階段；連線逾時則可能發生在位址、連接埠或網路路徑上；握手錯誤多半與 TLS、REALITY 或傳輸協商有關。看到錯誤後先定位發生階段，再檢查參數。只截取記錄最後一行可能缺少上下文，可以向前查看同一連線開始時的記錄，但不需要長期開啟最詳細的記錄。

連線成功但應用程式無法使用時，檢查本地入口

節點顯示已連線，只能表示核心已啟動或某次探測通過。瀏覽器、命令列工具與其他應用程式是否經過代理，還取決於系統代理、TUN、應用程式自身代理與路由規則。某個瀏覽器可用而另一個程式不可用，通常更接近本地入口問題。所有網域都失敗但直接使用位址可用時，應檢查 DNS；部分網站走錯出口時，應檢查網域與位址規則的比對順序。

路由規則會依核心設定順序或用戶端產生邏輯處理，寬泛規則放在前面可能遮蔽後面的精確規則。排錯時可暫時切換至用戶端提供的簡易代理模式，確認節點本身是否正常，再逐步恢復自訂路由。不要把路由問題誤判為 VLESS、VMess 或 Trojan 的協定問題。修改本地 SOCKS 或 HTTP 連接埠後，也要同步修改使用這些連接埠的應用程式。

建立可重複使用的檢查記錄

一份完整記錄應包含裝置平台、用戶端、核心家族、節點協定、傳輸、安全層、測試時段，以及錯誤發生的階段，不需要保存實際密碼或使用者憑證。記錄「連接埠可達、握手失敗」比只寫「節點不能使用」更有價值；記錄「Wi-Fi 正常、切換網路後無法自動復原」也比單次延遲數字更能定位行動裝置問題。經過幾次排查後，可以建立適合自身環境的固定順序。

如果是首次設定，建議先回到快速入門主線，使用訂閱匯入與預設設定建立基準；如果問題只出現在首次安裝與系統代理，可參考v2rayN 首次安裝與初始設定。需要重新選擇用戶端時，桌面端從 v2rayN 開始，Android 依 Xray 或 V2Fly 核心需求選擇 v2rayNG、v2flyNG，並透過下載中心進入對應平台。