V2Ray 協定與核心
選擇技術參考

協定與設定分層：先看懂一個節點

把連線拆解成四個問題

用戶端中的節點是一組連線參數，不是單一的協定開關。閱讀設定時，先確認四件事：要連到哪台伺服器、使用什麼身分驗證、資料透過哪種傳輸方式傳送，以及連線外層採用什麼安全機制。伺服器位址與連接埠用來定位入口；VMess、VLESS、Trojan 或 Shadowsocks 決定代理協定；TCP、WebSocket 等決定承載方式；TLS 或 REALITY 則涉及安全層。這些項目彼此相關，卻不是可以互換的同級選項。

例如，看到「VLESS + WebSocket + TLS」，就應分別確認使用者識別碼、WebSocket 路徑、請求主機與 TLS 伺服器名稱。路徑正確無法彌補使用者識別碼錯誤，伺服器名稱正確也不代表遠端有在相應連接埠監聽。用戶端介面有時會把這些欄位放在同一個視窗，容易讓人誤以為「選好協定就完成設定」。實際上應以伺服器端提供的完整參數為準，逐層核對，不要只憑節點備註猜測。

系統代理與 TUN 屬於另一層

系統代理決定應用程式是否將請求送到本機代理入口；TUN 則透過虛擬網路介面接收路由至該介面的流量。兩者改變的是流量進入用戶端的方式，不會把 VMess 變成 VLESS，也無法修復遠端驗證失敗。若某個瀏覽器能連線、另一個程式卻不行，應先確認該程式是否遵循系統代理；若所有程式都連不上，再依序檢查本機入口、核心出站與遠端入口。

分辨網域名稱在哪裡解析

如果伺服器位址是網域名稱，建立連線前必須先解析；而目標網站的網域名稱，則可能由本機應用程式、用戶端 DNS 模組或遠端負責解析。這是兩條不同的解析路徑。修改目標網域的分流規則，不一定會改變伺服器網域的解析結果。若遇到「網域位址連不上，直接填入 IP 位址卻能連線」，應檢查入口網域解析與 IP 位址類型，不要立刻更換協定。直接填入 IP 位址只是用來定位問題，仍須保留正確的安全層伺服器名稱。

選擇方案也應遵循這些層次：先確認現有服務提供哪些組合，再確認用戶端核心是否支援，最後才考慮是否需要 TUN、分流或訂閱管理。桌面端可先從 v2rayN 下載入口選擇平台；如果手上只有訂閱連結，請先完成匯入，再查看節點詳細資訊。貿然把安全層改成另一種，通常只會讓原本完整的設定失去對應關係。

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

VMess 的設計背景與相容性限制

VMess 是 Project V 生態系中的代理協定，設計包含使用者驗證與資料保護機制，形成較完整的協定處理流程。現有訂閱中仍常見 VMess，不應只因為它問世較早就判定無法使用。判斷依據應是目前的用戶端核心與伺服器端實作是否相容、設定是否完整，以及連線是否符合實際需求。協定內部的資料保護與外層 TLS 屬於不同層次，即使同時使用，也不能簡單視為重複設定加密選項。

VMess 常見的疑難排解項目包括使用者識別碼、加密設定與系統時間。驗證涉及時間相關檢查，裝置時間若明顯不準，可能導致交握失敗；此時應啟用系統自動校時，而不是不斷更新訂閱。舊設定可能留有額外的識別參數，新版實作通常採用 AEAD 驗證。遇到舊欄位時，請向服務提供者確認是否適用，不要照著舊截圖隨意填寫，也不要以為能相容舊參數就代表所有新舊實作都能互通。

VLESS 將安全性責任交由組合方案承擔

VLESS 的設計取捨是精簡協定本身的處理流程，不在協定層承擔與 VMess 相同的資料加密職責，因此通常會搭配 TLS 或 REALITY 使用。精簡不代表自動安全，也不保證任何連線都更快。在公共網路上使用時，必須確認外層保護如何建立；若只是把 VMess 節點的協定選項改成 VLESS，而伺服器端沒有相應入口，自然無法通過驗證。變更協定需要兩端共同設定，不能只在用戶端單方面完成。

VLESS 設定中的使用者識別碼仍是身分參數，不能與 TLS 伺服器名稱混為一談。流量控制欄位也受實作限制，例如服務提供者提供 Vision 相關設定時，須確認承載方式、核心支援情況與伺服器端要求。並非所有 VLESS 節點都應填入相同的流量控制設定，更不能看到 REALITY 就自行加入流量控制值。保留訂閱明確提供的設定，比套用所謂的通用參數更可靠。

如何在兩者之間做選擇

