V2Ray 協定與核心參考

連線分層：先確認設定屬於哪一層

圖形用戶端、核心與伺服器並非同一個項目

圖形用戶端負責儲存伺服器資料、管理訂閱群組、產生設定檔並顯示記錄。核心讀取產生的設定，處理本機入站、路由判斷、遠端連線與資料轉送。伺服器則接收遠端連線，並依約定完成驗證。介面中出現某個協定名稱，只代表用戶端提供相應的設定入口；能否實際使用，還要看所選核心是否支援，以及伺服器端是否啟用相同的組合。

以桌面使用為例，應用程式會先將請求交給系統代理，再由系統代理指向用戶端建立的本機監聽連接埠。核心取得目標位址後，才決定直接連線或交由遠端出站處理，接著建立遠端協定連線。Android VPN 模式會透過系統提供的虛擬網路介面接收應用程式流量。雖然入口方式不同，後續的協定驗證仍須逐項相符。系統代理已啟用，不代表遠端連線已成功。

將一條連線拆成四組資訊

第一組是伺服器位址與連接埠，說明要連到哪裡。第二組是代理協定與驗證欄位，例如 VMess 的使用者識別碼或 Trojan 的密碼，說明對端如何辨識這次請求。第三組是傳輸設定，決定代理資料如何透過底層連線傳送。第四組是安全設定，涉及 TLS、伺服器名稱、憑證驗證或 REALITY 參數。任一組設定不相符，都可能造成連線逾時或交握失敗。

常見的「VLESS 加 TLS」就是分層組合：VLESS 處理代理請求格式與驗證，TLS 提供外層傳輸安全。WebSocket 是傳輸方式，不能取代使用者驗證；REALITY 則是安全機制，也不是一組可單獨填入伺服器清單的完整驗證資料。閱讀訂閱或教學時，先確認各名詞所屬的層級，才不會在錯誤的頁面尋找設定選項。

連線位址與伺服器名稱可能不同

伺服器位址用於實際建立網路連線；TLS 的伺服器名稱則用於交涉與身分驗證。有些部署中兩者相同，有些則不同。將位址改成 IP 後，不要順手刪除伺服器名稱。反過來，填入正確的名稱也不代表任意位址都能連線。若設定經過反向代理，傳輸路徑、主機欄位與服務名稱還必須符合該部署的入口規則。

連接埠也不能只靠數字推斷用途。相同的常見連接埠可能承載不同服務，看到某個連接埠號碼，不能斷定它一定啟用了 TLS。用戶端的「允許不安全連線」通常與憑證驗證有關，不是提升相容性的通用選項。正常設定應保留身分驗證；發生憑證錯誤時，先檢查系統時間、名稱與信任鏈，不要關閉驗證來掩蓋欄位不符。

實際核對時，先記下用戶端名稱、核心名稱、協定類型、傳輸類型與安全類型，再與服務提供者提供的完整資料逐項比對。一次只修改一項，儲存後重新連線，並查看該次操作對應的記錄。如果原始訂閱可用，手動重建卻無法連線，應先比較是否漏了欄位，而不是先更換路由規則。建立分層記錄，比記住固定的按鈕位置更適合日後查閱。

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

VMess 在協定內處理較多工作

VMess 是 Project V 生態系中較早廣泛使用的代理協定，設計上將使用者驗證與資料保護納入協定本身。其使用者識別碼通常採 UUID 格式，用戶端也可能顯示加密方式等欄位。現代設定應依伺服器端支援的驗證方式使用；舊式參數不能照著舊教學直接填入。尤其是 alterId，舊的分享資料中可能仍包含這個欄位，但不代表應主動設定非零值。

VMess 的連線驗證與時間有關，因此裝置時間明顯不準時，可能出現資料看似正確卻驗證失敗的情況。排查時先啟用作業系統的自動設定時間與時區，再重新連線。顯示的時區不同，不代表時鐘一定有誤；關鍵在於系統時間是否準確。如果同一份資料在另一台裝置可用，也應先比較裝置時間與核心支援狀況，而不是反覆複製使用者識別碼。

