V2Ray 協議與核心選擇手冊

01 / MODEL

選擇協議前：先分清協議、傳輸與安全層

用戶端中的一行節點，實際上由多層參數組成

「協議」在用戶端介面中經常被當作廣義分類，但一條可用的連線並不只由協議名稱決定。以常見的 VLESS 節點為例，VLESS 負責描述用戶端與伺服器交換身分資訊及轉送資料的基本方式；TCP、WebSocket、gRPC 等欄位描述底層資料如何承載；TLS 或 REALITY 負責握手與安全層；XTLS Vision 則可能作為流控方式參與資料處理。位址、連接埠、使用者識別碼與伺服器名稱則屬於連線參數。任何一層不匹配，都可能表現為逾時、握手失敗或連線後沒有有效流量。

因此，選擇時不能把「VLESS」和「VLESS + TCP + REALITY + Vision」視為同樣精確度的名稱。前者只指出協議骨架，後者才接近一套完整組合。用戶端匯入訂閱後顯示的類型標籤，通常只突顯最容易辨識的部分；完整參數仍應進入節點編輯頁檢查。尤其從文字訂閱遷移到另一款用戶端時，名稱相同不代表所有擴充欄位都被保留。

四個判斷面向比固定排名更可靠

第一項是伺服器相容性。用戶端不能單方面把 VMess 改成 VLESS，也不能只勾選 REALITY 就讓一般 TLS 節點取得相應能力。協議、傳輸與安全參數必須與伺服器設定逐項一致。第二項是核心能力。v2rayN 可承載桌面端常見設定，v2rayNG 主要使用 Xray 核心，v2flyNG 則面向 V2Fly 核心；同一條基礎節點在這些用戶端中的支援範圍可能不同，涉及 REALITY、Vision 或特定傳輸擴充時，差異會更明顯。

第三項是裝置環境。桌面裝置通常有更充足的處理器時間與記憶體，可以優先考慮相容性、路由能力與維護便利性。Android 裝置還要考慮背景執行、無線網路切換、持續握手與反覆重連造成的耗電。第四項是設定來源。如果節點來自訂閱，應優先選擇訂閱明確提供且用戶端能完整辨識的類型，不要為了追求某個名稱而手動猜測缺少的參數。

先確認完整性，再討論效能

連線速度的前提是參數正確。位址解析、連接埠可達、系統時間準確、使用者識別碼一致、傳輸路徑一致，這些基礎條件對首次連線成功率的影響，比協議名稱更直接。如果匯入後缺少伺服器名稱、WebSocket 路徑、REALITY 公鑰或短識別碼，單純切換節點類型通常無法解決問題。應回到節點資料或訂閱來源核對，而不是在用戶端逐項試猜。

實用順序是：先確認用戶端是否辨識節點類型；再核對位址、連接埠與身分欄位；接著檢查傳輸方式及其附屬參數；最後檢查安全層與流控。完成這些步驟後，才比較連線建立時間、持續吞吐量、記憶體占用與電量表現。這樣可以將「設定錯誤」和「協議取捨」分開，避免把一次握手失敗誤判為某類協議本身速度較慢。

02 / VMESS

VMess：既有設定相容性與參數界線

設計背景與目前定位

VMess 是 Project V 生態中較早廣泛使用的一類協議。它將使用者識別碼、驗證資訊與資料傳輸規則組織在統一的協議結構中，並在用戶端與伺服器之間加入基於時間的驗證流程。這項設計使 VMess 不只是「位址加密碼」的簡單組合，也說明了系統時間偏差可能影響連線。許多較早部署的伺服器、訂閱轉換工具與用戶端設定都以 VMess 為基礎，因此在既有節點相容性方面仍有實際價值。

選擇 VMess 的主要理由通常不是追求最少處理步驟，而是既有設定已穩定運作，相關訂閱欄位也能被用戶端完整解析。若伺服器只提供 VMess，用戶端就應維持協議一致。將節點類型改為 VLESS 並保留原 UUID，不會得到等效連線，因為兩種協議的驗證與資料結構不同。協議遷移需要伺服器與用戶端同時調整，不能只修改本機標籤。

