V2Ray 協定與核心
選擇參考指南

設定分層：協定不等於整條連線

先將一筆設定拆成四個層次

用戶端常見的協定名稱，只涵蓋連線流程的一部分。應用程式先將請求交給本機代理入口，核心再依路由決定出站方式，接著以代理協定封裝目標位址與驗證資訊，最後透過指定的傳輸方式連至遠端。安全層則負責保護這段傳輸。因此，VLESS、TCP、TLS 可以同時出現在同一筆設定中，彼此並不衝突，也不能放在同一層互相替代。要判斷設定是否相容，必須一併檢查各個層次，而不能只看清單中的協定標籤。

本機入口與遠端協定也要分開看。瀏覽器連線至本機的 HTTP 或 SOCKS 埠，不代表遠端伺服器也使用相同協定。系統代理通常只是通知遵循系統設定的應用程式，將請求送至本機入口；它不會自動接管所有程式。虛擬網卡模式則在更接近網路層的位置接收流量，涵蓋範圍、權限需求與 DNS 處理方式都不同。遇到某個應用程式無法連線，先確認請求是否進入核心，再檢查遠端協定，才能少走冤枉路。

傳輸方式與安全層各自負責什麼

TCP 提供可靠的位元組串流；WebSocket 在建立連線時加入 HTTP 升級程序；gRPC 則以 HTTP/2 機制組織傳輸。這些方式會影響連線建立流程及中間設備的相容條件，但不會自動取代使用者驗證協定。路徑、服務名稱與請求標頭通常屬於傳輸設定，不是密碼。若用戶端選擇 WebSocket，而伺服器以一般 TCP 接收，即使位址、埠與使用者識別碼都正確，反覆重試也無法解決問題。應先確認連線兩端使用相同的傳輸類型。

TLS 負責驗證伺服器並保護傳輸；憑證名稱、伺服器名稱指示與憑證信任鏈都會影響驗證。REALITY 則是另一種安全層機制，實際支援範圍取決於核心。兩者的設定欄位並非處處都能直接互換。服務名稱中出現 TLS，也不代表設定已啟用正確的安全層；應以介面開關、實際匯出的欄位及執行記錄為準。代理位址可以使用 IP，而驗證時使用網域名稱，兩者用途不同，不必為了看起來一致而強行填成相同值。

依層次逐步排查

取得一筆設定後，建議依固定順序記錄：連線位址與埠、協定與驗證、傳輸類型、安全層及額外流控設定。接著再檢查路由、DNS 與本機代理模式。前一組決定遠端連線能否正確建立，後一組則決定哪些請求使用這條連線，以及網域名稱在哪裡解析。如果一次修改所有選項，即使碰巧恢復連線，也無從得知是哪個步驟生效；下次更新訂閱時，問題可能再次出現。一次只調整一個層次並保留原始設定，結果才容易重現。

記錄也可以依層次閱讀。連線遭拒時，通常先檢查位址、埠與伺服器監聽狀態；交握失敗時，先檢查安全層與傳輸；驗證失敗時，再核對使用者資訊。這裡所說的「先檢查」並非絕對判斷，伺服器主動關閉連線也可能呈現中斷。請將同一時間的錯誤與目前設定對照，避免把背景中其他請求的錯誤，誤當成這條連線的結論。錯誤關鍵字的詳細說明請參閱Xray 核心執行記錄排查筆記。

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

VMess 為何將更多功能納入協定

VMess 是 Project V 早期的重要協定，將使用者驗證與資料保護等功能納入協定設計，方便在不同傳輸環境中建立代理連線。它不只是替原始請求加上一個密碼欄位，交握與資料封裝都有各自的規則。因此，用戶端與伺服器必須支援相同的協定機制。VMess 的實際負載取決於加密實作、處理器效能、外層傳輸與連線重用；不能只因為它較早出現就認定一定比較慢，更不能從協定名稱推斷線路可用頻寬。

現代 VMess 設定通常使用 AEAD 驗證機制。舊教學中常見的額外識別碼參數，屬於歷史相容性背景，不適合當作現今的效能調校選項。匯入舊連結後，若用戶端提示格式過時或驗證失敗，應先向設定提供者確認目前使用的格式，而不是隨意嘗試額外識別碼。VMess 也要求時間同步；裝置日期、時區顯示與實際系統時間需要分開看，真正影響驗證的是系統時間是否準確。先校正系統時間再查看記錄，通常比更換加密選項有用。

