V2Ray 協定、核心與用戶端選擇手冊

01 / DECISION MODEL

先建立協定選擇的判斷模型

協定、傳輸、安全層與用戶端並非同一層

看到一筆節點資訊時，先將它拆成四層。第一層是代理協定，例如 VMess、VLESS、Trojan 或 Shadowsocks，規定用戶端如何驗證、如何組織連線，以及伺服器如何辨識請求。第二層是傳輸方式，例如 TCP、WebSocket、gRPC，決定資料如何承載於網路連線中。第三層是安全層，例如 TLS 或 REALITY，負責握手身分、加密通道或特定連線驗證。第四層才是用戶端與核心：v2rayN、v2rayNG、v2flyNG 提供介面，V2Fly 或 Xray 負責實際解析設定並建立連線。

這四層可以組合，但不能任意互換。VLESS 是協定，REALITY 是由 Xray 體系實作、並與特定傳輸形式搭配的安全方案，因此「VLESS」和「REALITY」不是兩個完全平行的選項。同樣地，WebSocket 不是代理協定，TLS 也不是節點類型。用戶端訂閱中常見的「VLESS + TCP + REALITY」，實際上是三層組合。匯入後遇到欄位很多的情況，按層檢查比逐一猜測參數更可靠。

選擇順序應從相容性開始

選擇協定時，第一項不是理論速度，而是伺服器與用戶端核心是否共同支援。伺服器只提供 VMess 時，討論用戶端使用 VLESS 的開銷優勢沒有實際意義；訂閱提供 REALITY 參數時，則要確認目前用戶端使用的核心能否辨識相關欄位。通過相容性確認後，再比較網路環境、裝置資源、連線數量與維護難度。最後才看極限吞吐量，因為多數日常差異來自線路品質、握手重試、網域解析與傳輸層設定，而不是協定名稱本身。

較穩妥的檢查順序是：先辨識連結方案名稱，再確認用戶端核心，接著查看傳輸與安全欄位，最後檢查位址、連接埠和驗證資訊。不要只根據節點顯示名稱判斷協定。顯示名稱是訂閱提供者寫入的標籤，可以包含任意文字；真正決定解析方式的是連結方案，以及設定中的 protocol、network、security 等欄位。

穩定性是整條連線鏈路的結果

相同協定在不同設定下可能有完全不同的表現。TCP 直連通常結構簡單，額外處理較少；WebSocket 便於搭配常見 Web 服務部署方式，但會增加訊框封裝成本；gRPC 以 HTTP/2 為基礎，連線管理能力較強，也會帶來更複雜的參數關係。TLS 的憑證名稱、系統時間與 SNI 必須相互吻合，否則即使協定設定正確也無法完成握手。REALITY 則要求用戶端與伺服器在短識別碼、公開金鑰、服務名稱等欄位上保持一致。

因此，選擇時應記錄「協定 + 傳輸 + 安全層 + 核心」的完整組合，不要只記下一個縮寫。排解問題時也依相同順序回查。若匯入成功但無法連線，先確認用戶端是否辨識協定，再確認傳輸欄位是否完整，最後查看安全層參數。若所有欄位都一致，再檢查 DNS、系統代理和本機連接埠。更具體的錯誤現象可前往疑難解答逐項核對。

02 / VMESS

VMess：完整驗證體系與成熟的相容範圍

設計背景與協定職責

VMess 是 Project V 早期生態中具代表性的協定。它將使用者識別、請求資訊與時間相關的驗證流程納入協定設計，用戶端與伺服器透過 UUID 等資訊辨識使用者。它的主要特色不是「某一種固定加密演算法」，而是一套包含驗證、請求封裝與連線協商的完整機制。由於出現較早，許多 V2Ray 設定、訂閱產生器和圖形用戶端都能辨識 VMess，歷史相容範圍較廣。

VMess 設定通常包含伺服器位址、連接埠、使用者 UUID、alterId、傳輸方式與安全層。目前設定中常見的 alterId 多為零，但舊訂閱仍可能帶有其他值。匯入用戶端時不應擅自修改此欄位，因為伺服器設定與用戶端必須一致。加密選項常見為 auto，實際行為由核心依設定處理。若訂閱能正常更新但 VMess 節點全部連線失敗，應優先核對系統時間，因為時間偏差可能直接影響驗證階段。

