V2Ray 協定與核心選擇指南

連線設定的四個層次

先區分用戶端、核心與遠端服務

在用戶端選擇協定之前，先確認三個對象。v2rayN、v2rayNG、v2flyNG 是圖形介面的用戶端，負責儲存設定、顯示選項、啟動連線與管理訂閱；核心負責解析設定、建立連線、比對路由及處理資料；遠端服務則依照約定的協定接收連線。三者並非同一個軟體層級。介面能儲存一筆設定，只代表用戶端接受了輸入，不表示核心能辨識所有欄位，也不代表遠端使用相同參數。桌面端建議從 v2rayN 的平台入口選擇安裝檔；Android 端則依設定所需的核心選擇合適的用戶端。

一條連線通常可拆分為伺服器位址、代理協定、傳輸方式及安全層四組資訊。伺服器位址說明連線目標；代理協定說明如何驗證身分及表示目標位址；傳輸方式說明如何承載協定資料；安全層則說明如何確保連線機密性並驗證身分。若將這些資訊一概稱為「協定」，排查時就容易失去層次。例如 VLESS 是代理協定、WebSocket 是傳輸方式、TLS 是安全層，三者可以同時出現在一筆設定中，並非互斥選項。連接埠只是遠端的監聽入口，不能單憑連接埠判斷使用哪種協定。

介面欄位彼此相關

用戶端中的「位址」通常用來建立底層連線；「伺服器名稱」或 SNI 則是在 TLS 交握時使用的名稱資訊。兩者可能相同，也可能依伺服器設定而不同。WebSocket 的 Host 與路徑屬於另一組應用層參數，不應因名稱相似就把 SNI 複製到所有欄位。直接連線到某個 IP 時，憑證驗證仍可能需要網域名稱。請保留服務提供者設定的欄位分工，不要把位址、Host、SNI 當成可以任意互換的別名，也不要以關閉憑證驗證來掩蓋設定錯誤。

路由規則不會改變遠端協定

路由設定決定要求進入核心後交由哪個出口處理，可以直連、代理或封鎖；它不會自動把 VMess 改成 VLESS，也不會補上缺少的 TLS 參數。Android VPN 模式與桌面系統代理屬於本機連線方式：前者透過系統提供的虛擬網路介面接收選定流量，後者則讓遵循系統代理設定的應用程式連線到本機監聽連接埠。若用戶端顯示正在執行，但某個程式沒有經過代理，應先確認連線方式，而不是立刻更換遠端協定。相關層次差異也可參閱系統代理與路由模式說明。

閱讀分享連結時，可以依照相同順序整理欄位清單：是否有位址與連接埠、驗證欄位屬於哪種協定、傳輸方式是否有專用路徑、安全層是否啟用，最後再檢查路由與 DNS。即使更換用戶端，也能藉此分辨哪些是遠端連線的必要條件，哪些只是本機使用偏好。不要根據連結長度、備註文字或協定名稱，判斷設定是否更先進；備註只是標籤，真正決定連線行為的是核心最後收到的設定。

VMess 與 VLESS 的設計取捨

VMess 將驗證與資料保護納入協定

VMess 是 Project V 生態系早期發展的代理協定，設計涵蓋使用者識別、要求驗證與資料保護。用戶端常見的 UUID 用來識別使用者，不是伺服器網域，也不是訂閱網址。設定中的加密或安全選項必須符合核心支援的方式，不能因為匯入成功就任意改成其他值。VMess 可搭配不同傳輸方式，也能再加上 TLS；協定本身的加密與外層 TLS 負責不同工作，不能把其中一個欄位直接等同於整條連線的安全狀態。

現代 VMess 部署通常採用 AEAD 驗證機制。舊教學中提到的額外 ID、舊式驗證模式或歷史相容選項，不應視為目前設定的通用建議。現有設定能否繼續使用，取決於兩端實作是否仍接受相同機制。遇到舊訂閱時，正確做法是確認伺服器實際使用的驗證方式、取得更新後的連線參數，再檢查用戶端與核心是否支援；反覆修改額外 ID 或套用網路上的固定數值，通常只會增加設定不一致的情況。