alterId、加密選項與舊設定辨識

舊資料中經常出現 alterId。它是早期 VMess 設定體系的一部分，現代設定通常使用零值。匯入歷史訂閱時，如果用戶端仍顯示這個欄位，應以伺服器實際設定為準，不要因教學年代不同就自行改成其他數字。不同用戶端可能隱藏不再常用的選項，或在匯入階段自動填入預設值；這類介面差異不代表協議內容已被改變。

VMess 節點也可能顯示 security 或「加密方式」。這個欄位描述 VMess 資料層採用的處理方式，與外層 TLS 並不是同一個選項。外層 TLS 是否啟用，由傳輸安全欄位決定。常見誤區是看到 security 已有值，就以為 TLS 也已設定；實際上兩者位於不同層級。排查時應分別檢查，不能以其中一項取代另一項。

{
  "protocol": "vmess",
  "settings": {
    "vnext": [{
      "address": "example.com",
      "port": 443,
      "users": [{
        "id": "11111111-1111-4111-8111-111111111111",
        "alterId": 0,
        "security": "auto"
      }]
    }]
  }
}

上面的片段只展示 VMess 出站的核心層級。實際連線還需要與伺服器一致的傳輸與安全設定。範例位址與使用者識別碼僅用於說明欄位結構，不能當作節點使用。手動輸入時，應將節點資料中的每個值放入對應位置，而不是複製範例內容。

傳輸組合與效能理解

VMess 可以與 TCP、WebSocket 等傳輸組合，也可以疊加 TLS。不同組合的差異往往大於 VMess 協議本身。例如，直接 TCP 的封裝路徑相對較短；WebSocket 需要額外的框架處理，並依賴路徑、Host 等欄位匹配；TLS 則會增加握手與加密計算。討論「VMess 快不快」時，必須說明比較雙方是否使用相同傳輸、相同安全層、相同伺服器與相同網路條件。

在資源占用方面，VMess 的驗證與資料處理通常比結構更精簡的 VLESS 多一些步驟，但在現代桌面裝置上，這種差異未必會成為主要瓶頸。真正明顯的延遲常來自網域解析、伺服器距離、無線網路抖動、反覆建立連線與傳輸層重試。行動裝置持續使用時，應注意用戶端記錄中是否週期性斷線重連；反覆握手會同時增加等待時間與電量消耗。

適合保留與適合遷移的情況

如果 VMess 節點參數完整、連線穩定、訂閱更新正常，而且目前用戶端能準確辨識傳輸設定，繼續使用是合理選擇。協議選擇不是每次出現新名稱就必須遷移。相反地，如果正在新建伺服器，且用戶端與核心都明確支援 VLESS 及所需安全組合，可以從更精簡的協議骨架開始評估。遷移時應保留原節點作為對照，先新增設定並驗證，再移除舊設定，避免在參數尚未核對完成時失去可用基準。

在 v2rayN、v2rayNG 與 v2flyNG 之間傳遞 VMess 節點時，基礎欄位通常具有廣泛相容性，但某些傳輸擴充仍取決於核心。匯入成功後至少檢查協議、位址、連接埠、UUID、傳輸方式、TLS 開關、伺服器名稱與路徑。若訂閱只提供一個 vmess:// 項目，用戶端通常會負責解碼；若顯示空白節點或欄位錯位，應優先檢查訂閱內容是否完整，而不是手動猜測補值。

03 / VLESS · REALITY

VLESS、REALITY 與 XTLS Vision：三個層級各自負責什麼

VLESS 是輕量協議骨架

VLESS 的設計重點是簡化協議本身承擔的工作。它使用使用者識別碼完成身分匹配，但不在 VLESS 資料層內重複提供一套完整加密機制，而是將安全能力交給 TLS、REALITY 等外層方案。這種分工讓協議結構更清晰，也減少部分重複處理。不過，「VLESS 本身較輕」不等於任何 VLESS 組合都一定更快；最終開銷仍由傳輸方式、安全握手、流控、伺服器實作與網路路徑共同決定。

