V2Ray 協定與核心選擇參考

// 01 · DECISION MODEL

先拆分協定、傳輸、安全與路由

客戶端設定不只包含單一協定

V2Ray 圖形客戶端將複雜設定濃縮成數個表單欄位，容易讓人誤以為選取 VMess 或 VLESS 就完成所有技術選擇。實際上，一條連線至少可拆成五層：應用程式存取產生原始 TCP 或 UDP 流量；客戶端本機入口接收流量；代理協定負責驗證與封裝；傳輸方式負責將代理資料放入 TCP、WebSocket、gRPC 等載體；TLS 或 REALITY 負責外層握手與加密。資料抵達遠端後，還要由出站與路由規則決定直連、代理或阻擋。任何一層參數不相符，都可能呈現「設定可匯入但無法連線」。

協定層主要決定驗證欄位、請求標頭結構與核心實作。例如 VMess 使用使用者識別資訊，並具備自身的協定結構；VLESS 較為精簡，將加密與傳輸安全交給外層。傳輸層決定資料如何分幀、是否需要 HTTP 語意，以及中間鏈路能否正確轉送。安全層則處理憑證驗證、伺服器名稱、金鑰交換與目標身分確認。路由層不會改變協定本身，卻會直接影響哪些要求進入代理連線。排查問題時必須先定位層級，再修改參數；連續替換多個選項只會掩蓋真正原因。

用限制條件取代「最強協定」

協定不存在脫離環境後仍適用的統一排名。選擇時需要同時確認伺服器端提供哪些功能、目前客戶端核心能解析哪些內容、作業系統需要哪些功能，以及鏈路中是否存在反向代理或只接受特定傳輸方式的基礎設施。伺服器端已固定使用 VMess 時，客戶端不能單方面改成 VLESS；訂閱只提供 WebSocket 時，也不能只在本機將傳輸切換為 gRPC。客戶端表單中的協定、位址、連接埠、使用者識別資訊、傳輸方式與安全參數，必須與伺服器端逐項一致。

判斷優先順序可依「可用性、相容性、資源成本、維護成本」排列。第一步確認伺服器端與核心支援，第二步確認訂閱欄位能完整傳遞，第三步才比較建立連線速度、吞吐量與耗電量。需要多裝置使用時，還要考慮桌面端與 Android 能否共用同一份訂閱。如果某個組合只有一端能完整辨識，日常維護成本往往高於它帶來的些微效能收益。

建立可回復的基準設定

準備比較協定時，應保留一筆已驗證可用的基準設定，不要直接覆寫。基準設定可用來排除本機連接埠、系統代理、DNS 與路由規則造成的干擾。測試新設定前，可暫時使用全域代理或最簡單的路由模式；確認基礎連線後再恢復分流。若基礎連線正常、恢復規則後才異常，問題就在路由或 DNS，不應繼續修改協定參數。圖形客戶端通常支援複製設定或依訂閱分組管理，善用分組能大幅減少反覆匯入造成的欄位混亂。

// 02 · PROTOCOL FAMILIES

VMess、VLESS、Trojan、Shadowsocks 與 REALITY

VMess：完整協定結構與成熟的相容性

VMess 是 Project V 生態早期形成的核心代理協定，設計目標是將使用者驗證、時間校驗與資料封裝納入統一協定。客戶端常見欄位包括伺服器位址、連接埠、使用者 ID、alterId、加密方式與傳輸設定。現代設定中的 alterId 通常為零；如果舊訂閱仍提供非零值，必須依伺服器端實際設定保留，不能按照新設定習慣擅自修改。VMess 對系統時間較為敏感，裝置時間明顯偏差時可能無法完成驗證，因此「相同設定在一台裝置可用、另一台不可用」時，應檢查自動校時。

VMess 的優勢在於長期累積形成的工具相容性與大量既有部署，許多訂閱格式都能穩定表達其基礎欄位。代價是協定本身的結構比 VLESS 複雜，驗證與封裝需要額外處理。對現代桌面與手機硬體而言，這部分成本通常不是瓶頸；真正影響體驗的多半是網路往返、傳輸方式、TLS 握手與伺服器負載。如果現有 VMess 設定穩定，單純為了追求理論上些微的開銷差異而遷移，收益未必能抵銷重新設定與跨裝置驗證的成本。

