VLESS 負責代理協定，REALITY 負責連線的安全握手，XTLS Vision 則負責特定流量的轉發最佳化。本文適合已匯入節點，卻不清楚 Flow、公鑰與 SNI 各自用途的使用者。讀完後，你能分辨效能提升與線路瓶頸，並依照伺服器參數核對 v2rayN 設定。
VLESS、REALITY、Vision 分別屬於哪一層
節點名稱中的「VLESS + TCP + REALITY + Vision」並非四種互相取代的協定，而是描述同一條代理連線的不同設定。VLESS 傳遞使用者身分與目標位址；TCP 承載位元組串流；REALITY 提供安全握手與驗證機制；Vision 則是 VLESS 的流控方式之一，符合條件時可最佳化後續資料路徑。
| 名稱 | 主要用途 | 需核對的欄位 |
|---|---|---|
| VLESS | 代理請求、使用者身分與目標資訊 | 位址、連接埠、UUID |
| TCP / RAW | 承載連線的有序位元組串流 | 傳輸類型；介面名稱會因版本而異 |
| REALITY | 安全握手與伺服器驗證 | SNI、公鑰或相關驗證欄位、Short ID |
| XTLS Vision | 辨識流量並選擇轉發路徑 | xtls-rprx-vision |
VLESS 本身不提供傳統意義上的載荷加密，常見設定中的 encryption=none 並不表示整條連線以明文傳輸。使用 REALITY 時，安全防護來自外層機制。不要為了「提高安全性」而任意將 VLESS 的加密欄位改成其他協定的選項。
本文探討 Xray 的 VLESS + REALITY + Vision 組合。v2rayN 是用來管理節點及呼叫核心的用戶端，並非組合本身；要判斷能否連線，應查看實際啟動的核心與產生的設定，不能只看軟體名稱。
HTTPS 流量進入代理後，重複加密發生在哪裡？
瀏覽器造訪 HTTPS 網站時，會與目標網站建立 TLS 工作階段。代理通常只負責傳送這些已加密的資料，不會解密網頁內容。如果代理連線又使用一層 TLS，用戶端可能需要將內層 TLS 資料再次封裝並加密後傳送至代理伺服器，伺服器端再解開外層加密。
這裡有兩段不同的安全連線：內層保護瀏覽器與網站之間的內容，外層則保護用戶端與代理伺服器之間的傳輸。兩層各有用途，但對已加密的大量資料再完整加密一次，會增加 CPU 運算、緩衝區處理與資料複製等成本。在高吞吐量、處理器效能較弱的環境中，這些成本更容易成為瓶頸。
並非所有請求都符合這種情境。一般 HTTP 沒有網站 TLS 層，UDP 流量也不是可直接套用相同處理路徑的 HTTPS 位元組串流。因此，「減少雙重加密」不代表所有應用程式都會固定提升一定比例的速度。
XTLS Vision 如何調整資料轉發路徑
Vision 不會在連線開始時直接關閉防護。它會先處理協定標頭與初始資料，並辨識內層 TLS 的狀態。對符合條件的 TLS 1.3 流量，Vision 會在適當階段切換至最佳化資料路徑，避免繼續對已加密的應用程式資料進行不必要的外層重複加密。
- 先建立連線。用戶端與伺服器完成外層安全握手，並傳送 VLESS 身分與目標位址資訊。
- 接著辨識流量。Vision 會檢查內層 TLS 握手與記錄特徵；初始階段也會使用填充機制，調整早期封包的特徵。
- 符合條件才切換。適合最佳化的 TLS 1.3 流量會進入直接轉發路徑，網站資料仍由內層 TLS 保護。
- 其他流量維持相應處理方式。未符合條件時，不應假設外層加密已經省略；實際路徑由核心判斷。
「直接轉發」也不代表一定會啟用特定作業系統層級的零拷貝。能否進一步減少複製，取決於系統、連線形式與核心實作。設定中寫入 xtls-rprx-vision，只能表示已啟用該流控，不能據此保證每條連線都會走相同的高速路徑。
判斷方式：先確認 CPU 是否為瓶頸
同一條線路上，如果下載速度已達頻寬上限而 CPU 仍有餘裕，啟用 Vision 後速度可能幾乎不變；若用戶端或伺服器的單核心持續忙碌，再比較相同檔案、相同時段的吞吐量與 CPU 使用率。
REALITY 如何免用自備憑證
一般 TLS 伺服器通常需要為自己的網域部署憑證與私鑰。REALITY 採用不同的握手與驗證設計，並結合目標網站的 TLS 握手特徵，讓代理伺服器不必依照一般方式為代理網域申請及更新公開憑證。這不代表可以把任意網站的憑證複製到伺服器上。
用戶端仍須驗證連線是否可信。常見部署會使用伺服器產生的 X25519 金鑰組：私鑰僅保留在伺服器端，公鑰則提供給用戶端；用戶端還需要正確的 SNI、Short ID 等參數。Short ID 會參與連線辨識，但不能取代金鑰驗證，也不應把它當成唯一的登入密碼。
- SNI：必須符合伺服器允許的名稱。連線位址可以是 IP，SNI 通常則是網域名稱；兩者不是同一個欄位。
- 公鑰：取自該節點的伺服器設定。不可使用目標網站憑證的公鑰，也不要任意複製其他節點的公鑰。
- Short ID：必須符合伺服器允許的值。它以十六進位表示，長度也受設定限制；建議保留訂閱提供的原值。
- 指紋：用戶端常見選項為
chrome，用來產生相應的握手特徵，不代表必須使用該瀏覽器。 - 時間：請確保裝置系統時間正確。若伺服器設定了時間差限制，時鐘明顯不準會導致驗證失敗。
伺服器也會設定握手目標，設定名稱可能顯示為 target 或舊版的 dest。目標網站須具備適當的 TLS 能力，且伺服器端能連線到該網站；選擇不當會影響握手。未通過驗證的連線可能會轉向目標網站，但這不代表在任何網路環境下都無法辨識代理。
v2rayN 設定：依欄位核對，不要只看節點名稱猜測
先匯入服務提供者提供的完整訂閱或分享連結，再開啟節點編輯視窗。以下兩張卡片是同一條連線的欄位核對示意，並非可直接使用的節點參數。連接埠 443 僅為常見部署範例，實際值請以伺服器設定為準。
VLESS 與傳輸欄位
- 協定
- VLESS
- 伺服器連接埠
- 443（範例）
- 傳輸方式
- TCP / RAW
- 加密
- none
- Flow
- xtls-rprx-vision
位址與 UUID 請使用節點原值，Flow 必須受到伺服器支援。
REALITY 驗證欄位
- 安全類型
- reality
- SNI
- 伺服器允許的網域名稱
- 公鑰
- 該伺服器提供的公鑰
- Short ID
- 與伺服器相符的十六進位值
- 指紋
- chrome（常見選項）
介面欄位名稱可能因核心與用戶端版本而異，匯入後仍須核對。
在 v2rayN 中開啟「設定」→「參數設定」，核對本機監聽連接埠，再檢查目前節點實際使用的核心。選單項目會隨版本變動，但本機連接埠與遠端連接埠始終是兩回事。瀏覽器連線至本機代理入口，核心才會連線到節點的遠端連接埠。
在 Android 上使用 v2rayNG 時，也要檢查 VLESS、REALITY 與 Flow 欄位，以及核心是否支援。v2flyNG 使用 v2fly 核心，不能直接套用本文介紹的 Xray 專屬組合。節點能顯示在清單中，不代表目前的核心一定支援其中所有功能。
如何驗證「更快」，而不是只看延遲數字
比較協定時，應盡可能使用相同的伺服器、出口與測試目標。若比較不同地區的兩台伺服器，線路差異可能會被誤認為協定帶來的效能提升。一般 TCP 連線測試只能確認特定連接埠能建立連線，無法證明 REALITY 驗證成功，也不能證明 Vision 已進入最佳化路徑。
- 固定測試條件：記錄用戶端與核心版本、節點位址、傳輸方式、Flow 及系統代理狀態，並關閉其他下載工作。
- 確認流量確實經過代理：查看記錄中的目標連線與路由結果，避免測速網域符合直連規則。
- 分別記錄指標：記錄網頁首位元組時間、持續下載速度，以及用戶端與伺服器的 CPU 使用率，不要只用單次延遲評分。
- 重複測試：每組測試執行 3 次，每次持續 60 秒，再以中位數比較。這是測試方法建議，並非本文的實測結果。
- 分析異常：速度下降時，同時檢查封包遺失、伺服器負載與出口限速；CPU 使用率降低但速度不變，也可能表示頻寬已達上限。
選擇方式：保留穩定可用的組合，再驗證最佳化效果
先讓伺服器與用戶端參數完全相符，再測試 Vision 的效果。不要同時修改 Flow、傳輸類型與路由模式；每輪只變更一個項目，才能找出效能變化的原因。
REALITY 與 Vision 連線失敗的常見問題
連接埠測試通過，為什麼網頁還是打不開？
先查看核心記錄是否完成握手，再逐項核對 UUID、SNI、公鑰與 Short ID。連接埠可連線僅代表 TCP 層正常。若握手成功但網頁仍無法開啟，請繼續檢查 DNS 與路由；在 v2rayN 系統匣選單確認系統代理入口，並檢查瀏覽器是否另外設定了代理。
把 Flow 改成 Vision 就能加速嗎？
不能只修改用戶端設定。開啟節點編輯視窗，將 Flow 與伺服器設定逐項比對；若伺服器未使用相應的流控，單方面填入 xtls-rprx-vision 可能會直接導致連線失敗。訂閱節點建議保留服務提供者提供的設定值。
REALITY 的 SNI 可以改成常用網站嗎？
請先確認伺服器允許的名稱，不可任意替換。連線位址、SNI 與伺服器握手目標的用途各不相同。還原訂閱提供的原值後重新連線；若仍失敗，請伺服器維護者檢查目標是否可連線及系統時間是否正確。
更新用戶端後顯示不認得參數，該刪除哪個欄位？
先記下用戶端與實際核心版本，查看記錄指出的欄位，再重新匯入完整訂閱。新舊核心可能採用不同的欄位名稱，請勿直接刪除驗證欄位或關閉驗證。桌面版請先確認該節點使用的是支援此組合的 Xray 核心。
排查順序應保持一致：本機入口、遠端連接埠、驗證參數、核心相容性、DNS 與路由，最後再比較效能。REALITY 的部署方式與 Vision 的轉發最佳化能降低特定環節的成本，但能否正常使用仍取決於整條連線。