VMess 的優勢與代價

VMess 的優勢在於資料成熟、設定工具涵蓋廣，V2Fly 與 Xray 通常都能處理常見組合。對於需要在不同用戶端之間移轉、伺服器仍採用傳統 V2Ray 設定，或訂閱格式已穩定運作的情境，繼續使用 VMess 往往比主動更換協定省事。它也能搭配 TCP、WebSocket 等傳輸方式，並可疊加 TLS。對維護者而言，既有部署若運作穩定，沒有必要只因出現新協定就立即遷移。

代價主要來自協定處理相對複雜，驗證與封裝步驟比輕量設計更多。在運算能力充足的桌機上，這種差異通常不明顯；在低功耗裝置、高並發連線或頻繁喚醒的行動環境中，額外處理則更容易被察覺。不過，實際耗電與速度仍受網路品質主導。反覆連線失敗造成的重試，往往比單次協定運算消耗更多資源，因此「設定能穩定完成握手」比紙面上的開銷更重要。

常見欄位如何核對

先檢查位址與連接埠是否完整匯入，再確認 UUID 是否保持原樣。UUID 應符合標準分段格式，複製時不能帶有多餘空格。接著查看傳輸層：若伺服器使用 WebSocket，用戶端的路徑與 Host 必須相符；若疊加 TLS，SNI 或 serverName 應與憑證涵蓋的名稱一致。用戶端中顯示的備註不參與連線，可自由修改，但其他欄位不要為了「看起來更簡潔」而刪除。

{
  "protocol": "vmess",
  "settings": {
    "vnext": [
      {
        "address": "server.example.com",
        "port": 443,
        "users": [
          {
            "id": "11111111-2222-4333-8444-555555555555",
            "alterId": 0,
            "security": "auto"
          }
        ]
      }
    ]
  }
}

上面的片段只展示 VMess 出站中的核心層級。完整設定還需要流量入口、傳輸參數與路由部分。手動輸入時，介面欄位與 JSON 名稱可能不同，例如「使用者 ID」對應 id，「額外 ID」對應 alterId。只要意義一致即可，不必追求介面文字與底層欄位逐字相同。

哪些情況適合保留 VMess

伺服器已穩定運作、訂閱供多部裝置使用、用戶端同時存在 V2Fly 與 Xray 核心時，VMess 是較保守的相容選擇。尤其當設定包含傳統 WebSocket 與 TLS 組合，而維運目標是減少遷移變數，優先維持現況更合適。若要建立新設定，且用戶端與伺服器都明確支援 VLESS，則可以進一步比較驗證開銷與安全層選擇，但這不代表 VMess 已失去使用價值。

排解 VMess 問題時，先區分「匯入失敗」與「握手失敗」。匯入失敗通常涉及連結編碼、訂閱內容或用戶端解析問題；握手失敗則多與時間、UUID、傳輸路徑、TLS 名稱和連接埠有關。不要在兩個階段之間反覆修改所有參數。一次只改一項，並記錄修改前後的結果，才能確認真正的故障點。

03 / VLESS + REALITY

VLESS 與 REALITY：輕量協定與安全層組合

VLESS 為何採用更輕量的設計

VLESS 將協定驗證與傳輸安全更明確地分開。它使用 UUID 辨識使用者，但不在協定內部承擔與 VMess 相同的加密職責，而是把通道安全交給 TLS、REALITY 等外層方案。這種分層讓協定本身更簡潔，也方便核心依傳輸與安全層組合功能。需要注意的是，「協定本身更輕」不代表可以省略安全層；是否需要 TLS 或 REALITY，應由完整部署方案決定。

在用戶端中，VLESS 節點通常包含位址、連接埠、UUID、流量控制、傳輸網路、安全類型、服務名稱和指紋等欄位。欄位之間存在組合限制。例如某些流控值只適用於特定傳輸和安全層；REALITY 會額外要求公開金鑰、短識別碼、serverName 等資訊。若訂閱漏掉其中一項，用戶端可能仍能建立節點，但會在握手階段失敗。因此，判斷匯入是否完整不能只看清單中是否出現節點。