VLESS：分離驗證與安全層

VLESS 延續使用者 ID 驗證方式，但不在協定內部重複負責資料加密，安全能力交由 TLS、REALITY 等外層機制處理。這樣可減少協定層冗餘，也讓傳輸安全的職責更清楚。VLESS 設定除了位址、連接埠與使用者 ID 外，也常見 flow 欄位。並非所有 VLESS 設定都需要 flow；只有伺服器端啟用對應流控方式時，客戶端才應填寫。最常見的相關值是 xtls-rprx-vision，留空或填入錯誤值，都會造成客戶端與伺服器端行為不一致。

VLESS 本身不等於 REALITY，也不會自動代表某種傳輸方式。它可以與 TCP、WebSocket、gRPC 等方式組合，也可使用 TLS 或 REALITY。選取 VLESS 後，仍需繼續檢查 network、security、serverName、flow 等欄位。現代 Xray 設定中，VLESS 與 REALITY、Vision 的組合相當常見，因為這些能力能在同一核心家族內協同實作。若需要將設定交給只支援 V2Fly 特性的客戶端，應先確認該組合是否在目標核心中有等價實作。

Trojan：以 TLS 為基礎的密碼驗證

Trojan 的核心欄位相對直接：伺服器位址、連接埠、密碼、TLS 伺服器名稱與可選的傳輸參數。它依賴正確的 TLS 部署，客戶端會依伺服器名稱驗證憑證。位址使用 IP、伺服器名稱填寫網域是正常組合，因為連線目標與憑證身分可以分開；但若伺服器名稱為空、拼寫錯誤或憑證鏈異常，連線會在進入代理資料階段前失敗。關閉憑證驗證雖然可能暫時繞過錯誤，卻會失去身分驗證，不適合作為長期處理方式。

Trojan 的協定理解成本較低，適合伺服器端已穩定提供標準 TLS 的環境。它與 VLESS TLS 的效能差距通常小於線路品質與傳輸選擇造成的差距。比較時應保持伺服器位置、連接埠、傳輸方式與並行數量一致。若一個設定走直接 TCP，另一個疊加 WebSocket 與中間轉送，僅憑下載速度判斷協定優劣並沒有意義。

Shadowsocks：輕量加密代理

Shadowsocks 常縮寫為 SS，設定主要由位址、連接埠、密碼與加密方法組成。它的結構簡潔，資源使用量通常較低，對 TCP 與 UDP 都有成熟實作。加密方法必須與伺服器端完全一致，名稱相近也不能互換。現代部署應使用客戶端與伺服器端共同支援的 AEAD 類方法；舊式方法可能仍可由部分核心解析，但其相容性、安全性與維護狀態不能與現代方法等量齊觀。

SS 適合欄位簡單、需要跨客戶端重複使用的情境。它的訂閱連結表達也相對精簡，但不同產生器對使用者資訊編碼、外掛參數與備註欄位可能採用不同寫法。基礎 SS 設定通常容易遷移，帶有額外外掛參數的設定則必須確認目標客戶端是否實作相同能力。v2rayN、v2rayNG 與 v2flyNG 能處理常見的基礎設定，但複雜擴充仍受各自核心與匯入器限制。

REALITY：傳輸安全方案，不是獨立代理協定

REALITY 經常與 VLESS 同時出現，因此容易被誤稱為獨立協定。更準確的理解是：VLESS 負責代理協定與使用者驗證，REALITY 負責外層握手與伺服器身分確認。客戶端常見欄位包括伺服器名稱、公鑰、短識別碼、瀏覽器指紋模擬值，以及可選的 SpiderX。公鑰來自伺服器端金鑰對，短識別碼由伺服器端允許值決定，兩者都不能在客戶端自行產生後直接替換。伺服器名稱同樣必須符合伺服器端設定。

REALITY 主要由 Xray 核心提供完整支援。匯入設定時，即使介面辨識出 VLESS，如果 REALITY 的 publicKey、shortId 或 fingerprint 被訂閱轉換器遺失，最終仍然無法連線。排查時應展開設定詳細資訊逐項查看，不能只看清單中的協定標籤。對於需要 V2Fly 核心的裝置，應準備另一份相容設定，而不是期待 V2Fly 自動忽略 REALITY 欄位後繼續運作。

// 03 · PERFORMANCE & RESOURCE

