V2Ray 協定指南
協定類型與核心選型

01 · 協定分層與 VMess

節點名稱並非完整的連線設定

客戶端中的一筆伺服器設定，通常包含伺服器位址、連接埠、代理協定、傳輸方式、傳輸安全與驗證憑證。協定負責標示目標、驗證使用者及組織請求；傳輸決定資料如何送達；安全層則負責連線身分與傳輸保護。訂閱備註可能只列出協定名稱，但實際連線仰賴整組參數。只把下拉選單從 VMess 改成 VLESS，無法將原有服務轉換成另一種協定。

排查前，先把設定分成三層記錄：出站協定、底層傳輸與安全設定。例如 VMess 可搭配 WebSocket 和 TLS；VLESS 可搭配直接傳輸和 REALITY。即使兩筆設定的位址相同，也可能由不同連接埠或入口接收。頁面中的組合僅用於說明結構，實際能否使用仍取決於伺服器設定。客戶端會依約定發起連線，無法自動補足遠端不具備的能力。

VMess 的設計背景與驗證特性

VMess 是 Project V 早期建立代理體系時採用的核心協定之一，會在協定層處理使用者驗證與代理請求封裝，並可搭配不同傳輸方式。它不是單純的通訊端轉發格式，也不等同於某種外層加密連線。理解這點有助於說明：名稱同為 VMess 的設定，在握手流程、外層保護、連線多工與網路行為上可能大不相同，不能只看名稱推斷實際效能。

現代 VMess 設定應採用支援 AEAD 驗證的實作。舊資料提到的額外識別碼數量與舊式驗證流程，不應直接套用到新設定。若客戶端仍顯示 alterId 等歷史欄位，請確認訂閱來源與核心說明；現代設定常使用零值。這裡的驗證方式與負載加密演算法並非同一概念，不能把安全性下拉選單中的演算法選項，當成驗證世代的證明。

系統時間會實際影響 VMess 的驗證流程。裝置長時間休眠、手動調整時間或時間同步失效，都可能導致位址與憑證正確的設定仍遭拒絕。先分清時區顯示與實際時間：介面時區不同不一定有問題，真正需要處理的是系統時鐘偏差。排查時先恢復系統自動校時，再重新連線，避免把時間錯誤誤判為伺服器故障或協定不相容。

欄位檢查順序與適用範圍

匯入後先檢查位址、連接埠與使用者識別碼，再檢查傳輸類型，最後確認 TLS、伺服器名稱與傳輸路徑。使用者識別碼屬於驗證資料，應完整保留，但不要出現在公開截圖中。傳輸路徑不是本機檔案路徑；WebSocket 的 Host 也不一定是伺服器位址。這些欄位可能用於比對遠端入口，看似重複也不能任意刪除，更不要把所有網域欄位都換成解析出的位址。

VMess 的負載加密選擇取決於核心實作、處理器能力與伺服器設定。具硬體加速功能的處理器可能更適合某些演算法；行動裝置的實際表現也會受系統排程影響。自動選擇通常適合作為基準；只有在雙方明確支援且測試結果可重現時，才值得手動指定演算法。關閉某一層負載加密，不代表整條連線已獲得其他層的保護；外層安全仍須另外確認。

已有穩定的 VMess 設定時，不必只為了更換名稱而移轉。若需要新功能，先確認現有核心是否支援，再向設定提供者取得完整的新入口。比較移轉前後的表現時，應盡量維持裝置、網路、目標與測試時段一致。否則，遠端入口變動造成的差異很容易被誤認為是協定本身所致，最後只留下難以重現的速度結論。

02 · VLESS 與 REALITY

輕量協定不代表省略傳輸保護

VLESS 在 V2Ray 生態系中以精簡驗證與請求封裝為設計方向。相較於 VMess，它不在基礎協定層負責相同的負載加密工作，而是仰賴搭配的傳輸安全方案保護連線。因此，「協定較輕」指的是職責劃分，不代表可以在任何網路上直接以明文傳輸。常見 VLESS 設定中的 encryption 為 none，代表該欄位的協定設定，並不表示整條連線沒有安全層。

在客戶端選擇 VLESS 後，還要確認遠端使用 TLS、REALITY 或其他明確支援的組合。安全性下拉選單不能依個人偏好切換，因為遠端握手入口必須採用相同方案。使用者識別碼相同，也不足以證明兩個入口可以互換。如果匯入工具將未知的安全類型降為預設值，畫面上看似仍建立了伺服器設定，實際握手卻可能已偏離原始設定，應立即回到參數頁重新核對。