REALITY 的位置與參數關係

REALITY 不是獨立的代理協定，而是 Xray 體系中的安全與握手機制，通常與 VLESS 組合使用。用戶端需要採用能解析相應欄位的 Xray 核心。設定中的 publicKey 用於用戶端驗證，shortId 用於比對伺服器設定，serverName 參與握手目標選擇，fingerprint 則描述用戶端握手指紋策略。這些欄位不是可以互相替代的別名，必須分別對應伺服器設定。

REALITY 設定最常見的問題是欄位存在但值填錯位置。例如把伺服器位址填入 serverName，把節點 UUID 當成公開金鑰，或複製短識別碼時漏掉字元。另一種情況是訂閱連結包含參數，但舊核心忽略了無法辨識的欄位；介面看似匯入成功，實際設定卻不完整。遇到這種情況，先確認用戶端目前的核心類型，再重新匯入；不要只在原節點上反覆切換系統代理。

效能預期應具體看待

VLESS 的協定處理較輕，在高吞吐量、較多並發連線或低功耗裝置上具有合理的理論優勢。但使用者看到的連線速度由多項因素共同決定：往返延遲影響握手耗時，封包遺失影響重傳，伺服器 CPU 與頻寬影響持續傳輸，傳輸方式決定額外封裝，DNS 影響首次存取。若線路本身波動明顯，更換 VMess 與 VLESS 未必會產生穩定且可見的差異。

REALITY 的握手參數較多，首次設定時比一般 VLESS + TLS 更容易因欄位缺漏而失敗；參數正確後，日常使用並不需要反覆調整。維護重點應放在核心支援與訂閱欄位完整性。升級用戶端後若舊節點仍正常，不必重新建立；若訂閱更新後突然失敗，則比較更新前後的 serverName、公開金鑰、短識別碼與流控欄位，通常比完整重裝用戶端更有效。

適合採用此組合的條件

建立新節點、伺服器明確提供 VLESS + REALITY，且桌面端使用 v2rayN 或 Android 端使用內含 Xray 核心的 v2rayNG 時，這組合有清楚的支援路徑。若 Android 端使用 v2flyNG，應先確認訂閱中的協定與安全層是否屬於 V2Fly 支援範圍，不能因名稱相近就假設能直接相容。需要跨核心共用同一份訂閱時，一般 VLESS + TLS 或成熟的 VMess 組合有時更容易維持一致。

最終判斷標準不是「是否更先進」，而是伺服器、核心與訂閱三方能否穩定表達同一組參數。選定後應做三次確認：用戶端能完整顯示安全欄位；連線記錄沒有未知設定項目；連續斷線重連後仍能恢復。通過這三項後，再將節點設為常用設定。

04 / TROJAN + SHADOWSOCKS

Trojan 與 Shadowsocks：兩條不同的簡化路線

Trojan 的設計取向

Trojan 使用密碼完成使用者驗證，並依賴 TLS 建立安全連線。它的設定概念相對直接：伺服器位址、連接埠、密碼、SNI、憑證驗證與傳輸設定構成主要部分。相較於 VMess 的時間相關驗證，Trojan 更依賴 TLS 層是否正確；相較於 VLESS，它通常不使用 UUID，而是使用密碼欄位。若用戶端介面同時提供「密碼」與「使用者 ID」，應先確認目前的節點類型，避免把驗證資訊填入錯誤位置。

Trojan 的連線問題通常集中在 TLS。系統時間偏差、SNI 與憑證名稱不一致、連接埠錯誤、憑證鏈異常，都可能在代理請求開始前終止連線。設定中的 allowInsecure 控制憑證驗證行為，不應把它當成通用的修復開關。正常憑證設定應優先維持嚴格驗證；只有在明確了解伺服器憑證安排並進行短時間診斷時，才考慮變更此項，而且診斷結束後應恢復預期設定。

Shadowsocks 的核心結構