如何比較連線速度、吞吐量與資源使用

先區分握手速度與持續吞吐量

「速度」至少包含建立連線時間、首位元組時間、持續下載吞吐量、上傳吞吐量與高並行穩定性。協定層較輕不代表所有指標都更快。建立新連線需要經過 DNS 查詢、TCP 建立連線、TLS 或 REALITY 握手、代理協定驗證，以及連線至目標網站。跨地區鏈路中，網路往返時間往往遠大於本機協定編碼時間。短連線較多的網頁瀏覽更容易受到握手輪次影響；長時間檔案傳輸則主要受線路頻寬、封包遺失、壅塞控制與伺服器處理能力影響。

比較 VMess、VLESS、Trojan 與 SS 時，應盡量使用同一台伺服器、同一路線、相近連接埠與相同傳輸層。測試前先關閉會改變路徑的自訂路由，確認 DNS 解析結果一致。每種設定至少進行多輪交替測試，不要先測完一種再測另一種，因為網路負載會隨時間變化。結果應記錄中位表現與異常次數，不要只保留最快的一次。若差異只有些微幅度，通常不足以證明協定本身更優。

傳輸封裝往往比協定差異更明顯

直接 TCP 的額外分幀較少，適合鏈路允許端對端穩定連線的情境。WebSocket 在資料外層加入 HTTP 升級與分幀結構，方便接入理解 HTTP 的基礎設施，但會增加標頭與分幀成本。gRPC 基於 HTTP/2，具備串流與連線管理能力，適合伺服器端與中間鏈路都正確支援 HTTP/2 的部署。HTTPUpgrade 與 WebSocket 的入口形式相近，但具體支援情況取決於核心與伺服器端。選擇時不能只看理論開銷，還要確認整條鏈路是否會緩衝、限時或重設長連線。

多路複用試圖讓多個邏輯請求共用較少的底層連線。它可能減少頻繁建立連線的成本，也可能在封包遺失時讓多個邏輯串流同時等待，形成隊頭阻塞。網頁小型請求、即時通訊與大型檔案傳輸對複用的反應各不相同。啟用複用後若出現下載穩定但網頁偶爾卡頓，或單一連線遺失封包時所有請求同時停頓，應關閉複用進行對照，不要直接將現象歸因於 VLESS 或 VMess。

CPU、記憶體與加密實作

資源使用量由協定解析、加密演算法、TLS 實作、傳輸分幀、日誌層級與連線數量共同決定。VLESS 將資料加密交給外層，協定處理相對直接；Trojan 依賴 TLS；SS 使用設定指定的加密方法；VMess 具備自身的協定結構。現代裝置通常具備高效的加密實作，在一般瀏覽情境下，幾種協定的 CPU 差異可能很難察覺。低效能裝置、高速傳輸或大量並行連線時，演算法實作與記憶體複製次數才較容易成為瓶頸。

日誌同樣會影響資源。排錯時使用詳細日誌有助於定位握手與路由，但長期維持除錯層級會增加磁碟寫入、記憶體緩衝與介面更新。穩定後應恢復一般日誌層級。路由規則數量也不是越少就越快：結構合理的網域集合與 IP 集合可由核心高效匹配，真正應避免的是大量重複、衝突與順序不清的自訂規則。

可重現的測試順序

建議先使用單一瀏覽器完成冷啟動測試，記錄首次開啟與連續開啟的差異；再進行持續傳輸，觀察吞吐量是否穩定；接著測試多個並行請求與 UDP 應用；最後恢復日常路由與 DNS 設定。每一步只改變一個變數。若從 VMess WebSocket TLS 一次改成 VLESS TCP REALITY，即使出現改善，也無法確認是來自協定、傳輸還是安全層。更可靠的方法是先保持傳輸與 TLS 不變，比較 VMess 與 VLESS；再單獨更換傳輸方式，最後比較安全層。

客戶端介面的連線測試通常只驗證遠端是否能回應，不代表完整業務路徑穩定。真實應用可能使用不同網域、IPv4 或 IPv6、UDP、長連線與並行請求。判斷某個設定能否作為主要設定，至少要涵蓋網頁瀏覽、持續傳輸、休眠恢復與網路切換。若測試結果只在特定應用中異常，應轉向檢查 DNS、路由或該應用的代理接入方式，而不是繼續隨機更換協定。