在用戶端編輯頁中，VLESS 常見欄位包括位址、連接埠、UUID、加密值、傳輸方式、安全類型與流控。部分介面會要求加密欄位使用 none，這是協議結構的一部分，不表示整條連線沒有安全層。若節點同時使用 TLS 或 REALITY，安全處理位於外層。判斷安全組合時，應查看「傳輸層安全」或同義選項，不能只看 VLESS 的加密欄位。

REALITY 是安全握手方案，不是 VLESS 的替代名稱

REALITY 經常與 VLESS 一起提供，因此不少用戶端會將組合名稱連在一起顯示。嚴格區分時，VLESS 負責應用程式協議，REALITY 負責安全與握手相關能力。REALITY 設定通常涉及伺服器名稱、公鑰、短識別碼與用戶端指紋等參數；這些值必須成組匹配。只有位址、連接埠與 UUID 不足以建立完整連線。若訂閱轉換遺漏其中任何擴充欄位，用戶端即使顯示為 VLESS，也可能在握手階段失敗。

公鑰是用戶端驗證並參與握手所需的重要欄位，短識別碼用於匹配伺服器設定，伺服器名稱則參與握手語意。用戶端中的「指紋」選項描述握手表現所採用的預設值。不同版本介面對這些欄位的命名可能略有差異，例如「Public Key」、「公鑰」或縮寫名稱，但欄位作用並未因此改變。遷移節點時應依照意義對應，不要只按介面位置複製。

XTLS Vision 屬於流控與資料處理方式

XTLS Vision 常出現在 VLESS + REALITY 組合中。它不是新的身分協議，也不是伺服器位址的附加形式，而是一種流控選擇。Vision 的目標之一是減少特定情境中的重複處理，讓已具備安全語意的資料採用更合適的資料路徑。用戶端與伺服器都必須支援並設定一致；若伺服器未啟用對應流控，用戶端單方面選擇 Vision 可能導致連線異常。

介面中常見的值是 xtls-rprx-vision。選擇時應以節點資料為準。留白與填入此值不是可以任意互換的效能檔位，而是伺服器設定的一部分。某些訂閱格式可以直接攜帶 flow 參數，某些舊式轉換流程則會遺失它。匯入後如果 REALITY 的公鑰、短識別碼都存在，但仍無法傳輸，應繼續檢查 flow，而不是反覆修改伺服器名稱。

為什麼這類組合通常有較好的回應表現

VLESS 協議骨架較精簡，REALITY 省去自行準備一般 TLS 憑證設定的部分流程，Vision 又針對資料處理路徑進行最佳化。三者組合時，較少的重複封裝與合適的流控可能降低處理開銷。但實際體驗仍受往返延遲、伺服器負載、壅塞、網域解析與裝置效能影響。協議只決定其中一部分，不應從一次測速直接推導普遍結論。

行動裝置上的優勢通常體現在持續連線較穩定、重複計算較少時。若網路頻繁在無線區域網路與行動數據之間切換，任何協議都會重新建立連線；此時背景策略與網路品質可能比協議差異更影響電量。想進一步了解握手與資料路徑，可閱讀REALITY 與 XTLS Vision 技術科普。實際設定前還應確認所用用戶端與核心支援完整欄位，其中 v2rayNG 更適合承載 Xray 相關擴充。

04 / TROJAN · SS

Trojan 與 Shadowsocks：結構簡潔，但取捨不同

Trojan：驗證與 TLS 組合清晰

Trojan 通常以密碼作為身分憑據，並與 TLS 一起使用。它的設定概念相對直接：用戶端連線至指定位址與連接埠，使用密碼完成協議驗證，同時由 TLS 提供安全層。常見節點資料還會包含伺服器名稱與憑證驗證相關選項。這裡的伺服器名稱需要與伺服器憑證設定匹配，不能只根據位址欄內容推斷。

