V2Ray 協定手冊：協定、傳輸與核心選擇

一、拆解協定、傳輸、安全層與核心

用戶端中的「協定」不是單一開關

在 v2rayN、v2rayNG 或 v2flyNG 的伺服器編輯介面中，一條連線通常同時包含協定類型、位址、連接埠、使用者憑證、傳輸方式、安全層與路由出口。協定類型決定用戶端如何向伺服器驗證身分及組織資料框架；傳輸方式決定這些資料框架透過 TCP、WebSocket、gRPC 等承載方式傳送；TLS 或 REALITY 等安全層負責握手、伺服器身分確認與鏈路加密；核心則負責將這些欄位組合成可執行的設定。若混淆這些概念，容易得出「某種協定一定更快」或「只改類型就能連線」等錯誤結論。

例如 VLESS 可以運作於一般 TCP、WebSocket 或 gRPC，也能與 TLS、REALITY 組合。兩個都標示為 VLESS 的節點，如果傳輸層、壅塞狀況、憑證握手與伺服器實作不同，實際表現可能完全不同。REALITY 也不是與 VLESS 同等級的代理協定，更接近由 Xray 實作的傳輸安全方案；常見組合是 VLESS、TCP、REALITY 與 XTLS Vision。用戶端選擇伺服器時，應將完整組合視為整體，而不是只看分享連結開頭的 vless://。

選擇時優先確認四項條件

第一項是伺服器已提供的設定。用戶端無法單方面將 VMess 改成 VLESS，也不能在伺服器尚未設定 REALITY 時自行勾選 REALITY。第二項是核心是否識別相應欄位。v2rayNG 主要以 Xray 核心執行，v2flyNG 面向 V2Fly 核心；v2rayN 是桌面圖形用戶端，常見設定由 Xray 核心執行。基礎 VMess、VLESS、Trojan 與 Shadowsocks 欄位在生態中具有廣泛支援，但 XTLS Vision、REALITY 等擴充功能必須搭配支援它們的核心。

第三項是設定來源。訂閱連結會同時攜帶協定、位址、連接埠與傳輸參數，通常應完整匯入，不要只複製位址與連接埠後重新手動填寫。第四項是使用環境。桌面端較能負擔 TUN、複雜路由與多程序連線；行動端更重視常駐耗電、網路切換後的重新連線與背景狀態。同一協定在不同平台上的體驗差異，往往來自系統網路堆疊、TUN 實作與連線維持策略，而非協定名稱本身。

不要用單一標籤取代完整判斷

合理的協定選擇順序是：先確認伺服器組合與用戶端核心相容，再檢查分享連結或訂閱是否完整，之後才比較效能與資源用量。如果可以建立連線但網頁無法存取，應繼續檢查系統代理、TUN、DNS 與路由分流；如果匯入設定時欄位已遺失，應先處理訂閱格式，而不是反覆切換系統代理。v2rayN 的桌面安裝包、v2rayNG 與 v2flyNG 的 Android 安裝包可在安裝包頁面依平台選擇，安裝完成後的基本操作則由入門指南接續說明。

二、VMess：完整工作階段協定與相容性基準

誕生背景與設計重點

VMess 是 Project V 生態早期形成的核心協定之一。它將使用者身分、時間資訊、請求目標與資料傳輸組織在自己的協定結構中，伺服器根據使用者 ID 識別連線。早期設定中經常可見 alterId，曾用於附加身分機制；現代實作普遍採用 AEAD 形式，一般設定中的 alterId 通常為零。匯入較舊訂閱時，如果用戶端仍顯示較大的 alterId，不應照搬到新伺服器，而應以伺服器實際設定為準。

VMess 的優勢不在於某一項極端效能，而在於生態累積時間較長、欄位定義成熟，許多用戶端與訂閱轉換工具都能識別。對於已穩定運作的 VMess 設定，沒有必要只因出現新協定名稱就立即遷移。它仍適合作為跨用戶端遷移時的相容性基準，尤其連線組合只使用 TCP、WebSocket 與 TLS 等常見功能時，V2Fly 和 Xray 通常都能處理其基礎設定。

