REALITY 協定與 XTLS Vision 科普：握手原理與效能優勢解析

先分清 REALITY、VLESS 與 XTLS Vision

訂閱中常見的完整組合是「VLESS + TCP + REALITY + XTLS Vision」。這四項並不是同一層級的協定名稱。VLESS 負責用戶端與伺服器之間的使用者識別與代理請求格式；TCP 是承載資料的傳輸方式；REALITY 負責外層握手、伺服器身分確認與流量外觀；XTLS Vision 則是一種流量控制模式，用於識別已由應用層 TLS 加密的資料並調整轉送路徑。

因此，更精確地說，REALITY 是 Xray 核心中的傳輸安全方案，而不是取代 VLESS 的獨立代理協定。它不要求伺服器為自己的網域申請公開憑證，也不要求將專用網域解析至伺服器。用戶端透過 publicKey、shortId、serverName 等參數識別目標伺服器，伺服器則以設定好的真實網站作為握手外觀與回落目標。

XTLS Vision 也不是新的加密演算法。網頁存取本身通常已經過 HTTPS 加密；若代理通道外部再使用標準 TLS，代理核心便需要持續處理已加密的應用資料。兩層加密在邏輯上分別保護不同鏈路，但對於大塊、不可壓縮的 TLS 密文，重複進入通用加解密與緩衝流程會增加 CPU 使用量、記憶體複製及排程次數。

REALITY 握手如何借用真實網站特徵

一般 TLS 服務通常由伺服器傳送與自身網域相符的公開憑證。REALITY 採用不同做法：用戶端先建立接近常見瀏覽器的 ClientHello，並將設定中的 serverName 放入 SNI。伺服器依據私鑰、公鑰關係與 shortId 等資訊判斷連線是否來自有效用戶端，再完成相應的身分確認流程。

如果連線不具備有效驗證資訊，伺服器可以將握手導向預先設定的目標網站。如此一來，從外部觀察到的 SNI、TLS 版本、密碼套件與目標網站回應便具有一致的上下文，不會暴露一套專為代理服務部署的自簽憑證。這裡的「借用」是指重用目標網站的公開握手特徵與回落行為，並非複製目標網站私鑰或偽造其正式憑證。

1. 產生問候：用戶端依照 fingerprint 參數建立 TLS ClientHello，常見值為 chrome。
2. 攜帶目標名稱：serverName 會進入 SNI，必須屬於伺服器允許的名稱集合，並與伺服器設定保持一致。
3. 完成驗證：用戶端 publicKey 必須對應伺服器 privateKey，shortId 也必須符合伺服器允許的值。
4. 區分連線：驗證通過後進入 VLESS 工作階段；驗證未通過的一般 TLS 流量則依伺服器設定轉向目標網站。
5. 開始代理：VLESS 解析目標位址，接著由 Vision 決定後續資料採用一般處理或最佳化轉送。

XTLS Vision 如何減少重複加密開銷

以開啟 HTTPS 網站為例，瀏覽器會先與目標網站建立一層 TLS。若代理通道外部再使用標準 TLS，代理核心便需要持續處理已加密的應用資料。兩層加密在邏輯上分別保護不同鏈路，但對於大塊、不可壓縮的 TLS 密文，重複進入通用加解密與緩衝流程會增加 CPU 使用量、記憶體複製及排程次數。

Vision 會觀察連線初始資料，識別內層 TLS 的握手與記錄邊界。符合條件後，便能讓後續加密資料進入更直接的轉送路徑。最佳化重點不是取消安全層，而是避免對已具備端對端加密特徵的大流量進行不必要的重複包裝。對於一般明文連線或無法識別的資料，核心仍會依相應規則處理。

連線前段仍然重要。Vision 會對初始資料進行必要的填充與形態處理，降低固定封包長度及首個封包特徵過於明顯的問題。待協定狀態、方向與資料類型確認後，再切換至更有效率的複製方式。因此，它在長連線、大型檔案下載與高畫質影片中更容易展現吞吐量優勢，只有少量資料的短連線通常差距較小。