Trojan 的優勢在於參數層次容易理解，許多用戶端也能穩定解析標準分享連結。它並不是「只有密碼和連接埠」這麼簡單，因為 TLS 握手、伺服器名稱與傳輸方式仍需要一致。若使用 WebSocket 或 gRPC，路徑、服務名稱等附屬欄位同樣會參與連線。排查時可以先將問題分為 TLS 握手階段與 Trojan 驗證階段：前者重點檢查系統時間、伺服器名稱與安全設定，後者重點檢查密碼及伺服器協議設定。

Shadowsocks：精簡的加密轉送結構

Shadowsocks 常縮寫為 SS。其核心參數通常包括伺服器位址、連接埠、加密方法與密碼，結構比 VMess 或帶有多個擴充層的 VLESS 組合更精簡。設定簡潔讓它便於手動輸入，也容易在不同用戶端之間傳遞。同時，加密方法必須由用戶端與伺服器共同支援，名稱需要逐字匹配；替換成看似相近的方法，不會自動協商成可用值。

不同核心對 Shadowsocks 加密方法的支援範圍可能有所差異。較新的方法需要相應核心能力，舊用戶端即使能讀取 ss:// 連結，也可能在連線階段提示不支援。遇到這類情況，應先確認用戶端核心，而不是修改密碼。v2rayN 適合在桌面端統一管理不同協議，v2rayNG 與 v2flyNG 則分別受所用核心的支援範圍影響。選擇用戶端時，應將實際加密方法列入相容性檢查。

{
  "protocol": "shadowsocks",
  "settings": {
    "servers": [{
      "address": "example.com",
      "port": 8388,
      "method": "aes-128-gcm",
      "password": "your-password"
    }]
  }
}

這段片段展示標準出站欄位的關係。位址、連接埠、方法與密碼必須替換為伺服器提供的真實值。加密方法不是本機偏好選項，不能為了降低資源占用而單方面更換。若用戶端匯入後方法為空，應重新核對分享連結或訂閱轉換結果。

兩者的效能差異不能只看欄位數量

Shadowsocks 參數較少，不代表在所有網路條件下都比 Trojan 快。Trojan 通常需要承擔 TLS 握手成本，但長連線建立後，握手成本會由後續持續傳輸分攤。Shadowsocks 的實際開銷與所選加密方法、裝置硬體加速、封包大小及核心實作有關。短連線很多時，連線重用與用戶端行為可能主導體驗；持續下載時，伺服器頻寬與鏈路品質往往更重要。

在行動裝置上，持續加密運算與頻繁重連都會影響電量。現代處理器對常見加密運算有良好支援，單看演算法名稱很難準確預測耗電。更有意義的觀察方式是維持相同網路、相同伺服器區域與相近負載，分別記錄一段時間內的連線穩定性、喚醒次數與用戶端背景狀態。幾秒鐘的單次測速不足以判斷長期電量表現。

適用界線與選擇方法

若節點資料只提供標準 Trojan 參數，而且用戶端能正確辨識 TLS 相關欄位，維持使用 Trojan 是最穩妥的做法。若節點提供 Shadowsocks，應重點確認加密方法是否受目前核心支援。兩者都不需要為了與其他節點「統一類型」而轉換。訂閱同時包含多種協議時，可以保留不同類型，讓用戶端按節點管理；系統代理與路由規則不要求所有出站都採用同一協議。

從維護角度來看，參數較少有利於人工核對，但不代表後續更新可以省略。伺服器位址、密碼、憑證名稱或加密方法發生變更後，舊節點仍會失效。使用訂閱時應透過用戶端的更新訂閱功能接收變更，避免長期維護多個手動副本。關於桌面端與 Android 的訂閱入口，可參閱V2Ray 訂閱連結匯入方法。

05 / PERFORMANCE

如何比較連線速度、資源占用與行動端電量

把「快」拆成四個可觀察階段

協議比較中的「速度」至少包含四個不同指標。第一是連線建立時間，從用戶端發起連線到握手完成；第二是首個封包時間，即發出請求後收到第一段有效資料所需的等待時間；第三是持續吞吐量，反映較長傳輸過程中的穩定速率；第四是抖動與重連，決定網頁連續載入、影音播放與背景工作是否平穩。某個組合建立連線稍慢，不代表持續吞吐量一定較低；反過來，首次連線很快也不代表在弱網路下更穩定。