驗證、時間與加密欄位

VMess 請求包含與時間相關的驗證資訊，因此用戶端與伺服器系統時間差距過大時，可能出現位址、連接埠與使用者 ID 全部正確卻仍驗證失敗的情況。排查時應先確認裝置已啟用系統自動設定時間與正確時區，再檢查伺服器時鐘。這裡關注的是系統時間誤差，而非網路延遲。重複匯入同一連結、切換全域代理或重新安裝用戶端，都無法修正明顯的時鐘偏差。

用戶端介面通常將 VMess 的安全選項顯示為 auto、aes-128-gcm、chacha20-poly1305 或 none。這些欄位描述 VMess 資料層的處理方式，不能取代外層 TLS。選用 auto 時，核心會依實作與裝置能力決定合適方式；只有在伺服器明確要求或排查相容性問題時，才有必要手動固定演算法。外層啟用 TLS 後，伺服器名稱、憑證對應網域與傳輸路徑仍需分別匹配。

VMess 常見設定錯誤

第一類錯誤是把使用者 ID 當成一般密碼編輯。VMess ID 通常採用 UUID 格式，字元遺漏、前後帶有空格或複製到錯誤的使用者項目，都會導致驗證失敗。第二類錯誤是混淆 WebSocket 路徑與 Host：路徑是 HTTP 請求路徑，Host 是請求標頭或 TLS 伺服器名稱相關欄位，兩者可以相同也可以不同，必須依原始設定填寫。第三類錯誤是只保留分享連結的主要欄位，遺漏傳輸層參數。能被用戶端識別的 vmess:// 連結，不代表目前的轉換工具能正確解析其中所有欄位。

第四類錯誤出現在 TLS 開關。伺服器要求 TLS 時，用戶端關閉 TLS 通常無法完成正確握手；伺服器未設定 TLS 時，用戶端自行啟用也不會自動取得安全連線。第五類錯誤是核心升級後仍使用過時欄位。核心可能對已棄用欄位發出警告或直接拒絕載入，圖形用戶端有時只顯示「啟動失敗」。此時應查看記錄中的欄位路徑，例如 outbound、streamSettings 或 security，而不是只看系統匣狀態。

何時保留，何時遷移

現有 VMess 連線穩定、伺服器維護明確且訂閱更新正常時，保留它通常比無目的遷移更省事。需要遷移的訊號主要來自伺服器設定變更、核心功能需求或訂閱提供者明確更換協定。如果希望使用 REALITY 或 XTLS Vision，應完整匯入新的 VLESS 設定，不能簡單複製 VMess 節點的位址與 ID 後只修改協定下拉選單。遷移後也應保留原節點一段時間作為對照，以區分協定設定問題與本機 DNS、路由規則問題。

三、VLESS 與 REALITY：輕量驗證與現代安全層組合

VLESS 為何採用精簡設計

VLESS 將重點放在輕量身分驗證與請求轉發，不在協定本身重複提供一套內容加密。用戶端介面中常見的 encryption 值是 none，這不表示完整鏈路必然沒有加密，而是表示安全能力應由 TLS、REALITY 等外層承擔。這樣可減少協定層與傳輸安全層重複處理的機會，也讓 VLESS 更容易與 XTLS 系列流控組合。設定人員必須清楚：只有 VLESS 搭配 TCP 且未啟用任何安全層時，鏈路特性才會與 VLESS 搭配 TLS 或 REALITY 完全不同。

VLESS 使用者憑證通常仍是 UUID。與 VMess 相比，它不依賴 VMess 的時間驗證結構，也沒有 alterId。伺服器可以為使用者設定 flow 等擴充欄位，用戶端必須逐項匹配。常見的 xtls-rprx-vision 是 XTLS Vision 流控值，屬於 Xray 生態的實作能力，並非所有使用 VLESS 名稱的核心都支援。匯入訂閱後如果 flow 為空，而原始連結明確包含 Vision，應先檢查用戶端核心與訂閱解析過程。

REALITY 解決的設定層問題