系統時間也值得單獨檢查。某些協定的驗證流程涉及時間範圍，裝置時間偏差過大時可能出現驗證失敗，但底層 TCP 連線仍然成功。先啟用系統自動設定日期、時間與時區，再嘗試連線，比反覆重新安裝用戶端更有針對性。時間正確不代表驗證設定一定正確，UUID、連接埠與遠端設定仍須逐一核對。若記錄停在驗證階段，應優先確認這些條件，而不是先修改 DNS 或路由規則，因為要求可能尚未進入後續轉送流程。

VLESS 將資料保護交由外層安全機制

VLESS 的設計方向是減少協定本身負責的加密工作，將資料保護交由 TLS、REALITY 等外層機制處理。它仍需要驗證身分與表示目標位址，並不代表沒有協定開銷。常見 VLESS 設定中的加密欄位為 none，這是該欄位的協定語意，不表示所有資料都會以明文傳輸。判斷整條連線是否安全時，必須一併檢查安全層。反過來說，若沒有外層保護，也不能只憑 VLESS 這個名稱就推斷連線具有機密性。

VLESS 設定可能包含 flow 欄位，例如 xtls-rprx-vision。它不是能套用到所有連線的通用加速開關，而是與特定處理流程、傳輸組合及核心能力相關的參數。用戶端與伺服器必須同時符合相應條件。若將它加入不支援的傳輸組合，可能直接導致設定遭拒或交握失敗。服務提供者沒有提供 flow 時，不應自行猜測加入；若有提供 flow，也不能因為另一個用戶端介面沒有輸入欄位，就認為可以省略。

沿用現有設定遷移時，請保留完整參數

VMess 與 VLESS 不能只透過變更下拉選單就互換格式。即使兩筆設定使用相同的伺服器位址與使用者識別資訊，伺服器端也必須設定相應的入站協定。遷移時應取得服務端提供的新連結，逐一檢查安全層、伺服器名稱、傳輸方式、路徑與 flow，再建立獨立設定進行測試。保留原本可用的設定，能在新設定失敗時快速分辨是「遷移參數錯誤」還是「本機網路變化」。不要直接覆寫由訂閱管理的設定，否則下次更新時可能會還原手動修改。

若現有 VMess 連線穩定，遠端目前也沒有遷移計畫，就不必只為了協定名稱更換整套環境。若新部署明確採用 VLESS 與指定安全層，則應選擇能完整設定這些欄位的用戶端與核心。兩種情況都應先確保端到端相容，再考慮開銷差異。若服務提供者只說「支援 VLESS」，卻未說明傳輸方式與安全層，資訊仍不完整；應先補齊參數再匯入，避免將相容性問題誤判為伺服器無法連線。

Trojan、Shadowsocks 與 REALITY

Trojan 仰賴正確的 TLS 連線

Trojan 以 TLS 為基礎設計，在受保護的連線中進行密碼驗證並傳送目標要求。常見設定需要伺服器位址、連接埠、密碼及用於名稱驗證的相關參數。這裡的密碼是遠端連線憑證，不應貼到公開記錄或討論區。TLS 交握成功與代理驗證成功是兩個階段：若憑證名稱不符，應檢查伺服器名稱與憑證部署；若交握完成後仍遭拒絕，再核對密碼與遠端服務設定。把兩個階段都籠統地稱為「連不上」，會讓排查範圍過大。

憑證驗證不是可以隨手關閉的開關。它用來確認連線對象的服務身分；關閉驗證後，即使暫時能建立連線，也改變了原有的安全假設。裝置時間錯誤、憑證鏈設定不完整、名稱填寫不一致，都可能導致驗證失敗，應分別修正。Trojan 的擴充能力也取決於實作；某個用戶端能匯入基本密碼設定，不代表它理解其他實作附加的所有選項。分享連結中多出的欄位應個別確認，不要預設它們只是裝飾資訊。

Shadowsocks 的加密方式與金鑰設定必須一致

Shadowsocks 在用戶端中通常顯示為 Shadowsocks 或 SS。它採用預先共用的密鑰與加密方式組合；設定看似簡短，但加密方式名稱是連線協定的一部分。兩端必須使用相同方式，不能在用戶端任意改成看起來較熟悉的選項。傳統 AEAD 方式與 Shadowsocks 2022 系列也不能只改名稱就互換。後者對金鑰材料有特定格式與長度要求，不能把任意日常密碼當成有效金鑰，也不要期待用戶端會自動轉換成伺服器所需的值。