進行比較時，應固定伺服器、網路、目標位址、路由規則與測試時段。若兩個節點位於不同地區，所得差異主要反映網路路徑，而不是協議。也應先完成一次預熱，減少網域解析與首次連線快取對結果的影響。用戶端中常見的「延遲測試」可能只測 TCP 建立連線或特定探測位址，不一定會完成實際協議握手。想判斷節點能否運作，應使用真實連線測試，並在連線後存取實際目標進行驗證。

協議處理通常不是唯一瓶頸

VMess 具有自身的驗證與資料處理流程；VLESS 將更多安全能力交給外層；Trojan 通常伴隨 TLS；Shadowsocks 的開銷與加密方法相關；VLESS + REALITY + Vision 則包含握手與流控協作。理論上的處理步驟有助於解釋差異，但在一般用戶端使用情境中，網路往返、伺服器處理能力、丟包與壅塞經常占更大比例。只有在伺服器與鏈路條件接近時，協議層差異才較容易被觀察。

傳輸方式也會改變結果。TCP 組合通常路徑直接；WebSocket 增加框架封裝；gRPC 基於 HTTP/2 語意，並可能利用多路複用。多路複用不是連線越多越好，過度聚合可能讓單一底層連線的抖動影響多個請求。用戶端中的並行、連線重用或 mux 選項應保守調整，一次只修改一項，並保留預設值作為比較基準。

記憶體、處理器與背景喚醒

資源占用由用戶端介面、核心、規則集、連線數量與記錄層級共同構成。協議只是其中一部分。大型路由規則、持續的詳細記錄與大量並行連線，往往比單一協議欄位更明顯地增加記憶體與處理器使用量。桌面端 v2rayN 還需要管理系統代理、系統匣狀態與設定清單；Android 用戶端則透過系統網路介面接管流量，並受到背景策略影響。比較資源時，應確認兩次測試使用相同規則與記錄層級。

記錄層級尤其容易干擾長期觀察。排錯時啟用詳細記錄很有價值，但完成排查後可以恢復一般層級，減少持續寫入與格式化開銷。節點清單過多通常不會持續占用大量處理器，但頻繁執行全量測試會同時建立許多連線。行動裝置上不宜將自動測試間隔設得過短；按需求測試目前候選節點，更容易得到可解釋的結果。

行動端電量由穩定性與重連頻率共同決定

行動端耗電不能簡單按照 VMess、VLESS 或 Trojan 排出固定順序。無線模組喚醒、螢幕使用、網路訊號強弱、背景保活、連線數量與重試策略都會影響結果。一個理論處理較輕、但每隔幾十秒就斷線重連的節點，可能比穩定維持長連線的節點消耗更多電量。應先選擇穩定路徑，再討論協議處理差異。

在 v2rayNG 或 v2flyNG 中比較節點時，可以維持相同路由模式與應用程式範圍，關閉不必要的連續測速，觀察正常使用週期內的系統電量統計。測試期間不要頻繁切換網路，也不要同時進行大規模系統更新。若裝置進入休眠後連線總是被系統回收，應檢查系統針對用戶端的背景執行設定；這屬於裝置調度問題，換協議未必能解決。

06 / CORES

V2Fly 與 Xray：核心家族、功能範圍與設定相容性

用戶端介面與代理核心是兩個組成部分

v2rayN、v2rayNG 與 v2flyNG 都提供圖形介面，但實際的協議解析、連線建立與路由處理通常由核心完成。介面負責訂閱管理、節點編輯、系統代理、記錄顯示與啟動控制；核心負責讀取設定並執行網路邏輯。理解這層分工後，許多相容性問題會更容易定位：介面能顯示某個欄位，只代表資料已被儲存；核心能否執行，還取決於對應功能是否受支援。

