V2Ray 協定與核心技術參考

一、先建立協定選擇框架

協定、傳輸層與安全層不是同一個維度

用戶端節點名稱中經常同時出現 VLESS、TCP、WebSocket、TLS、REALITY 等詞，容易被誤解為彼此競爭的多種協定。實際上，這些欄位通常位於不同層級。VMess、VLESS、Trojan、Shadowsocks 主要規定用戶端與伺服器如何識別使用者、封裝資料及建立代理工作階段；TCP、WebSocket、gRPC 等則描述資料的承載方式；TLS 與 REALITY 負責連線安全及握手特徵。一個完整節點通常是多個層次的組合，而不是從所有名詞中只選一個。

例如「VLESS + TCP + REALITY」表示應用層採用 VLESS，底層透過 TCP 傳輸，安全層則由 REALITY 相關握手參數處理。「VMess + WebSocket + TLS」則是另一種組合。比較節點時應分層檢視：先確認用戶端核心是否支援該協定，再檢查傳輸方式與安全方式能否同時啟用，最後核對位址、連接埠、使用者識別碼、伺服器名稱與公鑰等具體欄位。只比較節點名稱中的第一個詞，無法判斷整份設定是否適合目前裝置。

相容性優先於理論效能

選擇協定的第一原則，不是尋找抽象意義上最快的方案，而是確保伺服器、訂閱轉換端、用戶端核心與圖形介面能完整表達同一份設定。某種組合即使封裝更精簡，只要用戶端忽略關鍵欄位，最終仍可能握手失敗、連線後無法傳輸，或在匯入時直接遺失節點。因此應先確認協定支援矩陣，再討論連線速度、吞吐量與資源使用量。

桌面端首選 v2rayN，因為它可在 Windows、macOS 與 Linux 上提供較完整的圖形化設定入口，並支援常見的 Xray 相關協定欄位。在 Android 上，v2rayNG 採用 Xray 核心，適合需要 VLESS、REALITY 等能力的設定；v2flyNG 採用 v2fly 核心，較適合以 VMess、Shadowsocks 和 V2Fly 相容設定為主的使用環境。兩款 Android 用戶端介面相近，但不能因此推論底層協定能力完全一致。

節點品質不能用協定名稱取代

實際連線效果還會受到伺服器負載、線路品質、出口頻寬、距離、網域名稱解析、系統網路堆疊及伺服器參數影響。相同協定的兩個節點可能表現差異很大，不同協定的兩個節點也可能因線路條件而呈現相反結果。協定只決定封裝方式與能力界線，不直接代表節點頻寬、穩定度或可用時間。

因此，合理流程是先依相容性排除無法完整匯入的組合，再在同一裝置、同一網路與相近時間內比較真實連線延遲、網頁回應與持續下載表現。用戶端中的 ICMP Ping、TCP 真實連線延遲與下載測速測量的是不同鏈路階段，不能簡單依最小數值排序。需要了解三類測試差異時，可繼續閱讀Ping、真實連線延遲與下載測速的差異。

二、VMess 與 VLESS：從完整工作階段到精簡驗證

VMess 的設計背景與工作階段特徵

VMess 是 Project V 早期生態中具代表性的協定之一。它將使用者識別碼、時間相關驗證、工作階段建立與資料封裝納入自身的協定設計，讓用戶端與伺服器能以統一結構完成驗證與通訊。對早期 V2Ray 設定而言，VMess 承擔了較多職責，因此在舊訂閱、長期維護的伺服器與 V2Fly 生態中仍很常見。它的優勢是歷史相容範圍廣，許多訂閱產生系統與圖形用戶端都能識別其基本欄位。

VMess 設定通常包含伺服器位址、連接埠、使用者識別碼、加密或安全欄位、傳輸方式以及 TLS 等外層選項。使用者識別碼必須與伺服器一致，用戶端系統時間也應保持正常，因為時間偏差可能影響驗證流程。排查 VMess 連線失敗時，除了位址與連接埠，還應確認裝置時間、使用者識別碼、傳輸路徑、Host 欄位、TLS 伺服器名稱以及訂閱是否過期。只重新測速而不核對這些欄位，通常無法找出設定層錯誤。