VMess 本身具備資料保護能力，不代表外層 TLS 一定多餘。外層安全、傳輸承載與代理協定各有用途，實際組合取決於伺服器端部署。若已有完整訂閱，正確做法是保留原有組合並核對匯入結果，而不是看到「加密」就刪除 TLS 設定。任意移除一層，未必能讓連線更輕量，反而可能變成伺服器根本沒有監聽的連線形式。

VLESS 精簡協定本身，不代表整條連線都更簡單

VLESS 的設計方向是減少協定本身承擔的工作，不像 VMess 一樣在協定內提供資料加密層。使用者仍須提供正確的識別碼，連線資料的安全性通常由配套安全機制負責。介面中常見的 encryption 為 none，表示該欄位依協定約定不使用加密，不是建議關閉外層安全。跨網路連線應採用伺服器端明確支援的完整安全組合。

因此，「VLESS 比 VMess 少一層，所以任何情境都更快」並不成立。開啟一個網頁還涉及網域名稱解析、建立連線、外層安全交涉、伺服器處理與目標網站回應；協定標頭的差異只是其中一環。短連線可能更受交握影響，長時間傳輸則可能更受線路容量與裝置加密能力影響。同一協定換到不同線路，效能差異也可能遠大於協定本身的差異。

flow 是配套條件，不是通用加速選項

部分 VLESS 設定會帶有 flow，例如搭配特定流量控制方案的值。這個欄位必須同時符合用戶端核心、伺服器端設定、傳輸方式與安全組合的要求。訂閱未提供時，不要因為教學截圖出現過就自行加入；訂閱有提供但匯入後消失，則應檢查分享格式與解析器是否保留該欄位。只切換協定下拉選單，無法自動建立有效的流量控制組合。

手動檢查可依照「協定類型、使用者識別碼、加密欄位、傳輸、安全、流量控制」的順序進行。先確認協定下拉選單，再檢查 UUID 是否多了空格，接著查看傳輸與安全設定頁面。如果記錄顯示欄位不明或不支援流量控制，先確認目前實際啟動的核心，而不只是查看用戶端介面是否提供該選項。介面可編輯與執行時可辨識，是兩個不同條件。

已有穩定可用的 VMess 設定時，沒有必要只為了協定名稱而遷移。新設定若提供 VLESS，可依核心支援狀況與安全組合評估，但仍須實際測試應用程式。進一步比較可閱讀VMess 和 VLESS 的加密方式與相容性。選擇的目標是取得欄位完整、伺服器端支援且便於維護的設定，而不是把「更精簡」誤解為不必檢查其他層。

Trojan、SS 與 REALITY：分清協定與安全機制

Trojan 的前提是 TLS 連線正確

Trojan 將代理驗證放在 TLS 保護的連線中，常見圖形設定包含位址、連接埠、密碼與伺服器名稱。其設計以外層 TLS 為重要基礎，因此密碼正確仍不足以確保連線可用。伺服器憑證名稱、系統信任狀態與實際連線端點都必須相符。若用戶端先回報憑證錯誤，問題發生在代理密碼驗證之前；此時更換密碼通常不會改變結果。

Trojan 密碼應以完整字串儲存，複製時留意前後空格、換行及連結中的編碼字元。有些分享連結會以百分比編碼特殊字元，用戶端應依相應格式解析。手動編輯時，不要將已解碼的密碼再做沒有依據的跳脫，也不要把連結中用於分隔欄位的符號當成密碼的一部分。最好先直接匯入原始連結，再與手動填入的結果比較。

Shadowsocks 必須同時核對加密方法與密碼

Shadowsocks 常簡稱為 SS，源自相對精簡的加密代理設計。設定時應確認伺服器位址、連接埠、加密方法與密碼。加密方法不是可以任意挑選的本機偏好，而是通訊雙方的約定。即使密碼正確，方法不符仍無法正常解密。舊資料中的方法名稱也不代表目前所有核心都支援，應以實際實作與伺服器端設定為準。