使用 Shadowsocks 時，也要確認訂閱是否包含外掛參數。基本協定支援與外掛支援是兩種不同能力；若缺少外掛實作，即使位址、連接埠、加密方式與密碼都正確，也可能無法使用。不同核心支援的加密方式與外掛可能不同，應以本機核心實際接受的設定為準。需要 UDP 的應用程式還必須確認遠端允許 UDP 轉送、用戶端連線路徑能承載 UDP，且路由沒有另外封鎖。網頁能開啟，不代表這些條件都已符合。

REALITY 是安全機制，不是獨立的代理協定

REALITY 常與 VLESS 一起使用，因此分享設定可能命名為「VLESS + REALITY」。它負責安全層相關工作，不是與 VLESS 平行的另一種帳號類型。常見用戶端欄位包括伺服器名稱、公鑰、短 ID 與指紋；公鑰用來對應伺服器端的金鑰設定，短 ID 用來比對伺服器允許的識別碼，指紋則涉及用戶端交握特徵。欄位格式與是否必填取決於實際設定，不能從另一條連線任意挪用，也不要把公鑰誤認為 UUID。

REALITY 的參數組合應由伺服器端設計並提供。遠端位址可連線，不代表公鑰、短 ID 與伺服器名稱的組合正確。連線失敗時，先確認連結是否完整複製，尤其是含有特殊字元的查詢參數；再確認目前用戶端使用的核心能辨識這些欄位。不要先嘗試隨機指紋、短 ID 或不相關的網域。介面中某個欄位空白，也可能是匯入器未能解析，而非伺服器不需要該欄位；應回頭檢查原始分享內容。

這三者不能依「新舊」排成一條替代順序。既有 TLS 基礎設施、目前使用的訂閱格式、伺服器端實作與行動裝置支援情況，都會影響最終選擇。對只使用用戶端的使用者而言，最可靠的做法是保留服務提供者給定的參數組合，先確認本機是否完整支援，再使用相同網路與相同工作進行比較。安全層與代理協定的名稱再多，也不代表設定一定更合理；減少不必要的中間層，通常更容易理解與維護。

連線速度、傳輸量與資源使用

分開觀察首次連線與持續傳輸

「速度快」至少包含三種不同體驗：點擊後多久收到第一個回應、長時間傳輸能維持多少吞吐量，以及多個要求同時進行時是否穩定。首次回應會受到本機 DNS、遠端位址解析、底層連線與安全交握共同影響；持續吞吐量則更受路徑頻寬、封包遺失、壅塞控制、遠端負載與裝置處理能力影響。某筆設定第一次開啟頁面較慢，傳輸大型檔案時仍可能表現正常。因此，不能拿一次頁面載入與另一筆設定的單次測速直接比較，必須先確定要比較的指標。

代理協定本身的處理開銷，只是完整連線路徑的一部分。加密演算法能否運用處理器指令、外層是否再加上 TLS、中間是否經過反向代理，都可能改變 CPU 使用量與建立連線的成本。低功耗裝置上可觀察到的差異，在效能充足的桌面裝置上可能很小。不能脫離硬體條件宣稱某個協定永遠最省資源，也不能把遠端壅塞造成的低吞吐量歸因於本機加密演算法太慢。先檢查網路與服務負載，再討論協定開銷，會是更可靠的判斷順序。

傳輸封裝與連線重用各有適用界線

直接 TCP、WebSocket 與 gRPC 的差異，主要涉及承載方式、中間設備相容性與連線管理。WebSocket 可能需要 HTTP 升級與正確路徑；gRPC 通常仰賴 HTTP/2 及相符的服務名稱，中間轉送設定也必須配合支援。這些機制讓部署更有彈性，同時也增加了需要維護的參數。選用時應有明確的伺服器端需求，而不是把封裝層數當成效能提升手段。路徑或服務名稱錯誤時，底層連接埠仍可能連得上，但代理工作階段無法真正建立。