REALITY 是安全方案，不是獨立的代理協定

REALITY 是 Xray 生態系中的傳輸安全方案，常與 VLESS 搭配使用。它改變的是安全握手及其驗證方式，不會取代代理協定中的目標位址與使用者請求語意。訂閱中的「REALITY 節點」通常只是整組連線設定的簡稱。選型時仍須確認基礎協定、傳輸方式與流量控制設定，而不是在協定清單中尋找可取代 VLESS 的 REALITY 類型。

相較於常見的憑證部署流程，REALITY 使用本身的驗證參數與握手機制。客戶端通常需要伺服器名稱、公鑰相關驗證參數、短識別碼，以及實作所要求的客戶端指紋。公鑰不是客戶端使用者識別碼，短識別碼也不是任意備註。不同客戶端與核心可能使用不同欄位名稱，請依匯入來源及目前的實作對照檢查，不要只看欄位位置照抄舊教學。

伺服器名稱會參與握手與身分驗證相關流程，通常必須符合伺服器允許的範圍。它不必與連線位址的文字完全相同，但也不能任意換成其他網域。連線位址決定客戶端要先連到哪裡，伺服器名稱則影響安全握手的建構與驗證方式。若把兩者都當成「網域」來理解，排查方向就會混亂；位址可連線但驗證失敗，正是應分層檢查的典型情況。

Vision、指紋與傳輸方式的搭配限制

XTLS Vision 通常透過 flow 欄位設定，常見值為 xtls-rprx-vision。它負責特定連線組合中的資料流處理，不是填入後就會變快的通用加速開關。是否啟用取決於伺服器、核心與傳輸組合。尤其不要把適用於直接傳輸的設定，照搬到 WebSocket 等承載方式；若設定提供者沒有指定流量控制，就不要只因為另一筆設定有這個值而自行加上。

客戶端指紋會控制部分 TLS 客戶端握手特徵，但不代表已安裝對應瀏覽器，也不保證所有應用程式行為都會隨之改變。指紋選項需要核心支援；名稱相同的介面控制項也可能由不同實作處理。遇到連線失敗時，先還原訂閱中的原始值，再查看記錄中的安全層錯誤，判斷是否為指紋不受支援、驗證參數錯誤或伺服器名稱不符。

需要 REALITY 或 Vision 時，Android 端優先確認 v2rayNG 所附 Xray 的支援情況；桌面端則在 v2rayN 中確認實際啟用的核心。已有 VLESS 設定但缺少關鍵驗證參數時，應重新取得完整分享內容，而不是自行猜測。實作家族的進一步差異請見核心家族章節；協定名稱相同，只能作為相容性檢查的起點。

03 · Trojan 與 Shadowsocks

Trojan：以 TLS 承載驗證與代理請求

Trojan 的設計會在 TLS 連線中處理代理驗證與請求，常見設定以密碼作為使用者驗證資料。它的特點是協定層與外層安全界線相對明確：先建立符合設定的 TLS 連線，再交換代理請求。選擇 Trojan 並不代表憑證問題會自動消失。伺服器名稱、憑證信任鏈與裝置時間仍須正確，任何一項異常都可能在代理驗證開始前中斷連線。

標準 Trojan 連線通常不需要填寫類似 VMess 的使用者識別碼。若從其他協定複製設定後保留了不相關欄位，客戶端可能忽略它們，也可能產生錯誤設定。建議新增相應協定的設定項目，再依原始分享內容填入密碼、位址、連接埠與安全參數。密碼含有特殊字元時，手動拼接分享連結容易造成跳脫錯誤，請優先使用客戶端提供的匯入與匯出功能。

憑證驗證失敗時，不要把略過驗證當成常規處理方式。先確認連線位址與伺服器名稱是否混淆，再檢查系統時間、憑證有效期限、憑證鏈，以及遠端是否確實提供 TLS。允許不安全連線會改變身分驗證的界線，可能導致錯誤端點也被接受。若僅為釐清原因而暫時調整，請明確記錄並及時還原；長期設定應解決驗證失敗的根本原因。

Shadowsocks：加密方法與金鑰共同決定相容性

