REALITY 與 XTLS Vision 為什麼快：握手複用與流量控制原理解析

TLS 握手為什麼會影響首封包時間

代理連線的「快」至少包含三項不同指標：建立連線需要多久、持續傳輸能達到多少吞吐量，以及 CPU 為每個封包付出的處理成本。REALITY 主要改變握手與外觀特徵，XTLS Vision 則主要最佳化進入穩定傳輸後的資料路徑。把兩者簡單理解成「提升頻寬」並不準確。

以 TCP 上的 TLS 1.3 為例，客戶端先完成 TCP 三向交握，再傳送 ClientHello；伺服器回傳 ServerHello、憑證相關訊息與握手完成訊息。完整的 TLS 1.3 握手通常需要 1 次網路往返，才能傳送受保護的應用程式資料。若客戶端與伺服器之間的往返時間較高，這輪訊息交換就會直接反映在首次網頁請求或應用程式連線的等待時間上。

TLS 1.2 的完整握手通常需要更多訊息往返，因此 TLS 1.3 已經降低了啟動成本。不過，代理鏈路仍可能在外層 TLS 中承載瀏覽器自身的 HTTPS。外層保護代理通道，內層保護使用者存取的網站；如果代理層持續對已加密的 TLS 記錄執行通用加密、複製與封裝，CPU 與記憶體操作就可能重複進行。

REALITY 實際處理了什麼

REALITY 是 Xray 中用來建立具備驗證功能之 TLS 風格連線的安全層，常與 VLESS 和 TCP 搭配使用。客戶端會在 ClientHello 中提供由 REALITY 參數產生的驗證資訊，伺服器則根據私密金鑰與公開金鑰的關係、shortId、時間範圍等條件判斷連線是否合法。驗證通過後，連線會進入 VLESS 及後續的流量控制處理。

「借用真實網站憑證」更適合理解為複用目標網站的 TLS 外觀與握手情境，而不是複製目標網站的私密金鑰。REALITY 伺服器端不需要持有目標網站的憑證私密金鑰。設定中的 serverName 應與伺服器端允許的名稱一致，客戶端還必須使用正確的 publicKey、shortId 與 fingerprint；只要其中一個欄位不符，就可能在握手階段失敗。

伺服器端通常還會設定一個可存取的目標位址。未通過 REALITY 驗證的一般探測連線，可依設定轉向目標網站，讓外部觀察到的回應更接近一般 TLS 服務。這項機制解決的是握手形式與驗證問題，不會自動修復伺服器壅塞、跨網路丟包或電信業者的路由繞行。

XTLS Vision 如何減少重複處理

VLESS 本身不會為應用程式資料增加一層通用內容加密，安全性由 REALITY 或 TLS 等外部安全層提供。XTLS Vision 是 Xray 的流量控制方式，設定值通常寫作 xtls-rprx-vision。它會觀察連線中的 TLS 特徵，在完成必要的握手與驗證後，針對符合條件的資料採用更直接的轉送路徑。

瀏覽器存取 HTTPS 網站時，瀏覽器與目標網站之間已經建立一層端對端 TLS。傳統代理安全通道若再將整段內層 TLS 資料作為一般載荷持續加密，就會形成「TLS 資料位於另一層安全通道內」的處理結構。Vision 的重點不是取消目標網站的 HTTPS，而是辨識這類已加密的資料流，減少外層重複加密、緩衝與記憶體複製。

這項最佳化通常在大型檔案傳輸、並行 HTTPS 連線或伺服器 CPU 較緊張時更容易觀察到。短連線的總耗時仍可能主要取決於 DNS、TCP 建立連線與網路往返；低速鏈路則可能先受到頻寬限制。Vision 也不會改變目標網站 TLS 的憑證驗證結果，瀏覽器與目標網站之間的安全邊界依然存在。

• 短暫網頁請求：更容易受到往返時間、DNS 與首次握手影響，吞吐量差異未必明顯。
• 持續下載：更容易觀察到記憶體複製、加密處理與伺服器 CPU 之間的差異。
• 高並行連線：應同時觀察 Xray 記錄、程序 CPU 與系統連線數，不能只依據單一連線判斷。
• 高丟包網路：TCP 重傳與壅塞控制通常會成為主因，Vision 無法繞過底層重傳。

REALITY 與 Vision 為什麼經常一起出現

REALITY 和 Vision 處理的是同一條連線的不同階段。REALITY 負責建立具有特定 TLS 外觀且具備驗證能力的通道；Vision 則在通道建立後，最佳化符合條件的資料流。因此常見的組合是：VLESS 負責使用者與請求表達，REALITY 負責安全握手，Vision 負責流量控制，TCP 負責可靠傳輸。