用戶端中的「啟用 Mux 多工」功能，嘗試讓多個邏輯要求共用較少的底層連線。這可能減少頻繁建立連線的開銷，也可能讓不同要求共同承受同一條連線的壅塞與故障影響。若再與傳輸方式本身的多工機制疊加，效益不一定增加；某些協定、flow 或核心組合也有明確限制。建議先保留預設設定，只有在伺服器端明確支援且工作確實有大量短連線時再測試。不要把 Mux 當成遇到卡頓就必須開啟的通用修復方式。

以可重複檢查的測試取代單次排名

可以先用一般網頁觀察首次回應，再以允許測試的穩定資源觀察持續傳輸，最後執行實際工作，檢查並行要求與長連線。重複測試時，應區分首次連線與已重用的連線，因為快取和工作階段恢復會影響結果。測試期間暫停其他大量流量工作，並記錄是否發生網路切換或裝置休眠。不要只保留表現最好的一次結果，也不要把應用程式顯示的連線測試時間當成端到端下載速度；不同測試方式測量的內容可能完全不同。

觀察 CPU 與記憶體使用量也需要考量背景條件。規則資料庫、連線數量、記錄詳細程度與 DNS 快取都可能增加資源使用量，不應一概歸因於協定。若用戶端閒置時正常，開啟大量頁面後使用量才上升，應先檢查並行連線與規則處理；若單一持續傳輸就讓裝置明顯發熱，再比較加密與封裝條件。排查結束後，關閉不必要的詳細記錄並保留原始設定，才能確認後續變化來自哪項調整，而不是憑印象判斷。

即時通訊尤其需要額外檢查 UDP 路徑與抖動。網頁正常只能證明部分 TCP 要求可用，不代表通話、遊戲或名稱解析所需的 UDP 也能順利通過。若工作時出現間歇性停頓，應檢查連線方式、伺服器端轉送與網路封包遺失，而不是只更換協定名稱。長期使用時，實際工作能否穩定完成，比單次的最高吞吐量更有參考價值；選擇時也應將故障恢復能力與維護難度納入考量。

Android 背景執行、網路切換與耗電

耗電來自整條處理路徑

Android 裝置的耗電情況，不能只按 VMess、VLESS 或 Trojan 分類。無線網路喚醒、連線保活、DNS 查詢、背景應用程式要求、加密處理與詳細記錄，都可能影響電量。持續高吞吐量會增加無線模組與處理器的工作時間；大量零星的背景要求則可能頻繁喚醒裝置，即使總流量不大也會造成明顯影響。比較協定時，應讓代理應用程式範圍、遠端服務、網路類型與螢幕狀態維持一致，否則測到的往往是使用方式差異，而非協定設計差異。

v2rayNG 的 VPN 模式透過系統 VPN 介面接收流量，再交由核心處理。分應用程式代理可以縮小進入處理路徑的應用程式範圍，但「選擇應用程式」究竟表示只代理所選應用程式，還是略過所選應用程式，須依目前模式與介面說明判斷。修改後應重新建立連線，並實際開啟目標應用程式驗證。僅代理模式則需要應用程式能主動使用本機代理入口，不代表系統會自動將所有應用程式的流量交給它；使用模式不相符，經常會被誤認為連線不穩定。

依照症狀調整背景限制

如果切換到背景或關閉螢幕後連線立即中斷，先確認系統是否結束了用戶端服務、是否允許背景執行，以及其他 VPN 應用程式是否取代目前連線。不同 Android 裝置的電池管理入口與名稱可能不同，可先從應用程式資訊中的電池與背景權限檢查。不要一開始就關閉所有省電設定；先確認問題是否發生在螢幕關閉、鎖定畫面清理或特定省電模式之後，再視需要調整用戶端。如果網路仍可使用，但某個應用程式收不到訊息，也要檢查該應用程式本身的背景限制。

若用戶端仍在執行，但 Wi-Fi 切換到行動網路後連線失效，應先考慮原有底層連線已中斷。舊連線不會因為協定名稱相同，就自動跨網路延續；核心與應用程式需要重新建立工作階段。先停止再重新啟動連線，觀察是否恢復；若能恢復，再檢查自動重新連線行為、系統網路狀態與遠端如何處理連線。串流或通話應用程式也可能保留舊工作階段，需要重新進入應用程式畫面；不能只看狀態列圖示判斷是否恢復。