Shadowsocks 常簡稱為 SS，設計上採用相對精簡的加密代理封裝。它與 VMess、Trojan 的驗證方式及資料組織不同，不能只因密碼欄位相似就判定相容。設定 SS 時，至少要確認伺服器位址、連接埠、加密方法及密碼或金鑰。方法名稱是協定約定的一部分，不是客戶端可自行更換的偏好設定；雙方必須使用相符的演算法與金鑰解讀方式。

較早期的串流加密方法、後續的 AEAD 方法，以及 Shadowsocks 2022 系列，各有不同的設計與設定要求。現代部署通常應優先考慮目前實作仍支援的 AEAD 方案，但「支援 SS」不等於支援所有世代。尤其較新的方法可能要求特定格式與長度的金鑰，不能隨意填入短密碼，再期待核心自動轉換成相容值。具體格式請以遠端方法說明為準。

SS 分享連結也有多種歷史編碼方式。有些會將方法與密碼一併編碼，有些則將驗證資料獨立編碼，後面還可能附帶備註或外掛參數。匯入失敗時，先確認連結完整，且未被聊天軟體截斷，再判斷是否使用了目前客戶端不支援的擴充格式。反覆解碼後隨意重新拼接，往往會破壞特殊字元與分隔符號，造成新的錯誤。

不要把額外封裝視為協定預設功能

部分 SS 設定仰賴額外外掛或特定外層封裝。原始協定支援與外掛支援是兩種不同能力；圖形客戶端能辨識方法名稱，不代表已具備相應的外掛執行環境。本手冊不將其他客戶端列入推薦清單。遇到需要額外元件的分享內容時，先確認 v2rayN、v2rayNG 或 v2flyNG 的目前實作能否完整支援，再決定是否保留該設定。

UDP 是另一條需要個別確認的路徑。協定規範允許轉發 UDP，不代表訂閱入口、遠端服務、客戶端模式與本機應用程式都已啟用。網頁能正常瀏覽，只能證明部分 TCP 請求可用，無法保證即時影音或其他資料封包服務正常。特定應用程式發生故障時，請檢查是否發生回退、目標連接埠是否受支援，以及路由規則是否將兩類流量導向不同出站。

若已有完整且相容的設定，Trojan 適合希望沿用常見 TLS 維運方式的入口；SS 則適合已有相應部署且清楚掌握方法要求的情境。兩者都不能只因封裝看起來較少，就判定速度較快。若要更換協定，應取得遠端為新協定實際開放的入口，而不是保留原連接埠、只修改客戶端類型。

04 · 連線速度、資源與行動裝置耗電

分開比較首次請求與持續傳輸

單次存取耗時可能來自網域解析、連線建立、安全握手、代理驗證或目標回應，協定只會影響其中一部分。短連線較多的應用程式對握手成本較敏感；大檔案傳輸則更容易受連線頻寬、壅塞控制與遠端出口限制。比較協定前，先明確界定測量的是頁面載入、首次回應還是持續傳輸量；把這些指標混成單一速度數值，無法判斷問題出在哪一層。

外層傳輸可能增加請求或握手，也可能透過連線重用減少後續負載。啟用 TLS、採用 WebSocket 或使用支援多串流的傳輸方式，都沒有固定的速度排序。網路往返時間較長時，額外往返的影響可能更明顯；連線已重用時，單次新請求則可能不必重新負擔完整的初始化成本。因此，同一設定首次載入與連續重新整理的體驗，不能直接互相取代。

持續傳輸時的處理器負載，取決於演算法實作、硬體加速、緩衝區處理與資料複製等因素。即使使用相同協定，桌上型處理器與行動晶片也可能有不同瓶頸。只有在處理器確實持續繁忙、連線仍有餘裕時，才適合討論加密或封裝負載。若所有設定都在相近位置停滯，應先檢查網路與遠端資源，而不是繼續輪流更換協定名稱。

Mux 並非通用效能開關

Mux 會將多個邏輯連線放進較少的承載連線中，可能降低頻繁建立連線的成本，也可能讓多個請求共同承受同一連線的阻塞。實際效益取決於協定、傳輸方式、核心實作與業務類型。某些組合本身已具備多串流機制，再額外套用傳統 Mux 未必有幫助；部分流量控制方案也有搭配限制。測試時先使用原始設定，再一次只調整一項多工設定。

