V2Ray 協定與核心技術參考

在 v2rayNG 或 v2rayN 裡點開一個節點之前,先分清三層東西,後面的選擇會清楚很多。這三層分別是客戶端、核心、協定與傳輸,每一層能改動的東西並不一樣。

三層各自負責什麼

客戶端是看得見的那一層。桌面端是 v2rayN,Android 端是 v2rayNG 與 v2flyNG。客戶端負責介面、訂閱管理、路由開關、分應用程式代理這類操作,並把節點資訊轉譯成核心能讀的設定。

核心是真正建立連線的程式。它讀取一份 JSON 設定,依 inbounds 接收本機流量,依 outbounds 把流量送出去,中間依 routing 裡的規則決定走哪條出站。v2rayNG 呼叫的是 Xray 核心,v2flyNG 呼叫的是 V2Fly 核心,v2rayN 桌面版同樣以 Xray 核心為主。核心決定了哪些協定可用——例如 REALITY 只存在於 Xray 這一側,把 REALITY 節點匯入 v2flyNG 是無法解析的。

協定與傳輸是決定實際表現的一層。協定指 VMess、VLESS、Trojan、Shadowsocks、REALITY 這些身分與封裝方案;傳輸指 TCP、WebSocket、gRPC 這些承載方式;再疊加是否使用 TLS。這一層通常隨訂閱一起派送,日常使用中很少需要手動填寫。

日常能改的其實只有幾項

打開客戶端設定介面,一般使用者真正會動到的選項集中在幾個地方:選哪個節點、路由模式選哪一種、哪些應用程式走代理、是否開機自動啟動。協定與傳輸是跟著節點來的,不是現場編輯的。所以「選對協定」這件事發生在挑選訂閱或整理自建設定的階段,而不是每次連線的時候。理解協定差異的價值在於兩點:同一個訂閱裡有多種協定的節點時,你知道該優先試哪一個;某個節點連不上時,你能判斷問題出在協定參數還是鏈路本身。

本頁與快速上手頁的分工

快速上手負責讓一次連線順利跑通的最短路徑:匯入訂閱、選擇模式、連線、驗證,每一步只講必要動作。本頁不重複那條主線,而是把每個環節背後的選擇講清楚——協定之間差在哪、兩個核心怎麼取捨、訂閱欄位怎麼對應、什麼情境該用哪種組合。如果現在只想盡快連上,先看快速上手;如果正在挑訂閱、整理自建設定或排解疑難,留在本頁。

依需求找章節

• 想知道五種協定的設計差別 → 協定家族
• 想比較握手開銷與資源占用 → 速度與開銷比較
• 想知道 v2rayNG 與 v2flyNG 的核心差別 → 核心家族
• 訂閱匯入失敗或欄位對不上 → 訂閱格式與相容性
• 想了解傳輸方式與路由模式的影響 → 傳輸與路由
• 在意 Android 裝置的耗電 → 行動裝置電量表現
• 想直接看推薦組合 → 依情境選型
• 需要欄位速查或除錯清單 → 參數速查與除錯

術語約定

本頁所說的節點,指一條完整的出站設定,包含伺服器位址、連接埠、身分欄位與傳輸參數;訂閱指包含多條節點資訊的連結或檔案;核心指 v2ray-core 家族的處理程式;入站與出站分別對應本機流量的入口與出口。流量控制指協定層對資料轉送方式的控制參數。REALITY 在本頁以協定層方案討論,涉及的是選型與相容性判斷,不展開伺服器端部署細節。

協定之間的差別,大多不是「誰比較快」這種能一句話回答的問題,而是每個方案在設計時優先解決了什麼、又主動放棄了什麼。把五種協定放回各自的出發點來看,選型時的疑問會少很多。

VMess:協定內建認證與加密

VMess 是 V2Ray 專案早期自有的協定,目標是在品質不穩定的鏈路上完成身分確認與資料封裝。它內建 UUID 身分欄位與時間戳記驗證,早期透過 alterId 機制產生一批子身分,後來改為 AEAD 認證加密,alterId 設為 0 成為主流做法。設計上的特點是認證與加密都在協定內部完成,因此不依賴外層 TLS 也能運作。代價是每個封包都多一層封裝,握手時客戶端與伺服器端要完成一次請求與回應,行動裝置會因此多出幾次處理器喚醒。

VLESS:把加密交給外層

VLESS 可以理解為 VMess 的減法版本。它去掉了協定內建的加密層,只保留一個輕量的身分標識與可選的流量控制參數,加密完全交給外層通道,通常是 TLS。取捨很明確:放棄「裸跑也加密」的能力,換取更短的握手路徑與更少的封裝位元組。因此 VLESS 必須搭配 TLS 或同等可靠的加密通道使用,單獨裸跑不提供機密性。在 Xray 核心裡,VLESS 可以搭配 flow 參數啟用 XTLS Vision 流量控制,進一步減少加解密層數。