不要盲目增加重用、保活與 DNS 設定

保活有助於偵測失效連線，或維持某些網路設備上的工作階段，但更頻繁的探測也可能增加無線網路喚醒次數。若沒有明顯的閒置斷線問題，就不必刻意追求極短的探測間隔。Mux 同樣要依協定組合判斷，不能因為手機對耗電較敏感，就認定共用連線一定省電。大量資料持續傳輸時，減少一些交握不一定會改變主要耗電來源；連線異常後反覆重試，反而可能增加額外負擔。調整後應觀察實際使用情況，而不是只看開關是否已開啟。

DNS 設定錯誤可能造成重複查詢、逾時與連線重試，看起來像用戶端持續運作，實際上卻沒有有效要求。遇到這種情況，應先區分位址解析失敗與安全交握失敗，再檢查解析伺服器是否可連線、路由是否形成迴圈，以及網域策略是否引發額外解析。啟用本機 DNS 不代表所有應用程式都會自動使用相同解析路徑；應用程式本身的加密 DNS 也可能影響結果。相關問題可在FAQ 故障排除分類繼續確認，避免同時修改 DNS、安全層與路由。

比較耗電情況時，可在相同條件下分成兩個觀察時段：先在螢幕關閉、工作基本閒置的情況下檢查背景穩定性，再於固定工作情境下觀察發熱與耗電趨勢。記錄連線是否重建、網路是否切換、應用程式是否持續下載；不必提供脫離裝置條件的固定耗電百分比。若閒置時就異常，重點檢查喚醒、重試與記錄；若只有高負載時異常，則檢查吞吐量、加密與裝置散熱。這樣得到的結果才能用來調整實際設定。

V2Fly、Xray 與用戶端的相容性界線

來源相近不代表功能完全相同

Project V 是理解這個生態系的起點；V2Fly 與 Xray 則是相關核心家族中各自發展的路線。兩者共用部分概念與歷史基礎，例如入站、出站、路由與 DNS 的設定方式，但協定能力、傳輸實作及設定欄位各自演進。判斷相容性時，不能只憑「都屬於 V2Ray 生態系」就推論設定完全通用。某欄位在一個核心中有效，在另一個核心中可能不存在、名稱不同或限制不同；應逐項確認，而不是整份照搬。

v2rayNG 主要以 Xray 核心提供連線能力，v2flyNG 則採用 V2Fly 核心路線；v2rayN 提供桌面圖形管理介面與相應的核心執行設定。應一併考量圖形介面的功能與實際選用的核心。用戶端有某個匯入入口，不代表目前執行的核心一定能處理匯入內容。生態系的詳細關係可搭配閱讀Project V、V2Fly 與 Xray 家族說明，避免把用戶端名稱直接當成協定能力清單。

協定、設定與介面是三種不同的相容性

協定相容性表示雙方能依相同協定交換資料；設定相容性表示核心能理解設定結構與欄位；介面相容性則表示用戶端能輸入、儲存並傳遞這些欄位。三者缺一都可能導致無法使用。例如核心具備某項能力，但圖形匯入工具沒有保留新參數，最後產生的設定仍不完整。反過來說，介面保留原始字串，但實際使用的核心不認得該字串，也不會因此具備相關能力。排查時應確認失敗發生在哪個階段。

REALITY 與常見的 VLESS Vision 組合，是需要特別檢查 Xray 能力及欄位完整性的情況。不能假設另一個核心有同名、同義且能直接替代的實作。V2Fly 路線中的協定與傳輸功能也應以實際實作為準，不應把某個家族描述成另一個家族所有功能的子集。選擇核心不是抽象地評比哪個比較先進，而是確認目前伺服器要求的組合能否正確執行，以及用戶端是否能維護這份設定。

短設定也要檢查執行環境

以下是 Xray 風格的路由片段，用來說明規則的作用，並非可獨立執行的完整設定。使用時需要合併至相應的完整設定，並確認有標籤為 direct 和 block 的出站，以及已設定相應的規則資源。第一條規則封鎖指定的廣告網域集合，後兩條則分別將私人位址與指定網域集合交由直連出站處理。規則依序比對，後面的規則無法覆蓋已符合的前項，因此調整順序可能改變結果。

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