行動裝置耗電不只來自加密運算。VPN 服務持續執行、應用程式在背景輪詢、網域解析重試與網路切換，都可能喚醒處理器或無線模組。若客戶端耗電增加的同時，其他應用程式也大量使用網路，應先觀察流量來源。某個應用程式經由代理連線時，它觸發的部分網路成本可能計入 VPN 服務，不能直接把系統統計中的所有耗電都歸因於協定效率。

背景限制、連線保活與網路切換

電池最佳化限制過嚴，可能會終止背景服務，導致連線中斷後反覆重建；完全解除限制，也可能讓不必要的背景執行時間變長。較合適的做法是先確認服務是否真的被系統回收，再為客戶端調整必要的背景權限。不要同時修改系統保活、Mux、DNS 與分應用程式規則。一次調整太多變數，即使耗電下降，也難以判斷是流量減少還是協定設定改善。

從無線區域網路切換到行動網路時，原有連線通常需要重建，解析快取與網路介面狀態也可能改變。此時短暫失敗不一定是驗證錯誤。先等網路穩定，再手動重新連線一次，並記錄錯誤發生在解析、連線還是握手階段。若只在某類網路下失敗，請檢查該網路的位址類型、路徑 MTU 與可達性，避免為了掩蓋連線問題而反覆更換驗證參數。

要進行可重現的比較，需固定裝置、應用程式、目標與網路環境，分別觀察冷啟動存取、連續請求及閒置背景狀態。每輪只更換一項因素，並留足時間讓連線穩定。測試期間避免背景下載、系統更新及其他高負載工作。無須追求一份適用所有人的排名；有用的結論應能回答：在目前裝置與這類業務中，哪組設定減少了失敗、重新連線或持續資源占用。

分應用程式代理可避免不需代理的應用程式經由 VPN 轉送，但也須考慮應用程式之間的跳轉、登入元件與系統服務依賴。只代理主要應用程式、卻漏掉驗證元件，可能造成頁面能開啟但無法登入。效能最佳化應以功能完整為前提。確認服務正常後，再縮小不必要的代理範圍與背景活動，比單純挑選聽起來較輕量的協定更容易維持穩定。

05 · Project V、V2Fly 與 Xray

客戶端介面與核心並非同一層

Project V 是認識 V2Ray 生態系的重要背景。V2Fly 延續 V2Ray 的社群開發，Xray 則從相關程式碼體系分支發展，形成自己的功能方向。兩者共享部分歷史與設定概念，但已不能視為同一程式的不同名稱。協定名稱、JSON 欄位或目錄配置相似，只代表兩者有共同基礎，不表示新功能會同時出現在兩種實作中，也不代表相同設定始終會有相同行為。

圖形客戶端負責訂閱管理、設定編輯、路由選擇與啟動控制等工作；核心則負責實際建立及轉送連線。介面可以提供多種選項，但執行時仍受所選核心限制。輸入框能填值，不代表核心會接受；設定可以儲存，也不代表該項目已傳入最終執行設定。排查時必須同時確認客戶端、核心家族與實際生效的設定，而不只看視窗標題。

三款客戶端的選擇範圍

桌面端首選 v2rayN，提供 Windows、macOS 與 Linux 的安裝入口。它適合作為訂閱、路由與桌面代理管理的整合介面，但不同系統的介面細節與系統整合方式不一定完全相同。涉及協定能力時，應檢查目前啟用的核心實作與實際封裝內容。不能因為另一台裝置上的 v2rayN 能使用某種組合，就推斷目前的安裝版本也具備相同能力。

Android 端的 v2rayNG 採用 Xray 核心，適合需要相應協定組合的設定；v2flyNG 使用 V2Fly 核心，可作為相應實作的替代選項。選擇依據應是現有設定需要哪些能力，而不是因名稱相似就認為可以任意替換。若訂閱明確要求 REALITY 或 Vision，應優先確認 Xray 路徑；若維護的是 V2Fly 設定，則應依 V2Fly 目前的欄位與行為檢查。

兩套核心都具備廣泛使用的協定與傳輸能力，但支援範圍和具體語意會隨實作演進。REALITY 與 Vision 是檢查 Xray 能力時的重要項目，不能把含有這些欄位的出站設定原封不動交給 V2Fly。反過來，V2Fly 特有的傳輸方式或設定結構，也不應預設 Xray 能相容。更換核心時應逐項核對，不要直接覆寫整份檔案後只確認程式能否啟動。

移轉設定時應檢查結構與語意