REALITY 是 Xray 的傳輸安全實作，通常使用目標網站相關資訊參與握手，並透過伺服器私鑰與用戶端公鑰建立對應關係。用戶端常見欄位包括伺服器名稱、指紋、公鑰、Short ID 與 SpiderX；伺服器則保存對應私鑰及允許的伺服器名稱等設定。用戶端只需要公鑰，不應將伺服器私鑰寫入訂閱或分享連結。公鑰、Short ID 或伺服器名稱任一不匹配，都可能表現為連線快速關閉。

伺服器名稱通常在用戶端中顯示為 SNI 或 serverName，會參與握手選擇與驗證。指紋欄位常見值為 chrome 等瀏覽器指紋識別，用於決定握手特徵的實作；它不是裝置瀏覽器版本，也不需要實際啟動相應瀏覽器。Short ID 是伺服器允許的值之一，長度與內容必須符合伺服器設定。SpiderX 常見預設值為斜線，用於 REALITY 相關行為設定；除非伺服器另有指定，不應憑經驗加入複雜路徑。

XTLS Vision 與轉發路徑

XTLS Vision 的目標之一，是識別適合直接轉發的資料路徑，減少不必要的重複封裝與記憶體複製。當傳輸內容本身已具備安全層時，適當的流控可以降低額外處理成本，尤其對持續吞吐的連線更有意義。不過，Vision 的效益取決於核心、伺服器、傳輸組合與實際資料類型。短連線頁面載入主要受握手、DNS 與往返時間影響，不能期待只勾選 flow 就消除所有等待。

Vision 通常與 TCP 組合。任意搭配不受支援的傳輸方式，可能導致設定無法載入或遭伺服器拒絕。若用戶端編輯器提供協定、傳輸、安全與 flow 四組選項，應依伺服器提供的完整組合填寫。正確做法是先確認 protocol = vless，再確認傳輸方式，接著確認 security = reality，最後核對 flow、公鑰、伺服器名稱、指紋與 Short ID。

{
  "protocol": "vless",
  "user": {
    "id": "00000000-0000-4000-8000-000000000000",
    "encryption": "none",
    "flow": "xtls-rprx-vision"
  },
  "transport": {
    "network": "tcp",
    "security": "reality",
    "serverName": "www.example.com",
    "fingerprint": "chrome"
  }
}

上方片段用於說明欄位層次，採用保留的示例網域與示例使用者 ID，無法直接連線至實際伺服器。真實設定還必須包含伺服器位址、連接埠、REALITY 公鑰與 Short ID。其意義在於協助確認訂閱轉換後欄位是否位於正確位置：VLESS 的使用者欄位、TCP 傳輸欄位與 REALITY 安全欄位不能互相取代。

匯入失敗時的核對順序

先確認目前用戶端確實使用支援 REALITY 與 Vision 的 Xray 核心，再確認連結中的 security=reality、flow=xtls-rprx-vision 沒有在訂閱轉換時遺失。接著檢查 pbk 或 publicKey、sid 或 shortId、sni、fp 等欄位。不同分享連結規範可能使用簡稱，但匯入後的介面應還原為對應設定項目。如果用戶端能儲存節點但啟動時回報未知欄位，通常是核心能力不匹配；如果核心正常啟動但握手失敗，則優先核對公鑰、伺服器名稱與 Short ID。

四、Trojan 與 Shadowsocks：兩種不同的精簡路線

Trojan 的 TLS 前提

Trojan 使用密碼進行使用者驗證，並將標準 TLS 作為連線設計的重要基礎。用戶端設定通常包括伺服器位址、連接埠、密碼、伺服器名稱與憑證檢查相關選項。它的欄位數量相對直觀，但「欄位少」不代表可以忽略 TLS。伺服器名稱必須與伺服器部署相符，憑證名稱檢查也依賴此欄位；若直接將伺服器名稱改成 IP，可能導致憑證主機名稱不匹配。除非處於明確的診斷環境，不建議將關閉憑證驗證作為長期解決方案。