Trojan:讓流量維持標準 HTTPS 的樣子

Trojan 不發明新的流量形態,而是讓代理流量維持一次標準 HTTPS 存取的樣子。伺服器端監聽 443 連接埠並持有真實憑證,密碼正確時轉送流量,密碼錯誤時把請求回落到一個真實網站。從外部觀察,它就是一台普通的 Web 伺服器。取捨在於:必須擁有網域與有效憑證,憑證或連接埠設定出錯時會完全無法使用;好處是設定概念少、理解成本低,流量形態與一般 HTTPS 高度接近。

Shadowsocks:輕量對稱加密

Shadowsocks 走的是輕量對稱加密路線。客戶端與伺服器端共用一組密碼,由密碼衍生出加密金鑰,沒有額外的身分握手欄位。常見加密方式為 chacha20-ietf-poly1305 與 aes-256-gcm 這類 AEAD 演算法。它的封裝開銷在幾種方案裡最小,實作也最簡單,因此在運算能力有限的裝置上仍然常見。代價是協定本身不提供偽裝層,流量特徵相對固定,需要靠外層封裝或外掛來補足。

REALITY:借用真實網站的握手流程

REALITY 由 Xray 這一側提出,針對的是憑證維護成本這個具體問題。一般 TLS 方案需要自己擁有網域與憑證,REALITY 改為在握手階段借用某個真實網站的憑證鏈:客戶端事先知道目標網站的公鑰,握手時驗證的是目標網站,伺服器端不需要持有自己的憑證。對使用者來說,一個 REALITY 節點通常只需要填幾個參數:公鑰、shortId、目標網域。它目前主要與 VLESS 搭配,並配合 XTLS Vision 流量控制使用。

五種方案的取捨對照

從表裡能看出一條清晰的演化線索:早期方案傾向把能力做進協定內部,後來的方案傾向把能力交給外層、讓協定本身盡量薄。這條線索也解釋了為什麼新協定往往要求搭配 TLS——它們把安全邊界往外移了。

「哪個協定快」要先拆開來看。一次連線的時間由三部分構成:實體鏈路來回、握手來回次數、加解密與封裝的處理時間。前兩項由伺服器位置和鏈路品質決定,與協定無關;協定能影響的只有第三項,以及握手需要幾個來回。所以同一台伺服器換協定測速,差異通常很小;換一台伺服器,差異可能大得多。

握手路徑:需要幾個來回

VMess 的握手是請求與回應兩段式,客戶端送出身份資訊後要等伺服器端確認;VLESS 只帶一個輕量身分標識,不額外等待一輪確認;Trojan 走標準 TLS 握手,密碼驗證發生在握手之後的應用層資料裡;Shadowsocks 沒有身分來回,金鑰由共用密碼直接衍生;REALITY 的握手過程與存取一個真實網站一致,客戶端驗證的是目標網站的憑證鏈。來回次數越少,在高延遲鏈路上的首包時間越短。

封裝層數:加解密做幾遍

封裝層數決定處理器開銷。VMess 內建加密,如果外面再套一層 TLS,資料就要加解密兩遍;VLESS 與 Trojan 本身不做加密,只做一層 TLS;REALITY 配合 XTLS Vision 時,代理資料可以直通,減少重複的加解密。在桌面處理器上這幾層差異很難察覺,在低功耗 Android 裝置上則會反映在耗電與發熱上,這一點在行動裝置電量表現一章展開。

三種開銷對照

什麼時候差異能被察覺

三種情況下協定差異會變得明顯:鏈路本身延遲很高時,握手來回次數的影響被放大;裝置運算能力有限時,加解密層數直接反映為耗電與掉速;同時連線數多時,每條連線的開銷會累積。反過來說,在延遲較低的固網加上中階以上裝置上,VMess 與 VLESS 的體感差別通常小到無法穩定重現。

怎麼自測才有意義

在 v2rayNG 的節點清單裡,可以透過選單發起延遲測試,常見的有 TCP 測試與真連線測試兩類。TCP 測試只驗證位址與連接埠能否連通,速度快但資訊少;真連線測試會實際建立一次代理連線,結果更接近真實使用。比較協定時依下面的順序進行:

1. 固定一台伺服器,把同一份設定依不同協定各寫一條出站。
2. 用真連線測試各測三輪,記錄波動範圍而不是單次數值。
3. 在同一時段內完成全部測試,避免跨時段比較。
4. 再補一次實際存取測試,確認測試結果與體感一致。