VLESS 將哪些工作交由外層處理

VLESS 著重較精簡的協定結構，不在協定內負責與 VMess 相同的資料加密工作，而是搭配外部安全層使用。使用者識別碼可用於驗證，但本身並不足以完整保護傳輸內容。這也說明了為什麼常見設定會同時列出 VLESS 與 TLS 或 REALITY。選擇 VLESS 不代表可以省略安全設定；用戶端若出現「不加密」之類的協定欄位，應理解為只描述這一層，並非整條連線都應以明文通過不可信網路。

UUID 是常見的使用者識別碼格式，匯入時應完整保留，避免混入空格、換行或全形符號。用戶端可以產生新的識別碼，但在本機重新產生不會同步修改伺服器設定。使用者驗證資料必須與伺服器紀錄一致。另一個容易混淆的欄位是流控：它不是全域加速開關，也不是所有 VLESS 組合都需要填寫。只有伺服器明確提供相應設定，且目前核心與傳輸組合支援時，才應照原值使用；不確定時保留匯入內容，不要自行拼湊流控名稱。

實際上該如何選擇

若現有 VMess 設定穩定可用，遷移的理由應是明確的相容需求、伺服器維護方案或實際測得的問題，而不是看到另一種協定更常被討論。用戶端支援某種協定，只代表它能處理這類設定，不代表設定提供者已部署相應服務。反過來，取得 VLESS 設定時也不必逐一尋找 VMess 中的欄位：不同協定的驗證與封裝結構不同，欄位較少不一定是匯入失敗。請參照相同協定的欄位說明，不要照著另一套介面逐項補齊。

在 v2rayN 中檢查時，先開啟伺服器編輯視窗確認協定類型，再檢查傳輸、安全層與流控；v2rayNG 也可依相同順序檢查。介面標籤可能隨用戶端更新而改變，判斷依據應是欄位用途。若更換核心後突然無法連線，請記下切換前後的核心名稱與錯誤訊息，不要刪除 UUID 重新建立。需要復原時，還原整筆已知可用的設定並保留清楚的對照，比在同一筆紀錄上連續修改更容易找出差異。

安全層與傳輸設定都正確後，再比較資源使用情況才有意義。短時間的網頁請求可能主要耗在 DNS 解析與交握，持續下載則更受頻寬、壅塞與加密吞吐量影響，因此兩種負載可能得出不同結論。一般使用者應優先選擇由提供者持續維護、用戶端能完整辨識且不必手動補欄位的組合。選擇協定的目標是減少設定上的疑義，而不是讓每筆紀錄都追求看起來最簡短或最新的名稱。

Trojan 與 SS：密碼之外還有哪些條件

Trojan 需要完整的 TLS 設定

Trojan 的典型設計是在 TLS 連線中進行驗證與代理請求，並由成熟的 TLS 實作保護傳輸。用戶端通常需要伺服器位址、埠、密碼與伺服器名稱，但「欄位少」不代表驗證流程簡單。憑證是否涵蓋相應名稱、是否仍在有效期限內，以及伺服器是否提供完整憑證鏈，都會影響連線。密碼正確但憑證驗證失敗時，問題並不在密碼層。應先判斷安全連線尚未建立，還是連線建立後驗證未通過，再決定檢查哪個項目。

伺服器位址與伺服器名稱指示可以不同。前者決定連線目標，後者會用於 TLS 交握與憑證名稱驗證。若設定提供者提供 IP 位址與網域名稱，不要因為在瀏覽器中連至該 IP 時看不到熟悉的頁面，就認定代理設定有誤。代理監聽服務的回應方式與一般網站不完全相同。正確做法是保留原始欄位，透過用戶端記錄觀察交握結果，並向提供者確認伺服器要求的名稱，而不是隨意填入常見網域名稱。

不建議將略過憑證驗證當成日常修復方法。這會削弱對伺服器身分的確認，也可能掩蓋系統時間錯誤、名稱填寫有誤或伺服器憑證部署不完整等問題。若只有一台裝置連線失敗，先比對系統時間與信任環境；若所有裝置都失敗，則優先確認伺服器設定。交握過程也可能涉及應用層協定協商；若用戶端與伺服器有明確要求，應依設定填寫，不要為了「選項越多越相容」而把所有值都加上。