Trojan 與 VLESS 的主要差異不只在驗證憑證。Trojan 使用密碼，VLESS 常用 UUID；Trojan 的一般連線高度依賴 TLS，VLESS 則可與不同安全層組合。兩者都能搭配部分傳輸方式，但實際支援範圍由伺服器與核心決定。收到 trojan:// 分享連結時，應完整保留密碼、SNI、傳輸類型、Host 與路徑，不能只擷取最顯眼的伺服器位址。

Trojan 常見故障邊界

如果 TLS 握手階段就失敗，應先檢查裝置時間、伺服器名稱、憑證有效狀態，以及網路是否能連到目標連接埠；如果 TLS 建立後驗證失敗，再繼續核對密碼。密碼區分大小寫，連結中的特殊字元需要正確進行 URL 編碼。某些手動複製過程會將加號、百分號或井號誤當成連結結構字元，導致匯入結果與原密碼不同。最穩妥的方式是由用戶端直接匯入完整分享連結，再在編輯介面核對欄位。

WebSocket 或 gRPC 等傳輸還會增加路徑、服務名稱與 Host 等參數。此時「Trojan 可連線」實際上代表 Trojan 驗證、TLS 握手與傳輸層參數同時正確。記錄出現 HTTP 狀態錯誤時，應檢查傳輸路徑；出現憑證名稱錯誤時，應檢查伺服器名稱；出現驗證拒絕時，再檢查密碼。按階段排查，比反覆切換多個開關更容易定位問題。

Shadowsocks 的加密方法與密碼

Shadowsocks 採用較精簡的加密代理結構，用戶端與伺服器必須使用完全相同的加密方法與密碼。常見 AEAD 方法包括 aes-128-gcm、aes-256-gcm 與 chacha20-poly1305。不同方法在支援硬體加速的桌面處理器與行動處理器上可能有不同表現，但現代裝置上的差距通常也會被網路品質、連線數量與伺服器負載掩蓋。選擇時應優先遵循伺服器設定，不要只在用戶端單方面更換演算法。

Shadowsocks 2022 系列方法改進了金鑰與工作階段處理，但其密碼或金鑰格式與舊式 AEAD 方法不同，而且並非所有核心與訂閱解析器都完整支援。看到方法名稱包含 2022 時，應先確認用戶端核心支援相應方法，再檢查匯入後的金鑰是否完整。將 2022 方法改成傳統 AEAD 名稱不會產生相容連線，因為伺服器使用的協定細節已經不同。

何時選擇這兩類協定

伺服器提供標準 Trojan 設定，且憑證與伺服器名稱管理清楚時，Trojan 的設定模型容易理解，也方便依 TLS 與驗證兩個階段排查。伺服器提供精簡的 Shadowsocks 設定，且用戶端明確支援相應加密方法時，Shadowsocks 欄位較少，適合不需要複雜流控擴充的情境。兩者沒有脫離環境的絕對優先順序。實際選擇應考量伺服器維護方式、用戶端核心、訂閱能否完整表達欄位，以及裝置是否需要 TUN 與複雜路由。

v2rayN、v2rayNG 與 v2flyNG 都可能在介面中顯示這些協定選項，但可見選項不代表目前核心支援所有擴充組合。特別是 Shadowsocks 外掛參數、2022 方法與 Trojan 的特殊傳輸組合，應以執行核心產生的設定結果為準。若節點來自訂閱，應優先查看訂閱更新後的原始類型，不要用名稱相近的節點作為欄位範本覆寫。

五、連線速度、資源用量與行動端電量

速度由多段鏈路共同決定

使用者感受到的「速度」至少包含 DNS 查詢、用戶端與伺服器建立連線、TLS 或 REALITY 握手、伺服器與目標網站建立連線、首位元組等待時間及持續傳輸吞吐量。協定只影響其中一部分。短網頁請求較容易受 DNS、握手往返與連線多工影響；大檔案傳輸則較能反映加密實作、記憶體複製、壅塞控制與伺服器出口能力。僅憑一次節點測速，無法準確將差異歸因於 VMess、VLESS 或 Trojan。

