VLESS 負責請求格式與使用者驗證，REALITY 負責外層安全握手，XTLS Vision 則負責辨識流量並最佳化轉送。本文適合已匯入節點、想了解設定欄位與效能差異的使用者，依序說明握手、憑證驗證、流量控制及用戶端設定，並整理連線失敗時應檢查的參數。效能結論以運作機制與適用條件為限，不將協定名稱直接等同於實際網速。
VLESS、REALITY、Vision 各自負責什麼？
這三個名稱並非三種可以互相取代的協定。常見的「VLESS + REALITY + Vision」是分層組合：VLESS 定義代理請求，REALITY 提供傳輸安全，Vision 則是 VLESS 可使用的一種流量控制。用戶端介面將它們放在同一個節點編輯視窗中，容易讓人誤以為只要選取 REALITY，Vision 就一定會生效。
| 層級 | 主要職責 | 檢查位置 |
|---|---|---|
| VLESS | 傳送使用者識別資訊、目標位址、目標連接埠與請求類型 | 協定、UUID、encryption |
| REALITY | 完成具備驗證機制的 TLS 風格握手與安全傳輸 | security、SNI、公鑰相關參數、shortId |
| XTLS Vision | 處理初始填充、辨識內層 TLS，並在符合條件時最佳化轉送 | flow = xtls-rprx-vision |
| TCP | 承載底層的可靠位元組串流 | 傳輸類型與伺服器監聽連接埠 |
VLESS 的 encryption 通常設為 none。這裡的「不加密」僅表示 VLESS 協定本身不會再額外加密負載，不代表整條連線會以明文在網路上傳送。在本文介紹的組合中，外層安全由 REALITY 提供；瀏覽器瀏覽 HTTPS 網站時，應用程式本身也會與目標網站建立 TLS 連線。
用戶端與核心也要分開理解。v2rayN 是桌面用戶端，執行節點時需選用支援相應功能的核心；v2rayNG 使用 Xray 核心。v2flyNG 使用 V2Fly 系列核心，不能只因介面也能填寫 VLESS，就推論它能執行相同的 REALITY 與 Vision 組合。
REALITY 握手與「借用憑證」的實際意義
一般 TLS 代理通常由伺服器提供網域憑證，再由用戶端驗證憑證鏈與網域。REALITY 改變了這種部署與驗證方式：伺服器會設定一個目標網站，用戶端則帶上 SNI、指紋及 REALITY 所需的驗證參數，讓伺服器區分通過驗證的用戶端與其他連線。
「借用憑證」只是方便理解的概括說法，並非將目標網站的私鑰複製到代理伺服器。對於通過驗證的連線，REALITY 會使用自己的金鑰與驗證機制產生並驗證暫時憑證；未通過驗證等情況下，連線則可依機制轉送至設定的目標網站，呈現該網站正常的 TLS 行為。實際處理方式也會受到伺服器設定與實作版本影響。
因此，用戶端並不是取消所有驗證後就接受任何憑證。用戶端持有的伺服器公鑰相關參數會參與驗證，短識別碼用來比對伺服器允許的用戶端參數，SNI 也必須符合伺服器接受的名稱。若將「憑證看起來來自目標網站」理解成「隨便填一個網域就可以」，握手就會直接失敗。
REALITY 常見部署方式會依賴合適的 TLS 1.3 目標網站。伺服器能否正常連至目標網站、SNI 是否列在允許清單中，以及用戶端時間是否有過大誤差，都會影響握手。發生錯誤時，應先檢查這些明確條件，再考慮更換指紋是否有幫助。
XTLS Vision 如何減少重複加密與封裝
瀏覽器瀏覽 HTTPS 網站時，瀏覽器與網站之間已經有一層 TLS。如果代理又將這些 TLS 密文完整包進另一層 TLS，網路傳輸中就會出現常說的「TLS 套 TLS」。這種方式仍可運作，但外層記錄封裝、加解密與緩衝處理都會耗用資源。
Vision 並不是看到任意資料就停止加密。它會處理連線開頭的流量與填充，並辨識內層 TLS 的握手與記錄特徵。實作判定符合條件後，尤其是適合直接轉送的內層 TLS 1.3 流量，可以切換至更直接的轉送路徑，減少對既有密文的重複處理。
- 連線起始階段：仍須進行驗證、VLESS 請求與流量辨識，不能理解為完全略過外層握手。
- 符合條件的 HTTPS 流量：應用程式端的 TLS 仍會保護網站內容，Vision 主要是減少外層的重複處理，而非解密瀏覽器與網站之間的資料。
- 不符合條件的流量：不能直接套用轉送路徑，仍須進行相應的安全封裝與協定處理。
- 轉送實作：在系統與連線條件允許時，也可能採用效率更高的轉送機制；但不代表每個平台、每次連線都會使用相同路徑。
這也說明了為什麼在 CPU 效能較弱、並行連線較多或持續傳輸時，減少重複加密可能更有價值。不過，Vision 不會改變伺服器的對外頻寬，也無法讓壅塞的連線變成低延遲連線。如果瓶頸在跨網路封包遺失與線路排隊，節省本機加密開銷未必會帶來明顯的下載速度變化。
判斷方式：分開測量握手耗時與持續傳輸速度
比較時請固定伺服器、目標網站與測試時段，分別記錄首次請求耗時、持續下載速度及用戶端 CPU 使用率。若只有傳輸速度提升、首次請求耗時變化不大，通常較符合轉送與加密開銷降低的情況，不能直接歸因於「少了一次網路往返」。
設定欄位：連接埠、SNI、短識別碼與 flow
節點能否正常運作，取決於用戶端與伺服器參數是否完整相符。請先向服務提供者取得完整設定，再檢查用戶端匯入的內容。下列數值是協定或設定上的界線，不是本站的效能測試結果；其中 443 是常見的部署連接埠，並非 REALITY 唯一可用的連接埠。
協定與傳輸方式
- 協定
- VLESS
- encryption
- none
- 傳輸方式
- TCP，部分新版設定稱為 RAW
- security
- reality
- flow
- xtls-rprx-vision
這些選項僅說明本文介紹的組合，並非可直接連線的完整節點設定。
驗證與握手
- 位址與連接埠
- 使用服務提供者提供的連線入口
- UUID
- 對應伺服器端的 VLESS 使用者
- SNI
- 符合伺服器允許的 serverNames
- 公鑰相關參數
- 由伺服器端 REALITY 金鑰設定提供
- shortId
- 符合伺服器端 shortIds 中的值
不同版本中的公鑰參數介面或設定欄位名稱可能不同，請以目前使用的核心文件與訂閱格式為準。
shortId 使用十六進位表示，非空值的字元數必須是偶數，最多 16 個字元，也就是最多 8 位元組。能否使用空值取決於伺服器是否允許空短識別碼。它不是 UUID 的縮寫，也不能依節點名稱自行產生；最穩妥的做法是保留訂閱提供的原始值。
SNI 與伺服器位址也不是同一個概念。位址用來決定實際連線的主機，SNI 則是在握手時宣告伺服器名稱；節點位址可以是 IP，而 SNI 是設定中允許的網域。不要因為位址不同，就將 SNI 改成伺服器 IP；也不要試圖略過憑證驗證來掩蓋驗證參數錯誤。
v2rayN 設定與連線驗證順序
檢查設定時，應依照「匯入正確、核心可用、握手成功、代理生效」的順序進行。節點清單中顯示延遲數值，並不能證明 REALITY 驗證成功；一般 TCP 探測最多只能表示連接埠在某種程度上可以連線。
- 檢查節點內容。在 v2rayN 節點清單中雙擊目標節點，確認協定為 VLESS、安全選項為 REALITY，流量控制為
xtls-rprx-vision。介面分組名稱可能隨版本變動，但這些欄位的意義不變。 - 檢查執行核心。開啟「設定」→「參數設定」，查看核心相關選項，確認該節點實際使用的是支援 REALITY 與 Vision 的 Xray 核心。不要只根據用戶端安裝套件名稱判斷是否支援相關功能。
- 檢查本機監聽。在同一個設定頁面確認本機代理連接埠。例如實際監聽位址為
127.0.0.1:10808時，外部測試工具必須使用這個位址；若已變更連接埠，也要同步修改測試命令。 - 執行實際連線測試。選取節點後，使用節點清單選單中的實際連線延遲測試，並查看核心記錄。驗證錯誤、公鑰參數錯誤與連線逾時需要分別處理，不能一概歸類為「節點很慢」。
- 驗證應用程式連線路徑。啟用系統代理後，瀏覽 HTTPS 網頁。也可以在命令列明確指定 SOCKS 代理，以排除應用程式未讀取系統代理設定的可能性。
以下命令僅適用於本機 SOCKS 入口確實監聽於 10808 的情況。socks5h 會將網域名稱交由代理端處理，避免本機 DNS 解析結果干擾這次測試。回傳狀態碼可協助確認請求是否完成，但無法單獨證明連線使用了指定的流量控制，還需搭配目前選取的節點與記錄判斷。
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -I https://example.com/在 Android 裝置上，v2rayNG 同樣需要檢查匯入後的 REALITY 參數，並授予相應的 VPN 連線權限。如果設定來自支援 Xray 擴充功能的訂閱，不要直接原樣匯入 v2flyNG，然後期待得到相同結果；能讀取訂閱文字與核心支援所有欄位，是兩個不同層面的事。
效能限制：為什麼不是每條線路都會更快
「降低開銷」是運作機制上的結論，「降低延遲」則需要實際測量。REALITY 仍須建立底層連線並完成安全握手，Vision 的最佳化也有適用的流量條件。如果網頁需要多次 DNS 查詢、跨區連線，或伺服器正排隊處理請求，減少加密運算可能只占總耗時的一小部分。
| 觀察到的現象 | 優先檢查項目 | 不應直接下的結論 |
|---|---|---|
| 連接埠可連線，但實際連線失敗 | UUID、SNI、公鑰相關參數、shortId、系統時間 | 連接埠通了就代表驗證成功 |
| 下載速度快，但首次開啟很慢 | DNS、建立連線耗時、目標網站回應 | 持續傳輸速度快，就代表所有請求延遲都低 |
| 晚間傳輸速度下降 | 線路壅塞、封包遺失、伺服器負載 | 修改 flow 就能解決頻寬瓶頸 |
| CPU 使用率下降，但速度不變 | 對外限速、目標網站限速、本機網路頻寬 | 最佳化沒有生效 |
比較測試時，請固定下載內容、連線數量與代理規則，至少重複 3 次並記錄中位數。不要拿一次命中瀏覽器快取的結果，與一次冷啟動請求相比；也不要將不同地區伺服器的結果歸因於流量控制本身。這樣才能區分協定開銷、路由品質與伺服器資源差異。
常見問題：無法連線或設定不相符時如何處理
選了 REALITY，為什麼還要設定 Vision？
REALITY 是傳輸安全設定，Vision 則是 VLESS 的流量控制。重新開啟節點編輯視窗，分別確認安全選項與 flow；若服務提供者要求使用 xtls-rprx-vision，用戶端與伺服器的使用者設定必須相符，不能以空白流量控制取代。
TCP 延遲測得到數值，實際連線卻一直失敗？
先開啟核心記錄，再檢查 UUID、SNI、公鑰相關參數與 shortId。接著確認裝置已啟用自動校時，且伺服器可以連至設定的目標網站。TCP 延遲測試不包含完整的代理驗證，不能用來排除握手問題。
指紋填 chrome，就等於使用真實瀏覽器嗎？
並非如此。這項設定主要影響用戶端 TLS 握手特徵，不會讓後續所有網路行為都變成瀏覽器的行為。請保留服務提供者建議且目前核心支援的指紋值；若記錄指出不支援，應更新相容的核心或向服務提供者確認，不要隨機更換名稱。
更新訂閱後，還能沿用舊公鑰與短識別碼嗎？
請優先以新訂閱提供的參數為準。伺服器更換金鑰或短識別碼清單後，舊值可能無法通過驗證。重新匯入或更新節點，檢查是否有同名的舊節點，並確認目前選取的是更新後的設定，而不只是修改顯示名稱。
理解這組設定的關鍵，在於區分代理協定、外層安全與流量控制的職責。先確保參數與核心相符，再檢查握手及實際請求；只有確認連線路徑後，討論 Vision 能節省多少 CPU、是否縮短請求耗時才有比較基準。