由於 VMess 自身承擔較多工作階段邏輯，其協定處理比 VLESS 稍微複雜。不過在一般桌面裝置上，這項差異通常小於網路品質造成的波動。只有在低功耗 Android 裝置、高並發連線或持續大量傳輸的情境中，封裝複雜度才較可能反映在處理器喚醒、記憶體配置與耗電變化上。即使如此，傳輸方式與應用程式行為仍可能比協定本身帶來更大的影響。

VLESS 為何採用精簡設計

VLESS 的設計重點是減少協定內部承擔的加密與狀態管理職責，將安全性更多交由 TLS、REALITY 等外層機制處理。它保留使用者識別碼與必要的代理工作階段欄位，但不重複實作一套完整的資料加密層。如此可縮短協定處理路徑，並讓安全層與傳輸層的職責更清楚。VLESS 不能脫離適當的安全設定被簡單理解為「自動安全」；節點是否安全取決於整體組合，而不是只由 VLESS 這個名稱決定。

這種分層方式也說明了為什麼 VLESS 節點經常與 TLS 或 REALITY 一起出現。用戶端匯入時必須完整保留伺服器名稱、指紋選項、公鑰、短識別碼、流量控制參數等組合欄位。部分欄位只有在特定傳輸方式、安全方式與核心實作中才有效，任意複製到另一種組合可能導致握手無法完成。尤其是流量控制欄位，它不是通用的速度開關，只有伺服器與用戶端按相同模式設定時才應啟用。

從使用者角度來看，VLESS 的主要價值不是介面選項較少，而是協定職責更明確，便於與現代傳輸和安全機制組合。對於新設定，如果伺服器明確提供 VLESS，且目前用戶端能完整識別所有欄位，通常可將其列為優先測試對象。若現有 VMess 節點穩定、訂閱更新正常，也沒有必要只因協定名稱較舊就立即遷移。穩定運作的完整設定，比欄位缺失的新組合更可靠。

兩者的相容與遷移界線

VMess 與 VLESS 不是修改節點類型下拉選單就能互相轉換的格式。伺服器必須設定對應的入站協定，用戶端中的使用者識別碼、傳輸層與安全層也要相互匹配。把 VMess 分享連結中的協定標頭改成 VLESS，或只在圖形介面切換協定類型，都不會自動產生可用節點。遷移必須由伺服器設定與訂閱內容共同完成。

訂閱轉換環節還可能將舊欄位對映為新欄位。例如某些歷史 VMess 資料中的安全欄位、偽裝類型或路徑表達方式，在不同訂閱格式中的命名並不相同。匯入後應開啟節點編輯介面逐項核對，而不是只確認節點是否出現在清單中。節點能顯示只代表解析器識別了基本記錄，不表示所有進階欄位都已保留。

三、Trojan、Shadowsocks 與 REALITY 的界線

Trojan：驗證簡潔，但仰賴完整的 TLS 設定

Trojan 採用較直觀的密碼驗證結構，通常運作於 TLS 連線之上。它將安全傳輸交由成熟的 TLS 實作處理，自身負責代理要求與身分確認。節點欄位看起來往往比複雜的 VMess 組合精簡，但真正決定連線能否建立的，仍是位址、連接埠、密碼、伺服器名稱、憑證相關設定與傳輸選項。密碼正確而伺服器名稱錯誤時，連線仍可能在 TLS 握手階段中止。

Trojan 適合伺服器已正確設定 TLS，且用戶端能正確傳遞伺服器名稱的環境。它的基本模型容易理解，訂閱格式也相當常見。需要注意的是，不同實作可能進一步疊加 WebSocket、gRPC 等傳輸方式；此時 Trojan 不再只是「位址、連接埠和密碼」三項。路徑、服務名稱、Host 與 ALPN 等欄位都可能成為相容條件。匯入後若節點存在卻無法連線，應先與原始訂閱欄位逐項比對。