傳統 AEAD 方法與 Shadowsocks 2022 系列的金鑰要求不同。後者可能要求符合長度與編碼規範的金鑰，不能直接填入一般密碼並期待自動相容。分享格式也可能包含擴充參數，而三款用戶端支援的擴充欄位範圍未必相同。若匯入成功但執行失敗，應核對方法名稱、金鑰格式與核心支援狀況，不要只確認清單中是否出現伺服器名稱。

應從安全層理解 REALITY

REALITY 是 Xray 生態系中的安全機制，不應與 VMess、VLESS、Trojan、Shadowsocks 放在同一層比較。常見組合是 VLESS 搭配 REALITY：VLESS 負責代理協定部分，REALITY 則提供配套的安全交握機制。設定仍須包含有效的位址、連接埠與使用者驗證資料，以及伺服器端提供的公開金鑰資料、伺服器名稱、短識別碼等參數。

不能只把一般 TLS 的開關改個名稱，就當作完成 REALITY 遷移。伺服器端必須明確支援，所用用戶端核心也必須能辨識相應參數。介面欄位名稱可能因實作而異，核對時應了解各欄位用途：哪些是公開驗證資料、哪些是使用者驗證資訊、哪些是交握名稱。私密金鑰是伺服器端的敏感設定，不應出現在用戶端訂閱中，也不該被索取來補上「匯入時缺少的欄位」。

比較這些方案時，應寫出完整組合。例如只寫「使用 REALITY」，不足以判斷使用者驗證方式；只寫「使用 SS」，也無法確認加密方法。用戶端顯示的簡稱方便瀏覽清單，卻不適合作為排錯資料。記錄完整組合有助於減少溝通誤差，也能避免把外層交握失敗誤認為代理協定本身的問題。

實際選擇應以現有伺服器設定為起點：只有 Trojan 入口，就先核對 TLS 與密碼；只有 SS 入口，就核對加密方法與金鑰；有 VLESS 與 REALITY 入口，再確認 Xray 支援與欄位是否完整。協定資料不足時，應向設定提供者補齊，不建議輪流嘗試所有安全選項來猜測。猜測會增加新的變數，讓原本缺少的欄位更難找出。

效能與耗電：比較整條連線的成本

連線速度包含不同階段

使用者感受到的速度，至少包含開始連線、收到第一段內容與持續傳輸三個階段。第一階段受網域名稱解析、往返路徑與交握次數影響；收到第一段內容還取決於遠端目標的回應；持續傳輸則受線路容量、壅塞與裝置處理能力限制。因此，比較協定前必須先說明測試的是哪個階段。將單次延遲測試結果直接當成下載速度排名，很容易得出與實際使用相反的結論。

協定驗證、加密與封裝確實會消耗資源，但不同裝置的硬體加速、系統排程與實作最佳化都會影響結果。VMess、VLESS、Trojan 或 SS 這些名稱本身，無法決定固定的 CPU 使用率順序。VLESS 協定本身不負責同類型的加密工作，不代表配套的 TLS 或 REALITY 沒有成本。應在相同裝置、相近線路與明確安全組合下比較，而不是只看下拉選單中的名稱。

傳輸封裝與連線多工也有成本

WebSocket 等承載方式可能為了配合伺服器入口而增加額外封裝，這項成本在不同使用情境中的影響不一。多工則嘗試透過較少的底層連線傳送多個請求，可能減少重複建立連線的次數，也可能讓多個請求一起受到單一連線的封包遺失與排程影響。是否啟用必須配合伺服器端與流量控制方案，不能把所有名稱含「多工」的選項都打開。

測試時先選定同一個目標網站，保留相同的路由與 DNS 設定，分別觀察首次開啟、再次開啟與持續讀取的狀況。每輪只改變一個變數，並記錄是否重新建立連線。瀏覽器快取、目標網站快取與既有連線都會影響結果，因此重複測試一次並不代表誤差自然消失。如果不同設定連到不同伺服器，結果主要反映兩條服務線路，不能單獨證明某個協定效率較高。