如果現有 VMess 設定運作穩定，目標用戶端也能完整匯入，就沒有必要只因為「新協定比較快」這種概括說法而遷移。若伺服器端明確提供 VLESS 與合適的安全層，且用戶端使用支援該組合的核心，就可以依原始參數試用。比較時應固定伺服器、測試目標與本機流量接管方式，否則不同入口的負載、線路與路由策略會掩蓋協定差異；最後測到的只是兩個節點的整體差異，不是協定本身的差異。

遷移前先保留原設定，在獨立群組匯入新設定，確認網頁瀏覽、長連線與所需的 UDP 應用程式都能正常運作，再決定是否取代預設節點。不要先覆寫仍可運作的項目，才開始排除問題。若新設定只在某個核心下失敗，應檢查傳輸與安全層支援情況；若所有核心都失敗，則回頭檢查伺服器端參數與網路連線。匯入操作的詳細位置可參考v2rayN 訂閱匯入教學；本章僅說明欄位之間的關係。

Trojan 與 Shadowsocks：兩種連線模式

Trojan 仰賴完整的 TLS 連線

Trojan 的典型設計是在 TLS 連線中承載代理請求，並以密碼進行身分驗證。設定介面看起來簡潔，不代表只需要位址和密碼。伺服器名稱、憑證信任與傳輸設定同樣重要。連線 IP 位址與驗證網域可以不同：前者用來找到伺服器，後者用來建立預期的 TLS 身分關係。若伺服器提供專用名稱欄位，請保留該欄位，不要把節點位址直接複製到每個輸入框。

憑證錯誤通常應先檢查名稱是否相符、系統時間是否準確，以及信任鏈是否完整。關閉憑證驗證會改變安全前提，不應作為日常的修復方式。若使用伺服器端自訂的部署方式，還需確認採用哪種承載方式；不同核心或用戶端對延伸組合的設定方式可能不同。一般 Trojan 入口可用，不代表也支援某種額外的傳輸擴充，必須核對實際實作與參數。

Shadowsocks 的加密方法欄位不可省略

Shadowsocks 常簡稱為 SS，採用共用金鑰機制，用戶端必須知道伺服器位址、連接埠、密碼與加密方法。它與主要依賴外層 TLS 的設定方式不同，不能將 SS 的方法名稱填入 VLESS 的安全層選項。早期方法與現代 AEAD 方法有所差異，實際選擇應依伺服器端支援範圍而定。把方法改成用戶端清單中看起來更強的選項，不會自動升級伺服器端，反而會導致兩端無法解讀資料。

部分較新的 Shadowsocks 方法對金鑰編碼與長度有明確要求，不適合再把任意短語當成通用密碼。用戶端能顯示某個方法名稱，也不保證目前執行的核心已實作該方法。若匯入後方法遺失、密碼遭截斷或驗證持續失敗，請對照原始分享格式檢查，不要不斷重試相同連線。也要留意外掛參數：用戶端支援基本的 SS，不代表同時具備執行特定外部外掛或延伸傳輸的條件。

UDP、連線重用與使用限制

兩種協定都不能只憑「支援 UDP」四個字，就判定目標應用程式一定能正常使用。遠端是否允許轉送、用戶端是否啟用相關功能、本機應用程式的流量是否進入代理，以及路由是否放行，都會影響結果。有些測試只檢查 TCP 連線建立，無法說明語音、遊戲或其他 UDP 應用程式的表現。若網頁正常但某類應用程式失敗，應先核對該應用程式使用的傳輸方式與流量接管路徑，再檢查遠端支援情況，不要立刻更改密碼。

維護設定時，Trojan 通常要留意 TLS 名稱、憑證與密碼；SS 則要留意加密方法、金鑰與選用的延伸參數。若伺服器端只提供其中一種，選擇支援原始組合的用戶端即可，無須為了統一名稱而轉換成另一種協定。桌面端可優先在 v2rayN 查看節點完整參數；Android 端則依核心需求選擇 v2rayNG 或 v2flyNG。兩端使用相同的服務參數，有助於區分用戶端差異與伺服器端問題。

TLS 與 REALITY：逐項核對安全層參數

先分清名稱驗證與網路入口

TLS 為連線提供安全保護，一般使用時還需要驗證對端身分。伺服器名稱用來指定預期連線的身分，不一定與實際撥號位址完全相同；ALPN 用於協商應用層協定，也不是可以任意填寫的加速參數。只有在伺服器端設定要求特定值時，用戶端才應依照約定設定。為了讓連線成功而忽略名稱或憑證問題，會失去原本的驗證前提；應先確認設定來源與遠端部署是否一致。