v2rayN 是桌面端首選，適合 Windows、macOS 與 Linux，能管理多種節點與路由設定。v2rayNG 是 Android 常用用戶端，主要結合 Xray 核心能力。v2flyNG 同樣面向 Android，但採用 V2Fly 核心路線，可作為需要該核心相容範圍時的選擇。三款用戶端的安裝入口集中在下載中心，應依裝置平台與節點類型選擇，不要只根據名稱相似度判斷。

V2Fly 延續 Project V 設定體系

V2Fly 維護 V2Ray 相關核心能力，設定結構延續常見的 inbounds、outbounds、routing、dns 等層級。VMess、Shadowsocks、Trojan 以及相應的傳輸能力，都可以在其支援範圍內組織。對於已有 V2Fly 設定、依賴其具體行為，或希望維持相同核心體系的使用者，v2flyNG 提供了直接的 Android 圖形化入口。

「設定結構相似」不代表所有擴充欄位都完全通用。某些欄位可能只存在於特定核心，另一些欄位雖然名稱相同，支援的取值範圍也可能不同。將完整 JSON 從一個核心複製到另一個核心前，應先檢查協議與傳輸支援，再檢查路由規則與 DNS 結構。基礎出站通常較容易遷移，涉及實驗性功能、專用流控或擴充傳輸時，則應逐項驗證。

Xray 擴充 VLESS、REALITY 與 Vision 等能力

Xray 與 V2Ray 設定體系有深厚的結構關聯，因此許多基礎設定看起來相似。Xray 在 VLESS、XTLS Vision、REALITY 等方向提供相應能力，這也是這些節點通常更適合使用 v2rayNG 或桌面端相應核心環境的原因。若節點資料明確包含 REALITY 公鑰、短識別碼與 Vision 流控，應優先確認目前用戶端實際呼叫的核心是否支援，而不是只確認介面中存在 VLESS 類型。

核心選擇也會影響分享連結解析後欄位的保留情況。用戶端可能在匯入階段辨識 URI 參數，但啟動核心時仍會進行設定轉換或檢查。如果記錄提示未知欄位、無效取值或不支援的流控，問題重點通常在功能範圍，而不是位址是否可達。此時應回到節點類型與核心的匹配關係處理，不宜隨意刪除欄位讓設定勉強通過，因為被刪除的欄位可能正是連線必要項目。

哪些設定通常容易相容，哪些需要謹慎

位址、連接埠、基礎使用者識別碼、標準 VMess 欄位、部分常見傳輸與基礎路由規則，通常較容易在相近設定體系之間對應。DNS 與 routing 的基本層級也有共同概念。但 REALITY、XTLS Vision、特定傳輸擴充、協議專用設定，以及不同核心新增的欄位，應視為需要單獨核對的部分。用戶端產生的完整設定還可能包含本機監聽連接埠、記錄路徑與平台相關設定，這些內容不適合原樣跨裝置複製。

更穩妥的遷移方式是以節點分享資訊為輸入，讓目標用戶端產生自己的本機設定。這樣可以避免把來源用戶端的本機連接埠、快取路徑與平台選項一併帶過去。接著再遷移路由規則，並逐項驗證。若必須處理 JSON，先保留最小出站與必要傳輸欄位，確認連線後再加入 DNS、路由與進階選項。每增加一層就進行一次測試，出現錯誤時便能定位到最近的變更。

v2ray test -c config.json
xray run -test -c config.json

以上命令用於在相應核心的可執行檔已正確安裝，且位於目前命令環境時檢查設定語法。命令測試通過只代表設定能被解析，不代表伺服器一定可達。圖形化用戶端使用者通常可以直接查看啟動記錄，不必離開用戶端操作。

07 / SUBSCRIPTION

訂閱、分享連結與用戶端相容性：欄位如何在工具間傳遞

訂閱連結是設定集合的入口，不是協議本身

訂閱連結通常會返回一組節點資料，用戶端取得內容後再解析為本機設定。它可以包含 VMess、VLESS、Trojan、Shadowsocks 等不同類型，也可能返回經 Base64 編碼的多行分享連結。訂閱位址本身不能說明內部節點採用哪種協議，只有更新並解析後才能看到具體類型。將訂閱位址直接貼到單一節點編輯框，通常不會得到正確結果。

