本文重點

REALITY 負責代理連線的安全握手與驗證,Vision 則負責辨識流量並最佳化傳輸,兩者不是同一個開關。本文適合已取得 VLESS 節點、準備檢查設定的使用者:先了解重複加密發生在哪裡,再逐項確認 flow、SNI、公鑰和 shortId,最後透過對照測試判斷是否確實提速。

先釐清 VLESS、REALITY 與 Vision 各自的用途

常見的「VLESS + TCP + REALITY + Vision」是一組設定組合,並非四種可以互換的協定名稱。VLESS 負責處理代理請求與使用者識別;TCP 提供傳輸連線;REALITY 提供安全層功能;Vision 則是透過 xtls-rprx-vision 指定的流量控制模式。只填對 UUID,不代表安全層與流量控制也已設定正確。

設定層常見值主要用途
代理協定VLESS傳送目標位址、請求資訊與使用者識別
傳輸TCP / RAW承載位元組串流,新舊版介面的名稱可能不同
安全層REALITY完成握手、驗證伺服器身分並保護連線
流量控制xtls-rprx-vision辨識內層 TLS,並在符合條件時最佳化傳輸

本文討論的是 Xray 的實作方式。v2rayN 是桌面端設定管理客戶端,不等同於某種核心;使用這組設定時,實際執行的必須是支援此功能的 Xray 核心。Android 版 v2rayNG 使用 Xray 核心。v2flyNG 使用 v2fly 核心,不能因為它也能匯入部分 VLESS 連結,就認定支援本文介紹的完整組合。

TLS 巢狀加密:HTTPS 為何還會再加密一次

使用瀏覽器瀏覽 HTTPS 網站時,瀏覽器與網站之間已建立一層 TLS。將這項請求交由代理傳送後,一般的 TLS 代理通道還會再把這些密文封裝一次。因此,客戶端至代理伺服器的這段連線,可能承載「外層 TLS 包覆內層 TLS」的資料。

瀏覽器請求 網站 TLS 代理封裝 外層 TLS 伺服器轉送

內層 TLS 會一路保留到代理伺服器之後,直到抵達目標網站才終止。代理伺服器通常沒有網站工作階段金鑰,也不需要解密網頁內容。外層 TLS 則保護客戶端至代理伺服器之間的連線,避免未加密的代理請求及其他流量直接曝光。兩層保護的端點不同,不能簡單地說其中一層「毫無作用」。

這也說明了為什麼「握手延遲低」不一定代表「下載速度快」。握手影響連線建立時間,持續下載則還取決於頻寬、封包遺失、壅塞控制與 CPU。重複加密只是其中一項因素。

Vision 如何減少重複加密,同時保留哪些保護

Vision 並非將所有資料改成明文傳送。它會辨識內層 TLS 的握手與資料階段,並對連線初期的流量進行填充處理。辨識到符合條件的內層 TLS 1.3 流量後,便可切換至更直接的轉送路徑,避免持續對這些已受 TLS 保護的資料重複套用外層加密。

TLS 1.3
符合條件的內層 TLS 是最佳化的前提
443
常見伺服器連接埠範例,並非固定要求
10808
本機代理連接埠範例,請以客戶端實際設定為準

切換後,網頁內容仍由瀏覽器與網站之間的 TLS 加密保護。不符合辨識條件的流量,不能視為「已進入直接轉送」;仍須透過相應的安全傳輸路徑傳送。尤其是一般 HTTP、非 TLS 應用程式與 UDP 請求,不能只因節點設定了 Vision,就認定它們也享有相同的最佳化。

這裡所說的「流量控制」並非頻寬限速。xtls-rprx-vision 不會讓 100 Mbps 方案變成更高頻寬,也無法解決跨網壅塞。它的作用是減少特定流量的額外處理,並改善部分 TLS 巢狀加密特徵;實際效果仍須視連線狀況而定。

結論:先找出瓶頸,再比較流量控制效果

下載時若某個 CPU 核心持續接近滿載,可優先比較 Vision 帶來的處理負擔;若 CPU 還有餘裕,但封包遺失明顯增加,就應先檢查線路與伺服器負載,而不是反覆修改 flow。

REALITY 握手:公鑰、SNI 與目標網站如何搭配

REALITY 著重於安全握手與驗證。它運用 TLS 握手結構,搭配伺服器金鑰與客戶端設定中的驗證資訊,讓合法客戶端驗證伺服器並建立受保護的連線。它不要求像傳統網站 TLS 那樣,為代理入口自行申請並部署一張公開信任的憑證。