從效能角度來看，Trojan 的協定封裝相對直接，但首次 TLS 握手仍有運算與往返成本。長連線建立後，這部分成本會由後續資料傳輸分攤；頻繁建立短連線時，握手次數更容易影響回應速度與耗電。因此不能只根據單次測速判定它一定快於 VMess 或 VLESS。應用程式是否重複使用連線、網路是否頻繁切換，也會改變結果。

Shadowsocks：輕量資料轉送與方法相容性

Shadowsocks 常簡稱為 SS，設計目標偏向輕量轉送，設定核心通常由伺服器、連接埠、密碼與加密方法構成。相較於包含多層組合欄位的節點，它更容易由各種用戶端與訂閱格式表達，也適合資源較有限的裝置。不過「欄位少」不代表可以忽略相容性：用戶端與伺服器必須支援相同的加密方法，舊版與新版實作對方法清單的涵蓋範圍可能不同。

如果訂閱匯入後加密方法被替換、留白或顯示為不支援，節點通常無法靠重新測速自行恢復。應檢查目前核心是否實作該方法，並確認訂閱轉換過程沒有把方法名稱改寫成其他拼法。外掛式擴充也會增加額外參數，這類設定不能只保留基本 SS 欄位。v2rayN、v2rayNG 與 v2flyNG 都能處理常見 SS 節點，但具體方法與擴充能力仍取決於隨用戶端運作的核心。

SS 在協定處理上的開銷通常較低，適合連線數量不高、設定結構明確的日常使用。實際吞吐量仍由線路、加密方法、裝置處理器與伺服器負載共同決定。在低階 Android 裝置上，選擇核心原生支援且計算成本合適的方法，可能比更換節點名稱帶來更明顯的收益。不要在用戶端中任意修改加密方法，因為該參數是伺服器約定的一部分。

REALITY 是安全層組合，不是獨立代理協定

REALITY 經常與 VLESS 一起出現，因此容易被當成與 VMess、Trojan 並列的協定。更準確的理解是：它負責特定的握手與安全層邏輯，VLESS 等協定仍負責代理工作階段。一個 REALITY 節點通常還需要伺服器名稱、公鑰、短識別碼、指紋以及可能存在的流量控制參數。這些欄位彼此相關，缺少其中一項時，用戶端可能無法完成握手。

REALITY 相關能力主要由 Xray 核心提供，因此 v2rayNG，以及以 Xray 為核心執行選項的 v2rayN，更適合處理這類節點。採用 v2fly 核心的 v2flyNG 不應被假定具備相同的欄位支援。即使訂閱解析器能讀取節點標題，儲存時也可能捨棄核心無法識別的欄位。判斷相容性時，應查看節點編輯頁面是否存在相應的安全方式與參數，而不是只觀察清單中是否出現「REALITY」字樣。

伺服器名稱與目標位址的意義也不能混用。節點連線位址決定用戶端要向哪裡建立網路連線，伺服器名稱則參與握手參數，兩者可能是不同欄位。公鑰不是使用者識別碼，短識別碼也不是連接埠的附加值。複製設定時應維持欄位位置，不要將它們拼接進位址或備註。指紋欄位應使用伺服器設定支援的值，用戶端預設值並非適用於所有節點。

四、如何比較連線速度、吞吐量與資源使用量

連線速度由多個階段組成

使用者感受到的「開啟速度」通常包含網域名稱解析、到伺服器的網路往返、TCP 建立連線、安全握手、協定驗證、伺服器連往目標，以及首位元組回傳等階段。VMess、VLESS、Trojan、SS 的協定處理只佔其中一部分。若節點距離較遠或線路擁塞，節省少量封裝處理時間不會顯著改變整體回應；線路條件相近時，握手方式與連線重用才較容易呈現差異。

用戶端的延遲測試也未必涵蓋所有階段。一般 Ping 可能只測到位址的網路往返，真實連線延遲通常會實際建立代理連線，下載測速則同時受到出口頻寬、測試目標與持續傳輸能力影響。因此出現「Ping 較低但網頁回應普通」或「真實連線延遲偏高但下載穩定」的情況並不矛盾。篩選節點時應依用途選擇指標：瀏覽關注首次連線與回應，持續傳輸關注穩定吞吐量，即時應用則更重視抖動與丟包。

