REALITY 與 XTLS Vision 技術解析：為什麼握手機制與資料轉送路徑更快

REALITY 先解決握手與驗證問題

REALITY 是 Xray 體系中的傳輸安全機制，通常會與 VLESS、TCP 和 XTLS Vision 一起使用。它處理的是客戶端如何確認伺服器、伺服器如何辨識獲准的客戶端，以及連線在外部觀察下呈現何種 TLS 握手特徵。它不是獨立的代理協定，也不會取代 VLESS 的使用者識別資訊與出站設定。

傳統 TLS 服務通常由伺服器持有網域憑證，客戶端根據憑證鏈、網域與有效期限驗證伺服器。REALITY 採用不同的驗證資料：伺服器保存 X25519 私鑰，客戶端填入對應公鑰，同時攜帶伺服器名稱、Short ID 與客戶端指紋等參數。只有欄位相符且驗證通過的連線，才會進入代理處理路徑。

設定中的伺服器名稱常顯示為 serverName 或 SNI，應與伺服器允許的名稱一致；公鑰常顯示為 publicKey，部分新版介面會寫成 Password；Short ID 則是十六進位字串。這三個欄位無法由客戶端自行推導，必須由伺服器設定或訂閱內容提供。

所謂「不持有網站憑證」並不等於跳過身分驗證。客戶端仍需透過 REALITY 公鑰確認目標伺服器，伺服器也會檢查客戶端帶來的驗證資訊。公鑰填寫錯誤、Short ID 長度不符，或 SNI 不在允許清單時，連線通常會在握手階段中止，應用層請求尚未進入 VLESS 路由。

• 位址與連接埠：決定 TCP 連線要傳送至何處，常用的監聽連接埠是 443，但伺服器也可以使用其他連接埠。
• UUID：屬於 VLESS 使用者驗證資訊，不能以 REALITY 公鑰取代。
• SNI：必須取自節點設定，不應依伺服器 IP 任意填寫。
• 指紋：常見值為 chrome，用於產生相應的客戶端握手特徵。
• SpiderX：通常為 /，是否需要其他路徑取決於伺服器設定。

XTLS Vision 為什麼能縮短資料轉送路徑

XTLS Vision 對應 VLESS 的流控值 xtls-rprx-vision。它關注的不是首次身分驗證，而是連線建立後如何轉送資料。許多網頁與應用程式本身已使用 TLS；如果代理傳輸層再將整段內容放入另一層通用加密封裝，就會增加緩衝、資料複製與加解密排程。

Vision 會分析連線的資料階段，在符合條件時採用更直接的轉送方式，減少對已加密流量的重複處理。這裡的「減少」並不代表所有資料都繞過安全層，也不表示每個作業系統都必然採用相同的零複製實作。握手資料、控制資訊、不符合辨識條件的資料，以及協定要求的填充，仍須依規則處理。

首段資料還涉及 Vision 的填充與形態處理，目的之一是避免連線在早期階段呈現過於固定的結構。進入穩定傳輸階段後，核心才可能切換至開銷較低的路徑。因此，短連線較容易受到握手耗時影響；大型檔案下載、影片分段與長時間傳輸則較容易呈現資料路徑差異。

Vision 的效益也取決於核心與系統網路堆疊。線路只有 10 Mbps 時，CPU 開銷降低未必能轉化為明顯的速度提升；在數百 Mbps 的持續傳輸中，資料複製與排程成本更容易成為限制。若瓶頸是尖峰時段壅塞、跨網繞路或超過 5% 的封包遺失，更換 Flow 無法修復實體線路。

延遲、吞吐量與 CPU 使用率該如何比較

只看客戶端節點清單中的延遲值，無法判斷 Vision 是否更快。延遲測試通常只包含 TCP 建立連線、核心探測或指定網址的回應時間，其中可能混有 DNS、目標網站處理時間與線路抖動。協定差異應在相同伺服器、相同出口、相同測試檔案與相近時間內比較，並至少重複五輪。

本文的受控記錄使用 Windows 11 24H2、千兆有線區域網路、同一台遠端伺服器與同一條公網線路。測試檔案為 1 GiB，連續執行五輪並取中位數；兩組節點只變更傳輸安全性與 Flow，監聽連接埠皆為 443。這組數值用於說明觀察方式，不代表其他線路的固定結果。

在這組記錄中，吞吐量差距比首次請求差距明顯，符合長連線較能呈現轉送路徑差異的預期。但 322 Mbps 不是協定上限，也不能據此推算行動網路結果。測試期間若有背景更新、瀏覽器快取、伺服器磁碟讀取或系統代理模式不同，結論都會產生偏差。