Shadowsocks 的加密方式與金鑰必須相互搭配

Shadowsocks 在介面中常縮寫為 SS，設計上以精簡的加密代理機制處理流量。實際相容性不只取決於密碼，也與加密方式及協定世代有關。傳統 AEAD 方法和較新的方法，在金鑰格式、身分處理與核心支援上可能有所不同。選擇名稱相同的方法並輸入任意文字，不一定能得到有效設定。設定提供者提供的加密方式與金鑰應視為一組完整參數，不要只複製密碼，再依個人偏好更改加密方式。

部分較新的方法要求特定長度與編碼格式的金鑰，而不是一般口令；用戶端顯示的「密碼」只是統一介面標籤，不代表底層接受任意字串。匯入失敗時，先確認內容是否被聊天工具截斷、特殊字元是否遭到跳脫，以及目前核心是否實作了該方法。自行刪除尾端符號、替換字元或重新編碼，都可能破壞原本正確的金鑰。用戶端能儲存一筆紀錄，也不代表核心一定接受；啟動時的設定檢查結果更值得參考。

外掛、傳輸與協定功能不可混為一談

看到 SS 分享連結附有外掛參數時，還要確認目前用戶端能否辨識並執行該外掛機制。核心原生支援某種加密方式，與用戶端能否呼叫外部外掛，是兩回事。本指南不建議靠不斷更換外掛來試錯。請先確認提供者需要的是原生協定連線，還是附帶特定封裝的組合；若用戶端不支援相應功能，應改用雙方共同支援的設定，而不是把外掛名稱填進傳輸路徑欄位。欄位名稱相似，不代表用途相同。

兩者的實際使用範圍也不同。TCP 網頁瀏覽正常，不代表使用 UDP 的應用程式也能正常運作；UDP 轉送還會受到伺服器能力、路由與本機入口影響。選擇時可先用一般網頁確認基本連線，再針對需要的應用程式個別測試。若需求只是穩定使用日常服務，優先保留參數來源清楚的設定。若必須支援特定應用程式的網路行為，則將 UDP、網域解析與系統接管範圍列入檢查項目，不要把所有差異都歸因於協定速度。

REALITY：安全層與參數的對應關係

REALITY 不是另一個代理協定選項

REALITY 常與 VLESS 一起出現，但兩者處理的問題不同。VLESS 負責代理驗證與請求，REALITY 則處理外層安全交握機制。REALITY 以 TLS 相關機制為基礎設計，並加入自身的驗證與交握處理，不等同於一般網站的憑證部署方式。了解這點後，就不會把「伺服器類型 VLESS」和「安全層 REALITY」誤認為重複設定。也不能在其他協定設定中直接切換安全選項為 REALITY，期待伺服器自動接受；設定組合必須由連線兩端共同支援。

常見的 REALITY 用戶端設定包含連線位址、伺服器名稱、公鑰參數、短識別碼與用戶端指紋，此外也可能包含流控要求。每個欄位都對應伺服器端的設定。公鑰參數供用戶端進行驗證計算使用，不是填入伺服器私鑰的欄位；伺服器私鑰不應放進訂閱或分享連結。不同版本的介面欄位名稱可能有所調整，檢查時應以欄位用途和提供者說明為準，不要只看到「金鑰」兩字，就把同一段內容貼進所有相關欄位。

伺服器名稱、公鑰與短識別碼

伺服器名稱會參與交握，必須符合伺服器允許的設定。它不是可任意填寫的備註，也不一定與實際連線位址相同。伺服器還會設定交握目標等資訊，這些伺服器端細節不能由用戶端單方面更改。取得完整設定後，只需確認用戶端正確保留必要欄位；不要根據名稱猜測目標網站，再自行替換為其他網域。即使替換後的網域能正常開啟，也不代表它符合目前 REALITY 伺服器的設定。

短識別碼通常以十六進位文字表示，必須符合伺服器與實作的格式要求。是否允許留空也取決於伺服器設定，不能一概認為空白就代表遺漏。手動輸入時，請確認字元是否合法、長度是否符合要求，並避免混入空格或全形字元。公鑰也應原樣匯入，不要讓編輯器自動換行後連同換行字元一起儲存。若更新訂閱前能使用，更新後卻失效，先比對這類驗證欄位是否變動，再檢查本機是否仍保留舊的手動覆寫設定。

