V2Ray 協定詳解

設定層次：協定、傳輸方式與安全層

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

用戶端中的「協定」通常指代理協定，負責定義身分驗證、目標位址與資料轉送的規則。VMess、VLESS、Trojan 和 Shadowsocks 都屬於這一層。它們規範的是用戶端與伺服器如何理解同一個代理請求，而非決定所有網路細節。即使兩組設定都使用 VLESS，也可能因傳輸方式、安全層或伺服器入口不同，而形成完全不同的連線路徑；不能只看協定名稱判斷相容性或效能。

傳輸層決定代理資料如何傳送，例如直接使用 TCP，或透過 WebSocket、gRPC 等方式傳輸。傳輸選項必須與伺服器入口相符；把 WebSocket 改成 TCP，不會讓用戶端自動找到另一種入口。路徑、服務名稱和要求主機等欄位也各有用途，看似可有可無，實際上往往參與伺服器端的流量分配。訂閱已填妥的傳輸參數應先保留原樣，確認有完整替代設定後再調整。

安全層負責加密連線並驗證對端身分。TLS 是常見選項，REALITY 則是特定核心支援的安全層方案。REALITY 並非與 VLESS 並列的完整代理協定，用戶端中常見的是兩者搭配使用。介面把多個選項放在同一張編輯卡片上，不代表它們在技術上屬於同一層。閱讀設定時，先分別記下代理協定、傳輸方式與安全層，再查看驗證資訊，會比依欄位順序猜測用途更清楚。

用戶端、核心與流量接管方式各司其職

圖形用戶端負責編輯、儲存及匯入設定，也負責啟動核心和提供系統整合功能。核心才是實際處理協定交握、路由比對與資料轉送的元件。介面能顯示某個下拉選項，只代表用戶端認得該欄位，不表示目前執行的核心支援它。若匯入成功卻無法啟動，應同時檢查用戶端儲存的設定、選用的核心，以及日誌中實際執行的功能；匯入成功不等於連線成功。

系統代理、TUN 與 Android VPN 模式屬於流量接管方式，並非遠端協定。系統代理通常只影響遵循系統代理設定的應用程式；TUN 能接管更多網路流量，但也涉及權限、路由與 DNS。Android 顯示 VPN 已連線，只表示系統已授權本機虛擬網路介面，並不能說明遠端使用哪種協定。因此，更換接管模式或許能解決應用程式未走代理的問題，卻無法修正錯誤的使用者識別碼或伺服器連接埠。

依層次順序定位問題

一次連線至少會經過本機流量接管、位址解析、建立傳輸連線、執行安全交握及完成代理驗證等環節。日誌中的「連線逾時」和「驗證失敗」指向不同階段；後者通常表示請求已抵達能夠回應的一端。排查時先判斷問題停在哪一層，再修改該層相關欄位。若每次同時更換 DNS、協定與路由，即使恢復連線，也很難找出真正原因，下次更新訂閱後仍可能再次出錯。

選擇協定也應依照相同順序：先確認伺服器提供哪些完整組合，再確認本機核心支援哪些組合，最後比較裝置負擔與應用程式需求。用戶端不是協定轉換器，不能只靠修改下拉選單，就把現有帳號變成另一種服務。保留一份可正常運作的原始匯入設定，另外建立測試項目進行比較，可避免手動修改覆蓋訂閱來源。若要了解分流規則，請接著閱讀路由規則實作指南。

VMess 與 VLESS：驗證方式與加密的取捨

VMess 的設計背景與現有設定

VMess 是 Project V 生態早期的重要代理協定，將使用者驗證、要求描述與資料保護納入同一套協定設計。由於普及度高，許多既有服務和訂閱仍保留 VMess 設定。選用 VMess 的合理理由，是現有服務完整支援、設定來源可信，而且目前的用戶端能正常執行；不能因名稱中帶有某個專案字樣，就認定它適用所有環境。設定已穩定運作時，無須只為更換協定名稱而遷移。

VMess 的舊版設定包含不同的交握與安全選項。現代使用應留意 AEAD 相關支援，不要直接把舊教學中的參數複製到新設定。舊分享內容可能包含額外識別欄位或不同的安全演算法名稱；用戶端或許能以相容模式解析，但核心是否接受仍須另外確認。若匯入舊訂閱後無法啟動，應先索取目前格式、查看日誌對欄位的說明，而非不斷嘗試任意數值，期待用戶端自動補齊伺服器要求。