比較協定時，應使用同一裝置、同一網路入口、相近時間、同一伺服器與目標內容，並盡量保持傳輸層一致。若一個節點使用 WebSocket 搭配 TLS，另一個使用 TCP 搭配 REALITY，結果反映的是完整組合的差異。測試還應區分冷連線與已建立連線：冷連線包含 DNS 與握手成本，重複請求可能重用連線，兩者適合回答不同問題。

CPU、記憶體與連線多工

加密演算法是否具備硬體加速、資料封裝層數、並行連線數量與記錄等級，都會影響 CPU 使用量。具備 AES 硬體指令的桌面處理器通常能有效率地處理 AES-GCM；缺少相應 AES 加速的裝置可能更適合 ChaCha20-Poly1305，但不能只依裝置類型作絕對判斷。VLESS 搭配適當流控可以減少部分重複處理，實際效益仍需伺服器與傳輸組合共同支援。

Mux 多路複用會將多個邏輯連線集中到較少的底層連線中，可能降低頻繁握手的成本，也可能在單一底層連線出現壅塞或封包遺失時，讓多個請求互相影響。網頁包含大量短請求時，Mux 有機會改善連線建立成本；持續下載、即時連線或網路品質波動明顯時，關閉 Mux 反而可能更穩定。用戶端預設值通常是合理起點，不建議直接將「連線數越少」理解為「速度越快」。

記憶體用量還與路由規則、網域資料庫、DNS 快取、TUN 緩衝區與並行連線有關。協定本身的框頭差異通常不是圖形用戶端總記憶體用量的唯一主要來源。排查高用量時，應先比較關閉詳細記錄、縮減過大的規則集、停止重複測速並關閉不必要的並行工作後的變化，再決定是否更換協定。

TUN 模式為何更耗資源

系統代理主要接管遵循系統代理設定的應用程式流量，處理路徑相對直接。TUN 模式會建立虛擬網路介面，可涵蓋更多不讀取系統代理的程式，但需要處理 IP 封包、DNS、路由匹配與協定堆疊轉換。行動端長時間啟用 TUN 時，喚醒頻率、背景連線維持、DNS 請求與網路切換後重建連線，都會影響電量。這裡的主要成本來自系統層級的流量接管，不能簡單歸因於所選代理協定。

如果只需要瀏覽器與遵循系統代理的桌面程式，優先使用系統代理通常更省資源；需要依程序或完整接管應用程式流量時，再評估啟用 TUN。啟用後應避免同時執行另一個佔用虛擬網路介面的工具，並檢查略過區域網路、DNS 模式與路由規則。TUN 可以擴大涵蓋範圍，但不是「更強的協定」，也不會修復錯誤的使用者 ID、公鑰或伺服器名稱。

行動端電量的實際控制項

行動端電量表現更受網路狀態與背景行為影響。訊號較弱時，裝置維持無線連線本身就需要更多能量；節點頻繁斷線會觸發重新連線、DNS 重試與連線重建；自動測速與過短的訂閱更新週期也會喚醒網路。合理做法是選擇穩定節點，避免持續執行批次測速，依需求設定訂閱更新，並在不需要完整流量接管時減少 TUN 使用時間。

協定層面可優先選擇用戶端核心原生支援、欄位完整且連線穩定的組合。一個理論處理成本較低但頻繁握手失敗的節點，實際耗電可能高於穩定的傳統設定。v2rayNG 使用 Xray 核心，適合需要 REALITY、Vision 等 Xray 功能的設定；v2flyNG 使用 V2Fly 路線，適合與相應核心設定保持一致。選擇應用程式時，應同時考量協定功能與背景穩定性，而不是只比較安裝包名稱。

六、V2Fly 與 Xray 核心家族及設定相容性邊界

共同基礎與演進方向

V2Fly 和 Xray 都延續 Project V 生態的模組化設定思路：入站負責接收本機流量，出站負責連線至目標或代理伺服器，路由決定流量交給哪個出站，DNS 模組提供網域解析策略，傳輸設定描述 TCP、WebSocket、gRPC 等承載方式。兩者在 VMess、部分 VLESS、Trojan、Shadowsocks 與基礎路由結構上存在大量相似概念，因此許多訂閱可以被不同用戶端識別。