指紋、流控與排查順序

用戶端指紋通常透過核心提供的交握實作選項生效。介面顯示一長串名稱，不代表目前使用的核心全部支援。遇到「不支援的指紋」或相關初始化錯誤時，先檢查實際使用的核心與設定來源。流控也應獨立檢查，它不是 REALITY 的別名，也不能因為啟用了 REALITY 就任意填寫。常見組合各有適用範圍，尤其更換傳輸類型時，應重新確認流控是否仍適用，不要整套複製上一筆設定的進階選項。

排查可分成三個階段。第一階段確認網路能否連上指定位址與埠；第二階段檢查安全交握能否完成，並核對名稱、公鑰、短識別碼與指紋；第三階段再檢查使用者驗證、流控與實際代理請求。記錄中的同一個交握錯誤可能有多種原因，不應只憑一句錯誤訊息就斷定是公鑰有誤。先確認本機沒有使用其他訂閱群組中同名的紀錄，再確認修改後核心確實重新載入設定，最後將錯誤時間與連線嘗試對照。

使用 REALITY 的前提是提供者有維護這套設定，而且目前用戶端能完整匯入。它不需要使用者照搬一般 TLS 的所有憑證選項，也不代表可以略過參數來源確認。使用 v2rayN 或 v2rayNG 時，應優先保留正常解析後的原始值；若匯入工具不認得安全層，不要改成一般 TLS 來填滿介面。應先處理用戶端與核心的相容性，再討論是否改用雙方都支援的另一套設定。

V2Fly 與 Xray：用戶端背後的執行核心

圖形介面與代理核心不是同一個專案

Project V 是理解這個生態系的起點。V2Fly 社群延續 V2Ray 核心的開發與維護，Xray 則從相關程式碼分支發展，逐步形成自己的功能與設定細節。共同的開發基礎讓兩者在基本概念和許多設定結構上相似，但不代表新增功能會一直同步。不能把它們當成只有下載位置不同、功能完全相同的檔案；也不能只看介面標示「V2Ray」，就判斷實際執行的是哪個核心。執行狀態與記錄中的核心識別資訊更可靠。

v2rayN 是桌面端優先推薦的圖形用戶端，負責伺服器紀錄、訂閱管理、代理模式與核心調度等工作；實際協定連線則由它呼叫的核心執行。v2rayNG 是 Android 上常用的 Xray 核心用戶端，v2flyNG 則適用於需要 V2Fly 核心的情境。這三款用戶端並不是三種代理協定。行動裝置通常也不能像桌面電腦切換程式路徑那樣，任意將另一套核心檔案放進應用程式就取得相同功能；仍應依用戶端本身的版本與支援範圍選擇。

設定結構相似，不代表可以任意互換

兩套核心都有入站、出站、路由與 DNS 等概念，部分基本欄位也相近，因此簡單設定可能有一定的移轉空間。但涉及 REALITY、特定流控、新傳輸實作或擴充參數時，必須查明目前核心是否支援。尤其不能把「能讀取 JSON」理解成「能理解 JSON 中的每個選項」。有些差異會在啟動時直接報錯，有些會由用戶端轉換，還有些要等到發起連線才會顯現。成功儲存只是第一步，不能據此判定相容。

也要留意用戶端層的轉換。圖形用戶端通常會先儲存內部紀錄，再於啟動時產生核心設定；介面顯示的訂閱欄位不一定會原封不動地寫入最終檔案。自訂設定模式則可能略過部分圖形介面的路由與 DNS 產生邏輯。因此，修改介面選項後發現行為沒變，應先確認該筆紀錄是否使用自訂設定，以及該模式是否套用全域設定。不要繼續疊加同類開關，以免增加更多無法生效的設定。

移轉時保留可供比較的基準

更換核心前，先儲存已知可用的用戶端設定，記下協定、傳輸、安全層、DNS 與路由模式。首次啟動新核心時，優先使用簡單且雙方明確支援的設定，確認基本連線正常後，再還原自訂路由。若一開始就同時移轉複雜規則、實驗性傳輸與多個進階欄位，失敗時很難判斷原因。也不要把核心啟動失敗誤認為遠端服務異常：設定語法錯誤或參數不受支援，都可能導致核心根本沒有開始監聽。