// 04 · MOBILE POWER

Android 連線的耗電、背景運作與網路切換

耗電量不只由協定名稱決定

Android 上的代理客戶端通常透過系統 VPN 服務接管流量，耗電來源包括持續運作的本機入口、加密與解密、DNS 處理、路由匹配、連線維持、日誌寫入，以及網路頻繁重連。螢幕關閉後，系統排程與背景限制會改變連線狀態；從無線網路切換至行動網路時，原有 TCP 連線通常需要重建。因此，單看 VMess、VLESS 或 SS 的理論封裝成本，無法準確預測整台裝置的耗電表現。

v2rayNG 使用 Xray 核心，適合需要 VLESS、REALITY 與 Xray 路由能力的設定；v2flyNG 使用 v2fly 核心，可作為 V2Fly 生態設定的 Android 選擇。兩者的耗電差異需要在相同設定、相同路由模式與相近日常使用行為下比較。若一方啟用了完整日誌、複雜 DNS 分流與持續探測，另一方只執行簡單代理，結果不能歸因於核心家族。

連線維持與頻繁喚醒

連線維持用於保持連線並及時發現失效，但過短的維持間隔會頻繁喚醒網路與處理器。即時通訊需要穩定的長連線，一般網頁瀏覽則可以容忍按需重新連線。客戶端或伺服器端的閒置逾時、中間網路設備的連線回收策略，都會影響合適的間隔。出現待機耗電明顯時，應先檢查是否有持續傳輸、詳細日誌或異常重連，再考慮調整維持連線設定；不建議盲目將間隔設得極短。

多路複用有時能減少底層連線數量，但單一長連線也可能被系統或網路回收。關閉複用後連線數量增加，握手次數可能上升；開啟後若主要連線頻繁失效，又會造成成組重連。實際選擇應觀察一段完整的前景使用與待機週期。系統電量頁面能顯示應用程式活動趨勢，但無法直接分辨協定開銷，需要結合客戶端日誌中的重複連線、DNS 逾時與網路切換記錄進行判斷。

路由範圍與 DNS 對耗電量的影響

全域接管代表更多應用程式流量進入核心，背景同步、媒體傳輸與系統服務都會增加處理量。應用程式分流或合理的網域與 IP 分流可以減少不必要的轉送，但規則過於複雜、頻繁觸發遠端 DNS 查詢也會增加開銷。省電的重點不是追求最少規則，而是讓本機流量、區域網路存取與明確的直連目標不繞行，同時確保網域解析路徑與最終出站一致。

DNS 設定不當會造成重複查詢、逾時後回退與連線重試，這類耗電常被誤判為協定問題。若日誌持續出現解析逾時，應先確認目前網路能否連線至所設定的 DNS、查詢是否被路由到正確出站，以及 IPv6 結果是否符合實際網路能力。關閉 IPv6 並不是通用答案：具備穩定 IPv6 的網路可能因此多一次回退；沒有完整 IPv6 路徑的網路則可能因優先嘗試無效位址而延遲。應依據目前網路的實測結果判斷。

協定與傳輸的實際選擇

如果伺服器端同時提供多種方案，行動裝置可先選擇欄位完整、核心原生支援且連線恢復穩定的組合。VLESS REALITY 需要 v2rayNG 所使用的 Xray 能力；基礎 VMess、Trojan 或 SS 則有較廣泛的設定選擇。傳輸方面，直接 TCP 通常結構較簡單，WebSocket 與 gRPC 是否適合則取決於伺服器端部署。某種傳輸在桌面寬頻上穩定，不代表在行動網路切換時同樣穩定，尤其要觀察從背景恢復後是否需要手動重連。

出現高耗電時不要立即刪除訂閱。先複製設定並建立對照：關閉詳細日誌、減少不必要的探測，維持協定與伺服器不變，只切換複用；接著維持複用不變，只比較傳輸；最後比較不同協定。每輪測試保持相近的螢幕使用時間與流量類型。若耗電伴隨大量業務流量，可能只是正常的資料處理成本；若幾乎沒有流量卻持續活躍，才應重點排查循環重連、DNS 重試與背景應用程式不斷發出請求。

// 05 · CORE FAMILIES

V2Fly 與 Xray 核心家族的關係

共同基礎與不同的演進方向