Shadowsocks 通常簡稱 SS，核心設定由伺服器、連接埠、密碼與加密方法組成。它不使用 VMess 或 VLESS 的 UUID 模型，伺服器與用戶端必須選擇完全一致的加密方法。由於設定項目少、協定處理直接，SS 在資源有限的裝置與簡單連線情境中通常具有較低的管理成本。同時，功能範圍也更清楚：需要複雜傳輸組合時，應確認所用核心與伺服器是否透過額外機制提供支援，不能直接把其他協定的欄位套用到 SS。

選擇加密方法時不要靠名稱猜測。訂閱提供什麼值，用戶端就應保留什麼值。若匯入後方法顯示空白，或被替換成無法辨識的值，通常表示用戶端核心不支援該方法，或訂閱轉換過程遺失了欄位。此時應先查看用戶端記錄中的「unknown method」或類似解析提示，再決定更換核心或請訂閱輸出相容格式。反覆修改密碼無法解決加密方法不相符的問題。

如何看待連線速度與資源用量

SS 的處理鏈路通常較短，適合希望降低設定複雜度與計算開銷的情境。Trojan 需要完成 TLS 握手，首次連線會有相應成本，但連線重用與穩定維持可以減少重複握手的影響。若應用程式頻繁建立短連線，DNS、TLS 工作階段恢復與傳輸重用會明顯影響體驗；若主要是持續傳輸，線路頻寬與伺服器負載通常更關鍵。

不要只用一次網頁開啟速度為協定下結論。更可靠的測試方式是固定同一台伺服器、同一時段與同一個應用程式，分別觀察首次連線、持續傳輸、待機恢復和網路切換後的重連。至少重複多次，並將失敗重試計入結果。某個協定偶爾出現較高峰值，不代表它在行動網路或訊號較弱時更穩定。

如何在兩者之間選擇

伺服器提供標準 Trojan 設定、憑證與網域關係清楚，且用戶端核心支援完整時，Trojan 適合希望採用明確 TLS 模型的使用者。伺服器提供 SS、裝置資源有限，設定目標是減少欄位與維護步驟時，SS 更直接。兩者都不是 VMess 或 VLESS 的「簡化替代品」，因為驗證模型與安全邊界不同。遷移時必須由伺服器同步提供對應協定，不能只在用戶端下拉選單中修改類型。

若同一份訂閱同時提供多種協定，建議保留一個已驗證穩定的節點作為基準，再測試新的協定組合。基準節點可以協助區分本地網路問題與新設定問題。所有節點同時失敗時，優先檢查系統代理、DNS 與網路連線；只有某一類型失敗時，再回頭檢查該協定的驗證與安全欄位。

05 / PERFORMANCE

連線速度、資源用量與行動裝置電量

速度應拆成四個階段觀察

「速度」至少包含解析、握手、首個封包與持續傳輸四個階段。網域解析決定用戶端何時取得目標位址；協定與安全層握手決定連線何時可用；首個封包時間反映應用程式請求與遠端回應；持續傳輸才接近通常所說的頻寬。VMess、VLESS、Trojan、SS 在協定處理上各有差異，但若 DNS 緩慢或線路封包遺失嚴重，協定差異會被更大的網路變數掩蓋。

測試時先固定節點位址、傳輸方式與安全層，只變更一個變數。若把 VMess + WebSocket + TLS 與 VLESS + TCP + REALITY 直接比較，結果同時包含協定、傳輸與安全層差異，無法歸因於其中任何一項。更合理的方式是使用伺服器提供的可比組合，並在相同網路中重複測試。記錄連線成功率與恢復能力，不要只記錄最高吞吐量。

CPU 與記憶體開銷來自哪些部分

CPU 主要消耗在加密、協定封裝、TLS 握手、資料複製、壓縮或額外傳輸處理。記憶體則與連線數量、緩衝區、路由規則、DNS 快取及記錄層級有關。協定本身較輕不代表整個用戶端一定佔用較少，因為圖形介面、核心程序、規則集與 TUN 模式都可能成為主要開銷。v2rayN 在桌面系統中通常由介面程序管理核心程序；查看資源時應合併觀察相關程序。