確認功能支援時，應以實際安裝環境為準，不必為了比較而編造一份永久有效的支援清單。用戶端更新、核心更新與訂閱格式更新是三條不同的時間線。新版核心提供某個選項，不代表目前用戶端已支援匯入；反過來，用戶端先顯示某欄位，也不保證目前執行的核心已實作。遇到相容性差異時，提供用戶端名稱、實際核心名稱、協定組合與錯誤摘要，比只說「最新版不能用」更容易排查。

日常選擇可以簡單處理：桌面端先使用 v2rayN，Android 則依設定需求選擇 v2rayNG 或 v2flyNG；不要只因名稱相近，就跨核心搬移進階設定。開源代表程式碼與維護過程可供研究，不代表所有分支的行為都會一致。想進一步了解專案關係，可閱讀Project V、V2Fly 與 Xray 生態系整理；想比較各平台操作差異，請參閱三款用戶端比較。

連線速度、資源使用與 Android 耗電

將「快」拆分成不同階段

連線速度至少包含幾個部分：DNS 解析花多久、連上伺服器要多久、安全交握要多久、第一個回應何時抵達，以及持續傳輸能達到多少吞吐量。協定只影響其中部分環節，線路與伺服器通常影響更大。網頁開啟很快，不代表持續下載也很快；下載吞吐量高，也不代表每次短連線都能快速回應。比較兩種協定時，應先說明測量的是哪個階段，避免把不同指標混成一個「延遲」數字，再得出過度簡化的結論。

要得到可解讀的測試結果，應盡量固定裝置、網路、伺服器位置、存取目標與測試時段。測試前暫停訂閱自動更新、背景大型檔案傳輸與頻繁健康檢查，並維持相同的路由模式與 DNS 策略。接著交替測試兩套設定，而不是上午測一套、晚上測另一套。每次都觀察第一個請求與後續請求的差異，因為連線重用、網域快取與 TLS 工作階段恢復都可能影響後續表現。記錄趨勢即可，不必追求看似精確、實際上無法重現的小數點。

CPU、記憶體與連線重用並非越低越好

加密運算、資料複製、傳輸封裝與連線數量都會消耗資源。處理器是否具備相應的硬體加速功能，可能比特定協定標頭的大小更重要。外層使用 TLS 時，內層是否還有額外加密也會增加運算量，但不能因此隨意停用協定要求的保護。記憶體使用量則可能隨活動連線、緩衝區、DNS 快取與規則集增加。看到程序使用量短暫上升，應先觀察連線結束後是否回落，不要把正常快取直接當成記憶體洩漏，也不要只看閒置畫面就比較核心優劣。

連線重用可以減少重複建立連線的負擔，但也可能讓多個請求共同受到同一條連線的壅塞或故障影響。啟用後是否更快，取決於實作、傳輸方式與應用程式負載，沒有適用於所有設定的最佳開關。某些流控或傳輸組合也可能限制連線重用的方式。原本穩定的設定建議保留預設值；只有遇到可重現的短連線問題時，才進行單一項目的對照測試。不要同時調高連線重用、並行數與緩衝區，再把短暫變化歸因於其中一項。

Android 耗電通常不只取決於協定

行動網路耗電與無線電保持啟用的時間密切相關。頻繁傳送保活訊號、反覆重新連線、持續探測，以及背景應用程式的小型請求，都可能不斷喚醒網路，即使每次傳輸的內容很少也會耗電。螢幕關閉後，系統背景限制又可能讓程序進入休眠，恢復時便會重新連線。因此，某種協定在一次長時間下載中的耗電較低，不代表待機整晚也更省電。判斷時應分別觀察螢幕開啟使用與螢幕關閉待機的情況，並盡量維持相近的應用使用習慣與網路類型，避免將情境差異歸因於協定本身。

虛擬網卡的接管範圍、應用程式分流與 DNS 查詢也會影響行動裝置的負載。全流量接管時，更多背景流量可能經過核心；依應用程式或規則分流後，流量路徑與查詢次數都會改變。路由規則過於寬鬆或 DNS 反覆失敗，也可能造成額外請求與重試。耗電異常時，先檢查是否有持續錯誤、頻繁切換網路或過密的連線檢查，再檢查協定。不要只為了降低背景耗電就禁止用戶端所有背景執行，否則可能出現系統仍保留代理入口、實際連線卻已停止的情況。