IPIfNonMatch 表示網域規則未符合時，路由階段可以嘗試解析網域，再繼續檢查 IP 條件；它並非「所有網域都優先依 IP 分流」。規則資源缺漏、出站標籤填錯或 DNS 無法連線，都可能使片段無法如預期運作。這表示設定相容性不只在於欄位名稱相同，也涉及資源、標籤與解析路徑等背景條件。一般使用者建議透過用戶端提供的路由介面管理規則；只有在清楚了解產生的結構時，才使用自訂片段。

訂閱、分享連結與匯入相容性

訂閱網址與連線憑證不是同一種資料

訂閱連結通常是用來取得一組設定的網址，單筆分享連結則描述一條連線。若把單筆分享連結填入訂閱網址欄位，或將訂閱網址當成連線設定匯入，可能會導致取得失敗或沒有有效項目。訂閱也可能包含存取權杖，權限範圍可能涵蓋整組設定，應視為敏感資訊。排查時不要公開原始訂閱網址；記錄或截圖也應遮蔽驗證查詢參數、帳號識別資訊與遠端密碼，避免因尋求協助而暴露整組連線權限。

Base64 是編碼方式，不是加密協定，也不會保護訂閱內容。常見訂閱會先將多筆分享連結組成文字，再進行編碼；用戶端需要先還原文字，才能逐筆解析連結。有些介面則會直接傳回明文連結清單或特定結構化設定。若伺服器傳回網頁、登入提示或錯誤訊息，用戶端不一定能將其辨識為有效訂閱。更新失敗時，應先區分要求失敗與內容格式不相容，而不是直接認定 Base64 編碼有問題。

相同協定也可能採用不同的分享格式

VMess 分享內容常見以編碼後的結構化資料呈現；VLESS 與 Trojan 常見帶有查詢參數的 URI；Shadowsocks 連結則可能採用不同的使用者資訊編碼方式。這些屬於用戶端之間的分享格式，並不完全等同於核心設定格式。即使底層協定可用，匯入工具仍可能因編碼方式、參數名稱或擴充欄位不同而無法完整辨識。不能只看連結前綴是否能辨識，還要確認匯入後的傳輸方式、安全層與驗證欄位是否放在正確位置。

連結中的路徑、備註與查詢值可能經過百分比編碼。手動複製時，換行、空格、聊天工具自動截斷以及重複解碼，都可能改變原始值。尤其路徑中含有問號、井字號或與號時，這些符號在 URI 中具有結構意義，不能一概當成一般文字貼上。建議優先使用用戶端的剪貼簿匯入或掃描功能，不要先在文字編輯器中多次轉換。匯入後應比對欄位的意義，而不只是確認備註文字是否相同。

透過訂閱群組入口更新，再檢查結果

v2rayNG 通常透過「訂閱分組設定」新增群組備註與訂閱網址，儲存後再執行訂閱更新；v2rayN 則在訂閱分組相關選單中管理網址與更新。實際選單名稱可能隨用戶端介面調整，但應區分「儲存訂閱網址」與「取得訂閱內容」這兩個動作。儲存成功不代表遠端內容已下載。詳細操作請參閱訂閱入口與 Base64 格式說明；第一次操作則可依照入門指南完成主要流程。

更新完成後，先確認項目所屬群組、協定類型與重要安全參數，再嘗試連線。如果更新前可用、更新後卻失敗，應比較遠端是否修改了驗證、傳輸方式或安全層，而不是立刻重設整個用戶端。更新某個群組可能會取代由該群組管理的項目；手動修改訂閱項目也可能在下次更新時被覆蓋。若要暫時驗證欄位，應建立獨立測試副本並清楚標示用途，確認後再回到訂閱來源修正，避免長期維護兩份互相衝突的設定。