系統時間也是排查 VMess 時的重要因素。驗證流程對時間有要求，裝置時間誤差過大時，即使使用者識別碼和連接埠正確，仍可能連線失敗。請讓作業系統正常同步日期與時間，並分辨實際時間錯誤與顯示時區不同。時區顯示不同不一定會導致驗證失敗；反覆修改時區卻不檢查系統時鐘，通常無法解決問題。若安全層另使用 TLS，也必須符合憑證有效期限的時間條件。

VLESS 簡化了哪些部分

VLESS 著重於精簡的驗證與要求封裝，本身不提供 VMess 同等的資料加密機制。它常與 TLS 或 REALITY 搭配，由外層安全方案保護連線。用戶端顯示「加密：none」並不代表整個組合沒有加密，還需確認安全層是否正確啟用。反過來說，如果完全沒有合適的安全層，也不能因協定名稱較新，就認為驗證資訊和業務資料自然受到完整保護。

VLESS 常使用 UUID 格式的使用者識別碼，但外觀相同不代表能與 VMess 帳號互換。伺服器監聽的協定類型、使用者設定與傳輸入口都必須相符。部分組合還包含 flow 欄位，用來指定特定處理流程，例如符合條件的 Vision 設定。這個欄位不是通用的加速開關，不能任意加到任何 VLESS 節點；只有伺服器、傳輸方式與安全層都符合要求時，相關流程才有作用。

如何比較兩者而不誤判

從封裝設計來看，VLESS 不在自身協定層重複處理部分加密工作，某些組合的處理負擔可能較低。但實際連線還要經過安全交握、網路往返、伺服器排隊與應用程式要求，這些因素往往比協定標頭的差異更明顯。拿不同地區、不同服務商的兩個入口測試，得到的是整條連線路徑的差異，不是 VMess 與 VLESS 的純協定差異。因此，本頁不提供脫離環境的固定速度排名。

在用戶端選擇時，優先使用伺服器明確提供的完整設定。若兩種協定都可用，盡量維持相同的目標服務、傳輸路徑與測試應用程式，觀察首次開啟、持續傳輸，以及短暫閒置後恢復的情況。不要只看用戶端清單中的單次連線測試：測試可能沒有涵蓋實際網頁要求，也未必能重現應用程式的 DNS 與連線重用行為。測試方法應能回答日常使用是否改善，而非只比較單一結果。

對需要維護大量既有設定的桌面使用者而言，相容性與可追溯性通常比遷移本身更重要。建立新連線時，若伺服器提供適用於目前核心的 VLESS 安全組合，可列入候選，再檢查行動網路切換、UDP 應用程式與路由需求。若只有 VMess 可用，就使用目前支援的現代設定並保持系統時間同步。兩種選擇都必須符合實際部署條件，不能只靠用戶端改變伺服器能力。

Trojan 與 Shadowsocks：部署方式與參數範圍

Trojan 以 TLS 為基礎

Trojan 的基本設計是以 TLS 保護用戶端與伺服器之間的連線，再於其中進行代理驗證與轉送。它與採用 UUID 的協定不同，常見用戶端會使用密碼欄位。密碼只負責驗證，伺服器位址、連接埠、憑證驗證名稱與傳輸設定仍須正確相符。Trojan 適用於已有相應 TLS 伺服器設定、希望沿用憑證管理機制的情境，但不能因此省略憑證驗證，也不能以為只填入密碼就能建立可信連線。

使用網域連線時，用戶端通常會依設定傳送伺服器名稱並驗證憑證。入口位址與憑證名稱可能相同，也可能因伺服器部署方式而不同，不能一概互換。若伺服器提供獨立的伺服器名稱欄位，請依原始資料填寫；若未提供說明，不要借用其他節點的網域名稱。連線失敗時，可先確認系統時間、網域拼寫與憑證有效性，相關處理方式請見TLS 交握與憑證錯誤說明。

Trojan 的不同傳輸組合與擴充實作，不應視為可互換的同一種格式。用戶端能辨識 Trojan 類型，不代表能執行所有以 Trojan 為基礎的擴充功能。匯入分享連結後，應確認傳輸方式、安全層與額外欄位都有保留。若目前核心不支援伺服器要求的功能，修改密碼通常無濟於事；應改用相符的完整入口，或使用明確支援該組合的用戶端與核心。