Android 裝置的耗電更受持續運作方式影響

Android VPN 模式透過系統的 VpnService 接收應用程式流量。只要應用程式持續發出網路請求，用戶端就可能被喚醒並處理資料；連線重試、DNS 查詢與寫入記錄也會增加活動量。某個協定在桌面裝置上的資源使用率較低，不代表手機待機時也一定更省電。無線網路品質、背景應用程式數量與系統省電策略，往往是行動裝置耗電差異的重要因素。

排查耗電時，可先在相同使用習慣下，比較啟用與停用用戶端期間的系統電池記錄，再進一步檢查 VPN 模式、依應用程式代理與特定應用程式。觀察耗電是否集中在訊號不穩、頻繁切換網路或背景持續傳輸的時段。如果記錄顯示反覆重新連線，應先處理連線失敗的原因。單純延長所有逾時時間，可能只讓失敗的連線等待更久，並未減少實際工作量。

記錄層級應配合排錯目標。暫時診斷時可提高詳細程度，確認問題後應恢復為適合日常使用的層級，避免持續產生大量記錄。延遲探測與自動測試也會主動發起連線，不應為了觀察狀態而設定過於頻繁的測試。用戶端清單更新、訂閱更新與實際使用流量也應分開檢視；背景活動不一定都來自正在使用的應用程式。

如果只有特定應用程式耗電或連線失敗，請檢查它是否使用 UDP、長連線或背景推播，再核對代理範圍。只讓必要的應用程式進入 VPN 路徑，有時能減少無關流量，但前提是了解依應用程式代理模式的含義。詳細設定請參閱v2rayNG 權限、省電與依應用程式設定。速度問題則依節點、線路與本機設定逐層排查處理，不要以更換協定取代問題定位。

V2Fly 與 Xray：依功能核對相容性

同屬一個生態系，不代表實作完全相同

Project V 是了解 V2Ray 生態系的背景；V2Fly 延續相關核心與元件的開發，Xray 則在共同歷史基礎上發展出自己的功能方向。兩者在部分協定、設定結構與術語上相近，因此不少基本設定看起來類似，但不代表任何檔案都能直接互換。安全機制、流量控制、傳輸細節與 DNS 行為可能不同，必須依具體功能判斷。

REALITY 與特定 VLESS 流量控制方案，是選擇核心時常見的分界點。如果訂閱明確要求 Xray 提供的相關功能，改用 V2Fly 不會因為設定格式相似就自動支援。另一方面，不需要這些功能的基本連線，也不能據此推論必須使用特定核心家族。選擇核心應配合現有協定組合與維護需求，而不是把家族名稱當成效能等級。

三款用戶端在同一連線中的角色

v2rayN 是桌面端的優先選擇，適用於 Windows、macOS 與 Linux。它負責圖形介面管理與產生設定，實際核心功能仍須依所用發行版本與執行設定確認。介面允許選取某個參數，不代表任意核心都能處理。排錯時應查看實際啟動記錄，確認執行的是預期核心，而不是只根據用戶端名稱推斷執行環境。

Android 版 v2rayNG 使用 Xray 核心；v2flyNG 則是採用 V2Fly 核心的另一種選擇。兩款應用程式的操作方式可能相近，但不能因此忽略協定功能差異。若匯入資料包含只有其中一方支援的安全或流量控制功能，應先依功能選擇用戶端，再設定權限與連線。完整比較請見三款 V2Ray 用戶端選型比較。

遷移設定時應檢查產生結果

遷移時，最可靠的起點是原始訂閱或完整分享資料，而不是根據舊用戶端的截圖逐項猜測。先在目標用戶端建立獨立群組，匯入後核對協定、位址、驗證、傳輸、安全與流量控制。不要立刻刪除舊設定，先測試單一入口。如果原始資料缺少擴充參數，即使目標用戶端支援相關功能，也無法憑空還原遺漏資訊。