記錄層級也會影響開銷。排解問題期間可以暫時提高記錄詳細程度，正常使用後應恢復一般層級，避免大量寫入磁碟。路由規則越多，匹配過程與記憶體用量越明顯，但分類合理的規則通常不會成為首要瓶頸。真正需要注意的是規則重複、網域清單過大、DNS 查詢反覆失敗及持續重試連線。

行動裝置電量的主要決定因素

Android 端使用 v2rayNG 或 v2flyNG 時，耗電量不只由協定決定。維持背景連線、網路在 Wi-Fi 與行動網路間切換、系統省電策略終止程序、頻繁 DNS 請求、失敗重連與大量並發連線，都會影響電量。一個理論開銷較低但經常斷線的設定，可能比稍微複雜但穩定的設定更耗電，因為每次重連都要重新解析、握手並恢復應用程式連線。

檢查電量時，先確保用戶端取得持續執行所需的系統權限，並依裝置設定加入適當的省電白名單。接著觀察待機階段是否頻繁出現連線記錄。如果螢幕關閉後連線不斷中斷，應優先檢查系統背景限制，而不是立即更換協定。關於 Android 端 VpnService 授權、省電白名單與分應用程式代理，可繼續閱讀v2rayNG Android 使用要點。

TUN 模式會改變資源基準

桌面端啟用 TUN 模式後，用戶端處理的流量範圍通常比一般系統代理更廣，核心需要接管更多連線，並可能執行額外的 DNS 與路由判斷。因此，拿一般系統代理模式與 TUN 模式比較協定開銷沒有直接意義。應先固定代理模式，再觀察協定差異。若切換 TUN 後資源明顯增加，先檢查路由範圍、DNS 設定，以及是否存在流量迴圈。

v2rayN TUN 模式適合需要統一接管不遵循系統代理設定的應用程式，但不應作為連線失敗時的第一個修復步驟。一般系統代理已無法連通的節點，切換 TUN 通常只會增加變數。正確順序是先用用戶端內建測試確認節點，再啟用系統代理驗證瀏覽器，最後依應用程式需求決定是否使用 TUN。

建立可重複的測試記錄

建議為每個候選組合記錄協定、傳輸、安全層、核心、代理模式與測試網路。每次只修改一項，持續觀察首次連線、十分鐘持續使用、待機恢復和網路切換。若某組合峰值略高但重連失敗較多，應優先選擇成功率穩定的組合。日常體驗取決於大多數時間的可用性，而不是單次最佳結果。

資源異常時按順序縮減變數：關閉詳細記錄，恢復簡單路由，退出 TUN，只保留一個節點，再觀察核心程序。若用量恢復正常，逐項重新啟用功能。這樣可以區分協定開銷、規則開銷與代理模式開銷，避免把所有問題都歸咎於節點類型。

06 / CORE FAMILY

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

共同來源與不同演進方向

V2Fly 與 Xray 都延續 Project V 生態中的設定理念，常見的入站、出站、路由、DNS 與傳輸層結構有許多相似之處。它們不是圖形用戶端，而是負責解析設定與處理連線的核心程式。v2rayN 是桌面圖形用戶端，可以管理相應核心；v2rayNG 主要使用 Xray 核心；v2flyNG 則面向 V2Fly 核心。選擇用戶端時，實際上也在選擇預設核心能力。

兩者的共同基礎讓許多 VMess、Shadowsocks、Trojan、一般 VLESS 與常見路由規則可以採用相似的表達方式，但「相似」不等於所有欄位都能雙向相容。Xray 在 VLESS、XTLS、REALITY 等方向加入了自身功能；V2Fly 則沿著原有設定體系持續發展。某個設定檔能被一個核心接受，不代表另一個核心能理解其中全部擴充欄位。

功能差異要落實到欄位層級

判斷相容性時，不要只問「是否支援 VLESS」，還要繼續檢查安全層、流控、傳輸與擴充參數。例如一般 VLESS + TLS 與 VLESS + REALITY 對核心的要求不同；同樣是 TCP 傳輸，是否啟用特定流控也會改變支援範圍。訂閱名稱可能只寫 VLESS，真正影響核心選擇的參數藏在查詢字串或底層 JSON 中。