相似不代表設定檔可以完全互換。Xray 在 VLESS、XTLS Vision、REALITY 等方向形成自己的功能擴充，也可能為傳輸與路由增加特定欄位；V2Fly 則沿著自身版本與模組體系維護功能。某個 JSON 能被一個核心讀取，不代表另一個核心會接受其中所有欄位。圖形用戶端的「匯入成功」也只表示連結已解析為伺服器記錄，真正的相容結果仍應以核心啟動與連線記錄為準。

三款用戶端與核心定位

v2rayN 是本站桌面端首選用戶端，支援 Windows、macOS 與 Linux，提供伺服器清單、訂閱分組、系統代理、TUN、路由設定與核心管理等圖形化入口。它適合需要在桌面端處理多個訂閱、複雜路由與協定測試的使用者。常見設定以 Xray 能力為主，因此匯入 REALITY 與 XTLS Vision 時，應確認實際啟用的是相應核心，而不是只查看用戶端名稱。

v2rayNG 面向 Android，主要使用 Xray 核心，適合 VLESS、REALITY、Vision 以及常見的 VMess、Trojan、Shadowsocks 設定。v2flyNG 同樣面向 Android，但以核心路線作區分，適合需要使用 V2Fly 設定語義的情境。兩款應用程式的介面欄位可能相近，執行結果仍由核心能力決定。伺服器明確要求 Xray 擴充欄位時，優先選擇 v2rayNG；設定明確面向 V2Fly 時，可以選擇 v2flyNG。

設定相容性的三個層次

第一層是語法相容，也就是 JSON 欄位名稱與資料類型能否解析。第二層是功能相容，也就是核心是否實作該協定、傳輸或安全層。第三層是行為相容，也就是雙方雖然都接受欄位，但預設值、DNS 策略或路由匹配細節是否相同。遷移時只看到「設定載入成功」還不夠，應繼續驗證網域解析、直連規則、代理規則與 UDP 流量是否符合預期。

分享連結相容性也分層次。用戶端可能認識 vless://，卻不認識連結中的新查詢參數；也可能保留節點主體，但遺失 flow、fingerprint 或 Short ID。訂閱轉換服務還可能將核心專屬欄位改寫為自己的中間格式。遇到這類情況，應比較原始分享連結與匯入後的編輯頁面，並查看用戶端匯出的完整設定，而不是籠統地將問題歸為「不支援協定」。

切換核心前後的檢查

在 v2rayN 中切換執行核心前，應記錄目前節點的協定、傳輸、安全層與路由設定。切換後重新啟動用戶端，讓設定完整載入，再查看啟動記錄是否包含未知欄位、無效列舉值或缺少資源檔案。對於只使用基礎 VMess、TCP 與 TLS 的設定，遷移通常較順利；對於 REALITY、Vision、特殊 DNS 與核心專屬路由功能，應逐項驗證欄位。

行動端不建議為了測試而頻繁在不同用戶端之間手動重建複雜節點。更可靠的方法是保留原有訂閱，在目標用戶端重新匯入，再核對節點類型與關鍵欄位。若訂閱本身針對單一核心產生，應選擇相應用戶端。安裝入口可在Android 用戶端清單查看，兩款用戶端不要同時維持活動連線，以免虛擬網路介面與系統路由互相覆蓋。

七、訂閱、分享連結與原生 JSON 的相容性

三種常見設定載體

單條分享連結通常以 vmess://、vless://、trojan:// 或 ss:// 開頭，一條連結描述一台伺服器。訂閱連結則指向可更新的節點集合，用戶端請求訂閱後解析其中多筆記錄。原生 JSON 設定包含入站、出站、DNS、路由與策略等完整結構，表達能力最強，但不一定適合直接匯入只接受伺服器記錄的訂閱介面。三者用途不同，不能只因內容看起來都是文字就互相取代。