1. 先關閉其他下載與雲端同步工作，固定使用有線網路或相同的無線位置。
2. 為兩組節點使用相同的伺服器位址、連接埠與出站線路。
3. 分別執行五輪以上，記錄中位數，不要以單次最高速度代替結果。
4. 同時觀察核心記錄、工作管理員中的 CPU 使用率、失敗次數與測試時段。
5. 將延遲與吞吐量分開記錄，不要把節點探測值當成網頁完整載入時間。

v2rayN 與 v2rayNG 中的設定欄位位置

在 v2rayN 中，透過訂閱或分享連結匯入節點後，雙擊節點開啟編輯視窗。需要核對的欄位包括位址、連接埠、使用者 ID、Flow、傳輸協定、傳輸層安全性、SNI、指紋、公鑰、Short ID 與 SpiderX。不同版本介面的欄位排序可能有所變化，但欄位意義不變。

全域參數位於「設定」→「參數設定」。核心應選擇相容 REALITY 與 Vision 的 Xray 核心；變更核心後需重新啟動客戶端，再從記錄確認實際載入的核心。節點的傳輸協定通常選擇 TCP，安全性類型選擇 reality，Flow 填寫 xtls-rprx-vision。

在 v2rayNG 中，開啟設定清單後點選目標節點進入編輯頁面，檢查「傳輸協定」「傳輸層安全性」「Flow」「SNI」「Fingerprint」「Public Key」「Short ID」等項目。v2rayNG 使用 Xray 核心處理這套組合，更新訂閱後通常會自動寫入欄位；手動編輯主要用於排查訂閱轉換遺漏。

v2flyNG 使用 v2fly 核心，協定能力與 Xray 核心並不相同。REALITY 與 XTLS Vision 屬於需要 Xray 能力的設定，因此這類節點應使用 v2rayN 的 Xray 核心或 v2rayNG。不能只將安全性類型文字改成 reality，就假設其他核心也能建立連線。

連線失敗時，依握手層、代理層與系統層逐層排查

REALITY 節點發生錯誤時，最有效的方法是先確認失敗發生在哪一層。TCP 連線逾時通常指向位址、連接埠、防火牆或線路；REALITY authentication failed、invalid response 這類訊息通常指向公鑰、Short ID、SNI、指紋或系統時間；握手成功但網頁無法開啟，則應繼續檢查系統代理、TUN 模式、DNS 與路由規則。

電腦端還要區分客戶端正在執行，以及系統流量是否已經進入客戶端。v2rayN 啟動核心後，瀏覽器是否經過代理，取決於系統代理、TUN 模式或應用程式本身的代理設定。若使用系統代理，應確認目前模式已啟用；若使用 TUN 模式，應查看虛擬網卡建立記錄與管理員權限相關提示。

本機連接埠衝突也會造成「節點無法使用」的假象。例如客戶端預計監聽 10808，但該連接埠已被其他程序佔用，核心可能無法正常啟動。此時應根據記錄找出佔用項目，或在參數設定中更換本機連接埠；反覆測試節點無法解決監聽失敗。

• 第一步：確認伺服器位址可以解析，且 TCP 連接埠可以建立連線。
• 第二步：核對 UUID、公鑰、Short ID、SNI、指紋與 Flow。
• 第三步：查看核心記錄是否出現握手成功後的目標連線記錄。
• 第四步：檢查系統代理、TUN 模式、本機連接埠與 DNS 設定。
• 第五步：暫時停用複雜的路由規則，以直連規則集進行最小化測試。

選型時應看相容範圍，不只看協定名稱

VLESS + REALITY + XTLS Vision 適合客戶端與伺服器都能執行相容 Xray 核心，且希望減少憑證部署環節、最佳化長連線轉送的情境。它的設定欄位比一般 VLESS + TCP 更多，訂閱產生與轉換流程也必須完整保留相關參數。

如果現有服務已穩定使用標準 TLS 憑證，或需要與不支援 REALITY 的核心協作，繼續使用 VLESS + TCP + TLS 可能更便於維護。協定選型不是單純的新舊替換：相容性、伺服器控制權、訂閱格式、客戶端核心與線路品質都應納入判斷。

VMess、Trojan 與 Shadowsocks 仍有各自的部署與相容情境，但無法透過填寫 Flow 取得 Vision 的運作方式。xtls-rprx-vision 是特定組合中的設定值，不是可套用至任意協定的通用加速開關。

最終判斷可歸納為三點：REALITY 負責握手與雙方驗證，Vision 負責符合條件的資料轉送最佳化，VLESS 則承載使用者與代理連線資訊。只有客戶端欄位、伺服器入站設定與核心能力三者一致，這套組合才能依預期運作。