將 Xray 專有欄位交給 V2Fly 時，常見結果包括匯入時被忽略、啟動時出現未知欄位，或節點能儲存但無法連線。反向遷移也可能遇到預設值不同或欄位命名變更。最安全的方式不是手動刪除報錯項目，而是先確認該項目承擔的功能。如果它屬於安全層必要參數，刪除後即使設定能啟動，也不會得到等效連線。

設定遷移的檢查順序

從一個核心切換到另一個核心前，先匯出或記錄目前的節點類型、傳輸方式、安全層與路由設定。第二步查看設定中是否包含目標核心不認識的擴充欄位。第三步在目標用戶端中只匯入一個節點，確認核心能夠啟動。第四步檢查 DNS 與路由記錄，確認請求實際走向預期的出站。最後再遷移完整訂閱。一次遷移全部節點會讓錯誤來源難以定位。

如果只是圖形介面升級而核心家族沒有變化，通常不需要重寫設定。若切換核心後一般 VMess 節點可用、REALITY 節點失敗，就應把檢查範圍縮小到 Xray 擴充能力與安全欄位，而不是重裝網路驅動程式。相反地，若所有節點都無法啟動，應先查看核心檔案是否被用戶端正確呼叫、本機監聽連接埠是否被佔用，以及設定語法是否通過。

路由與 DNS 也有相容範圍

代理協定可用不代表整份設定完全相容。路由規則中的網域類別、規則集引用、DNS 查詢策略與出站標籤也可能存在差異。遷移時若節點測試成功但部分網站行為異常，應檢查路由規則是否引用不存在的標籤、DNS 出站是否指向正確物件，以及規則順序是否改變。底層設定通常按順序匹配，前面的寬泛規則可能覆蓋後面的具體規則。

簡化設定是驗證相容性的有效方法。保留一個本機入口、一個代理出站與最小 DNS 設定，確認基礎連線後再加入分流。不要在最小測試設定中同時啟用複雜規則、TUN 與多個備用出站。每增加一層功能就做一次連線確認，這樣才能明確是哪一層引入差異。

如何選擇預設核心

訂閱以 VMess、一般 VLESS、Trojan 或 SS 為主，且既有 V2Fly 設定已穩定運作時，可以維持原核心。訂閱明確包含 REALITY、特定流控或 Xray 擴充欄位時，應選擇 Xray 支援路徑。桌面端優先使用 v2rayN，再依節點需求設定核心；Android 端則依訂閱能力在 v2rayNG 與 v2flyNG 之間選擇。

核心選擇不是長期不可變的決定，但每次切換都應有明確原因。只因某個名稱較熟悉就更換核心，會增加設定解讀差異。更具體的功能對照可閱讀Xray 核心和 V2Fly 核心有什麼差別，其中進一步拆解協定支援、效能與設定遷移範圍。

07 / SUBSCRIPTION

訂閱格式、分享連結與用戶端相容性

訂閱是設定容器，不是協定

訂閱連結負責向用戶端提供一個或多個節點設定，本身不決定節點使用 VMess、VLESS、Trojan 還是 SS。用戶端更新訂閱後，會下載文字或結構化內容，再將其中的分享連結、欄位與備註轉換成內部設定。因此，「訂閱更新成功」只表示內容已取得，不代表每個節點都被完整解析，更不代表節點一定能連線。

常見分享連結會使用不同方案名稱區分協定，例如 vmess://、vless://、trojan:// 和 ss://。VMess 分享內容通常經過編碼後攜帶 JSON；VLESS 與 Trojan 常透過 URI 使用者資訊和查詢參數表達傳輸、安全層及附加欄位；SS 連結則包含加密方法、密碼、位址與連接埠。用戶端必須辨識對應方案以及連結中的參數版本。

為什麼同一份訂閱在不同用戶端中的數量不同