遷移原生 JSON 時，還要區分完整設定與局部出站。完整設定可能同時指定本機監聽、路由標籤、DNS 與記錄；新核心接受某個欄位，不代表整體行為都能維持一致。尤其路由引用的標籤必須與出站標籤相符，否則可能發生設定可載入，但目標流量未依預期路徑轉送的情況。應先驗證最基本的連線，再逐步遷入本機策略。

升級用戶端與升級核心也不一定是同一個操作。不同發行方式可能將核心隨套件提供，也可能透過用戶端功能管理。請以實際安裝套件與介面說明為準，不建議混用來源不明的核心檔案。升級前先匯出並保留設定，升級後核對重要連線與路由行為；若發生問題，記錄變更範圍，分辨是解析器、設定產生或核心執行有所改變。

開放原始碼代表程式碼與實作可以被研究和改良，不代表所有分支都採用相同授權、發布週期或功能清單。轉發或重新散布時，應依各元件的實際授權條款處理。日常選擇時，最有用的紀錄是「用戶端、實際核心、所需協定功能」三項，而不是籠統地寫成「已安裝 V2Ray」。這份紀錄也能讓後續問題描述更精確。

訂閱格式：匯入成功不代表欄位完整

網址、內容與內部設定是三回事

訂閱網址只是取得內容的入口，網址結尾並不能決定回傳格式。一次請求可能取得分享連結清單、經過 base64 編碼的清單、原生 JSON 或錯誤頁面。用戶端取得內容後，還須辨識格式、解析欄位，再轉換成自己的設定模型。因此，瀏覽器能開啟網址只代表請求收到回應，不能證明回傳內容是目前用戶端可辨識的伺服器資料。

base64 是編碼方式，不是加密協定，也不會自動讓內容變得安全。常見訂閱會先將多條分享連結串成文字，再進行編碼；解碼後仍須依各連結的規則解析。重複編碼、缺少換行、混入網頁標籤或字元集處理錯誤，都可能影響辨識。請勿將私人訂閱上傳至線上解碼工具；訂閱網址本身可能含有存取憑證，應視為敏感資訊妥善保存。

分享連結沒有統一的欄位語法

常見的 VMess 分享連結會帶有經過編碼的結構化資料；VLESS 和 Trojan 連結常以位址搭配查詢參數；SS 則有不同的分享格式。協定前綴相似，不代表查詢參數可以互相套用。名稱通常只是備註，修改名稱不會改變遠端功能；傳輸路徑、伺服器名稱與流量控制則可能直接影響連線，轉換時不能一併刪除。

解析器也必須能辨識擴充欄位。有些用戶端可能保留協定主體，卻忽略不認識的安全參數，最後出現清單中有項目但連線失敗的情況。匯入後至少開啟一次伺服器編輯頁面，核對協定、傳輸、安全類型與重要附屬欄位。若發現資料遺失，應優先尋找適用於目標用戶端的原始格式，而不是反覆更新同一份已遺失欄位的轉換結果。

原生 JSON 不一定適合用於訂閱群組入口

原生 JSON 可以是一整套執行設定，也可能只是部分出站資料。完整設定可能包含本機監聽連接埠、DNS、路由規則與多個出站，其匯入方式不同於一般伺服器訂閱。有些用戶端會將它作為自訂設定管理，不能期待它自動拆成一般清單中的多個伺服器。匯入前應先確認入口說明，避免將完整設定當成逐條節點資料處理。

完整設定也可能覆蓋原本的本機行為。例如，訂閱清單通常由用戶端統一產生監聽與路由；自訂 JSON 則可能自行指定這些內容。若匯入後系統代理失效，應檢查實際監聽連接埠是否仍與系統設定相符。如果有額外設定路由標籤，也要確認引用的出站項目存在。不要因為 JSON 語法正確，就認定它適合目前圖形用戶端的管理方式。

在 v2rayN 中，可從訂閱群組管理進入「訂閱群組設定」，儲存網址後執行相應的更新操作。如果有「更新目前訂閱（不透過代理）」選項，表示這次取得訂閱內容時不會使用既有代理路徑，不代表回傳內容會變成其他格式。既有連線正常但直接更新失敗時，可檢查用戶端支援的更新方式；若完全沒有可用連線，則應先確認能否直接連上訂閱入口。