Shadowsocks 的簡潔設計與方法相符性

Shadowsocks 常縮寫為 SS，透過預先共用的密鑰與指定的加密方法進行代理通訊。設定結構通常較精簡，主要欄位包括伺服器、連接埠、密碼與方法名稱。早期設計與現代 AEAD 系列在安全特性和相容要求上有所不同，不能只看到「SS」就認為設定等同。建立新設定時，應採用伺服器與核心共同支援的現代方法，不要為了相容舊教學而退回已不適合繼續使用的舊方法。

方法名稱必須完全相符，密碼的編碼要求也必須符合該方法。尤其部分現代方法要求特定長度的金鑰材料，不能以任意短密碼取代。分享連結有時會將方法與密碼編碼在一起，有時則使用分開欄位，因此不要只憑連結外觀手動截取一段作為密碼。請優先讓用戶端完整解析，再依提供者說明核對欄位；若解析失敗，先確認連結格式，不要逐一刪除看不懂的字元。

Shadowsocks 2022 等方法的相容範圍更具體，不能從「核心支援 Shadowsocks」推論「所有方法都支援」。此外，部分設定依賴額外傳輸擴充或外部元件，而本站三款用戶端不保證所有平台都整合相同功能。選擇入口時應優先確認目前的用戶端能直接執行該設定。若必須另外安裝元件，請先確認用戶端文件與伺服器需求，不要直接把其他軟體生態的設定檔當成可匯入的訂閱。

選擇時也要考量 UDP 與維護成本

Trojan 與 Shadowsocks 的 UDP 支援情況，須同時考量協定實作、用戶端接管方式、伺服器設定與網路路徑。應用程式能開啟一般網頁，只能證明部分 TCP 要求可用，不能證明通話、遊戲或其他資料封包服務正常。系統代理也未必會接管這些應用程式的流量。測試時先確認應用程式是否進入用戶端，再查看日誌是否有對應的轉送紀錄；否則很容易把流量接管範圍的問題，誤判為某種協定天生無法處理該服務。

從維護角度來看，Trojan 需要留意 TLS 憑證與名稱是否相符，Shadowsocks 則要特別確認方法與密鑰材料是否相符；兩者的排查重點明確而不同。若伺服器已穩定提供其中一種，而且所有目標裝置都能正常使用，簡化設定並保留來源通常比頻繁更換類型更有價值。選擇協定的目標是滿足身分驗證、相容性與業務需求，而非讓清單中的類型越多越好，也不應以名稱新舊判斷品質。

TLS 與 REALITY：如何確認安全層參數

TLS 的關鍵在於驗證連線對象

TLS 不只加密傳輸，也會透過憑證與名稱驗證，協助用戶端確認連線對象。伺服器憑證須在有效期限內，憑證鏈應受裝置信任，驗證名稱也須符合憑證涵蓋範圍。加密連線建立失敗時，原因可能出在其中任何一個環節。若把所有憑證問題都歸咎於「協定不相容」，便可能忽略裝置時間錯誤、入口填寫錯誤或伺服器憑證鏈更新不完整等更直接的原因。

SNI 是交握時傳送的伺服器名稱，常用於伺服器選擇憑證與入口；用戶端實際採用的驗證名稱則取決於實作與設定。兩者經常相同，但用途不可混淆。手動改成能開啟一般網站的網域名稱，不會讓現有服務自動取得相應憑證。若使用 IP 位址連線，而設定另有提供伺服器名稱，請保留這種分工，不要把 IP 位址一律複製到所有名稱欄位。

ALPN 用於協商應用層協定，指紋選項則涉及用戶端交握特徵；兩者都不是密碼，也不是可任意切換的效能檔位。若伺服器或中間入口對這些參數有特定要求，錯誤組合可能導致交握成功後仍無法使用。請優先保留原始分享內容；只有明確了解部署支援哪些選項時，才調整這些進階設定。遇到名稱相近但行為不同的欄位，應查看目前用戶端的實際對應方式，不要只按中文標籤猜測。

REALITY 需要完整的參數組合