格式轉換工具只能轉換它能理解的內容。來源訂閱包含的外掛、flow、REALITY 參數或特殊傳輸欄位，若目標格式沒有相應表示方式，轉換結果可能仍可匯入，卻已失去關鍵能力。增加轉換步驟也會讓其他處理方有機會接觸敏感設定。優先使用服務端提供的原生相容格式；確實需要轉換時，應逐項比對轉換前後的欄位。不要把「轉換成功」當成端到端相容的證明。訂閱負責散布設定，無法修復伺服器與核心能力之間的差異。

依使用情境選擇，並找出故障階段

先確認必要條件，再比較使用體驗

已有服務設定時，選擇首先受伺服器端限制。取得 VMess 設定，就先使用支援其驗證與傳輸組合的用戶端；取得 VLESS 與 REALITY 設定，就先確認 Xray 能力及必要欄位。只有伺服器端同時提供多種完整設定時，才適合在相同條件下比較。桌面端建議首選 v2rayN，依作業系統與處理器架構選擇安裝入口；Android 端通常可從 v2rayNG 開始，若需要 V2Fly 路線的設定，再確認 v2flyNG。相關檔案說明統一放在下載頁；本頁不取代安裝檔選擇指南。

日常瀏覽網頁與辦公更重視首次回應、憑證驗證及長期穩定，通常不必為了理論上的開銷增加複雜封裝。使用開發工具與終端機時，應先確認應用程式是否遵循系統代理，是否需要另外設定代理環境變數；瀏覽器可用但終端機失敗，通常是本機連線方式不同，而非遠端協定不適合終端機。可參閱瀏覽器與終端機分別排查的說明，避免反覆修改已能使用的遠端設定中的驗證與安全參數。

使用即時通訊、互動服務或依賴 UDP 的應用程式時，應將 UDP 支援列為必要條件。先檢查用戶端連線方式，再檢查核心、遠端轉送與路由，最後測試實際工作情境。經常切換行動網路的情境，更應重視重新連線、背景執行與工作階段恢復，而非短時間內的最高吞吐量。長時間傳輸可著重觀察持續速率、處理器負載與穩定性，但仍須保持遠端位置與測試資源一致，否則無法分辨網路差異與協定差異。

按階段縮小故障範圍

第一階段，確認設定能否載入。如果記錄顯示未知欄位、無效加密方式或缺少參數，先檢查用戶端匯入與核心相容性，不要先調整路由。第二階段，確認遠端位址能否解析並建立底層連線。解析失敗時重點檢查 DNS；連線逾時則檢查位址、連接埠、網路路徑與遠端監聽狀態。連接埠可連線，只能證明底層入口有回應，不代表代理驗證成功。每次只修正目前階段的問題，能避免多項不相關的變更互相掩蓋。

第三階段，檢查安全交握與驗證。憑證錯誤時，先檢查時間、伺服器名稱與憑證鏈；REALITY 相關失敗時，先檢查公鑰、短 ID、指紋及名稱參數；驗證遭拒時，再核對 UUID、密碼或協定專用欄位。第四階段，確認要求是否進入正確的出站。交握完成但目標無法開啟時，檢查路由比對結果、DNS 解析結果、出站標籤與目標服務狀態。若只有部分應用程式失敗，再回頭檢查系統代理、分應用程式代理與應用程式本身的代理設定，不要直接將局部故障歸類為整條連線失效。

將測試結果整理成維護紀錄

可以為每種候選設定記錄用途、必要欄位、用戶端與核心、測試網路及觀察結果，不必記錄公開後可能遭濫用的帳號密鑰。清楚記下用途是瀏覽網頁、使用開發工具，還是即時通訊；觀察結果則記錄首次回應慢、背景中斷或只有 UDP 失敗。這類紀錄比「某協定不好用」更有參考價值，也有助於更換裝置後重新建立正確設定。更新用戶端或訂閱後，先重新測試基準工作；發現變化時再逐層比對，不要以全部重設取代故障排除。

最終選擇應同時符合三項條件：伺服器端的組合獲得完整支援、安全驗證設定正確，而且實際工作能在目標裝置上穩定執行。符合這些條件後，再依資源使用量、維護難度與網路切換表現作取捨。協定名稱不能取代上述驗證，也沒有適用於所有裝置與工作的固定最佳選擇。常見症狀的簡短解答請見FAQ；若要重新完成匯入、連線與驗證流程，請返回入門指南依步驟操作。