更新訂閱後沒有伺服器項目，應先確認請求是否成功，再檢查內容能否解析，最後確認是否被群組篩選條件隱藏。回傳登入頁、流量額度說明或錯誤文字，與格式不相容是不同問題。更新後只有少數項目失效，應優先檢查對應的協定欄位，而不是刪除所有群組。向他人描述問題時，可提供已移除個人資訊的錯誤類型與協定組合，不要公開完整訂閱網址或驗證資料。

格式轉換只有在資訊足夠時才能保留原有語意，無法憑空補齊伺服器端參數。將完整設定匯出成簡單連結時，複雜路由與 DNS 通常無法一併帶入；將連結重建成 JSON 時，也無法還原原始資料未包含的本機策略。更多範例請見base64、原生 JSON 與分享連結的轉換限制。完成轉換後，仍須重新核對重要欄位並測試連線。

路由與參數：協定可用後再設定分流

先分清本機入口與遠端出站

本機 SOCKS 或 HTTP 監聽用來接收應用程式請求，遠端出站則負責連線至伺服器。兩者的連接埠可能完全不同，不能把伺服器連接埠填入應用程式的本機代理設定。介面中常見的本機連接埠只是範例，實際值應以用戶端目前的監聽設定為準。如果本機連接埠被其他程式占用，核心可能無法啟動；此時即使遠端協定資料正確，也不會被使用。

以下是一段實際的入站設定片段，用來說明欄位之間的關係，並非可單獨用來連線伺服器的完整設定。它只監聽本機迴路位址，應用程式必須連線至同一裝置上的對應連接埠。不要為了解決應用程式設定問題，就隨意將監聽位址改為所有網路介面；這會改變其他裝置存取本機代理的範圍。遠端協定與驗證資料須由完整出站設定另外提供。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

domainStrategy 控制路由比對時的解析方式

路由中的 domainStrategy 決定比對規則時如何處理目標網域。AsIs 優先保留原始目標格式，不會為了比對 IP 規則而主動將網域轉成位址；IPIfNonMatch 會在網域規則未命中時嘗試解析，再繼續比對 IP 相關規則；IPOnDemand 則會在比對需要 IP 資訊的規則時觸發解析。三者影響的是規則比對過程，不會直接決定請求一定走代理或直連。

這些選項也不應與出站本身或其他模組中名稱相近的策略混為一談。選擇前應先確認欄位位於哪個設定物件，再閱讀其含義。如果應用程式一開始只提供 IP，路由未必能直接比對網域。流量嗅探有時能從連線內容取得網域線索，但不適用於所有協定與流量，也不能保證還原應用程式原本使用的完整網域資訊。

DNS、規則順序與目標格式會共同影響結果

常見路由會依序尋找符合條件的規則。較寬泛的條件若排在前面，可能讓後續更精確的規則沒有機會生效。網域規則與 IP 規則也取決於當下可用的目標格式。排查「規則已設定卻未生效」時，應先確認請求實際呈現為網域還是 IP，再查看哪條規則先命中，最後檢查目標出站標籤，而不是一開始就放寬所有規則範圍。

核心 DNS 與作業系統 DNS 的作用範圍也可能不同。應用程式可能自行解析，核心可能為了路由判斷再次解析，遠端伺服器也可能解析最終目標。修改一個 DNS 位址，不能證明所有請求都採用相同路徑。若網域可以連線，但某條 IP 規則未如預期生效，應檢查解析發生的位置、回傳的位址類型與快取，再決定是否調整 domainStrategy。

Android 的依應用程式代理功能，控制哪些應用程式進入或繞過 VPN 路徑；核心路由則決定進入後的流量如何轉送。啟用繞過模式時，應用程式清單的意義可能從「包含」變成「排除」，應以介面說明為準。修改後，須依用戶端要求重新建立 VPN，系統才會套用新的範圍。測試時請選定一個明確的應用程式與目標，避免同時修改應用程式清單、DNS 與網域規則。