Base64 聚合訂閱的常見做法，是將多條分享連結逐行排列後再編碼。Base64 只是編碼，不具備協定轉換能力。如果其中某條 VLESS 連結包含 REALITY 欄位，用戶端仍需識別這些查詢參數。原生 JSON 訂閱可能使用用戶端自訂結構，欄位名稱與核心設定並不完全相同。判斷訂閱是否相容，應先確認回應內容屬於分享連結集合、用戶端專用 JSON，還是完整核心設定。

各協定連結的關鍵欄位

VMess 連結常見於編碼後的 JSON 物件，包含位址、連接埠、使用者 ID、網路類型、Host、路徑、TLS 與伺服器名稱等資訊。由於歷史格式存在多種欄位約定，轉換工具之間容易對 host、sni 與路徑採取不同處理方式。VLESS 連結通常將 UUID 放在使用者資訊位置，並透過查詢參數表達 encryption、security、type、flow、sni、fp、pbk 與 sid 等欄位。REALITY 設定尤其依賴查詢參數完整保留。

Trojan 連結以密碼作為使用者資訊，查詢參數可攜帶 SNI、傳輸類型、Host 與路徑。密碼中的特殊字元必須進行 URL 編碼，否則井號後的內容可能被識別為節點備註，問號後的內容可能被識別為查詢參數。Shadowsocks 連結既有將加密方法與密碼整體編碼的形式，也有分開表達使用者資訊的形式；部分連結還包含外掛參數。用戶端能識別 ss:// 前綴，不代表支援其中指定的所有外掛或 2022 方法。

匯入訂閱後節點為空

第一步是在用戶端中手動更新訂閱分組，並查看更新提示是請求失敗、內容為空，還是解析結果為零。請求失敗通常與訂閱位址、網路路徑或位址有效狀態有關；回應有內容但節點為零，則更可能是格式不受支援。第二步確認複製的是訂閱位址，而不是網頁位址或單一節點備註。第三步檢查位址前後是否混入空格、換行或中文標點。

如果只有部分節點遺失，應依協定分類檢查。傳統 VMess 可以匯入但 REALITY 節點消失，通常表示解析器未保留新欄位或核心能力不足；一般 Shadowsocks 可以匯入但 2022 方法遺失，可能是方法支援範圍不同；Trojan 節點存在但無法連線，則繼續核對密碼、SNI 與傳輸參數。更完整的格式結構與轉換思路可參考Base64、原生 JSON 與分享連結說明。

訂閱更新與本機修改的衝突

訂閱節點通常由遠端記錄管理。使用者在用戶端中手動修改訂閱節點後，下一次更新可能會覆寫本機欄位。需要長期調整路由、DNS 或系統代理時，應優先修改用戶端的全域設定或路由設定，而不是逐一修改訂閱節點。確實需要保留節點副本時，可以複製到本機分組，並清楚區分它與可更新訂閱之間的關係。

訂閱分組還可用於區分不同設定來源，分別設定更新週期。更新不宜過於頻繁，因為伺服器清單通常不需要每分鐘重新整理；行動端頻繁更新也會增加背景網路活動。節點備註可以協助識別用途，但備註不參與協定驗證。重新命名節點不會改變伺服器位址、公鑰或密碼，也不能修復底層欄位遺失。

QR Code、剪貼簿與手動輸入

QR Code 只是分享連結的圖形載體。掃描成功後仍由用戶端解析原始 URI，因此 QR Code 清晰度只能影響讀取，無法解決欄位不相容。剪貼簿匯入適合一次處理一條或多條完整連結，手動輸入則適合核對少量欄位。REALITY、WebSocket 與 gRPC 設定欄位較多，優先使用完整匯入，再進入編輯介面檢查，通常比從零手動填寫更可靠。

在 v2rayN 和 v2rayNG 中匯入訂閱的具體入口、手動更新時機與節點清單檢查順序，可繼續閱讀訂閱連結匯入教學。如果只是收到一條 vmess:// 或 vless:// 連結，則可參考分享連結與訂閱的差異，避免將單條連結誤填至訂閱位址欄。

八、依使用情境選擇協定並完成遷移驗證

桌面一般使用