REALITY 常見於 Xray 生態中的 VLESS 組合，會改變安全交握與伺服器身分驗證的運作方式，不應視為獨立的帳號類型。用戶端設定的是相應的公開驗證資料與連線參數，伺服器私密資料不應放入用戶端訂閱。了解這一點有助於核對分享內容：用戶端必須能驗證伺服器，但不需要持有伺服器的所有機密，也不應要求使用者從伺服器複製整份設定檔。

常見欄位包括伺服器名稱、公開驗證資料、短識別碼與用戶端指紋；部分組合還需要對應的 flow。欄位名稱會隨用戶端與核心演進而變更，請依目前介面說明對照分享資料，不要只照著舊截圖尋找同名輸入框。公開驗證資料與短識別碼必須來自同一項服務設定，不能從兩個可用節點各取一半拼湊。看似都是字元組成的欄位，編碼方式與用途可能截然不同。

REALITY 也不代表可以忽略時間、網路可達性與傳輸設定是否相符。用戶端仍須連上正確的位址與連接埠，安全交握也必須符合實作要求。更新後若失效，先確認實際啟動的是支援該組合的核心，再檢查訂閱解析是否漏掉參數，最後確認伺服器是否同步調整。直接把安全層改成一般 TLS 通常無法解決問題，因為伺服器沒有義務在同一入口同時接受另一套交握方式。

加密範圍與應用程式本身的安全性

代理連線的安全層只保護用戶端到代理伺服器這一段，不能取代應用程式本身的 HTTPS 或其他端對端保護。業務資料抵達伺服器後如何存取目標，仍取決於目標協定與伺服器行為。因此，不能因代理入口顯示 TLS 就忽略網頁憑證警告，也不能把核心顯示連線成功理解為所有應用程式內容都受到相同安全保護。選擇方案時，應清楚掌握各層保護的起點、終點與信任對象。

在一般 TLS 與 REALITY 之間選擇時，先確認伺服器提供的完整方案與裝置支援情況，再考量維護需求。已有完善憑證管理的環境可以繼續使用相符的 TLS 入口；明確採用 REALITY 的服務則須保留完整參數。兩者不適合透過單一開關進行所謂的「升級」。若不同裝置必須共用訂閱，請確認每台裝置的解析器與核心都能保留相關欄位，否則應依相容範圍分組提供入口。

Xray 與 V2Fly：核心家族與設定相容性

源自相同背景，不代表功能完全相同

Project V 是理解 V2Ray 生態的重要背景；V2Fly 延續 V2Ray 相關核心的發展，Xray 則以相關程式碼為基礎，形成獨立的演進路線。兩者在許多概念上相近，例如入站、出站、路由與 DNS，但功能擴充、欄位語意和預設行為並不保證始終一致。將它們理解為背景相近的兩條實作路線，比視為同一程式的兩個名稱更準確，也更有助於判斷設定遷移風險。

協定能否使用，須具體檢查協定、安全層、傳輸方式與擴充流程。Xray 生態中的 REALITY、Vision 等功能，不能假設切換到 V2Fly 後仍可使用；V2Fly 持續發展的功能，也不能只因欄位看起來相似，就推定 Xray 具有相同行為。兩者都認得某個頂層協定，只是相容性檢查的第一步。實際支援範圍應以目前執行的核心文件、用戶端整合情況與啟動日誌為準。

核心在網域策略、DNS 處理、連線重用與路由規則細節上也可能不同。遷移後即使能建立遠端連線，仍須確認本機流量是否依照原本預期分流。部分欄位遭忽略時不會立即報錯，卻可能改變解析位置或出站選擇。長期使用的複雜設定，應將「能夠啟動」、「能夠存取目標」與「規則行為符合預期」視為三個獨立驗證階段，逐一確認後再取代日常設定。

三款用戶端的選擇範圍

v2rayN 是本站優先推薦的桌面用戶端，支援 Windows、macOS 與 Linux。它提供圖形化管理功能，但不同平台、發行形式與整合版本可使用的系統功能可能有所差異。若用戶端提供核心選擇，應先確認目前設定依賴哪些功能，再選用相符項目；不能只為了讓選單顯示另一個核心名稱就切換。桌面介面能否編輯某個欄位，與安裝目錄中的實際核心檔案是否具備相應功能，也應分別確認。