比較協定時應控制變因。使用同一用戶端、同一裝置、同一網路、相近地區與伺服器負載，在短時間內進行多次測試，才能減少偶然波動。如果兩個節點同時更換了協定、伺服器地區與傳輸方式，結果便無法歸因於協定。實際選擇不需要實驗室等級的精確度，但至少應避免將線路差異誤判為 VLESS 或 Trojan 的固有優勢。

傳輸封裝可能比應用協定更影響吞吐量

TCP 直連式傳輸的結構通常較直接；WebSocket 會增加框架封裝並依賴 HTTP 升級流程；gRPC 基於 HTTP/2，具備自己的串流與連線管理機制。不同傳輸方式在伺服器部署、連線重用、標頭開銷及中間網路設備相容性方面各有取捨。對大型檔案的持續傳輸而言，少量標頭開銷通常不是唯一瓶頸；對大量短請求來說，握手與重用策略可能更重要。

傳輸方式也會影響記憶體與處理器負載。連線數增加時，每條連線對應的緩衝區、協定狀態與加密內容都會佔用資源。WebSocket 或 gRPC 不一定較慢，但其實作路徑比簡單 TCP 更長，效能更仰賴用戶端與伺服器的實作品質。在資源有限的裝置上，減少不必要的多層封裝通常較容易取得穩定表現。

UDP 業務需要另外觀察。部分協定與傳輸組合能轉送 UDP，但實際行為可能是原生資料報處理，也可能透過其他連線承載。遊戲、語音與 DNS 查詢對丟包、抖動與隊頭阻塞較敏感，僅憑 TCP 下載速度無法預測 UDP 體驗。用戶端啟用 TUN 模式後，系統流量的進入方式也會改變，路由規則、DNS 策略與核心處理鏈都會納入測量結果。

資源使用量應觀察穩定區間，而非啟動瞬間

核心啟動時會讀取設定、建立路由規則，並初始化 DNS、日誌與連線管理模組，此時短暫的處理器使用量沒有代表性。更有意義的做法是在設定相同、應用程式活動相近時觀察一段穩定運作區間，分別記錄閒置、網頁瀏覽與持續傳輸三種狀態。記憶體使用量也應區分常駐記憶體、連線緩衝與系統快取，單一瞬間數值很難說明協定效率。

日誌層級會影響資源消耗。排錯時開啟詳細日誌有助於定位握手、DNS 與路由問題，但長期維持高詳細度會增加寫入與格式化工作。日常使用可選擇 warning 或 error 等較精簡的層級，需要排查時暫時提高，確認問題後再恢復。節點數量很多時，批次測速與訂閱更新也會製造短時間高峰，這與目前連線協定的穩定使用量不同。

五、Android 端耗電與背景連線表現

耗電來自持續喚醒，不只是加密運算

在 Android 上執行 v2rayNG 或 v2flyNG 時，耗電由多個環節共同造成：核心處理資料、虛擬網路介面轉送流量、應用程式維持前景服務、系統網路切換、DNS 查詢、日誌寫入，以及其他應用程式的背景要求，都會觸發處理器與無線模組。協定加密只是其中一項。即使節點處於「已連線」狀態，若沒有應用程式產生流量，其耗電模式也與持續播放影片、檔案同步或大量通知完全不同。

行動網路與無線區域網路的耗電特徵也不同。訊號較弱時，無線模組可能需要更高的發射功率，並在網路狀態變更後反覆重建連線。此時頻繁握手帶來的成本會被放大。移動過程中，網路位址切換、休眠恢復與連線失效都可能讓用戶端重新建立通道。在固定無線網路下表現穩定的協定組合，不一定能在頻繁切換網路時維持相同耗電量。

長連線通常有助於減少重複握手，但需要依靠心跳或系統維持機制來保持。心跳過於頻繁會增加喚醒次數，間隔過長又可能被網路設備清理連線，之後觸發重新連線。使用者很少需要手動調整底層心跳；更實際的做法是選擇穩定節點、減少頻繁切換、避免背景批次測速，並讓用戶端使用核心與系統建議的預設連線參數。