V2Fly 與 Xray 都延續了 Project V 設定體系中的許多核心概念，包括入站、出站、路由、DNS、傳輸與策略物件。兩者在 VMess、基礎 VLESS、Shadowsocks、SOCKS、HTTP 等常見能力上有不少交集，因此許多基礎設定看起來相似。但它們是獨立演進的核心家族，新功能、欄位名稱、預設行為與發布節奏不要求完全同步。設定結構相似，不代表任何設定都能直接互換。

Xray 在 VLESS、XTLS Vision、REALITY 等能力上形成了明確的組合路徑。V2Fly 則持續維護自身核心的協定、傳輸、路由與平台能力。選擇核心時不應只問哪個「更新」，而應確認訂閱使用的功能屬於哪一方、客戶端是否提供對應設定，以及伺服器端是否採用相同實作。協定越基礎，跨核心相容性越容易；使用專屬安全層、流控或實驗欄位時，相容範圍越窄。

三款圖形客戶端如何對應

桌面平台首選 v2rayN，涵蓋 Windows、macOS 與 Linux，並提供訂閱管理、系統代理、路由規則與多種核心設定入口。Android 上，v2rayNG 以 Xray 核心為主，適合需要 VLESS、REALITY、Vision 等 Xray 能力的設定；v2flyNG 對應 V2Fly 核心，可用於伺服器端與訂閱明確採用 V2Fly 相容能力的情境。具體安裝入口與平台要求可在取得客戶端頁面依系統選擇。

客戶端名稱與核心名稱不能混為一談。v2rayN 是圖形管理層，負責訂閱、設定編輯、啟動核心與系統代理；真正執行協定、傳輸與路由的是所選核心。同一個 v2rayN 介面中，切換核心後可用欄位與執行結果可能改變。排錯時除了客戶端名稱，也應記錄目前的核心類型。只說「v2rayN 無法連線」資訊不足，同一份設定在不同核心下可能得到不同結果。

設定相容性的三個層次

第一層是語法相容性：JSON 能否解析，欄位類型與物件位置是否符合核心要求。第二層是功能相容性：欄位雖然能讀取，對應的協定或傳輸是否真正實作。第三層是行為相容性：兩端都實作同名功能，但預設值、回退規則或邊界處理是否一致。訂閱匯入成功只證明圖形客戶端接受了輸入，不代表核心一定能運作，更不代表伺服器端參數相符。

例如一份 VLESS REALITY 設定可能以通用連結格式匯入 v2flyNG，清單也顯示位址與使用者 ID，但如果目標核心不支援 REALITY，連線不會因此降級為一般 TLS。安全層不能靜默替換，因為伺服器端期待的握手完全不同。正確做法是使用伺服器端另外提供的相容設定，或在支援對應功能的 v2rayNG、v2rayN 與 Xray 核心中使用。

遷移核心前的驗證方法

遷移前先匯出或記錄原設定的協定、傳輸、安全性、路由與 DNS，不要只保存分享連結。接著查看目標核心是否支援每個關鍵欄位，尤其是 flow、REALITY 公鑰、短識別碼、傳輸服務名稱與自訂出站。遷移後先停用複雜路由，用單一設定驗證基礎連線；再恢復 DNS；最後恢復分流。這樣能分辨是協定不相容、DNS 行為差異，還是規則標籤發生變化。

切換核心後還應檢查本機監聽連接埠與系統代理。圖形客戶端可能為不同設定模式使用不同入口，舊有瀏覽器或應用程式代理設定仍指向原連接埠時，就會呈現「核心啟動成功但沒有流量」。如果日誌顯示入站沒有連線記錄，應先檢查應用程式是否進入本機入口；如果有入站但遠端握手失敗，再檢查協定與安全欄位。關於連接埠衝突可參考本機監聽連接埠排查。

// 06 · TRANSPORT & SECURITY

傳輸方式、TLS、REALITY 與關鍵參數

TCP、WebSocket、gRPC 與 HTTPUpgrade

TCP 在客戶端設定中通常表示直接以 TCP 承載協定資料，並不代表沒有 TLS。network 決定傳輸，security 決定外層安全性，兩者是獨立欄位。WebSocket 需要路徑，部分部署還需要 Host；路徑通常以斜線開頭，且必須與伺服器端及中間轉送規則一致。gRPC 使用 serviceName 識別服務，不應將 WebSocket 的 path 原樣填入。HTTPUpgrade 同樣涉及路徑與 Host，但它與 WebSocket 是不同的傳輸類型，伺服器端必須明確支援。