節點數量不同通常有四類原因。第一，某個用戶端不支援訂閱中的協定或擴充欄位，因此略過對應項目。第二，訂閱內容存在格式錯誤，部分連結無法解析。第三，用戶端啟用了去重、篩選或依關鍵字排除。第四，訂閱轉換端針對用戶端類型輸出了不同內容。排查時先比較協定類型分布，而不是只比較總數。

若 v2rayNG 能看到 REALITY 節點而 v2flyNG 看不到，應先檢查核心支援範圍；若兩者都缺少同一批 VMess 節點，則更可能是訂閱編碼或連結完整性問題。桌面端 v2rayN 若只匯入部分節點，可以查看更新記錄中的「略過」、「未知方案」或「欄位解析失敗」等資訊。不要透過手動複製節點名稱來補齊，因為名稱不包含真正的設定。

URI 編碼會造成哪些隱藏問題

密碼、備註、路徑與查詢參數若含有特殊字元，需要依 URI 規則編碼。訂閱轉換過程若重複編碼，用戶端看到的值會多出百分比序列；若完全沒有編碼，井字號、問號、斜線等字元可能被解讀為連結結構。Trojan 和 SS 的密碼尤其需要注意這一點。看到匯入後的密碼長度明顯改變時，應回到原始訂閱檢查，而不是在用戶端中猜測字元。

連結結尾的井字號部分通常作為節點備註，不參與驗證。備註出現亂碼一般不會導致連線失敗，但它提示訂閱編碼流程可能存在問題。若備註與關鍵參數同時異常，應重新取得完整訂閱內容。複製連結時不要經過會自動換行或替換字元的編輯器，也不要只複製可見的截斷文字。

訂閱更新後的安全操作順序

更新前先保留一個已驗證可用的節點，不要立即刪除舊設定。更新後檢查節點類型與數量，再選擇一個新節點執行用戶端內建測試。測試通過後啟用系統代理並確認實際存取，最後再更新路由或 TUN 設定。如此可以將訂閱解析、節點連線與系統接管分成三個階段。任何階段失敗，都能回到上一個有效狀態。

若訂閱更新後原節點被覆蓋，可以檢查用戶端是否提供保留本機修改、依備註合併或單獨建立訂閱群組的選項。手動修改訂閱節點通常會在下次更新時被覆蓋，長期修正應在訂閱來源完成。臨時測試節點則適合複製成獨立設定，並加上清楚的備註，避免與自動更新項目混淆。

用戶端選擇應與訂閱類型相配

Windows、macOS、Linux 桌面端優先選擇 v2rayN，方便集中管理訂閱、切換核心和檢查記錄。Android 訂閱以 Xray 擴充能力為主時選擇 v2rayNG；明確需要 V2Fly 核心相容時選擇 v2flyNG。具體安裝套件應從取得用戶端頁面依平台和架構選擇，不要根據分享連結名稱推斷安裝套件類型。

訂閱連結屬於設定入口，應避免在公開頁面或截圖中直接展示完整內容。排解問題時可以記錄協定類型、錯誤提示和非敏感欄位，但驗證資訊應保持私密。需要向他人說明問題時，使用「協定 + 傳輸 + 安全層 + 核心 + 錯誤階段」的格式描述，通常已足以定位方向。

08 / SCENARIO GUIDE

依使用情境選擇協定、核心與用戶端

桌面日常使用：優先減少維護變數

Windows、macOS、Linux 桌面環境優先使用 v2rayN。第一步依訂閱現有協定選擇，不主動變更伺服器提供的節點類型。第二步檢查是否包含 REALITY 或特定 Xray 擴充；若包含，使用相應的 Xray 核心支援路徑。第三步在一般系統代理模式下完成單節點連線確認。只有應用程式不遵循系統代理，或確實有統一接管需求時，再評估 TUN 模式。

協定方面，既有 VMess + TLS 設定穩定時可以繼續使用；新設定明確提供 VLESS + REALITY 時，依完整欄位匯入並確認核心；伺服器提供 Trojan 時重點檢查 TLS 與 SNI；使用 SS 時確保加密方法一致。桌面裝置資源通常足以負擔這些協定，選擇重點應放在相容性、恢復能力與維護成本，而不是追逐很小的理論開銷差異。