Android 主要使用 v2rayNG，其設定以 Xray 核心功能為主；v2flyNG 則是 V2Fly 路線的替代選項。兩者名稱相近，不代表進階參數與原生設定可以直接互換。若伺服器使用特定 Xray 擴充功能，請優先確認 v2rayNG 目前的支援情況；若既有設定明確依賴 V2Fly 行為，再考慮 v2flyNG。不要讓兩款用戶端同時啟用 VPN 流量接管後再比較測試結果，以免實際流量路徑改變。

切換前後的檢查順序

共用 JSON 語法不代表設定語意完全相同。將原生設定交給另一個核心前，應確認協定名稱、傳輸欄位、安全設定、路由參照與資源檔案都能辨識。以下是一個簡單的規則物件，可加入相應的路由規則清單，將私有位址範圍導向名為 direct 的出站；這不是完整設定，使用前必須先定義相應出站並提供可用的 GeoIP 資源。

{
  "type": "field",
  "ip": ["geoip:private"],
  "outboundTag": "direct"
}

即使是這麼簡短的物件，也依賴周邊設定：出站標籤必須存在、規則檔案必須可讀，而且前面的規則不能先匹配到相同流量。遷移複雜設定時，先在副本中保留最精簡的可用出站，再逐步加入 DNS、規則與連線重用選項。若啟動失敗，先閱讀日誌，確認是否有不支援的欄位、缺少參照或本機連接埠遭占用；詳細流程請參考v2rayN 核心啟動失敗排查，不要一次重寫所有參數。

連線表現、資源使用量與行動裝置耗電

首次連線與持續傳輸應分開比較

使用者感受到的「速度快」，可能是指頁面首次開啟，也可能是大型檔案持續傳輸，兩者受不同因素影響。首次存取會經過 DNS、建立底層連線、安全交握、代理驗證與目標回應；持續傳輸則更受線路容量、壅塞、封包遺失、伺服器負載與裝置處理能力影響。協定封裝會增加負擔，但不能脫離這些條件單獨下結論。首次交握順暢的入口，在持續負載下也可能出現明顯波動。

傳輸方式也會影響連線表現。額外的承載層可能增加封裝與處理步驟，也可能是配合現有服務入口的必要條件。連線重用能減少部分重複連線，但多項業務共用同一底層連線時，也可能互相影響。某些業務對短暫封包遺失、排隊與恢復更敏感，不能只看平均傳輸量決定是否啟用重用。若伺服器未要求或明確支援，不應將 Mux 視為預設必開的最佳化選項。

測試時應控制變因。盡量維持相同裝置、網路、目標內容與測試時段，並分別觀察冷啟動、連續存取、閒置後恢復與網路切換。用戶端的連線測試只能作為輔助，不能取代應用程式的實際體驗；測試要求可能使用特定目標，也可能未經過相同路由。若兩個候選入口位於不同地點、使用不同資源，結果應記錄為「這兩個入口的表現」，不應延伸成兩種協定的普遍排名。

CPU 與記憶體使用量不只取決於加密

加解密會使用處理器資源，裝置是否具備相關指令最佳化、核心的實作方式與封包大小，都會影響實際負擔。較新的協定或演算法名稱，不代表在每台裝置上都更省資源；較精簡的封裝，也可能被額外傳輸層抵銷優勢。低功耗裝置應觀察執行實際任務時處理器是否持續高負載、裝置是否明顯發熱，以及應用程式是否順暢，而非照搬其他架構裝置的使用經驗。

記憶體使用量也與並行連線、緩衝區、DNS 快取、規則規模和日誌量有關。長時間保留詳細偵錯日誌會增加儲存寫入與處理負擔，日常使用時應調回合適的日誌層級。大範圍測速或自動偵測可能在背景持續建立連線，干擾對協定本身的判斷。比較資源使用量前，應關閉不必要的測試工作，讓兩組設定使用相近的規則與接管模式，否則很難解釋觀察到的差異。

行動裝置耗電，先檢查喚醒與重新連線

Android 的耗電表現往往受無線網路狀態影響。頻繁的小型要求、過於積極的保活、網路品質不佳造成的重傳，以及連線反覆失敗後不斷重試，都可能讓無線模組長時間維持啟動狀態。即使協定本身處理負擔不高，這些行為仍會增加耗電。待機耗電異常時，先查看日誌是否持續重新連線，再檢查背景應用程式是否不斷發出要求，最後才考慮更換協定組合。