在 v2rayN 中，應使用訂閱群組或訂閱管理入口儲存位址，再執行更新訂閱。v2rayNG 與 v2flyNG 也有對應的訂閱設定與更新操作。更新後先確認節點數量與類型，再選擇節點進行測試。若清單為空，應檢查位址是否完整、網路請求是否成功、返回內容是否為用戶端支援的格式。完整步驟可查看v2rayN 與 v2rayNG 訂閱匯入說明。

常見 URI 格式分別攜帶哪些資訊

vmess:// 常見形式會將一段 JSON 資訊編碼後放入連結，其中可包含位址、連接埠、UUID、傳輸、Host、路徑與 TLS 等欄位。不同產生工具曾使用略有差異的欄位名稱，因此舊連結在新用戶端中的解析結果需要人工核對。vless://、trojan:// 與部分 ss:// 連結更接近標準 URI：身分資訊位於使用者資訊部分，位址與連接埠位於主機部分，其餘參數放在查詢字串中。

URI 中的參數名稱具有明確意義。例如 security 可能指出 TLS 或 REALITY，type 可能表示傳輸方式，flow 表示流控，sni 或同義參數表示伺服器名稱，pbk 與 sid 常用於 REALITY 公鑰與短識別碼。用戶端需要辨識這些參數，並正確對應到核心設定。分享連結看起來很長，不代表資訊一定完整；若產生工具沒有寫入某個必要欄位，再長的連結也無法恢復缺失內容。

Base64 只是表示方式，不等於某一種協議

不少訂閱會將多行分享連結整體進行 Base64 編碼，以便以單段文字傳輸。解碼後仍然是多個 vmess://、vless://、trojan:// 或 ss:// 項目。Base64 不負責加密節點內容，也不決定用戶端相容性。相容性取決於解碼後的協議連結、擴充參數以及目標用戶端的解析能力。

當一個用戶端能匯入、另一個用戶端匯入後為空時，不應先判定訂閱已失效。可以依序確認目標用戶端是否支援訂閱返回類型、是否辨識其中的協議，以及是否支援連結所帶的擴充參數。v2flyNG 與 v2rayNG 採用不同核心路線，包含 REALITY 或 Vision 的節點更應注意差異。若訂閱同時包含多種節點，部分成功、部分失敗通常代表協議或參數支援範圍不同，而不是整個訂閱請求失敗。

更新、去重與本機修改的界線

訂閱更新可能覆蓋由訂閱管理的節點。若直接在用戶端修改訂閱節點，下次更新後這些變更可能遺失。需要長期保留的本機實驗設定，可以複製為獨立節點並重新命名，避免與訂閱項目混淆。節點名稱相同也不一定是重複項目，應比較位址、連接埠、協議、身分欄位、傳輸與安全參數後，再決定是否刪除。

更新訂閱後突然無法連線，應先檢查節點參數是否發生變化，再判斷本機代理設定。伺服器可能調整位址、連接埠或安全欄位，用戶端也可能因解析規則變更而顯示不同內容。保留一份更新前的獨立對照設定，有助於判斷變化發生在哪一層。若所有訂閱節點同時逾時，再依照節點逾時排查順序檢查系統時間、本機連接埠、節點參數與訂閱狀態。

08 / DECISION

依使用情境選擇協議，並安全完成遷移

已有穩定節點：相容性優先於追逐名稱

如果現有 VMess、Trojan 或 Shadowsocks 節點已穩定運作、訂閱更新正常，且用戶端也能完整辨識參數，就沒有必要只因看到新的協議名稱而立即遷移。協議選擇首先受伺服器能力限制，其次才是本機偏好。穩定連線本身包含經過驗證的伺服器設定、網路路徑與用戶端組合，這些條件比理論比較更有價值。