Windows、macOS 與 Linux 桌面端優先使用 v2rayN。已有穩定訂閱時，先完整匯入並使用訂閱提供的協定組合，不必預先將所有節點改成同一類型。一般瀏覽與遵循系統代理的應用程式，可先啟用系統代理；只有不讀取系統代理的程式需要接管時，再評估 TUN。選擇節點時先確認能否穩定完成連線，再比較連續存取表現，避免用一次測速排序取代長期判斷。

如果訂閱同時提供 VMess、VLESS REALITY、Trojan 與 Shadowsocks，可以保留多種類型作為對照。使用 Xray 核心時，伺服器提供的 VLESS、REALITY、Vision 組合通常具備較完整的功能匹配；已有 VMess 或 Trojan 穩定連線仍可繼續使用；Shadowsocks 則應重點確認加密方法。協定名稱不是品質等級，伺服器維護與完整設定比名稱新舊更重要。

行動端常駐連線

在 Android 上需要 Xray 擴充時選擇 v2rayNG，需要 V2Fly 核心語義時選擇 v2flyNG。行動端首先考量穩定性、背景重新連線與電量，而不是啟用盡可能多的功能。選擇穩定節點，關閉不必要的批次測速，妥善安排訂閱更新。如果應用程式流量可由系統提供的代理路徑涵蓋，就不必一直使用較耗資源的 TUN 接管；必須使用 TUN 時，應簡化路由規則並檢查 DNS 是否重複處理。

行動網路與無線區域網路切換後，原有 TCP 連線通常需要重建。短暫斷線不一定是協定故障；如果每次切換後長時間無法恢復，再檢查用戶端背景權限、系統網路狀態與節點重新連線記錄。更換協定只能解決協定或握手層問題，無法修復系統暫停背景網路、訂閱欄位遺失或伺服器無法連線。

將舊設定遷移至現代組合

從 VMess 遷移至 VLESS REALITY 時，應讓伺服器產生完整的新設定，並在用戶端作為新節點匯入。不要修改舊 VMess 節點的協定下拉選單後，繼續沿用其 TLS、WebSocket 或使用者欄位。遷移時需要同時核對 UUID、傳輸類型、REALITY 公鑰、Short ID、伺服器名稱、指紋與 flow。舊節點應暫時保留，方便在同一網路下進行對照。

從傳統 Shadowsocks 方法遷移至 2022 方法時，同樣需要伺服器與用戶端同步更換，舊密碼格式不能直接沿用。Trojan 更換憑證或網域後，需要更新伺服器名稱及可能相關的傳輸 Host。任何遷移都應先驗證基本連線，再恢復複雜路由、TUN 與自訂 DNS；一次修改太多項目，會讓記錄難以指向具體原因。

故障現象對應的優先檢查項目

一套可重複的驗證流程

第一步，記錄原始設定的協定、傳輸、安全層與執行核心。第二步，匯入新設定但先不要刪除原節點。第三步，關閉複雜路由與額外 DNS 改寫，只驗證核心能否啟動、伺服器能否連線及基本網域能否存取。第四步，依序恢復系統代理、路由分流、DNS 與 TUN，每恢復一項就進行一次簡單存取測試。第五步，觀察網路切換與裝置休眠後的恢復情況。第六步，再根據實際使用情境比較冷連線、連續存取與持續傳輸。

閱讀記錄也應遵循層次。設定解析錯誤出現在啟動階段，應檢查欄位與核心；握手錯誤出現在連線階段，應檢查憑證與安全層；網域解析錯誤應檢查 DNS；只有特定應用程式無法存取時，才應檢查系統代理、TUN 與路由。將記錄階段與設定層次對應起來，可以避免把所有問題歸結為「節點無法使用」。

如果目標是盡快完成首次連線，依照入門指南的主線操作即可；如果尚未安裝適用於平台的用戶端，可前往安裝包頁面選擇 v2rayN、v2rayNG 或 v2flyNG。Windows 安裝與桌面版、WPF 版的差異可查看v2rayN Windows 安裝設定完整流程。完成連線後再回到本手冊核對協定欄位，通常比一開始同時修改核心、路由與傳輸參數更容易得到可解釋的結果。