在採用 WebSocket 或其他中間承載方式的方案中，請求主機、TLS 伺服器名稱與路徑可能分別影響不同的處理階段。有些部署使用同一個網域，另一些則不然。排除問題時應釐清各欄位名稱與用途，不要因為介面只有幾個輸入框，就把所有欄位都改成同一個值。瀏覽器能連上某個網域，只能表示該存取路徑可用，不能證明代理協定驗證、路徑與遠端轉送也都正確。

REALITY 不是第五種出站協定

REALITY 是 Xray 生態系中的安全層機制，常見於 VLESS 組合。它與一般 TLS 憑證部署的設定方式不同，不能只把安全層名稱改成 REALITY 就完成遷移。用戶端通常需要伺服器端提供的伺服器名稱、驗證公鑰參數與 shortId，必要時還須確認指紋與流量控制。不同用戶端可能將相關欄位顯示為「公鑰」，或因核心更新而採用不同名稱；請依核心說明與訂閱提供者的欄位對照方式核對。

公鑰用來對應伺服器端持有的私鑰，無法根據網域推算；shortId 必須屬於伺服器端允許的集合，只有在伺服器端明確允許時才能留空。不要借用其他節點的這兩項參數。連線位址負責找到部署入口，伺服器名稱則必須符合該部署的要求，兩者用途不同。若訂閱更新後這些欄位有所變動，舊設定可能已不適用，應重新匯入完整參數，而不是只更新位址與連接埠。

指紋與流量控制都不是獨立的效能開關

用戶端指紋與 TLS 交握特徵的實作方式有關，可選值取決於核心，不能光看名稱判斷是否相容。流量控制同樣受協定組合與遠端設定限制。若匯入後用戶端提示參數未知，請優先確認是否選用了正確的核心、目前設定格式能否表達這些欄位，以及轉換過程是否遺失資訊。不同介面的預設值不一定相同，因此排除問題時應查看實際儲存的設定，而不是只回想匯入前的分享內容。

較穩妥的核對順序是：先確認遠端提供的是一般 TLS 還是 REALITY，再核對伺服器名稱；使用 REALITY 時，接著確認公鑰參數與 shortId，最後檢查指紋、流量控制及傳輸方式。每次只修改一組相關欄位並保留原值，避免同時更換位址、核心與安全層，導致無法定位問題。遇到交握錯誤時，可參考疑難排解中的連線問題排查來理解記錄，但不要公開貼出含驗證參數的完整設定。

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

區分首次連線與持續傳輸

討論「哪種協定比較快」之前，必須先定義觀察項目。首次開啟頁面涉及網域名稱解析、與伺服器建立連線、協定驗證，以及可能發生的 TLS 交握；持續下載則較受線路容量、壅塞、遠端負載與裝置處理能力影響。某種組合減少一個處理環節，不代表在所有網路環境下都能明顯縮短頁面載入時間。若測試目標或伺服器入口不同，就不能把最後的差異全歸因於協定，更不能據此做出固定的速度排名。

交握過程容易受往返時間影響，大型檔案傳輸則更看重穩定的吞吐量。在適合的情境中，連線重用可以減少重複建立連線，但也可能改變連線間的資源競爭與故障影響範圍。用戶端提供重用開關，不代表所有節點都應一律啟用。部分組合對重用或流量控制有特定限制，應優先遵循伺服器端建議；若要驗證效果，請保持其他設定不變，分別觀察短請求、長連線與並行存取。

CPU 與記憶體負載來自完整的處理流程

VMess 協定處理、SS 加密方法、TLS 交握、資料複製與傳輸封裝都會產生負載，而現代處理器的硬體加速能力也會改變相對成本。VLESS 減少協定層的處理，但外層安全機制仍需要運算資源。TUN、DNS 模組與規則比對也會耗用資源，不能把用戶端整體用量直接當成某個協定的用量。若桌面端切換模式後記憶體用量改變，應先確認是否同時啟用了額外核心功能與規則集。

行動裝置應特別觀察喚醒與重新連線

Android 裝置耗電不只來自加密運算，也包括維持無線連線、背景心跳、DNS 請求，以及失敗後不斷重新連線。訊號較弱或頻繁切換網路時，相同協定也可能有不同表現。若啟用用戶端後待機耗電明顯增加，應先檢查是否持續出現失敗記錄、是否有應用程式頻繁連網，以及訂閱或探測工作是否過於頻繁。只更換協定、卻保留相同的重連循環，通常無法解決根本問題。