協定與傳輸方式對耗電的相對影響

在相同線路條件下，處理路徑較短、重新建立連線次數較少的組合，通常更有利於控制耗電量。VLESS 將安全職責交給外層機制，SS 的基本結構也較輕量，但最終耗電仍取決於 TLS 或 REALITY 握手、傳輸封裝、應用程式連線數量與網路穩定性。VMess 的工作階段處理較完整，不代表它在所有裝置上都會明顯耗電；如果 VMess 節點穩定，而另一個輕量協定節點持續重新連線，前者反而可能更省電。

WebSocket 與 gRPC 會各自引入協定處理與連線管理。對現代裝置而言，正常流量下的差異可能很小；在低效能裝置、大量並發短連線或長時間背景執行時，額外封裝更容易產生可觀察的變化。TUN 模式還會讓更多系統流量進入用戶端，包括原本不經過手動代理連接埠的應用程式要求。若切換至 TUN 後耗電增加，應先檢查是否有背景應用程式持續連網，再判斷是否與協定有關。

DNS 設定同樣重要。解析失敗、結果無法連線或規則造成重複查詢時，用戶端與應用程式可能反覆嘗試連線。表面上看是代理用戶端持續活躍，根本原因卻可能是 DNS 或路由規則。排查時可暫時簡化規則，使用穩定節點，並觀察系統耗電頁面中哪些應用程式持續產生流量。不要只根據用戶端在耗電清單中的占比下結論，因為虛擬網路服務可能被系統計入更多轉送活動。

建立可重複的耗電比較方法

比較 v2rayNG 與 v2flyNG，或比較兩種協定時，應盡量維持螢幕亮度、網路類型、背景應用程式與使用時間一致。先讓裝置的充電狀態穩定，關閉批次更新與測速，再分別觀察待機、輕度瀏覽與持續傳輸。短短幾分鐘的電量百分比變化精度有限，較適合結合系統耗電曲線、前景活動與發熱情況綜合判斷。

若某個節點在鎖定螢幕後經常斷線，首先檢查 Android 對應用程式背景執行的限制、前景服務狀態與網路切換情況。接著查看用戶端日誌中是否反覆出現連線逾時、DNS 錯誤或握手失敗。如果問題集中發生在網路恢復後，可能是連線重建問題；如果在固定網路中持續發生，則應核對節點欄位與伺服器可用性。相關通用排查步驟可在常見問題中繼續查閱。

日常最佳化可以從減少無效工作開始：依需要執行訂閱更新，不讓用戶端持續循環測速；節點清單過大時使用分組或篩選；排錯結束後恢復一般日誌層級；只有確實需要全域接管時才啟用 TUN；選擇重新連線次數少、真實連線測試穩定的節點。協定名稱本身不是耗電開關，穩定鏈路與合理流量範圍通常更關鍵。

六、V2Fly 與 Xray 核心家族及設定相容性

Project V 生態與兩個核心方向

Project V 是由代理協定、核心程式、設定體系與用戶端工具共同形成的開源生態。「V2Ray」一詞有時指整個技術體系，有時特指某個核心實作，因此討論相容性時應明確說明是在討論協定、設定格式，還是具體核心。V2Fly 延續 V2Ray 的社群維護方向，重視既有協定與設定生態；Xray 則在相近的設定模型上持續擴充功能，並提供 VLESS、REALITY 等相關能力。

兩者具有共同歷史與許多相似概念，但不能視為兩個名稱不同、能力完全相同的程式。基本的入站、出站、路由、DNS 與日誌結構有不少共通之處，但具體協定欄位、傳輸選項、安全設定與預設行為可能不同。設定檔能被另一個核心解析，不代表每一項都會以相同方式運作；反過來，解析失敗也不一定表示整套設定體系不相容，可能只是包含另一核心專有的欄位。