如果三輪結果互相重疊,說明在目前鏈路上這幾個協定沒有可分辨的差異,選型應該轉向其他因素:是否需要偽裝、憑證維護成本、裝置耗電。依同樣思路篩選節點的完整流程,見首次連線檢查。

訂閱是節點資訊從服務方到客戶端的主要通道。理解它的格式,能在匯入失敗時快速定位問題,也能避免在不同客戶端之間搬移設定時遺失欄位。

訂閱連結與分享連結的差別

分享連結描述單一節點,形如 vless://、vmess://,複製一條就能匯入一個節點。訂閱連結描述一組節點,本身是一個 HTTP 或 HTTPS 位址,客戶端存取後取得一段文字,文字裡的每一行是一條分享連結。訂閱的價值在於更新:節點有增減時服務方改一處,客戶端下次重新整理就同步,不需要逐條重新複製。

文字是怎麼編碼的

訂閱回傳的內容有兩種常見形態:明文的多行分享連結,以及把整段文字做一次 Base64 編碼後的單一字串。客戶端匯入時會先嘗試依明文解析,失敗則依 Base64 解碼再解析。所以手動檢查訂閱內容時,如果看到的是一長串沒有換行的字元,先做一次 Base64 解碼再讀。解碼後的每一行應該以協定名稱開頭。

四種分享連結的欄位形態

可以看出,VMess 與 Shadowsocks 把欄位打包進 Base64 區段,VLESS 與 Trojan 則把欄位攤在 URL 查詢參數裡。REALITY 節點通常以 vless:// 形式出現,額外帶上公鑰與 shortId 兩個參數,少任何一個都無法完成握手。

匯入失敗的常見原因

• Base64 區段在複製過程中被截斷,末尾少了幾個字元,解碼結果不完整。
• 分享連結裡的伺服器位址是網域,而目前環境解析不到該網域,表現為匯入成功但連線失敗。
• REALITY 節點的公鑰或 shortId 缺失,匯入後節點存在但握手無法完成。
• 訂閱裡的節點使用了目前客戶端核心不支援的功能,匯入時被略過。
• 訂閱位址需要額外的請求標頭或驗證參數,直接貼到瀏覽器能開啟、在客戶端裡卻拉取失敗。

匯入之後客戶端內部長什麼樣

匯入完成後,節點會被轉譯成核心能讀的 JSON。下面是 VLESS 出站的最小骨架,欄位名稱與真實設定一致,位址與身分已做替換:

{
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "node.example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-0000-0000-000000000000",
                "flow": "xtls-rprx-vision"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "serverName": "www.example.com",
          "publicKey": "example-public-key",
          "shortId": "0123456789abcdef"
        }
      }
    }
  ]
}

對照這份骨架就能理解匯入過程:分享連結裡的每個查詢參數,最終都會落到 settings 或 streamSettings 的某個鍵上。欄位對不上時,問題通常出在連結本身,而不是客戶端。

多個客戶端並存時的同步

同一個訂閱在 v2rayN 與 v2rayNG 上匯入,節點清單理論上應該一致。如果桌面端有某個節點、Android 端沒有,先檢查該節點的協定與傳輸:REALITY 與帶 flow 的 VLESS 節點在只支援基礎協定的核心上會被略過。更新訂閱時,客戶端通常依訂閱分組整批替換,本機對單一節點的改名或排序可能不會保留,重要節點建議另外記下關鍵欄位。多裝置之間搬移設定的幾種做法,可以參考多裝置同步 V2Ray 設定。

同一套協定參數,換一種傳輸方式,表現可能完全不同。傳輸決定資料怎麼被承載,路由決定哪些流量進入代理,兩者共同影響連線成功率與使用體驗。

常見傳輸方式

選傳輸的實用判斷是:能用 TCP 就用 TCP,需要配合前置服務或特定連接埠時再考慮 WebSocket 與 gRPC。WebSocket 的可設定項目最多,路徑與 Host 標頭寫錯是最常見的連線失敗原因之一;gRPC 在鏈路品質波動時靠多工有優勢,但設定裡多一個服務名稱參數,填錯同樣連不上。

TLS 與 SNI 在選型中的位置

TLS 決定流量是否加密,SNI 決定握手時向對端聲明存取哪個網域。對 VLESS 與 Trojan 來說,TLS 不是可選項而是前提;對 VMess 來說,TLS 是可加的一層。REALITY 把 SNI 指向一個真實網站,握手時驗證的是該網站的憑證鏈,因此設定裡的 serverName 必須與目標網站一致,寫錯會導致握手失敗。選擇傳輸時先確認訂閱裡帶的 SNI 欄位,再決定是否需要額外設定。

路由模式三選一

v2rayNG 與 v2rayN 的路由模式通常提供三種:

• 僅代理:依內建規則分流,比對到的流量走代理,其餘直連。日常使用最常用。
• 繞過區域網路:區域網路位址直連,其餘流量走代理。適合需要存取路由器管理頁面、區域網路儲存這類本機裝置的情境。
• 全域:所有流量都進代理。排解問題時用得多,日常使用會增加不必要的流量消耗。

三種模式對應的是核心設定裡 routing 區段的不同規則集。切換模式不會改變節點本身,只改變哪些流量被送進出站。

分應用程式代理與開機自動啟動

Android 端的分應用程式代理依應用程式套件名稱決定是否走代理,適合只讓少數應用程式走代理的使用方式。開啟後需要逐一勾選應用程式,未勾選的應用程式以直連處理。桌面端沒有這項設定,取而代之的是依處理程序或依位址區段的規則。開機自動啟動適合長期在線的裝置;行動裝置上開啟會持續占用一個背景連線,是否啟用取決於使用頻率。

domainStrategy 與 DNS 的關係

路由規則裡的 domainStrategy 決定網域在什麼時候被解析成 IP。常見取值有三種:

這一項與 DNS 設定互相牽動:如果 DNS 查詢沒有走代理,解析結果可能暴露真實出口。相關現象與檢查方法整理在V2Ray DNS 洩漏檢測與防洩漏設定一文裡。需要讓全部流量都經過虛擬網卡接管時,做法見TUN 模式原理與開啟。

把前面幾章的結論收攏成一套判斷順序:先確認核心支援,再看鏈路與維護成本,最後依裝置類型微調。下面依常見情境給出建議組合。

三步判斷順序

1. 看核心:節點裡是否出現 REALITY 或 flow 參數。出現就用 Xray 核心的客戶端,不出現則兩個核心都能涵蓋。
2. 看鏈路與維護成本:是否願意維護網域與憑證。願意維護的話,Trojan 與 VLESS 加 TLS 都是成熟選擇;不願意維護的話,VLESS 加 REALITY 可省去憑證這一環。
3. 看裝置:低功耗裝置優先選封裝層數少的方案;桌面端依便利性選擇即可。

情境對照

幾種不建議的組合

• VLESS 不搭配 TLS 直接使用:協定本身不提供機密性,資料在鏈路上沒有加密保護。
• 在 V2Fly 核心上使用 REALITY 節點:核心不支援該方案,設定無法生效。
• 把 Shadowsocks 當成唯一方案涵蓋所有情境:缺少協定層偽裝,可設定項目少,遇到需要自訂路徑的鏈路時沒有退路。
• 在行動裝置上長期開啟全域模式:所有流量都進代理,連線數與喚醒次數都會上升。

一套可執行的落地流程

1. 在客戶端裡匯入訂閱,確認節點數量與預期一致。
2. 依協定分組,優先測試封裝層數少的節點。
3. 用真連線測試篩掉不通的節點,步驟參考首次連線檢查。
4. 選定兩到三個節點作為常用項目,其餘保留備用。
5. 依裝置類型調整路由模式與分應用程式代理。

協定之間的橫向比較還可以參考VMess、VLESS、Trojan、SS 橫向比較,那篇依握手開銷、延遲與情境選型三個角度展開,與本頁的對照表互相補充。客戶端的選取與系統需求集中在下載中心,三款客戶端的差異集中在選型指南。

這一章是前面內容的索引化收尾:常用欄位的含義、典型現象對應的檢查項目,以及站內相關頁面的入口。

常用欄位速查

現象與檢查項目

相關頁面

• 快速上手:匯入訂閱、選擇模式、連線、驗證的完整主線。
• 下載中心:三款客戶端的平台入口與系統需求。
• 選型指南:v2rayN、v2rayNG、v2flyNG 三款客戶端的橫向比較。
• 常見問題:依基礎認知、安裝設定、使用技巧、疑難排解分類整理。
• 首次連線檢查:節點挑選、真連線測速與代理生效驗證。
• DNS 洩漏檢測:現象、檢測入口與設定項目。
• 多裝置設定同步:三種搬移做法的取捨。
• 四種協定橫向比較:握手開銷、延遲與情境選型。
• TUN 模式:原理與開啟順序。

最後一點說明

本頁的結論都建立在協定與核心的公開設計之上,不涉及具體伺服器端的部署參數。協定選擇沒有唯一正確答案:同一份訂閱在不同鏈路上表現可能不同,同一台伺服器在不同裝置上的耗電表現也不一樣。把本頁當作判斷依據,把實際測試當作最終結論,兩者結合才能選出適合自己的組合。如果本頁沒有涵蓋你的問題,可以在常見問題裡依分類查找,或回到快速上手依主線重走一遍流程。