比較耗電時，應在訊號狀況相近的環境下，使用相同的應用程式與方式，並區分螢幕常亮測試與背景待機測試。短時間的電量百分比變化不足以證明協定優劣。桌面端也應分別檢查閒置與忙碌狀態，避免比較時其中一端還在執行其他下載工作。若要讓非瀏覽器程式的流量也經過代理，可進一步閱讀v2rayN TUN 模式原理與設定，先確認流量進入路徑，再評估額外負載。

V2Fly、Xray 與三款用戶端的分工

核心家族與圖形介面屬於不同層次

Project V 是了解這個生態系的起點；V2Fly 延續 V2Ray 相關專案的開發，Xray 則與 V2Ray 有共同歷史並獨立發展。兩者在協定、傳輸與設定結構上有共同基礎，也各自發展功能。開放原始碼代表可依各專案的授權條款檢視與使用程式碼，不代表不同專案會永久共用完全相同的設定語意。涉及特定功能時，應以實際執行的核心實作為準，而非只看專案名稱。

圖形用戶端負責訂閱管理、節點編輯、啟動核心與系統代理等操作；核心則負責連線處理、協定實作與規則執行。v2rayN 是桌面端的優先選擇，支援 Windows、macOS 與 Linux；同一用戶端的不同介面形式或封裝方式，也不應誤認為不同代理協定。選擇安裝檔時，先確認作業系統與處理器架構，再確認實際執行的核心及其接收的設定內容。

Android 端依核心需求選擇

v2rayNG 適用於 Android，採用 Xray 核心；v2flyNG 則是採用 V2Fly 核心的替代選擇。兩者的介面可能有相似的匯入步驟，但核心功能不會因此相同。需要 REALITY 等 Xray 相關功能時，應優先確認 v2rayNG 是否支援目前的組合，不要預設 v2flyNG 也能照原樣支援。若已有適用於 V2Fly 的設定，則可依實際傳輸與協定支援情況評估 v2flyNG，不要只憑名稱相似就決定。

若 v2rayN 提供核心選擇功能，請留意節點與路由設定最後交由哪個核心處理。介面能儲存某個欄位，只代表編輯器接受該文字，不代表背景核心已實作相應功能。啟動失敗時先查看核心錯誤；連線失敗時再檢查交握與路由錯誤。若記錄顯示欄位不明或不支援傳輸類型，應回頭檢查核心相容性，而不是反覆開啟或關閉系統代理。這兩類錯誤發生在不同處理階段。

依欄位逐項確認設定相容性

兩個核心都使用 JSON，不代表可以直接互換整份設定。部分協定名稱相同，但延伸參數、預設值、傳輸實作或 DNS 行為可能不同。遷移設定時，應先移轉最基本可用的出站設定，再逐項加入路由、DNS 與其他功能。一次複製整套複雜設定，容易連同不支援的欄位與邏輯相依一起帶入，造成看似節點有問題、實際上卻是設定載入失敗。

升級用戶端時，也要分辨介面與核心的變化：介面新增選項，不一定代表所有現有設定都需要修改；核心更新後，舊欄位也可能出現提示或相容性變化。保留可還原的設定、記錄目前的核心名稱，並先測試單一節點，有助於降低遷移成本。安裝與執行環境問題可參閱v2rayN 首次安裝與初始設定；用戶端與作業系統架構的下載入口統一在下載中心，無須另外尋找獨立的核心下載區。

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

訂閱網址、分享連結與核心設定

訂閱網址通常指向一個會回傳節點內容的網路資源；單一節點分享連結則包含一組連線設定；核心設定檔還可能包含本機入站、DNS 與路由。三者用途不同，不能只憑文字看起來很長，就用相同方式匯入。部分用戶端可以自動辨識多種格式，但辨識能力並非毫無限制。請先確認取得的是訂閱網址還是單一節點內容，再選擇相應的匯入入口，避免把網頁網址或整份設定誤當成節點連結。

傳統訂閱常見以 Base64 編碼的多行分享內容，也有其他結構化格式。Base64 只是編碼，不具備保密功能；能解碼也不代表每一行都包含有效節點。VMess 分享內容常把欄位放在編碼後的 JSON 中，VLESS 與 Trojan 常使用帶有查詢參數的 URI，SS 則有不同的編碼格式。不同格式對新欄位的支援能力不一，轉換訂閱時尤其要留意安全層、流量控制與延伸傳輸參數。

編碼正確，語意仍可能遺失

密碼、路徑與查詢參數含有特殊字元時，必須遵循相應格式的編碼規則。例如 URL 中的分隔符號不能隨意當成一般字元使用，透過通訊軟體傳送時換行或複製不完整，也會破壞連結。排查時應優先從原始來源重新複製，避免先手動解碼、編輯，再重新編碼，反而引入新錯誤。若訂閱內容回傳登入頁面或錯誤訊息，即使網路請求成功，也無法產生有效節點。