需要更換用戶端時，桌面平台優先選擇 v2rayN；Android 上，包含 Xray 擴充的設定優先考慮 v2rayNG，需要 V2Fly 核心路線時則選擇 v2flyNG。遷移前記錄原用戶端中的協議、傳輸、安全、伺服器名稱、路徑、流控與身分欄位。透過分享連結或訂閱匯入後，再逐項對照。只有名稱和位址一致還不夠，擴充欄位缺失可能讓節點在握手階段失敗。

建立新設定：先決定核心，再決定組合

準備建立新節點時，可以先從目標裝置與用戶端反推核心能力。若桌面端與 Android 都需要使用，而且設定涉及 REALITY 與 Vision，應確認兩端都有合適的 Xray 執行環境，再採用 VLESS + REALITY + Vision 組合。若目標環境強調 V2Fly 設定一致性，則應從 V2Fly 的支援範圍內選擇協議與傳輸。先決定核心，可以避免伺服器部署完成後才發現某一端無法解析關鍵欄位。

若需求是參數簡潔、方便手動輸入，而且伺服器與用戶端對加密方法的支援一致，Shadowsocks 可以作為明確選項。若已有標準 TLS 設定體系，並希望採用密碼驗證與清晰的 TLS 層次，Trojan 便於理解與維護。VMess 更適合繼續承載既有設定與相容歷史訂閱。不同組合沒有脫離環境的絕對排名，應將相容性、維護、穩定性與資源四項放在同一張檢查表中。

弱網路與行動裝置：優先減少重連

網路波動明顯時，選擇穩定伺服器與合適傳輸，比追求理論上最少封裝更重要。觀察記錄中的連線重設、握手逾時與重複解析。如果某個節點頻繁中斷，應先判斷是無線訊號、伺服器負載、傳輸設定還是協議參數問題。直接更換協議可能同時更換伺服器與路徑，導致比較失去依據。

Android 裝置應減少持續批次測速與過於頻繁的訂閱更新，維持合理的路由規則規模，並讓系統允許用戶端按需在背景執行。VLESS + REALITY + Vision 在完整支援且參數匹配的前提下，可能有較佳的處理路徑；但穩定的 Trojan 或 Shadowsocks 節點仍可能在實際裝置上表現更好。應以完整使用週期的穩定性、電量與真實連線結果作判斷。

多裝置同步：以訂閱作為來源，以用戶端設定作為本機層

桌面端與 Android 端共同使用時，適合將節點訂閱作為共用來源，將系統代理、應用程式範圍、路由模式與本機監聽連接埠留在各自裝置管理。不要直接複製完整用戶端設定檔，因為其中包含平台相關欄位。訂閱更新後，兩端分別檢查節點類型與擴充參數；如果某類節點只在一端出現，應檢查該端的解析與核心支援，而不是立即刪除訂閱內容。

路由規則也不應與協議選擇混為一談。同一條 VLESS 或 VMess 出站可以被不同規則引用，切換路由模式不會改變節點協議。排查「某些網站能存取、某些不能存取」時，應先判斷請求是否命中預期路由，再檢查節點。若所有請求都失敗，才回頭檢查協議與連線參數。分清這兩個層次可以減少無效修改。

遷移流程：新增、對照、驗證，再清理

安全遷移可以分為四個步驟。第一步保留舊節點，新增目標協議設定，不覆蓋目前可用項目。第二步逐項對照位址、連接埠、身分、傳輸、安全與流控，確保伺服器已同步支援。第三步執行真實連線測試，檢查記錄並存取實際目標，分別驗證連線建立與系統代理是否生效。第四步經過一段穩定使用期後，再刪除不再需要的舊設定。

如果新設定失敗，應回復到最近一次可用狀態，再按層級排查。驗證錯誤檢查 UUID 或密碼；握手錯誤檢查系統時間、伺服器名稱、公鑰與短識別碼；逾時檢查位址、連接埠與傳輸；啟動階段提示未知欄位則檢查核心相容性。不要同時修改協議、傳輸、路由與 DNS，否則記錄很難指出真正原因。詳細的首次連線驗證流程可參考v2rayNG 首次連線完整流程。