建議依序處理：先確認設定穩定，再停止不必要的高頻測試，檢查背景執行權限，最後比較不同協定組合。每次測試至少涵蓋一段正常使用與一段待機時間，並觀察是否伴隨斷線重試。若只有某個應用程式明顯耗電，接著檢查該應用程式本身的背景行為，不要立刻更換核心。若已連線卻無法瀏覽網頁，請先依照已連線卻無法瀏覽的逐項檢查清單排查；無法連線導致的持續重試，本身就可能讓耗電判斷失準。

訂閱格式：成功匯入後還要檢查什麼

分享連結、訂閱清單與完整設定

單筆分享連結主要描述一筆伺服器紀錄；訂閱網址通常會提供多筆紀錄或用戶端可辨識的內容。完整核心設定則是另一種格式，可能同時定義本機入站、多個出站、DNS 與路由。這三者不是改個副檔名就能互換的同一種檔案。用戶端的「從剪貼簿匯入」和「新增訂閱網址」處理的對象也不同：將訂閱網址當成單筆伺服器連結，可能只會出現無法辨識的提示；把整段核心 JSON 貼進訂閱網址欄位，也不會自動變成線上訂閱。

不同協定的分享連結在欄位編碼方式上不完全相同，部分格式也存在歷史差異。備註中的中文、特殊符號與空格通常需要正確編碼；部分內容會使用 Base64 表示，但這種編碼並不會保護訂閱內容。連結能複製貼上，不代表經聊天工具轉傳後仍然完整。若匯入筆數異常，先從原始來源重新複製，確認沒有混入說明文字、換行或尾端標點，再查看用戶端的解析提示；不要急著把內容交給不熟悉的轉換工具。

紀錄筆數相同，不代表欄位完整

較新的安全層、流控或傳輸參數，可能會被舊版匯入邏輯忽略。因此，用戶端可能顯示了伺服器名稱、位址與埠，清單看起來也正常，關鍵欄位卻沒有儲存。REALITY 等組合匯入後，至少抽查一筆紀錄：確認協定類型、安全層、伺服器名稱、公鑰參數、短識別碼與流控都符合原始說明。WebSocket 或 gRPC 則應重點檢查路徑、請求標頭或服務名稱。不能只看清單中出現幾筆紀錄，就認定整種訂閱格式完全相容。

不同用戶端對訂閱更新、重複紀錄與手動修改的處理方式也可能不同。有些手動修改會在下次更新時遭到覆寫，有些覆寫設定則會持續套用到新紀錄。維護時最好將訂閱來源群組與本機測試設定分開，先複製紀錄再進行單項修改。不要把訂閱中的同一筆紀錄當成長期手動維護的設定；否則提供者更新伺服器參數後，本機覆寫會與新資料混在一起，很難判斷各欄位的來源。

伺服器紀錄不會自動附帶路由設定

從一個用戶端移轉到另一個用戶端時，伺服器紀錄可以匯入，不代表原有的 DNS、路由、應用程式分流與代理模式也會一併移轉。基本連線成功後，還要重新檢查預設出站與網域處理方式。以下片段是常見核心設定中的路由結構示意，只將環回位址交給名為 direct 的出站；它不是完整設定，無法單獨啟動，完整檔案中必須已定義相應的出站標籤。這類短片段適合說明欄位關係，不適合直接取代用戶端產生的整份設定檔。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "::1/128"],
        "outboundTag": "direct"
      }
    ]
  }
}

AsIs 表示路由判斷不會依此策略主動將網域名稱轉換成 IP；這不代表整個用戶端停止 DNS 查詢，也不代表請求永遠不會解析。其他網域策略會在不同條件下參與解析與 IP 規則判斷，實際行為應搭配核心與 DNS 設定理解。移轉後若路由結果改變，先確認請求進入核心時帶有的是網域名稱還是 IP，再檢查網域規則、IP 規則與最終預設出站，不要只憑選項名稱推測實際路徑。