以下是本機 SOCKS 入站的最小範例，用來說明核心設定與節點分享連結屬於不同結構。這不是完整的用戶端設定，不能用來匯入訂閱；必須放入相應核心的完整設定脈絡中，並設定出站。範例只綁定迴圈位址，避免本機代理入口直接暴露給其他裝置。實際使用圖形用戶端時，通常應在介面中修改本機連接埠，交由用戶端產生設定，不要同時手動修改產生的檔案。

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ]
}

轉換訂閱無法補足核心功能

訂閱轉換的作用是重新表達現有資訊，不是替不支援特定功能的用戶端補上實作。如果目標格式無法攜帶 REALITY 所需參數，轉換後可能出現節點清單正常、交握卻失敗的情況。請對照原始設定，確認協定、安全層、伺服器名稱、公鑰參數與 shortId 是否保留。若原始內容本來就缺少欄位，轉換服務也無法推算正確值，應向設定提供者索取完整資訊。

訂閱網址往往包含可用來存取帳戶設定的識別資訊，應視為敏感資料。將網址提交給第三方轉換服務，等於讓該服務取得訂閱內容；分享截圖時也要避開連結、QR Code 與驗證欄位。更新失敗時，先確認有效期限與回傳內容，再分辨是「直連更新失敗」還是「透過代理更新失敗」。詳細檢查步驟可參閱訂閱解析失敗自我檢查；轉換限制請見訂閱轉換常見問題。

依使用情境選擇，並完成連線驗證

已有可用訂閱：先確保相容，再進行調整

如果已經有有效訂閱，最務實的做法是使用能完整呈現訂閱參數的用戶端。桌面端優先選用 v2rayN，並依作業系統與處理器選擇下載項目；Android 端則依核心需求選擇 v2rayNG，既有的 V2Fly 設定可評估使用 v2flyNG。不要先排出協定優先順序，再硬把所有節點改成排名第一的協定。可用組合已由伺服器端決定，用戶端的任務是正確還原設定，而不是憑空替換。

首次驗證時，先採用最簡單的使用方式：完成訂閱匯入，選擇參數完整的節點，再用明確支援系統代理的應用程式檢查連線。確認基本連線正常後，再加入分流規則、TUN 或其他功能。若一開始同時啟用所有設定，發生錯誤時就很難判斷問題出在協定、DNS、規則還是權限。快速操作步驟請參閱訂閱匯入流程；Android 的詳細操作請見v2rayNG 訂閱匯入。

分別處理行動裝置與複雜應用程式

行動裝置經常切換網路，應留意重新連線、背景執行與系統電量管理，而非只看單次連線測試。若裝置休眠後中斷，先確認用戶端是否受到系統限制、切換網路後是否重新建立連線，以及入口網域能否重新解析。對耗電敏感的使用情境而言，減少不必要的探測與失敗重試，通常比追求特定協定名稱更有幫助。訂閱更新間隔也應設定得當，相關設定可參考v2rayNG 訂閱更新說明。

桌面端若有不遵循系統代理的程式，再考慮使用 TUN，並一併檢查系統權限、DNS 與路由迴圈。啟用虛擬網卡不代表所有流量都應交給遠端，也不代表可以忽略本機網路存取需求。遠端辦公、區域網路裝置與本機服務可能需要保留直連路徑。路由器或旁路由部署則屬於另一種執行環境，還須考慮處理器架構與設定維護，可進一步參閱在路由器上部署 Xray 概覽。

透過分層驗證縮小問題範圍

連線驗證可分四個步驟。第一步確認用戶端核心正常啟動，且本機入口沒有連接埠衝突；第二步確認伺服器網域可解析且入口可連線；第三步檢查協定驗證與安全層交握；第四步檢查目標應用程式的 DNS、路由與傳輸需求。每個步驟都應有可觀察的資訊。連接埠可連線不代表驗證成功，驗證成功不代表能瀏覽目標網站，瀏覽器可用也不代表其他應用程式的流量已進入代理。

比較方案時，記錄用戶端、核心、協定組合與流量接管方式，每次只變更一項。若問題隨某個節點出現，應檢查服務參數與遠端狀態；若問題只出現在某個應用程式，應檢查代理支援與路由；若切換網路後才發生，則應檢查解析、重新連線與網路限制。最終應依參數是否便於維護、所需應用程式能否穩定運作，以及裝置負載是否可接受來選擇。協定沒有脫離部署環境的通用排名；保留一份可還原的設定，比頻繁套用陌生參數更實際。