核心設定通常包含入站、出站、路由、DNS 與記錄等部分。移轉時只複製出站設定，可能漏掉出站標籤引用的路由或 DNS 策略；複製整份設定，又可能帶入本機不存在的監聽位址、連接埠與檔案路徑。應先保留可用的備份，再分模組移轉。即使欄位檢查通過，也要確認目標流量是否進入預期的出站，以及網域解析是否仍由原策略處理。

記錄中的未知欄位、無法辨識的安全類型或不支援的流量控制，都是相容性線索，不應為了消除錯誤而直接刪除欄位。刪除關鍵欄位可能讓程式成功啟動，卻使連線失去原本所需的語意。應先查明該欄位由哪種實作提供，再決定改用相符的核心，或重新取得適用於目前核心的設定。這兩種做法都比盲目刪除欄位更容易維持設定的可理解性。

更新客戶端與更新核心也應分開看待。介面更新可能修正匯入解析問題，核心更新則可能改變協定支援，兩者解決的問題不同。更新前保留訂閱與本機規則，更新後先測試一筆已知可用的設定，再還原複雜路由。若出現回歸問題，應記錄具體階段與欄位，而不只寫「升級後不能用」。若要了解核心家族的詳細關係，請接著閱讀Xray 與 V2Fly 的差異及設定相容性。

06 · 傳輸參數、路由與 DNS

路徑、Host 與伺服器名稱各有用途

傳輸方式決定代理資料如何承載。直接以 TCP 傳輸的連線結構較直觀；WebSocket 會加入 HTTP 升級流程；gRPC 等傳輸則有各自的請求與多串流語意。這些方式不是客戶端可自行決定的裝飾選項，而是遠端接收入口的一部分。伺服器只接受某種傳輸時，本機改用其他方式通常會在驗證前失敗，因此比較效能前，必須先確定對照組合都是真正可用的設定。

WebSocket 路徑用於請求路由；Host 可能參與反向代理的虛擬主機比對；TLS 伺服器名稱則用於安全握手。三者可能相同，也可能依部署需求分別設定。路徑中的大小寫、開頭斜線與特殊字元都應完整保留。若反向代理未將請求轉送到正確後端，即使憑證握手成功，也可能只收到一般網頁或錯誤回應，不能據此判斷代理協定運作正常。

gRPC 常見的服務名稱也必須與遠端相符，不是客戶端中方便閱讀的備註。ALPN 用於安全連線中的應用協定協商；若錯誤地限制候選項，可能導致所需傳輸無法建立。除非部署說明明確要求，否則不要照搬其他節點的 ALPN 清單。排查時應依序檢查位址可達性、安全握手、承載協定與代理驗證，先找出失敗階段，再調整相應欄位。

路由順序會影響協定的使用範圍

選擇某個代理出站，不代表所有流量都會經由它傳送。系統代理、VPN 接管、應用程式自訂代理與核心路由共同決定流量走向。系統代理只會影響遵循相關設定的應用程式；VPN 或虛擬網卡模式的接管範圍較廣，但仍受排除項目與權限限制。若某個應用程式始終表現不同，先確認請求是否進入客戶端，再檢查出站協定，避免在入口問題上耗費時間。

路由規則通常依序比對。較寬泛的規則若排在前面，可能讓後續的精細規則永遠無法生效；預設出站則會接收未符合規則的流量。以下僅展示規則片段，並非可獨立執行的完整設定。它需要既有的 direct 與 block 出站，以及相應的規則資源。合併時應確認標籤確實存在，不要只因 JSON 語法正確，就認定可以直接取代整份檔案。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

DNS 與出站設定須一併驗證

DNS 不只是填入解析器位址。還須確認由誰發起解析、解析請求走哪條出站，以及解析結果如何用於後續路由。應用程式可能自行使用加密 DNS，系統也可能保留獨立的解析路徑；核心 DNS 設定不一定會接管這些請求。因此，在客戶端填入遠端 DNS 後，仍須驗證實際請求路徑，不能只看設定頁上的文字就認定解析已經透過代理。

遠端解析也可能造成啟動依賴。如果代理伺服器使用網域名稱，而解析該網域的解析器又必須透過尚未建立的代理連線，就會形成循環。應為伺服器網域提供明確可達的解析路徑，同時避免這條啟動路徑意外接收所有業務網域。區分伺服器位址解析與目標網站解析，有助於說明為什麼某些設定只有在清除快取後才會暴露故障。