訂閱更新失敗與伺服器無法使用也要分開處理。前者發生在取得與解析設定的階段，後者則發生在實際連線階段；舊紀錄仍可使用時，不要因為一次更新失敗就刪除整個群組。先檢查更新請求是否成功、回應內容是否為有效訂閱，再核對格式。空白清單等常見狀況可參閱常見問題；需要處理解析與分流設定時，請接著閱讀V2Ray DNS 分流解析設定，不要靠隨意更換協定來迴避設定來源問題。

依使用情境選擇：從需求回頭檢查設定

先確認桌面與行動裝置支援相同功能

桌面端建議先選擇 v2rayN，再依作業系統與處理器架構前往下載頁選擇合適的版本。安裝用戶端後，優先使用設定提供者明確支援的協定組合，不必為了「功能齊全」而啟用所有進階選項。現有穩定可用的 VMess、Trojan 或 SS 設定可以先沿用；取得 VLESS 與 REALITY 組合時，則先確認實際使用的核心及匯入欄位。選擇時，首要目標是讓用戶端、核心與伺服器的功能支援範圍彼此重疊，其次才是最佳化特定情境的資源使用。

在 Android 上，若設定需要 Xray 的相應功能，優先確認 v2rayNG 是否支援；若明確採用 V2Fly 設定與維護方式，再考慮 v2flyNG。不要同時啟用兩款應用程式來比較，因為系統 VPN 接管可能互相影響，測試結果也會混入應用程式切換與連線恢復的因素。背景使用時，先確認系統權限與電池管理符合預期的執行方式，再比較協定。若需要依應用程式分流，還要另外檢查選取範圍，確認瀏覽器測試流量與目標應用程式確實走相同路徑。

依負載測試，不要依名稱排名

日常網頁與訊息應用程式以短請求為主，應重點觀察解析、建立連線與休眠後恢復；持續下載更重視穩定吞吐量、裝置發熱與長連線維持；需要 UDP 的應用程式則必須另外確認相應通路。每種情境都應先使用已知可用的基本設定建立基準，再比較其他組合。如果兩套設定來自不同伺服器，結果只能反映這兩項服務的整體表現，不能證明某種協定天生更好。若無法取得一致的伺服器測試條件，應先看相容性與維護品質，不要急著比較速度排名。

多裝置使用時，所謂同步設定通常是讓不同用戶端訂閱同一個來源，而不是把整份桌面設定直接複製到手機。各裝置的本機埠、系統接管方式、應用程式分流與背景權限仍需分別設定。可以統一伺服器來源與群組名稱，但不要同步不適用於該裝置的系統代理參數。移轉完成後，各裝置都應分別檢查網頁請求、必要的 UDP 應用程式與 DNS 行為，避免將「相同訂閱」誤解成「所有裝置的網路行為都相同」。

建立可復原的檢查流程

實際操作可固定分成四個階段。第一階段只檢查來源與欄位，確認連結完整、驗證參數相符，且傳輸與安全層搭配正確。第二階段確認用戶端呼叫了正確的核心，檢查核心是否成功啟動，以及本機入口能否正常運作。第三階段驗證基本連線，先維持簡單路由，不要同時修改 DNS 與代理模式。第四階段才還原應用程式分流、自訂規則與選用的最佳化設定。每個階段都保留一個已知可用的狀態，遇到問題便退回上一階段，避免把後續最佳化造成的差異誤認為協定本身無法使用。

遇到失敗時，也要判斷錯誤發生在本機還是遠端。核心啟動錯誤、埠遭占用與系統代理殘留屬於本機執行環境；連線逾時、交握失敗與驗證遭拒，才應繼續從網路及伺服器方向檢查。若網頁能開啟，但解析路徑不符合預期，問題可能出在 DNS 與路由，而不是協定驗證。可參考DNS 洩漏檢測與設定實作了解查詢路徑；檢測結果必須依目前的網路與用戶端模式解讀，不能只憑單一頁面的顯示就下完整結論。

最後，保留簡短的維護紀錄即可：用戶端與核心名稱、協定與傳輸組合、特殊安全欄位是否完整、使用的路由模式，以及上次確認可用的環境。記錄問題時請隱藏驗證資訊，只留下足以排查的結構與錯誤摘要。設定提供者調整參數後，先更新訂閱並抽查，再處理本機覆寫。協定指南說明了這些判斷依據；需要重新操作匯入與連線步驟時，請回到快速入門教學，依照單一流程逐步操作，不必在所有進階設定之間反覆嘗試。