這不代表「隨便填個網域就能使用」。伺服器設定了目標網站與允許的伺服器名稱,客戶端的 SNI 必須符合伺服器設定;公鑰也必須與伺服器私鑰配對。SNI 是握手中的名稱資訊,不能取代節點伺服器位址,也無法把任意網站變成代理伺服器。

  1. 連線位址:客戶端會先連線至節點提供的 IP 或網域與連接埠,例如服務商實際分配的 443,而非直接連線至 SNI 對應的網站。
  2. 握手參數:客戶端會帶上指定的伺服器名稱、指紋與 REALITY 驗證所需資訊。各欄位都應取自同一份節點設定。
  3. 驗證流程:伺服器辨識合法請求後建立代理連線;不符合驗證條件的連線,則可依 REALITY 機制轉向設定的目標網站。
  4. 代理請求:安全層建立後,才會驗證 VLESS 使用者並處理目標連線;若設定了 Vision,後續還會辨識流量。

客戶端設定重點:分別核對兩組欄位

建議先匯入提供者給的完整連結或訂閱,再核對各項欄位。手動輸入時,v2rayN 可從「伺服器」→「新增 VLESS 伺服器」進入設定;若已有節點,則可開啟編輯視窗。v2rayNG 可點選右上角「+」,手動輸入 VLESS 設定。不同版本的文字與入口可能有所調整,請依欄位用途確認,不要只認視窗位置。

代理與流量控制欄位

協定
VLESS
位址與連接埠
節點提供者給定的伺服器位址與連接埠
使用者 ID
指派給該節點的 UUID
傳輸
TCP / RAW,依核心與介面中的名稱對應
Flow
xtls-rprx-vision

flow 必須與伺服器端的使用者設定相符,不能只在客戶端單方面啟用。

REALITY 安全欄位

安全類型
REALITY
伺服器名稱
提供者指定的 SNI
公鑰
與伺服器私鑰配對的客戶端參數
Short ID
伺服器允許的 shortId
指紋
例如 chrome,請依提供者要求設定

部分新版調整了公鑰驗證欄位在介面中的名稱,請一併核對連結解析結果與核心文件。

shortId 是十六進位字串,通常最多 16 個十六進位字元,長度必須是偶數;是否允許空值則取決於伺服器設定。請勿自行補零,也不要在此填入 UUID。客戶端只需要伺服器對應的公鑰驗證參數,不應將伺服器私鑰交給客戶端。

速度對照測試:別用延遲數值取代傳輸量

要驗證「減少重複加密是否能提速」,測試條件必須可以比較。最好由同一台伺服器提供兩份設定,只變更要觀察的因素。若同時更換伺服器地區、傳輸方式與路由,測出的差異就無法歸因於 Vision。若沒有伺服器的控制權,測試結果只能代表兩個節點的整體使用體驗。

  1. 固定路徑:使用同一台裝置、同一個網路與同一個下載目標;確認該請求符合代理規則,避免一次直連、一次走代理。
  2. 固定入口:兩組測試都使用相同的本機代理連接埠,並先停止其他下載工作,避免背景流量搶占頻寬。
  3. 重複測量:每組連續測試 3 次,每次 60 秒,並交替測試順序。分別記錄平均傳輸量、CPU 使用率與失敗次數。
  4. 統一單位:100 Mbps 理論上等於 12.5 MB/s,實際速度還會受協定額外負擔影響。不要直接比較這兩種單位的數值。
  5. 保留記錄:記下測試時間、核心版本、節點設定類型與錯誤資訊;分享前請移除 UUID、訂閱網址及其他存取憑證。

上述次數與測試時間是建議的測試方式,並非本站實測結果。若傳輸量相近但 CPU 使用率降低,仍代表資源負擔可能有所改善;若只有首次連線時間縮短,則不能據此宣稱持續下載更快。更多握手與欄位資訊,請參閱協定參考中的 REALITY 說明。

REALITY 與 Vision 常見問題

節點測得 TCP 延遲正常,為什麼網頁還是打不開?

TCP 探測通常只能證明連接埠可連線,無法證明 REALITY 驗證或 VLESS 請求成功。請先開啟客戶端核心記錄,再依序核對 SNI、公鑰驗證參數、shortId、UUID 與 flow;接著確認系統時間正確。每次只修改一個項目,並保留原設定以便還原。

只把 flow 改成 Vision,就能讓舊節點提速嗎?

不行。客戶端與伺服器端必須支援並設定相同的流量控制模式,傳輸組合也必須符合要求。請先向提供者確認是否支援 xtls-rprx-vision,再匯入對應的完整設定;舊節點若使用 WebSocket,不應直接照搬本文的 TCP 組合。

憑證出錯時,可以開啟「允許不安全」來解決嗎?

不要把略過憑證驗證當成修復 REALITY 的方法。請先確認安全類型確實選了 REALITY,再核對客戶端驗證參數與伺服器設定。若介面仍顯示傳統憑證錯誤,也要檢查是否匯入成一般 TLS 節點,或實際啟動了另一份設定。

換成 REALITY 後速度沒有變快,代表設定無效嗎?

不一定。先查看記錄,確認連線確實經過目標節點,再依前述方法測試 3 次、每次 60 秒,比較傳輸量與 CPU 使用率。若瓶頸原本在電信業者線路或伺服器出口,減少加密處理不會自動提高頻寬上限。連線問題可進一步參閱常見問題中的連線疑難排解。