圖形用戶端進一步增加了一層對映。v2rayN 負責將介面、訂閱與系統代理操作轉換為核心設定；v2rayNG 主要以 Xray 核心能力為基礎；v2flyNG 則對應 v2fly 核心。使用者在介面中看到的是節點與開關，實際連線行為則由產生的設定與底層核心共同決定。排查時應區分「訂閱未解析欄位」、「介面未提供選項」與「核心不支援該能力」這三種情況。

共用設定骨架與專有欄位

兩類核心通常都採用 JSON 設定，並圍繞日誌、入站、出站、DNS、路由等部分組織。以下最小範例會建立本機 SOCKS 入站，並透過自由出站直接存取，用於驗證設定檔結構、監聽連接埠與核心啟動流程。它不包含遠端節點，也不能取代用戶端產生的日常設定。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

在已正確安裝 Xray 並將上述內容儲存為 config.json 後，可以從終端機執行以下指令，檢查設定是否能夠啟動。若連接埠已被其他程式占用，應先關閉衝突程式或變更監聽連接埠。圖形用戶端正常使用時通常不需要手動執行此指令。

xray run -config config.json
curl --proxy socks5h://127.0.0.1:10808 https://example.com/

真正的 VLESS、VMess、Trojan 或 SS 出站還會加入伺服器清單、使用者識別碼、密碼、加密方法與流量設定。REALITY 相關欄位屬於需要特別核對的擴充能力；若將包含這些欄位的 Xray 設定直接交給不支援它們的核心，可能在啟動時回報未知欄位，也可能由上層轉換工具提前刪除。面對跨核心設定，不應只檢查 JSON 語法，還要逐項確認協定語義。

設定相容不等於訂閱相容

核心設定檔與訂閱檔案解決的是不同問題。核心設定描述程式如何監聽、路由與連線；訂閱主要傳遞節點記錄，再由用戶端產生完整的核心設定。一個用戶端可能支援某種分享連結，卻不提供匯入整份核心 JSON 的功能；也可能允許匯入核心設定，卻無法將其中所有欄位轉換成可編輯節點。因此，「Xray 能執行」不能直接推論為「任何訂閱用戶端都能匯入」。

v2rayN 適合在桌面端進行節點管理、訂閱更新、路由選擇與系統代理切換。v2rayNG 更適合在 Android 上使用 Xray 相關協定。v2flyNG 則是 V2Fly 路線的另一個選擇。三款用戶端可透過訂閱連結或單節點分享資訊同步常見設定，但複雜路由、DNS 規則、核心專有欄位與用戶端介面偏好通常無法完整互換。多裝置同步的具體方法可參考訂閱連結、設定匯出與 QR Code 分享。

遇到核心差異時的排查順序

首先記錄節點原始協定及所有安全、傳輸欄位；其次確認目前用戶端實際使用的核心家族；接著開啟節點編輯介面檢查欄位是否存在；最後查看執行日誌，判斷錯誤發生在解析、啟動、握手還是傳輸階段。若匯入後某個欄位根本沒有對應入口，通常屬於用戶端或核心的能力界線，而不是網路延遲問題。此時應改用支援該設定的用戶端，不應靠猜測刪除關鍵欄位。

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

訂閱是節點容器，不是統一的設定標準

「訂閱連結」描述的是用戶端取得一組節點資料的入口，但回傳內容可能採用不同的組織方式。常見情況包括多行分享連結、經過編碼的文字、結構化節點清單，以及用戶端專用格式。用戶端首先要識別外層格式，再解析每筆節點記錄，最後將欄位對映至核心設定。任何一層不相容，都可能造成訂閱更新失敗、節點數量異常或進階參數遺失。

VMess 分享資料通常包含較多結構化欄位；VLESS、Trojan 與 SS 常見為 URI 形式，並透過查詢參數表達傳輸與安全選項。URI 能被識別，不代表目前用戶端一定支援其中的參數名稱。特別是 REALITY 公鑰、短識別碼、指紋、流量控制，以及 gRPC 服務名稱、WebSocket 路徑與 Host 等欄位，容易在舊版解析器或格式轉換過程中遺失。