這個組合要求客戶端與伺服器端的參數精確對應。客戶端只有 publicKey，沒有伺服器端 privateKey；shortId 應來自伺服器端的允許清單；serverName 必須與伺服器端設定相符；Flow 必須設為 xtls-rprx-vision。將一般 TLS 節點的網域與連接埠直接套入 REALITY 欄位，無法建立可用連線。

在 v2rayN 中透過訂閱匯入時，這些值通常會自動寫入伺服器設定。需要手動核對時，可進入「伺服器」→「編輯伺服器」，確認位址、連接埠、使用者 ID、Flow、傳輸協定、安全類型、SNI、指紋、公鑰與 shortId。接著進入「設定」→「參數設定」，確認目前的 Core 類型是支援此組合的 Xray 核心。

協定：VLESS
傳輸：TCP
安全性：REALITY
Flow：xtls-rprx-vision
SNI：與伺服器端 serverNames 相符
Fingerprint：chrome
Public key：由伺服器端公鑰產生
Short ID：與伺服器端允許值完全一致

1. 先更新訂閱並重新選取對應的伺服器，避免繼續使用舊的 publicKey 或 shortId。
2. 開啟 v2rayN 的伺服器編輯視窗，逐項核對 VLESS、TCP、REALITY 與 Vision，不要只檢查位址和連接埠。
3. 儲存後啟動連線，在「說明」→「檢視記錄」中觀察 Xray 啟動、握手與出站錯誤。
4. 啟用系統代理後存取一般 HTTPS 頁面，再測試持續下載，分別判斷握手與傳輸階段。
5. 若本機應用程式手動使用代理，請確認它指向 v2rayN 目前的監聽連接埠；常見的本機混合代理連接埠為 10808，但仍應以「設定」→「參數設定」中的實際值為準。

哪些情境適合，哪些瓶頸不會消失

VLESS、REALITY 與 Vision 的組合適合客戶端和伺服器端都能穩定使用 Xray 核心的情境，尤其適合以 HTTPS 為主、持續傳輸較多，且希望減少重複處理的桌面或 Android 連線。v2rayN 可用於 Windows、macOS 與 Linux 桌面環境；Android 端若需要此組合，應使用採用 Xray 核心並支援相應參數的 v2rayNG。

v2flyNG 使用 v2fly 核心，設定能力應依該核心實際支援的範圍判斷。收到包含 REALITY 或 Vision 的訂閱項目時，不能只因訂閱成功匯入，就認定能夠建立連線；客戶端介面能顯示欄位，也不代表目前的核心已實作相應的握手與流量控制。

線路本身的品質仍然決定效能上限。伺服器出口只有固定頻寬時，Vision 不會突破出口限制；跨地區路徑持續丟包時，TCP 會降速並重傳；伺服器時間偏差過大時，REALITY 驗證也可能失敗。協定選擇應建立在記錄、網路路徑與資源使用量的綜合觀察上。

如何判斷效能提升來自哪裡

判斷協定是否適合目前的網路，應先建立可重複的對照條件。保留相同的伺服器位址、出口連接埠與測試檔案，只變更安全層或 Flow；每組至少執行 3 次，並在測試前重新建立連線。否則 DNS 快取、伺服器負載與網路波動會掩蓋真實差異。

首封包速度慢但持續下載正常，優先檢查網路往返、DNS 與握手；首封包正常但長連線 CPU 很高，才較符合重複加密或複製開銷的表現；吞吐量週期性下降並伴隨 TCP 重傳，則應先處理丟包。記錄中的握手失敗屬於設定問題，不應與效能問題混在一起分析。

• 記錄 v2rayN 或 v2rayNG 從點選連線到核心回報可用的時間。
• 使用相同的 HTTPS 資源持續傳輸至少 60 秒，觀察穩定階段而非瞬間峰值。
• 在桌面系統的工作管理員或系統監視工具中，記錄 Xray 程序的 CPU 使用率。
• 分別測試直連規則與代理規則，確認路由沒有將測試目標送往錯誤的出口。
• 檢查核心記錄中是否存在握手逾時、連線重設、連接埠佔用或 DNS 解析錯誤。

因此，REALITY 與 XTLS Vision 的優勢並非來自單一的「加速開關」。REALITY 透過可驗證的參數建立符合目標 TLS 外觀的連線，Vision 則在安全通道內辨識已加密的應用程式流量並減少重複處理。只有在參數相符、核心相容、路由正確且線路瓶頸允許的情況下，這套組合才會展現為更短的啟動等待時間、更低的資源使用量或更穩定的持續傳輸。