FakeDNS 透過合成位址保留網域關聯，適用於特定的接管與路由組合，但不是開啟後就能防止 DNS 洩漏的簡易選項。合成位址必須回到能辨識它的處理路徑；若被不相關的應用程式或出站當成真實位址使用，就會連線失敗。快取、位址類型與規則也須協同設定。具體驗證方式請見DNS 請求路徑檢查與設定實作，修改前先保存原設定。

完成傳輸與 DNS 調整後，至少分別測試以網域存取、需要解析的代理入口，以及業務所需的資料封包連線。若只用單一網頁測試，快取可能掩蓋解析問題，重用連線也可能掩蓋握手問題。測試中應包含一次新建連線，並在記錄中確認命中的出站標籤。如此才能分辨協定無法使用、規則未命中與解析路徑錯誤這三種常見原因。

07 · 訂閱格式與跨客戶端相容性

訂閱是分發格式，不是通訊協定

訂閱連結用於取得一組伺服器描述，再由客戶端將這些描述轉換成實際執行的設定。訂閱本身不會定義資料如何傳輸，也不代表其中每筆項目都適用於目前的核心。更新成功，只能表示內容取得與解析流程完成了部分步驟。接著仍須檢查項目數量以外的品質資訊：協定類型是否正確、安全參數是否保留，以及目前的核心能否解析這些欄位。

常見內容包括逐行排列的分享連結、經編碼的連結集合，以及針對特定實作的完整設定。副檔名或網址外觀不足以判斷實際格式，客戶端應依回傳內容辨識。如果取得的是網頁、登入提示或錯誤文字，再複製幾次也不會變成訂閱資料。排查時先確認來源是否需要授權、回傳內容是否符合約定，再處理解析相容性，而不是一開始就重裝客戶端。

能辨識格式前綴，不代表保留了所有設定語意

VMess 分享內容通常包含結構化欄位；VLESS 與 Trojan 分享連結通常透過位址和查詢參數描述安全及傳輸設定；SS 則有不同的歷史編碼方式。各客戶端對別名、選用參數與擴充欄位的支援範圍可能不同。匯入工具即使忽略未知參數，仍可能顯示看似完整的設定。因此，跨客戶端移轉後應開啟編輯頁逐項比對，不能只看名稱與位址相同就認定設定一致。

最容易遺漏的欄位包括伺服器名稱、流量控制、指紋、短識別碼、傳輸路徑與服務名稱。某些參數只會在特定安全或傳輸類型下出現；一旦類型辨識錯誤，後續欄位可能被隱藏或清空。若原始分享內容中有欄位，介面卻沒有相應選項，應先確認客戶端與核心是否支援。不要把未知參數塞進備註，也不要用外觀相似的欄位代替。

訂閱通常描述連線入口，不一定包含完整的路由、DNS、系統代理與分應用程式規則。兩台裝置匯入同一份訂閱後，存取行為仍可能不同，因為本機策略並未同步。從桌面端移轉到 Android 時，尤其要區分這兩部分：先移轉伺服器，再另外檢查路由與 VPN 設定。相關流程請見多裝置訂閱、分享碼與備份匯入方式。

更新、分組與本機修改的界線

自動更新通常會由訂閱來源重新產生所屬分組中的項目。本機手動修改可能在下次更新時遺失，實際行為取決於客戶端實作。需要長期保留的測試設定，建議複製到明確的手動分組，並記錄它與訂閱原始項目的關係。不要在同一分組混放來源不明的修改，再依賴備註猜測哪些項目會被更新覆蓋。更新前後應抽查重要安全參數，而不只是觀察排序。

訂閱篩選與備註中的正規表示式，只會影響項目如何加入清單或顯示在清單中，不會自動驗證協定是否可用。篩選條件過於嚴格，可能排除原本可用的入口；名稱相似也不代表設定相同。排查「更新後找不到伺服器」時，先關閉篩選並檢查分組，再確認來源是否真的移除了該項目。管理方式可參考訂閱分組與伺服器篩選，避免把顯示問題誤判為核心故障。

QR Code 只是文字的另一種載體，不會增加協定支援。掃描失敗可能是圖片辨識問題；掃描成功後匯入失敗，則可能是文字格式問題，兩者應分開處理。可以先在裝置本機查看辨識結果中的協定前綴與結構，避免將含有憑證的內容提交給不明轉換服務。超長分享文字經聊天軟體轉傳時，也要留意換行、標點替換與尾端截斷。