匯入訂閱後，如果位址、連接埠與使用者 ID 正確，但日誌出現 HTTP 狀態錯誤、服務不存在或連線立即關閉，應優先核對傳輸設定。常見問題包括路徑結尾多出斜線、serviceName 被轉換器當作 path、Host 與伺服器名稱混用，以及中間轉送只啟用了 HTTP/1.1 或 HTTP/2 其中一種。客戶端無法透過自動嘗試猜出伺服器端的實際部署，表單值必須準確。

TLS 的伺服器名稱與憑證驗證

TLS 設定中的 serverName 用於握手身分驗證，通常對應憑證中的網域。連線位址可以是網域或 IP，而 serverName 應依伺服器端要求填寫。allowInsecure 類選項用於控制憑證驗證，正常設定應維持嚴格驗證。遇到憑證錯誤時，應檢查裝置時間、伺服器名稱、憑證有效範圍與憑證鏈，而不是長期關閉驗證。憑證錯誤發生在代理驗證之前，修改使用者 ID 或密碼無法解決。

ALPN 用於協商上層協定，常見值與 HTTP/2 或 HTTP/1.1 有關。只有伺服器端或中間基礎設施有明確要求時，才需要手動指定。任意加入 ALPN 可能讓客戶端協商出伺服器端無法正確處理的協定。指紋模擬欄位則會影響 TLS 客戶端握手特徵，具體可選值由核心實作決定。訂閱已提供該欄位時通常應保留；手動編輯前先確認目前核心接受的名稱。

REALITY 的四個關鍵欄位

REALITY 設定最需要核對的是 serverName、publicKey、shortId 與 fingerprint。serverName 是握手中使用的伺服器名稱；publicKey 對應伺服器端金鑰對中的公鑰；shortId 必須是伺服器端允許的值；fingerprint 指定客戶端握手指紋。任何一項遺失或字元錯誤，都可能導致連線在早期失敗。分享連結中這些欄位常以 sni、pbk、sid、fp 等參數出現，匯入後應在設定詳細資訊中確認它們沒有被截斷。

VLESS REALITY 常與 Vision 流控組合。此時客戶端的 flow 必須與伺服器端一致，不能因為其他 VLESS 設定留空就刪除。反過來，伺服器端未啟用 Vision 時也不應擅自加入。REALITY 參數看似都屬於「進階設定」，實際上是連線所需資訊。訂閱轉換、QR Code 辨識或手動複製後出現問題時，先逐字對照這些欄位，比反覆切換路由模式更有效。

路由設定範例與協定設定的界線

路由規則不負責建立遠端協定連線，它只會將已進入核心的請求分配至不同出站。以下範例展示常見的優先順序：先阻擋廣告分類，再讓私有位址與本地區域網域直連，其餘請求進入預設代理出站。範例是可解析的 Xray/V2Ray 路由物件片段，實際使用時需要確保完整設定中存在名為 block、direct 與 proxy 的出站標籤。

{
  "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"
      }
    ]
  }
}

規則會依核心設定語意進行匹配，衝突規則的順序會影響結果。建立自訂規則前，應確認客戶端在產生最終設定時是否會追加預設規則，因為介面中的順序不一定等於最終 JSON 順序。domainStrategy 決定何時將網域解析為 IP 以繼續匹配 IP 規則，也會影響 DNS 查詢數量與分流結果。關於 domain、ip、geosite 的具體寫法與優先順序，可繼續閱讀自訂路由規則語法詳解。

// 07 · SUBSCRIPTION COMPATIBILITY

訂閱格式、分享連結與欄位相容性

訂閱是設定的傳輸方式

訂閱本身不是代理協定。它負責將伺服器設定從提供端傳送至客戶端，內容可能是 Base64 編碼的多行分享連結，也可能是客戶端能辨識的結構化設定。常見分享連結以 vmess://、vless://、trojan:// 或 ss:// 開頭。連結方案表示協定類型，查詢參數則繼續表達傳輸、安全性、伺服器名稱、路徑、公鑰等欄位。客戶端匯入時需要完成解碼、欄位映射與內部設定產生。