建議依序驗證：本機監聽已建立、應用程式請求確實進入、協定連線正常，最後再加入分流規則。發生問題時，先暫時回到已驗證的簡單策略，再逐條恢復規則。分流、DNS 與代理模式的常見狀況請參閱常見問題。如此便能將「入口未接入」、「遠端無法連線」與「路由未命中」拆成三個獨立問題，不必反覆修改協定欄位碰運氣。

使用情境與排錯：將選擇落實為核對順序

桌面端先選用戶端，再核對協定組合

桌面端建議從 v2rayN 開始，在下載頁面依作業系統與裝置架構選擇對應安裝檔。安裝檔的介面類型與遠端協定是兩種不同選擇：Windows 桌面版與經典 WPF 版的差異在介面與發行形式，不代表需要分別購買或建立不同的協定入口。已有訂閱時，先匯入並測試一條連線，再調整介面偏好與本機群組。

Android 裝置若使用明確需要 Xray 功能的設定，應選擇 v2rayNG；若現有資料是為 V2Fly 提供且功能相符，可考慮 v2flyNG。不要因為兩款應用程式都能辨識相同的前綴，就忽略配套安全參數。長時間在背景執行時，還須確認 VPN 權限、省電策略與依應用程式設定範圍。系統收回權限導致連線中斷，不應靠更換 UUID 或加密方法解決。

現有資料決定可選範圍

只有一套有效的伺服器資料時，應優先正確設定，而不是依通用排名改選其他協定。伺服器端提供多個入口時，再比較用戶端支援程度、資料完整性、實際使用表現與維護成本。對經常需要遷移裝置的人來說，格式是否通用、重要欄位能否完整匯入，可能比少量協定開銷更重要。需要特定 Xray 功能時，核心支援則是不可略過的條件。

區域網路管理、網頁瀏覽與長時間傳輸對連線的要求不同。瀏覽網頁常涉及許多短請求；即時應用程式更重視連線穩定性與 UDP 路徑；長時間傳輸則更仰賴線路的持續容量。協定名稱無法取代實際業務測試。選擇一項實際工作，在相同網路條件下完成，再檢查斷線重連與切換網路後的恢復狀況，會比只看清單中的單次測試結果更符合實際需求。

依失敗階段定位，不要猜測著更換參數

第一步，確認核心是否啟動。若出現設定解析失敗、欄位不明或連接埠被占用，先處理本機問題。第二步，確認能否連上伺服器位址與連接埠；連線逾時可能與位址、路由或遠端監聽有關，還不能據此判定密碼錯誤。第三步，檢查安全交握，重點確認系統時間、伺服器名稱、憑證與 REALITY 參數。最後再檢查代理驗證與目標轉送。

如果記錄顯示連線已建立，但應用程式沒有資料，應確認請求是否真的進入用戶端，再核對 DNS、路由目標與遠端存取能力。若只有某個網站失敗、其他網站正常，通常應針對目標網域與應用程式行為縮小範圍，不宜直接重新安裝用戶端。若只有 UDP 相關服務異常，應檢查本機入口、協定支援與伺服器端轉送能力，不能以一次 TCP 連線成功就認定一切正常。

需要協助時，請保留與單次失敗操作相對應的記錄片段，並記下用戶端、實際核心、協定、傳輸、安全機制與失敗階段。移除訂閱憑證、密碼、使用者識別碼及其他可能連結個人帳戶的資訊；截圖也要檢查是否露出隱藏區域或完整網址列。只描述「連不上」，排查就得從頭開始；明確指出「安全交握失敗」，便能排除許多無關設定。

最後可將選擇歸納為三個問題：伺服器端提供了哪些完整組合？目前使用的核心能否照原樣設定？實際應用程式在目標裝置上是否穩定運作？確認這三點後，再調整路由與背景行為。首次連線請以入門教學為主；反覆出現的具體狀況可查閱常見問題；想了解設計差異時，再回到本手冊的相關章節。將操作、原理與排錯分開處理，設定會更容易維護。