可靠的移轉記錄應包含來源類型、客戶端、核心家族與重要組合，而不只是一張伺服器清單截圖。移轉後先驗證一筆結構簡單且來源明確的設定，再批次匯入；確認可用後，再恢復篩選、自動更新與複雜規則。若發生失敗，可以沿著取得、解析、產生設定、啟動、握手五個階段定位，避免反覆替換所有設定而失去最初的故障線索。

08 · 依使用情境完成選型

先列出限制，再比較協定

選型時第一步不是比較速度排名，而是確認遠端目前開放哪些入口。接著確認裝置系統、客戶端、核心家族、所需服務與維護方式。若伺服器只提供一種完整設定，就應先確保這筆設定能正常運作，再討論是否需要申請其他協定。客戶端無法憑空轉換遠端能力；在本機修改協定類型，通常只會產生一筆沒有對應接收端的新設定。

日常桌面使用可先選擇 v2rayN，匯入原始訂閱並維持容易理解的預設設定。需要 REALITY 或 Vision 時，請確認所選路徑使用支援該組合的 Xray；已有穩定的 VMess、Trojan 或 SS 設定時，先核對具體欄位與核心支援情況，不必為了統一名稱而移轉。安裝套件與系統架構的選擇請前往下載頁處理；本頁著重說明安裝後如何判斷設定是否相符。

Android 與耗電敏感情境

Android 端需要 Xray 功能時，優先檢查 v2rayNG；維護 V2Fly 設定時，可選擇 v2flyNG，並依相應實作核對參數。首次測試時，先將 Mux 與分應用程式規則維持在容易判斷的狀態，再逐步調整。若背景連線中斷，先檢查系統是否回收 VPN 服務；若連線穩定但耗電增加，再觀察應用程式請求與網路重建情況，避免把系統排程問題歸因於協定標頭負載。

耗電敏感的裝置應減少不必要的持續網路活動，而非一味追求最少欄位。選擇能穩定連線、減少重建且符合業務需求的組合，再依實際應用程式範圍設定分應用程式代理。若需要即時影音或資料封包服務，應另外確認 UDP 路徑。若只需要瀏覽網頁，可以先以一般瀏覽請求建立基準，但不要據此推論所有應用程式都能正常使用。

穩定既有設定與新部署的不同考量

對穩定運作中的設定而言，維護成本也應納入決策。更換協定可能牽涉遠端入口、安全參數、訂閱產生方式與所有裝置的相容性，實際收益卻未必來自協定本身。只有在有明確需求時，例如目前核心缺少必要功能、握手成本確實成為瓶頸，或現有方法已不利於維護，移轉才有清楚目標。目標應可透過測試驗證，而不是籠統地「更新一下」。

新部署時，先選擇雙方都明確支援、文件完整且容易檢查的組合。需要常見 TLS 維運方式時，可評估 Trojan 或相符的 VLESS 組合；已有 SS 基礎時，請核對現代加密方法、金鑰格式與資料封包支援；使用 VMess 時，確認採用現代驗證流程並維持時間同步。選擇 REALITY 時，也應一併評估 Xray 支援與驗證參數管理，不要只看客戶端是否顯示該名稱。

依故障階段縮小選擇範圍

若匯入時就失敗，優先檢查分享格式與客戶端解析；若核心無法啟動，檢查欄位結構與功能支援；若位址無法連線，檢查解析、連接埠與網路路徑；若安全握手失敗，檢查伺服器名稱、憑證或 REALITY 參數；若握手成功但應用程式無法使用，再檢查代理驗證、路由與接管範圍。每個階段都有不同線索，不應一概歸納為「協定不行」後就更換所有設定。

保留一筆已知可用的設定很有幫助，可用來判斷故障來自整台裝置、目前網路還是單一入口。比較時不要同時切換網路、核心與協定；先在原環境重新測試，再逐項替換。分享記錄時應隱藏憑證，但保留錯誤發生順序與類別。若需要依操作步驟重新建立基準，請回到使用指南；特定問題則可依分類前往常見問題查找。

協定選型沒有脫離環境的唯一答案。可維護的結果，應能說明每個關鍵欄位的來源、了解流量如何進入核心、分辨解析與握手失敗，並在更新後重現基本測試。分別管理協定、安全層、傳輸方式與本機策略，再一併驗證，才能在移轉裝置或調整核心時維持穩定行為，而不是仰賴一次偶然成功的連線。