VPN 模式會讓更多流量進入本機處理流程，因此電池用量統計中用戶端占比上升，不一定代表增加的耗電全由用戶端造成；部分轉送工作可能被系統歸到它名下。依應用程式設定代理可縮小處理範圍，但須確認已選取需要代理的應用程式，並了解包含清單與排除清單的差異。若系統省電功能反覆終止背景連線，也會造成恢復與重新連線，不僅影響使用，也會讓耗電判斷失準。

實際選擇時，可先重視連線中斷後的穩定恢復，再考慮峰值表現。經常在 Wi-Fi 與行動網路之間切換的使用者，應檢查切換後能否順利重新建立連線，以及通話、訊息或背景工作是否受影響。切換網路後舊連線中斷，不一定是協定缺陷；重點是用戶端與應用程式能否及時恢復。優先保留能穩定完成日常工作的組合，再以可重複的測試判斷是否值得更改傳輸、連線重用或安全設定。

訂閱與分享格式：可匯入不代表可執行

分享連結、訂閱與原生 JSON 的差異

分享連結通常描述一項連線，包括協定、位址、驗證資訊與部分傳輸參數。訂閱則是用戶端定期取得設定清單的入口，回應內容可能是多條分享連結文字、Base64 編碼內容，或特定結構的資料。原生 JSON 通常描述核心的執行設定，可能同時包含本機入站、多個出站、DNS 與路由。三者用途不同，不能因為都能複製成文字，就認為可以在同一個匯入入口互換使用。

Base64 是一種編碼方式，不具保密功能，也不會決定內容使用哪種協定。編碼後的訂閱可能包含多種分享連結，單一分享連結的部分內容也可能經過編碼。因此，判斷格式時應檢查解碼後的結構與用戶端要求，而不是只看結尾是否有某種符號。訂閱網址與分享內容通常包含可用服務的驗證資訊，應妥善保管帳號資料，不要為了辨識格式就提交給不熟悉的線上工具。

原生 JSON 與圖形用戶端產生的設定，在管理範圍上也有所不同。匯入原生設定可能代表讓核心依整套規則執行，而不只是新增伺服器清單中的一項。它可能改變本機監聽、日誌輸出與路由行為。匯入前應先了解用戶端是將其作為完整設定使用，還是只嘗試擷取部分欄位。不了解用途時，不要用外來的完整設定覆蓋已正常運作的本機管理方式。

解析器與核心是兩道相容性關卡

匯入訂閱時，首先會經過用戶端解析器。解析器必須能理解分享格式，將參數轉換成內部記錄；接著用戶端再產生核心可執行的設定。因此，匯入相容性與執行相容性是兩道不同的關卡。解析器可能接受連結，卻漏掉不認識的新欄位；核心也可能支援某項功能，但目前介面尚無法完整產生相應設定。因此，清單出現一筆記錄只是中間結果，不能取代編輯頁面檢查與實際啟動驗證。

部分參數會有不同的命名或編碼方式，例如伺服器名稱、傳輸服務名稱、指紋與安全層附加項。透過不同用戶端匯出再匯入時，這些欄位最容易遺失或改變語意。核對時應依用途比較，不必要求兩邊顯示完全相同的標籤，但必須確認值沒有變成預設值或空白。若連線在原用戶端可用，轉存後卻失效，應優先比對這些進階欄位，不要立刻重新申請帳號或修改伺服器。

所謂訂閱轉換，本質上是解析來源格式，再依目標格式重建內容。如果目標格式沒有對應欄位，轉換過程可能無法完整表達原始語意；即使轉換結果能匯入，也可能已遺失重要資訊。使用特定安全層或擴充流程的連線，應優先選擇提供者直接提供的相容格式。更多結構差異請閱讀Base64 訂閱、原生 JSON 與分享連結比較，不要把格式轉換當成新增核心功能。

如何兼顧訂閱更新與手動修改

訂閱管理的優點是由來源統一更新連線，但也表示清單可能會重新建立。用戶端處理重複項目、備註與手動修改的方式各不相同，不能假設本機修改會永久保留。進行協定測試前，應將原始項目保留在訂閱群組，把測試副本放入獨立的手動群組，並以備註記錄修改內容。這樣更新訂閱時仍能取得來源變更，也能確認測試設定是否與最新入口一致。