Base64 只是編碼，不代表內容經過加密，也不決定協定能力。同一個訂閱網址可能隨更新回傳不同節點、備註或參數。客戶端更新訂閱時，通常會依分組替換或合併舊設定，因此手動修改訂閱產生的項目可能在下次更新時被覆寫。需要長期保留本機調整時，應複製為獨立設定，或使用客戶端提供的訂閱前置、後置處理能力，並記錄修改原因。

分享連結欄位為何會遺失

當產生端、轉換流程與客戶端匯入器對同一參數採用不同名稱時，就容易發生欄位遺失。以 VLESS REALITY 為例，公鑰可能寫作 pbk，短識別碼可能寫作 sid，伺服器名稱可能寫作 sni，指紋可能寫作 fp。若匯入器只辨識其中一套命名，清單仍能產生位址與使用者 ID，但關鍵安全欄位會是空白。VMess 的 JSON 分享內容也可能因舊欄位、字元編碼或備註中的特殊字元而解析失敗。

判斷訂閱問題時，可將「取得訂閱」與「執行單筆設定」分開處理。訂閱網址無法更新時，先檢查網址是否完整、是否需要驗證、系統時間與網路能否連線至提供端；訂閱更新成功但某筆設定無法執行時，再檢查該項目的協定欄位。若手動匯入原始分享連結可用，但經由訂閱匯入後無法使用，代表問題更可能出在訂閱內容或轉換流程，而不是核心。

三款客戶端的相容性判斷

v2rayN 適合在桌面端集中管理 VMess、VLESS、Trojan、SS 等常見類型，並依所選核心執行。v2rayNG 面向 Android 與 Xray 設定，較適合 VLESS REALITY 等 Xray 能力。v2flyNG 使用 V2Fly 核心，適合訂閱明確提供 V2Fly 可執行設定的情況。三款客戶端都可能辨識基礎分享連結，但「辨識連結」與「支援連結中的全部功能」必須分開判斷。

跨裝置共用訂閱時，最穩妥的做法是讓訂閱同時提供基礎相容設定與需要專用核心的設定，並以清楚備註加以區分。若所有項目都依賴 REALITY，v2flyNG 端不會自動取得可用的替代項目。反之，只使用基礎 VMess 或 SS 時，跨核心遷移通常更簡單，但仍要核對傳輸擴充、UDP 與加密方法。完整匯入步驟請參閱v2rayN 與 v2rayNG 訂閱連結匯入教學。

更新訂閱的安全操作順序

更新前記錄目前正在使用的項目與路由模式，重要的手動設定先複製到非訂閱分組。更新後不要立即刪除舊分組，先檢查項目數量是否合理、備註是否變更、目前設定是否仍被選取，再進行連線測試。若更新後所有項目都異常，可回到舊設定，判斷是訂閱內容變更還是本機網路問題。只有單筆異常時，才應比較更新前後的位址、連接埠、協定、安全性與傳輸欄位。

QR Code 匯入同樣屬於分享連結解析。QR Code 畫面清晰不代表內容完整，截圖裁切、縮放與長連結容量都可能影響辨識。辨識後應查看設定詳細資訊，不要以跳出「匯入成功」作為最終驗證。若訂閱或分享連結包含敏感連線資訊，應按存取憑據管理，不要在公開頁面或日誌截圖中展示完整內容。提交問題時可保留協定類型與欄位名稱，但應遮蓋位址、使用者 ID、密碼與金鑰參數。

// 08 · SCENARIO CHOICE

依使用情境選擇協定與客戶端

已有伺服器端：優先保持匹配

如果設定來自現有伺服器端或訂閱，選擇空間由伺服器端決定。客戶端應原樣使用協定、傳輸與安全參數，不要將 VLESS 改成 VMess，也不要將 WebSocket 改成 TCP。桌面端優先使用 v2rayN，依設定選擇能完整支援欄位的核心；Android 端遇到 VLESS REALITY、Vision 等 Xray 能力時使用 v2rayNG，明確採用 V2Fly 相容設定時可使用 v2flyNG。穩定運作比追求較新的協定名稱更重要。