Android 長時間背景執行：先控制重連

Android 端若訂閱包含 VLESS + REALITY 等 Xray 能力，優先選擇 v2rayNG；若設定明確圍繞 V2Fly 核心組織，則選擇 v2flyNG。完成匯入後，先授予 VpnService 連線權限，再依裝置的背景管理方式處理省電白名單。觀察螢幕關閉後的連線維持情況；若記錄持續出現斷線與重新握手，先解決系統背景限制。

行動端選擇協定時應重視穩定連線與待機恢復。SS 的設定較簡潔，VLESS 本身較輕，但任何協定只要頻繁失敗重試都會增加耗電量。測試時固定使用同一節點半天以上，觀察待機、網路切換與應用程式喚醒，而不是只看短時間測速。分應用程式代理可減少不需要經過代理的應用程式連線數量，也有助於降低無關流量處理。

跨裝置共用訂閱：選擇共同能力集合

同一份訂閱需要同時用於桌面與 Android 時，應以所有目標用戶端共同支援的協定組合為基準。VMess、Trojan、SS 與一般 VLESS 通常具有較廣的用戶端覆蓋範圍，但具體仍要看傳輸與安全欄位。若訂閱包含 REALITY，可讓支援該能力的用戶端使用對應節點，同時保留一個相容範圍較廣的備用節點。不要為了「統一名稱」而強行將不同安全組合轉換成同一種連結。

共用訂閱的維護重點是欄位一致與分組清楚。可依協定或核心需求為節點加入明確備註，例如「VLESS-REALITY-Xray」或「VMess-TLS-通用」，但備註只用於辨識，不能取代實際參數。每次更新後在兩類裝置上各測試一個節點，確認轉換過程沒有刪除查詢參數。

低資源與高並發情境：先測試完整鏈路

資源有限的裝置可以優先比較 SS、VLESS 等處理較直接的方案，但必須在伺服器支援且安全層完整的前提下選擇。高並發情境則要同時考量連線重用、傳輸方式、核心緩衝與伺服器限制。協定封裝較輕只能降低其中一部分開銷，無法彌補線路封包遺失、伺服器負載或錯誤的 DNS 策略。

測試時記錄 CPU、記憶體、連線成功率與持續吞吐量。若降低協定開銷後 CPU 有改善但失敗率上升，整體效果仍可能變差。應選擇在目標負載下能持續穩定運作的設定，並保留可回復方案。調整傳輸、核心或安全層時一次只改一項，確保結果能夠歸因。

最終確認清單

完成選擇後，依序確認八項：協定名稱與伺服器一致；用戶端核心支援全部欄位；位址與連接埠完整；驗證資訊沒有空格或截斷；傳輸方式與路徑一致；TLS 或 REALITY 參數完整；用戶端單節點測試通過；系統代理或 VpnService 接管後實際存取正常。任何一項未通過，都先停留在目前階段，不要繼續疊加路由或 TUN。

連線成功後再觀察斷線重連、待機恢復與網路切換。穩定運作一段時間後，保存目前有效組合的文字記錄，包括協定、傳輸、安全層、核心與用戶端名稱。日後出現問題時，以這份記錄作為基準，只比較發生變化的欄位。這比重新匯入整份訂閱更容易定位問題。

一頁式選擇結論

已有成熟設定且重視跨核心相容性，可以先保留 VMess；新設定由 Xray 體系提供完整的 VLESS + REALITY 參數，可使用支援該組合的核心與用戶端；希望採用明確的 TLS 驗證模型且憑證設定完整，可以選擇 Trojan；設定目標簡單、伺服器明確提供 SS 且加密方法相容時，可以採用 Shadowsocks。協定沒有脫離情境的統一排名。

桌面端首選 v2rayN，Android 端依核心需求選擇 v2rayNG 或 v2flyNG。完成選擇後，可回到使用指南，依訂閱匯入、啟用代理和連線確認的順序操作。若用戶端啟動閃退、連接埠被佔用或憑證握手仍出現錯誤，可查閱疑難解答以及TLS 憑證錯誤排查清單。