REALITY 負責外層連線的驗證與握手偽裝，XTLS Vision 則負責轉送符合條件的資料流，兩者並非同一個協定開關。本文適合已取得 VLESS 設定，並想了解 SNI、公鑰、shortId 與 flow 的讀者，依序說明握手、加密層次及用戶端排查方式。讀完即可分辨各設定欄位的用途，也能判斷「握手失敗」和「連線後無法瀏覽網頁」該從哪裡查起。
一、VLESS、REALITY 與 Vision 各自負責什麼
常見的「VLESS + REALITY + Vision」是分層搭配的組合。VLESS 傳遞使用者識別碼、目標位址等代理請求資訊，本身不會加密應用程式資料；REALITY 提供這套組合所需的安全傳輸與驗證機制；Vision 則以更合適的方式轉送符合條件的流量。若把三者都稱為「加密協定」，設定項目就容易對不上。
連線與驗證層
- 代理協定
- VLESS
- 使用者識別碼
- UUID
- 安全傳輸
- REALITY
- 伺服器驗證
- 公鑰與握手驗證
UUID 與 REALITY 公鑰用途不同，不能互相取代。
本文討論的傳輸組合
- 底層傳輸方式
- TCP / RAW，名稱依版本而異
- 流控值
xtls-rprx-vision- 握手指紋範例
chrome- 常見遠端連接埠
- 443，請以實際設定為準
這組搭配不需要額外加入 WebSocket 路徑或其他傳輸封裝。
v2rayN 是桌面圖形介面用戶端，實際能否使用特定功能取決於所選核心；v2rayNG 使用 Xray 核心。v2flyNG 使用 v2fly 核心，不能只因名稱相似，就認定它也能處理相同的 REALITY 與 Vision 設定。成功匯入只代表用戶端接受了輸入內容，不表示目前執行的核心已具備相應功能。
二、REALITY 的「握手偽裝」不代表取得目標網站的私鑰
一般 TLS 連線中，瀏覽器會透過憑證鏈與網域驗證確認網站身分。REALITY 的設計則須同時處理兩類連線：持有正確驗證資料的用戶端，以及未帶有效驗證資料的一般存取或探測。它會利用目標網站的握手特徵與回落轉送機制，讓未通過驗證的連線看起來像是在瀏覽目標網站，而不是直接收到明顯的代理服務錯誤。
上述流程描述的是驗證成功的代理連線。用戶端會依據預先設定的伺服器公鑰及握手內容，驗證 REALITY 的臨時憑證機制，而不是把任意憑證都視為可信。伺服器並未取得目標網站的私鑰，也沒有替目標網站簽發公開可信的替代憑證。「模擬憑證特徵」適合作為直觀說明，但不代表複製憑證就能冒充任意網站。
未通過 REALITY 驗證的連線，伺服器可轉送至設定的目標網站，讓存取者看到目標網站實際的 TLS 行為。因此，目標網站不是可隨意填寫的裝飾欄位：伺服器能否連上目標網站、是否支援 TLS 1.3，以及連線行為，都會影響設定品質。不同版本的 Xray 設定中，伺服器目標欄位可能顯示為 target 或舊名稱 dest，請依執行版本確認。
三、Vision 減少的是哪一層重複加密
瀏覽器瀏覽 HTTPS 網站時，瀏覽器與目標網站之間已經有一層 TLS。若再把整條連線包進代理的外層 TLS，同一段應用程式密文可能又會經過外層記錄封裝與加密。代理伺服器也得處理外層解密及轉送，增加運算與資料搬移負擔；實際增加多少則取決於實作方式、硬體及流量類型。
| 階段或流量類型 | Vision 的處理方式 | 不能據此推論的結論 |
|---|---|---|
| 連線初期與代理請求 | 完成外層安全握手、驗證及必要的協定處理。 | 不代表從第一個位元組開始就繞過安全通道。 |
| 符合識別條件的內層 TLS 1.3 流量 | 符合安全切換條件後，可改用直接複製路徑，減少持續套用外層 TLS 的負擔。 | 並非所有 HTTPS 連線都一定會走這條路徑。 |
| 一般明文或不符合切換條件的流量 | 仍會依相應的受保護轉送路徑處理。 | 不能宣稱所有資料都少了一層加密。 |
| 底層系統資料轉送 | 核心、作業系統與連線條件允許時，也可能採用更有效率的資料搬移方式。 | 啟用 Vision 不代表一定能實現零拷貝。 |
此處的「直接複製」不代表網頁明文會暴露在網路上。進入相應路徑的資料仍受瀏覽器與目標網站之間的 TLS 保護。Vision 會依內層協定狀態進行識別與切換，並非單純關閉加密；不符合條件時，也不能套用這套說法。
判斷方式：先確認流控設定一致，再比較傳輸量
先確認用戶端與伺服器都使用 xtls-rprx-vision，再以同一條線路、同一個 HTTPS 大型檔案，並選擇相近時段比較 CPU 使用率與傳輸量。只看一次網頁開啟速度，無法證明直接複製路徑是否生效，也不能據此推算固定的提速百分比。
四、匯入後應逐項確認的欄位
訂閱通常會帶入大部分參數，但更新時欄位遺失、手動編輯或核心版本不同，仍可能造成連線失敗。建議先保留原始匯入設定，再逐項修改副本。每次只改一個欄位，才容易對照記錄與設定的變化。
- 伺服器位址與連接埠：必須指向代理服務實際監聽的位置。遠端
443與用戶端本機 SOCKS 監聽連接埠是不同欄位，不能互換。 - UUID 與 flow：UUID 對應伺服器上的 VLESS 使用者；用戶端的
flow必須與該使用者的伺服器端設定一致。填入xtls-rprx-vision，不會讓未啟用 Vision 的伺服器自動支援此功能。 - 公鑰：取自伺服器 REALITY 私鑰所對應的公鑰，不是網站憑證文字。分享連結通常以
pbk傳遞此值；圖形介面與核心 JSON 的欄位名稱可能因版本而異，請查閱相應版本文件，不要直接把連結參數名稱當成 JSON 欄位。 - SNI 與指紋：
serverName必須屬於伺服器允許的名稱範圍；fingerprint的範例值chrome用來描述 ClientHello 指紋，不會改變本機瀏覽器，也不代表能隱藏所有網路特徵。 - shortId：用戶端的值必須符合伺服器允許清單中的其中一項。它以十六進位表示，最多 16 個字元且長度須為偶數；只有伺服器允許空值時，用戶端才能留空。
在 v2rayNG 中，長按相應設定並進入「編輯」，即可確認伺服器位址、連接埠、傳輸安全、SNI 與公鑰等項目；介面名稱可能因版本略有不同。在 v2rayN 中，雙擊設定進入編輯視窗，並確認實際使用的核心。排查問題時，不要直接啟用「允許不安全憑證」之類的選項，它無法取代 REALITY 公鑰驗證。
五、依握手、代理請求與應用程式連線分段排查
「節點連不上」可能代表多種不同故障。TCP 連接埠無法連線時，修改 SNI 不會有幫助；REALITY 驗證失敗時，調整路由規則也無法補救。應按連線發生的順序蒐集資訊，不要把所有參數重新隨機填一遍。
- 先確認連線目的地：核對伺服器位址、實際連接埠、伺服器監聽狀態與防火牆規則。連線逾時和遭拒絕是不同狀況；逾時也可能與線路封包遺失或過濾有關。
- 接著檢查握手驗證：核對公鑰、SNI、shortId 與指紋設定。若伺服器設有握手時間差限制，也要確認兩端系統時間同步，避免把時鐘偏差誤判為金鑰錯誤。
- 再檢查 VLESS 使用者：握手完成後仍然失敗，就要繼續核對 UUID、flow 與伺服器端使用者設定。外層連線建立，不代表代理請求已獲接受。
- 最後檢查應用程式連線：確認應用程式流量有進入用戶端，再檢查 DNS、路由規則與伺服器出口。記錄中只有連線成功，不代表瀏覽器流量已經經過該代理。
公鑰和 UUID 都填了，為什麼握手還是失敗？
先從原始訂閱重新匯入一份副本，逐項比對 SNI、shortId 與傳輸安全是否設為 REALITY。接著確認伺服器更換私鑰後，公鑰是否也同步更新；查看同一時間點兩端的記錄，不要只依延遲測試結果判斷。
可以連線但網頁打不開，還需要更改指紋嗎？
先確認瀏覽器使用系統代理或指定的本機代理，並檢查用戶端記錄中是否出現請求。若請求已進入代理，再核對 DNS 解析與路由出口；沒有握手錯誤時，不應優先反覆切換指紋。
啟用 Vision 後速度沒有變快，是設定沒有生效嗎？
不一定。先確認兩端的 flow 設定，再固定下載來源與測試時段，觀察 CPU 使用率及傳輸量。線路頻寬、封包遺失或目標伺服器限速都可能成為瓶頸；一般的小型網頁也不容易看出資料轉送負擔降低帶來的差異。
為什麼換成 v2flyNG 後，同一份訂閱不能直接使用？
先確認設定是否依賴 Xray 的 REALITY 與 Vision 功能。這類設定應在支援相關功能的 v2rayNG，或使用合適核心的 v2rayN 中套用；只改用戶端名稱或傳輸標籤，無法解決核心功能差異。
六、了解適用範圍，再決定是否更換設定
REALITY 不會隱藏代理伺服器的 IP，也無法保證流量不會被識別。目標網站的選擇、伺服器部署、網路路徑與用戶端版本都會影響實際表現。Vision 的主要價值在於提升符合條件的資料流處理效率，而不是改變實體線路的頻寬或往返延遲；高封包遺失率、網路壅塞及伺服器負載仍須另外排查。
- 已有穩定設定時，請保留原設定作為對照，不要同時更換伺服器、傳輸方式與 DNS。
- 若需手動維護，請記錄核心版本與欄位變更；升級後先測試一項設定，再批次更新。
- 分享排錯資訊時，請隱藏 UUID、訂閱網址與伺服器私鑰；保留錯誤類型、發生時間及必要的欄位名稱。
- 想進一步了解欄位說明，可參閱本站的 JSON 手冊；首次匯入與啟用代理，請依照 入門指南 操作。
最後要確認的不是介面上是否同時出現三個名稱，而是整條連線是否順利：用戶端連上正確的伺服器、REALITY 驗證通過、VLESS 使用者與流控設定相符，應用程式請求也依預期路由至目標。把各層分開確認，設定與排錯才更容易重現。