同一份訂閱有多筆不同協定時，可先排除欄位不完整與核心不匹配的項目，再比較實際鏈路。VMess 適合延續成熟部署；VLESS 適合與現代 TLS 或 REALITY 組合；Trojan 適合標準 TLS 參數清楚的部署；SS 適合基礎欄位簡潔且需要良好 UDP 支援的情況。最終選擇應依據穩定性、恢復速度與日常應用表現，而不是清單排序或名稱印象。

多平台共用：優先考慮相容性

需要在 Windows、macOS、Android 與 Linux 之間共用設定時，應先確認各端客戶端都能完整匯入。基礎 VMess、Trojan 與 SS 通常更容易跨環境表達，基礎 VLESS TLS 也有廣泛支援；加入 REALITY、Vision 或特定傳輸擴充後，則要逐端確認核心。多平台方案可以保留一份功能較新的主要設定，再準備一份欄位簡單的相容設定，避免某台裝置因核心差異而完全無法連線。

訂閱備註應包含易讀的協定與用途資訊，例如區分 Xray 專用與基礎相容設定，不要依賴客戶端自動辨識後再自行猜測。更新訂閱時先在一台裝置驗證，確認欄位與分組正常後，再更新其他裝置。這樣能降低訂閱產生端欄位變更同時影響所有裝置的風險。裝置之間不必強求使用相同客戶端，但應記錄各端核心與設定的對應關係。

低資源與行動裝置使用：減少額外處理

低效能裝置或重視待機電量時，優先選擇核心原生支援、傳輸層簡單且不需要複雜轉換的設定。SS 結構簡潔，VLESS 協定層開銷較低，但最終資源使用仍取決於外層安全性、連線數量、DNS 與路由。直接 TCP 往往比疊加多層 HTTP 語意更簡單，不過伺服器端部署條件必須允許。不要為了節省些微協定處理成本而關閉必要的身分驗證或憑證檢查。

Android 上應先減少除錯日誌、無效 DNS 重試與過短的維持連線間隔，再比較協定。若待機後頻繁斷線，應檢查背景限制與網路切換，而不是只更換加密方法。需要 UDP 的應用程式還要確認伺服器端、協定、傳輸與客戶端入口都支援 UDP，任何一層缺失都會導致部分功能異常。TCP 網頁瀏覽正常，不能證明 UDP 路徑正常。

複雜路由：優先考慮核心與規則能力

需要依網域、IP、應用程式或協定類型進行精細分流時，客戶端的規則產生方式與核心能力比代理協定更重要。v2rayN 適合桌面端維護較複雜的路由；v2rayNG 可在 Android 上搭配 Xray 規則。設計規則時先確定 direct、proxy、block 三類出站，再依高優先級例外、私有網路、區域集合與預設路徑組織。規則越多，就越需要明確的順序與 DNS 策略。

路由異常的典型表現是只有部分網域無法存取、區域網路裝置無法連線、解析結果與連線出站不一致。此時切換 VMess 與 VLESS 通常無法解決問題。應暫時使用簡單路由驗證基礎協定，再逐組恢復規則。DNS 洩漏、遠端解析與本機解析都屬於 DNS 與路由設計問題，可參考DNS 檢測與客戶端設定實作繼續排查。

最終決策清單

1. 確認伺服器端：記錄協定、位址、連接埠、傳輸、安全層與所有驗證欄位，客戶端不得單方面改型。
2. 確認核心：REALITY 與 Vision 優先核對 Xray 支援；V2Fly 設定在 v2flyNG 或對應桌面核心中驗證。
3. 確認訂閱：檢查匯入後的 flow、sni、publicKey、shortId、fingerprint、path 與 serviceName 是否完整。
4. 建立基準：先用簡單路由與一般 DNS 驗證連線，再恢復分流、複用與進階選項。
5. 依情境測試：分別觀察短連線、持續傳輸、UDP、休眠恢復、網路切換與多裝置匯入。
6. 保留回復方案：複製已驗證的設定，協定遷移、核心切換與訂閱更新不要同時進行。

如果仍無法判斷，桌面端可從 v2rayN 與伺服器端原始設定開始，Android 端則依核心能力在 v2rayNG 與 v2flyNG 之間選擇。出現錯誤後先定位層級：本機入口沒有流量，檢查系統代理與連接埠；遠端握手失敗，檢查協定與安全欄位；只有部分網域異常，檢查路由與 DNS；訂閱更新後異常，則比較更新前後的欄位。依這個順序處理，通常比連續更換協定更快找到原因。