REALITY 負責連線的安全握手與驗證，XTLS Vision 則負責最佳化符合條件的資料轉送，兩者不是同一個開關。本文適合已取得 VLESS 訂閱、想了解設定欄位的使用者：先釐清各協定的分工，再核對 flow、伺服器名稱、公鑰與 shortId，最後透過記錄檔和受控測試判斷問題；不要把測速結果變化直接歸因於「少加密一層」。
REALITY、VLESS 與 Vision 各自解決什麼問題？
三者分屬不同層次，可以搭配使用，但不能互相取代。VLESS 提供代理請求與使用者識別資訊，本身不負責通用的載荷加密；REALITY 提供安全握手與驗證機制；Vision 則是 XTLS 的流量控制方案，著重於 TLS 流量的識別、填充與後續轉送路徑。
常見的 VLESS + REALITY + Vision 節點通常採用 TCP 傳輸。用戶端會將瀏覽器發出的連線交給本機代理入口，再由核心連線至代理伺服器，最後由伺服器連到目標網站。這裡至少包含「用戶端至代理伺服器」和「瀏覽器至網站」兩種不同的安全情境，不應混為同一次握手。
實際提供這些功能的是核心，而不是用戶端的名稱。v2rayN 是桌面管理介面，使用這類節點時，請確認選用支援相關功能的 Xray 核心；Android 上的 v2rayNG 使用 Xray 核心。v2flyNG 使用 v2fly 核心，不能只因為它能匯入 VLESS，就認定它也能執行 Xray 的 REALITY 與 Vision 組合。
- 協定層：訂閱中的 VLESS 與使用者 ID，決定代理請求的組成方式與身分識別。
- 安全層：REALITY 會搭配伺服器提供的公鑰、伺服器名稱等參數建立連線。
- 流量控制層：用戶端與伺服器都必須支援
xtls-rprx-vision。 - 傳輸層：常見設定採用 TCP；部分介面或設定文件也會標示為 RAW，請依目前使用的核心欄位判讀。
為什麼「TLS 裡再包一層 TLS」會增加額外負擔？
再次保護已加密的 HTTPS 資料，會增加代理這一層的處理負擔。瀏覽器連線至 HTTPS 網站時，應用程式資料已經由網站的 TLS 工作階段加密；傳統 TLS 代理通道又會把這段密文包進另一層 TLS。外層雖然不需要理解網頁內容，仍須處理記錄封裝、加解密、緩衝與資料傳遞。
Vision 的關鍵不是關閉網站加密，而是在辨識出符合條件的內層 TLS 流量後，切換後續資料的轉送方式，避免繼續將這些已加密資料完整包進外層 TLS 記錄。Vision 也包含前期填充等處理，因此不能簡化成「從連線一開始就直接裸轉送所有內容」。
| 比較項目 | 一般 TLS 通道 | Vision 的條件式最佳化 |
|---|---|---|
| 網站 HTTPS | 瀏覽器與網站之間維持 TLS | 瀏覽器與網站之間仍維持 TLS |
| 代理外層處理 | 持續封裝內層資料 | 符合辨識條件後切換轉送路徑 |
| 資料搬移 | 通常會經過 TLS 處理與緩衝 | 部分平台可進一步利用 splice 等機制減少複製 |
| 非 TLS 載荷 | 由通道提供保護 | 啟用 Vision 不代表一律移除外層保護 |
減少複製和減少加密並不是同一件事。核心實作、作業系統與連線類型都會影響能否採用更直接的資料路徑；「使用 Vision」不代表每條連線都能零複製。尤其應聚焦於符合條件的 TLS 1.3 等內層連線，不能據此推論所有 UDP、影片或下載工作都會等幅提速。
判斷方式：先確認瓶頸，再比較傳輸量
如果下載時伺服器 CPU 使用率已接近滿載，減少重複加密可能確實有幫助；如果 CPU 尚有餘裕，但網路壅塞或封包遺失明顯，應先檢查網路路徑。只比較單次測速的峰值，無法證明 Vision 帶來效能提升。
REALITY 為什麼不需要自有網域憑證？
REALITY 採用不同於一般網站憑證部署的驗證方式，因此伺服器通常不必為這條代理連線申請或續期自己的網域憑證。伺服器持有私鑰，用戶端則使用相符的公鑰等參數驗證連線；這不代表「沒有驗證」，也不表示隨便填入網站名稱就能成功連線。
伺服器也會設定目標網站與允許的伺服器名稱。未通過驗證的連線，REALITY 可依其機制導向設定的目標網站；合法用戶端則會完成相應驗證。目標網站應符合部署需求，常見基本條件包括支援 TLS 1.3 與 HTTP/2，但「瀏覽器能開啟」本身並不足以證明相容。
公鑰通常以編碼後的文字呈現，因此不能要求輸入欄位只保留「32 個字元」。公鑰與私鑰是成對產生的，伺服器私鑰不應複製到用戶端；用戶端也不應自行產生新公鑰取代訂閱提供的值，否則雙方的金鑰便不再相符。
v2rayN 的 flow、公鑰和 shortId 要怎麼填？
建議先完整匯入訂閱，再逐項比對服務提供者給的參數，通常比手動拼湊可靠。在 v2rayN 主視窗選取節點後，按兩下開啟編輯視窗，檢查 VLESS 節點的傳輸、安全性與流量控制欄位；不同版本的介面可能使用不同中文標籤，請以欄位實際用途為準，不要為了尋找同名選單而更動無關設定。
以下兩張卡片描述同一個節點的兩組設定，並非可直接連線的範例帳號。443 連接埠只是常見範例；實際連接埠、使用者 ID、公鑰、shortId 與伺服器名稱，都必須來自同一份伺服器設定。
協定與傳輸
- 協定
- VLESS
- 加密
- none
- 傳輸
- TCP / RAW，依介面標示為準
- Flow
xtls-rprx-vision
flow 須與伺服器端一致；VLESS 的 none 不代表整條連線沒有安全保護。
REALITY 安全參數
- 安全性
- reality
- 伺服器名稱
- 伺服器端允許的 SNI
- 公鑰
- 對應伺服器端私鑰的用戶端公鑰
- Short ID
- 伺服器端允許的 shortId
- 指紋
- 依訂閱指定，例如 chrome
這些值必須成套使用，不能從不同節點各複製一項來組成新設定。
- flow：常見值為
xtls-rprx-vision，拼字與連字號都必須正確。不要直接套用舊教學中的其他 flow 值，也不要在未使用 Vision 的節點上強行加入。 - 公鑰：分享連結常見的參數名稱是
pbk。不同世代的核心或介面可能以publicKey、password等欄位承載相應值，請查閱目前版本的說明；不要在原始設定中不加判斷地同時填入多個欄位。 - shortId：通常是偶數長度的十六進位文字，最多 16 個十六進位字元。只有伺服器端允許時才能留空；它不是可以隨意填寫的「節點備註」。
- 指紋：
chrome是一種握手指紋選項，不代表必須使用對應的瀏覽器上網，也不會替使用者安裝瀏覽器。
儲存後，請重新選取該節點，讓核心重新載入設定。如果只修改節點清單中的資料，卻沒有更新目前正在執行的出站連線，記錄檔的內容可能會與編輯視窗互相矛盾。Android 版 v2rayNG 可在節點編輯頁面核對相應欄位，再從主畫面的記錄檔入口確認啟動結果。
連線失敗和速度沒變，該如何分別排查？
先判斷連線卡在哪個階段，再考慮效能最佳化。握手尚未完成時，討論 Vision 預期能提升多少傳輸量沒有意義；網站已能正常開啟時，也不應因為測速沒有增加就判定公鑰錯誤。建議每次只修改一項，並保留修改前的節點設定，避免覆蓋後無法還原。
- 檢查核心是否能啟動：先查看記錄檔有沒有未知欄位、無效 flow 或設定解析失敗等錯誤。此階段應優先核對核心類型與設定格式，而不是更換 DNS。
- 檢查位址與連接埠：確認實際連線的位址、連接埠與訂閱內容一致。連接埠能建立 TCP 連線，只表示網路入口可連通，不代表 REALITY 驗證成功。
- 檢查驗證參數：核對使用者 ID、公鑰、shortId、SNI，並確認系統日期與時間正確。握手錯誤可能有多種原因，不能只憑「連線已關閉」一句訊息就斷定是公鑰錯誤。
- 確認應用程式是否走代理：瀏覽器、終端機與其他應用程式不一定使用相同入口。先查看記錄檔是否出現相應的目標請求，再檢查系統代理或應用程式本身的代理設定。
- 最後檢查路由與名稱解析：若代理連線成功，但特定網域無法使用，請接著檢查 DNS、分流規則與目標網站的連線狀態；問題不一定出在 REALITY 或 Vision。
比較效能時，請固定伺服器、目標檔案、網路連線與並行數，並分別記錄用戶端和伺服器的 CPU 使用率、持續傳輸量及失敗情況。例如每組執行 3 次、每次 60 秒，觀察中段的穩定區間，而不是一開始的瞬間峰值。這只是測試安排，不是本文提供的實測結果。
操作建議：使用成套設定進行比較，不要只清除 flow
若要比較有無 Vision，應請伺服器端提供兩套都能正常運作的對照設定。只在用戶端刪除 flow，可能破壞雙方的設定約定；因此得到的連線失敗或速度變化，都不具比較價值。
幾個容易混淆的設定問題
多數誤解都源自把「功能支援」、「驗證通過」與「應用程式使用代理」混為一談。依照以下問題逐項核對，通常就能縮小排查範圍；如需進一步檢查分流設定，可接著閱讀站內的進階設定說明。
啟用 REALITY 後，還需要開啟「允許不安全」嗎？
不要用「允許不安全」來繞過 REALITY 參數錯誤。請維持正常的驗證設定，回到節點編輯視窗核對公鑰、SNI 與 shortId；相關開關無法修正雙方金鑰不相符的問題。
訂閱可以匯入，為什麼還是提示不支援 flow？
能解析分享連結，不代表目前執行的核心支援所有欄位。請先從啟動記錄確認實際使用的核心，再核對該核心是否支援 REALITY 與 Vision；不要只因用戶端顯示 VLESS 圖示就判定相容。
使用 Vision 後，一般 HTTP 會以明文通過整條代理鏈嗎？
Vision 不會將所有載荷都切換成直通。非 TLS 內容仍需要相應的外層保護，但一般 HTTP 在代理伺服器至目標網站這一段仍可能是明文；涉及帳號或敏感資訊時，請使用目標網站的 HTTPS。
同一個節點，終端機無法連線但瀏覽器正常，該怎麼辦？
先確認終端機是否設定代理入口，並使用用戶端實際監聽的連接埠進行測試。瀏覽器能正常使用，只能證明它的請求路徑可用，不代表終端機也讀取了系統代理設定；此時不要先改公鑰或更換 flow。
可以直接把現有的 WebSocket 節點改成 Vision 嗎？
不能只修改用戶端欄位。傳輸方式、伺服器端入站設定與 flow 都必須配套支援；請取得服務提供者給的完整節點設定，不要保留原有 WebSocket 路徑後自行加入 Vision。
選擇節點時，請先查看服務提供者提供的完整參數與核心需求，再確認是否適合目前的網路環境。REALITY 可減少部署自有憑證的負擔，Vision 則為符合條件的 TLS 流量提供更有效率的轉送路徑；兩者都無法取代可靠的伺服器、正常的網路連線與正確的用戶端設定。