節點備註通常只用於顯示，不參與連線。修改備註不會改變協定，但依備註自動分組的規則可能受到影響。相反地，位址、連接埠、使用者識別碼、密碼、加密方法、伺服器名稱與安全參數都屬於連線欄位，不能為了讓介面更整齊而刪除。匯入異常時，應保留原始訂閱作為對照，不要連續手動修改多個欄位，否則很難判斷是哪項變更造成結果差異。

匯入成功與連線成功是兩個檢查階段

訂閱更新後出現節點，只代表用戶端完成了基本解析。接下來應檢查節點類型是否正確、傳輸與安全方式是否匹配、關鍵輸入欄位是否有值，然後再執行真實連線測試。若所有節點都未匯入，優先檢查訂閱位址是否可存取、內容是否為空，以及用戶端是否選錯訂閱類型；若只有某一類協定缺失，則更可能是格式或核心能力問題。

節點存在但全部連線失敗時，先判斷是否有共同欄位，例如相同的伺服器名稱、傳輸方式或核心專有設定。只有個別節點失敗時，則檢查其位址、連接埠與使用者資訊。把所有失敗都歸因於訂閱位址，會掩蓋節點層級的錯誤。反過來，訂閱更新報錯時不斷切換節點也沒有作用，因為更新流程尚未進入節點連線階段。

訂閱更新還涉及覆蓋規則。某些用戶端會依訂閱分組取代舊節點，手動修改的訂閱節點可能在下一次更新時還原；另一些情況則會保留本機節點並新增記錄，因而產生重複項目。需要長期自訂參數時，可先了解用戶端的更新行為，再決定保留獨立手動節點，或修改訂閱來源。v2rayN 匯入訂閱的基本步驟請參閱快速入門主線。

跨用戶端同步要接受能力交集

從 v2rayN 同步至 v2rayNG 時，常見節點協定與基本欄位通常可透過同一訂閱保持一致，但桌面端的系統代理設定、路由規則群組、程序比對與介面偏好不會自然出現在 Android。反向同步也是如此，Android 的應用程式選擇與背景服務設定不屬於節點訂閱。訂閱適合維護伺服器連線資訊，不適合承擔所有裝置設定的備份工作。

v2rayNG 與 v2flyNG 的差異主要來自核心能力。包含 REALITY 的訂閱可能被 v2rayNG 完整識別，卻無法在 v2flyNG 中形成相同的設定。此時不應嘗試將 REALITY 降級成一般 TLS，因為兩者不是可以任意互換的開關。更合理的做法是為不同核心提供其支援的節點類型，或在 Android 上選擇與訂閱能力相符的用戶端。

QR Code 分享本質上通常是將單一節點 URI 以視覺方式編碼，受限於單筆記錄長度與用戶端解析能力。它適合臨時傳遞少量節點，不適合取代長期訂閱更新。設定檔匯出可能包含更完整的路由與 DNS 資訊，但跨用戶端匯入時，專有結構更容易產生不相容。選擇同步方式時應先明確目標：只同步節點使用訂閱，臨時分享單一節點使用 QR Code，需要保留完整進階設定則使用用戶端本身支援的匯出方式，並在目標裝置逐項複核。

八、依使用情境選擇協定與用戶端

桌面日常使用：先選用戶端，再選完整節點

Windows、macOS 與 Linux 桌面環境優先使用 v2rayN。它適合管理訂閱、切換系統代理、編輯節點並查看連線日誌。在協定選擇上，如果訂閱同時提供 VLESS、VMess、Trojan 與 SS，先排除欄位不完整或核心不支援的節點，再對剩餘節點進行真實連線與實際存取測試。新設定可優先測試 VLESS 搭配明確的安全層；已有穩定 VMess 或 Trojan 節點則可繼續使用。

桌面裝置的處理器與記憶體通常較充足，協定之間些微的處理開銷往往不是首要問題。更應關注連線穩定性、伺服器負載、傳輸方式與路由設定。需要程序分流或全域接管時，TUN 模式會改變流量入口，應先記錄目前的系統代理與路由選項，再逐步啟用。若切換 TUN 後只有部分應用程式異常，優先檢查 DNS 與路由，不要立即更換協定。