更新失敗時，應區分「無法取得回應」與「取得內容但無法解析」。前者可能涉及訂閱網址是否有效、連線方式或解析問題；後者則可能是回傳了網頁、帳號提示或不支援的格式。不要把錯誤回應當成訂閱繼續轉換，也不要公開包含驗證資訊的完整網址。多來源管理方式請參考多訂閱分組與篩選實務；基本故障也可查看常見問題中的安裝設定與問題排查分類。

依情境選擇：從可用組合到穩定設定

先篩選相容性，再比較使用體驗

開始選擇時，先列出伺服器實際提供的完整組合，而不是先挑選偏好的協定名稱。每個組合至少要包含代理協定、傳輸方式、安全層與必要擴充功能，再確認本機用戶端與核心是否能完整呈現。排除欄位缺失、實作不支援或依賴條件不明的組合後，剩下的候選項目才值得測試。依照這個順序，可以避免花大量時間嘗試缺少伺服器配合的本機開關，也能減少跨裝置設定時的誤解。

桌面日常瀏覽與辦公可先使用 v2rayN，保留訂閱提供的預設安全組合。若應用程式遵循系統代理設定，可先用系統代理完成驗證；確實有應用程式不讀取代理設定時，再評估 TUN。不要為了擴大流量接管範圍，就同時更改協定、DNS 與路由。連線可用後，應測試常用網頁、檔案傳輸與工作應用程式，並觀察休眠後能否正常恢復；日常工作穩定完成，比單次連線測試更有參考價值。

Android 日常使用以 v2rayNG 為主要選擇。應確認 VPN 權限、依應用程式設定的範圍、背景執行策略，以及切換網路後的恢復能力，而非只比較手機上的協定標籤。若現有設定明確依賴 V2Fly 行為，可另外使用 v2flyNG 驗證，但應避免兩款用戶端輪流接管，造成測試結果混亂。測試期間只保留一款實際接管流量的用戶端，並記錄每次使用的設定來源與核心路線。

業務需求決定測試重點

通話、遊戲與其他即時應用，應優先確認 UDP 轉送、流量接管路徑與連線穩定性。一般網頁正常但即時服務失敗時，先確認應用程式流量是否進入用戶端，再檢查伺服器是否允許相應轉送，以及中間網路是否符合必要條件。不要只因 TCP 入口可用，就推論所有資料封包服務都能正常運作。不同傳輸組合承載這些資料的方式可能不同，能否符合應用程式需求須實際驗證，不能只憑協定名稱保證。

多台裝置共用訂閱時，應優先考量彼此共同支援的完整功能範圍。如果桌面端能執行某項擴充功能，但行動端解析器尚無法保留相關參數，可將其放入桌面專用群組，並為行動裝置保留明確相容的入口。不要為了讓所有裝置的清單看起來一致，就強行複製並不等價的設定。對需要長期維護的環境而言，清楚的分組、來源記錄與更新流程本身也是選擇方案的一環，有助於大幅降低後續排查成本。

資源有限的裝置適合先減少額外處理：保留必要的路由規則、設定合適的日誌層級與明確的流量接管範圍，並暫停不必要的背景偵測。若連線仍占用較多資源，再比較協定與傳輸組合。不要因裝置較舊就停用身分驗證或安全層，也不要把降低安全要求當成效能最佳化。值得保留的調整，應能在相同工作下反覆改善表現，且不會影響應用程式需求與連線對象驗證。

保留回復方案與最少修改紀錄

設定最佳化應在副本上進行，每次只變更一類參數，並記錄預期改善的項目。例如只比較連線重用開關時，應保持協定、入口、路由與測試應用程式一致；只排查安全交握時，就不要同時更換 DNS 規則。若結果變差，應能立即還原至上一個可用組合。遇到故障時，可依「本機流量接管、名稱解析、底層連線、安全交握、代理驗證、目標存取」的順序查看日誌，避免在錯誤的層次反覆操作。

最終選擇不必涵蓋所有協定，也不必讓每台裝置使用完全相同的進階功能。伺服器明確支援、用戶端能完整呈現、核心可正確執行、實際應用程式穩定可用，四項條件都成立，才是適合目前情境的設定。首次操作請回到快速入門教學，選擇平台安裝方式請查看下載頁，若持續遇到問題則透過常見問題分類縮小排查範圍。協定參考用來說明各種取捨，不能取代對實際環境的驗證。