• HTTPS 大流量：內層資料已經加密，Vision 更容易進入最佳化路徑。
• 短網頁請求：DNS、TCP 建立連線與伺服器回應時間占比更高，速度差距可能只有幾毫秒。
• 高頻寬伺服器：CPU 或記憶體複製成為瓶頸時，吞吐量提升會更明顯。
• 高丟包鏈路：重傳與壅塞控制仍由 TCP 主導，Vision 無法修復線路本身的丟包問題。

延遲、吞吐量與 CPU 使用量怎麼看

以下是一組用於理解差異的同機對照資料：伺服器為 2 核心虛擬機器，用戶端使用千兆有線網路，往返延遲約 42 ms，測試檔案為 1 GB，連續執行三次並取中位數。標準 VLESS + TCP + TLS 與 VLESS + REALITY + Vision 使用相同伺服器與出口。資料只呈現典型趨勢，不應直接視為所有線路的固定結果。

結論：大流量看吞吐量，短請求看線路

如果主要問題是網頁首次開啟速度慢，應先檢查 DNS、節點距離與丟包；如果伺服器 CPU 在下載時長期超過 80%，在相同線路切換至 REALITY + Vision 更可能獲得明顯改善。

測試時不要同時更換節點、目標網站與協定，否則無法判斷改善來自哪個項目。較穩妥的做法是關閉其他下載工作，固定同一個測速檔案，分別執行三次，再比較中位數與 CPU 峰值。瀏覽器顯示的即時速度波動較大，持續 30 秒以上的傳輸結果更具參考價值。

用戶端匯入後需要核對哪些參數

v2rayN 桌面版與 v2rayNG Android 版通常會隨訂閱匯入 REALITY 節點。匯入成功不代表參數一定完整，尤其訂閱經過轉換或手動編輯時，flow、serverName、fingerprint、publicKey 與 shortId 可能遺失。v2flyNG 使用 V2Fly 核心，不適合承載依賴 Xray REALITY 與 Vision 的節點，應選擇符合訂閱核心要求的用戶端。

相容性排查可以將 Xray-core v1.8.0 作為較保守的 REALITY 基準；實際使用時，優先採用用戶端目前穩定版所附帶的更新核心。舊核心若不識別 realitySettings 或 xtls-rprx-vision，常見情況是節點無法啟動、設定檢查失敗，或日誌直接顯示未知欄位。

1. 先更新訂閱並開啟節點編輯頁，確認協定為 VLESS、傳輸方式為 TCP。
2. 核對位址與連接埠，連接埠常見為 443，但必須以訂閱實際值為準。
3. 檢查安全性類型是否為 REALITY，serverName 是否為完整網域名稱。
4. 確認 fingerprint 常見值為 chrome，publicKey 與 shortId 沒有被截斷。
5. 檢查 flow 是否為 xtls-rprx-vision；伺服器未啟用時不要自行新增。
6. 儲存後重新啟動核心，查看日誌中是否出現握手、驗證或未知欄位錯誤。

常見問題與握手失敗排查

REALITY 連線問題通常發生在三處：用戶端設定未完整匯入、用戶端與伺服器核心能力不相容，或網路無法連達伺服器監聽連接埠。排查時應先確認核心能否啟動，再確認 TCP 是否連通，最後分析 REALITY 握手。依照這個順序，可避免把連接埠無法連線誤判為公鑰錯誤。

排錯順序：啟動、連接埠、握手、代理

先確認核心是否正常執行，再檢查伺服器連接埠是否能連線，接著核對 REALITY 身分參數，最後檢查系統代理與路由；每次只修改一項並重新測試，最容易定位實際故障點。

從選擇角度來看，REALITY + Vision 適合使用 Xray 核心、希望減少憑證部署步驟並最佳化 HTTPS 大流量轉送的情境。它不會自動解決節點距離、出口壅塞與 TCP 丟包問題。當用戶端版本合適、訂閱參數完整、伺服器線路穩定這三項同時符合時，握手外觀與資料路徑最佳化才會轉化為可觀察的連線品質。