下載大型檔案或持續傳輸時，選擇吞吐量穩定、抖動較小的節點，不必追求單次最低延遲。辦公網頁與互動式應用程式更重視首次回應，可優先比較真實連線延遲與實際開啟速度。協定名稱相同的節點仍應分別測試，因為伺服器地區與線路差異通常大於封裝差異。

Android 日常連線：關注背景穩定性與核心匹配

在 Android 上需要 VLESS、REALITY 或其他 Xray 能力時，使用 v2rayNG；主要處理 VMess、SS 等 V2Fly 相容設定時，可選擇 v2flyNG。裝置資源有限或需要長時間在背景執行時，優先選擇重新連線少、欄位簡單且核心原生支援的組合。理論上較輕量的協定若不斷握手失敗，也不會帶來耗電優勢。

行動網路經常切換時，應觀察節點能否在網路恢復後正常重新連線。若特定節點只在無線區域網路可用，或切換至行動網路後持續失敗，應分別檢查位址解析、傳輸方式與伺服器可達性。不要一次修改協定、安全層與 DNS 三組設定；每次只改變一個變因，並記錄日誌中的錯誤階段。

裝置發熱或待機耗電明顯時，先暫停批次測速與頻繁訂閱更新，檢查背景應用程式流量，再比較協定。TUN 會擴大接管範圍，可能讓更多應用程式要求經過核心。只需少量應用程式連線時，可依用戶端能力選擇較小的應用範圍，從源頭減少不必要的轉送。

舊訂閱與長期設定：穩定優先，遷移需整套完成

舊訂閱中常見 VMess 與 SS。如果節點仍能完整匯入且連線長期穩定，繼續使用通常比手動改成 VLESS 更可靠。協定遷移必須由伺服器、訂閱與用戶端共同完成，不能只改變本機節點類型。計畫遷移時，先保留原節點作為對照，再匯入伺服器提供的新節點，分別測試後再調整分組。

若訂閱轉換工具只能輸出基本欄位，複雜的 WebSocket、gRPC、TLS 或 REALITY 參數可能遺失。此時應減少中間轉換環節，讓支援目標格式的用戶端直接讀取訂閱。節點備註、分組名稱與排序可之後整理，連線欄位則應保持原樣。訂閱更新失敗的進一步排查可參閱FAQ 分類說明。

低資源裝置與高並發情境

低資源 Android 裝置可優先測試結構較直接、核心成熟支援的 SS、VLESS 或現有穩定協定，但不能脫離伺服器條件指定唯一答案。應減少節點總量、關閉持續詳細日誌，並避免同時進行批次測速與大量傳輸。若記憶體使用量隨連線數明顯增加，應檢查應用程式是否建立大量短連線，以及 TUN 是否接管了不必要的背景流量。

在高並發情境中，連線重用、伺服器檔案描述元、緩衝區與路由規則複雜度，都可能比協定封裝更重要。WebSocket、gRPC 與一般 TCP 的連線管理方式不同，應結合伺服器部署進行測試。單一使用者日常瀏覽得出的結論，不能直接套用到大量並發連線。對長期運作的裝置而言，穩定區間、錯誤率與重新連線次數，比瞬時峰值速度更值得記錄。

最終決策表與驗證閉環

完成選擇後，應建立簡單的驗證閉環：記錄用戶端與核心家族，保存節點的協定、傳輸與安全方式；執行多次真實連線測試；使用實際應用程式驗證回應與持續傳輸；觀察一段穩定運作期間的日誌與資源使用量；最後再決定是否設為預設節點。遇到問題時，從最近一次變更回復，避免同時替換協定、用戶端與網路環境。

如果多個節點表現相近，選擇設定較清楚、訂閱更新穩定且目前用戶端完整支援的一個即可。沒有任何協定能在所有平台、網路與伺服器條件下始終佔優。協定選擇的目標是降低相容性風險，讓連線行為可解釋、可重現，而不是追逐脫離環境的理論排名。