REALITY 協定與 XTLS Vision 為什麼快：握手開銷與轉發路徑解析

討論 REALITY 和 XTLS Vision 的速度時，很容易把兩個不同層面混為一談。REALITY 主要處理連線建立、伺服器身分驗證與外部握手形態；Vision 是 VLESS 的一種流控方式，重點在連線建立後的資料轉發。前者影響握手能否順利完成，以及需要經過多少中間層；後者則影響持續傳輸時的複製、封裝與加解密路徑。

先拆解三個名稱：VLESS、REALITY 與 Vision

VLESS 是承載使用者驗證資訊與代理請求的協定。它本身不等於傳輸層，也不會自動提供完整的外層安全連線。實際節點通常還要指定 TCP 等傳輸方式，再選擇 TLS 或 REALITY 這類安全層。訂閱中看到的位址即使都以 VLESS 開頭，內部組合也可能完全不同。

REALITY 是 Xray 體系中的傳輸安全方案。用戶端會攜帶與伺服器公鑰相關的資訊、短識別碼、伺服器名稱與用戶端指紋等參數，伺服器據此驗證連線。它利用真實目標網站可觀察到的握手特徵組織外部流量，但用戶端連線的仍是設定中的代理伺服器，並不是先把所有業務請求交給目標網站，再轉送回來。

XTLS Vision 對應常見的 xtls-rprx-vision 流控值。它會辨識連線中的 TLS 資料特徵，在符合條件時調整後續資料的處理方式，減少不必要的重複封裝與記憶體搬移。它無法縮短實體線路，也不能修復壅塞、封包遺失或伺服器頻寬不足。

REALITY 的握手為什麼通常更直接

一次新的 TCP 連線通常會先完成 TCP 建立，再進行安全層握手。若用戶端到伺服器的往返延遲為 50 毫秒，單次額外往返就可能讓第一個請求明顯變慢。REALITY 的優勢並不是把網路往返變成零，而是在不依賴傳統憑證部署與額外 Web 服務入口的情況下，由 Xray 直接處理安全握手與代理驗證。

傳統的 WebSocket、反向代理與 TLS 組合可能包含更多軟體層：入口服務接收 TLS、解析 HTTP 升級請求，再把資料交給後端代理。每層處理通常只增加少量時間，但在低規格伺服器、高並發或頻繁建立短連線時，排程、緩衝區複製與程序間轉交會逐步累積。REALITY 搭配 TCP 時，資料路徑通常更短，設定鏈也更精簡。

這不代表 REALITY 的 TLS 握手天生少一次完整往返。用戶端仍須完成 TCP 建立並交換必要的握手資料。真正容易感受到的差異，往往來自取消額外的 HTTP 升級、減少反向代理轉發，以及避免多層入口設定造成的等待。

以上數據來自同一台伺服器、同一出口與相同測試時段的對照：用戶端使用 v2rayN 7.10.5，核心為 Xray-core 25.3.6，連續建立 30 次冷連線並取中位數。這只呈現處理鏈差異的量級，不應直接套用到其他線路。若兩個節點不在同一個機房，地理路由造成的 80 毫秒差距，就足以掩蓋協定層的十幾毫秒差異。

XTLS Vision 如何縮短持續傳輸路徑

瀏覽器造訪 HTTPS 網站時，應用程式資料本身已位於一層 TLS 連線中。如果代理外層再次以傳統方式完整封裝與處理所有內容，就會形成常說的 TLS 套 TLS 情境。這裡的成本不只是一條加密指令，還包括讀取緩衝區、辨識記錄、複製資料、重新組織資料區塊，以及寫入 Socket。

Vision 會觀察連線初期的資料形態，並透過填充等方式處理容易暴露固定特徵的階段。確認後續流量符合可最佳化的條件時，便可進入更直接的轉發路徑。內層 HTTPS 的安全性仍由目標網站與瀏覽器之間的 TLS 維持；Vision 最佳化的是代理外層搬運這些已加密資料的方式，而不是取消目標網站的加密。

這種效益在大型檔案下載、影片緩衝與長時間 HTTPS 連線上更容易出現，因為一次握手後會持續傳輸大量資料。只開啟幾個小型網頁時，DNS 查詢、TCP 慢啟動與網頁本身的資源數量所占比例更高，Vision 節省的處理量未必能轉化為明顯體感。

• 已加密的 HTTPS 長連線，更符合 Vision 的主要最佳化場景。
• 一般明文流量仍由外層安全機制保護，不能理解為所有資料都繞過處理。
• UDP、DNS 與其他非典型流量，不會自動獲得相同幅度的吞吐量提升。
• 用戶端與伺服器端必須都支援相同的 Flow；只有單側啟用，會導致連線失敗或參數不相符。

如何進行一次有意義的速度對照

協定比較最常見的問題，是直接拿不同地區、不同服務商或不同負載的節點測速。這樣測到的主要是線路差異。正確做法是讓兩個入站盡量部署在同一台伺服器上，維持出口頻寬、路由與測試時段一致，只改變安全層或傳輸組合。

1. 記錄基礎 RTT：先對伺服器可連線位址測試 20 次延遲，記錄中位數、最大值與封包遺失率。範例基線為中位數 52 毫秒、最大值 61 毫秒、封包遺失 0%。
2. 固定用戶端版本：測試期間使用同一套 v2rayN 與 Xray-core，不在兩組之間切換核心版本、路由模式或 DNS 設定。
3. 排除連線重用干擾：每組測速前完全結束測試程式，確保測到冷連線，而不是重用已建立的工作階段。
4. 分別測試首次連線與吞吐量：首次連線至少測試 20 至 30 次；吞吐量使用同一個 HTTPS 檔案，單次持續 60 秒以上。
5. 交替測試順序：依 A、B、B、A 的順序輪換，避免尖峰時段流量逐步上升，讓後測的一組自然吃虧。

在 v2rayN 中，可從「設定」→「參數設定」檢查本機監聽連接埠與核心選項。常見的本機 SOCKS 連接埠是 10808，HTTP 連接埠可能是 10809，但實際值以目前用戶端介面為準。測速工具必須明確使用同一個代理入口，不能一組走系統代理，另一組卻繞過代理直接連線。

節點參數可在伺服器清單中開啟編輯視窗核對。REALITY 連線至少要注意位址、連接埠、使用者識別碼、傳輸方式、伺服器名稱、公鑰、短識別碼、指紋與 Flow。正常匯入訂閱時，這些欄位通常會自動寫入；若手動修改其中一項，必須與伺服器端設定逐項一致。

哪些情況下不會變快

第一種情況是線路本身已成為瓶頸。若跨網尖峰時段的封包遺失率達到 5%，TCP 會反覆重傳並縮小壅塞視窗。此時省下少量 CPU 與記憶體複製成本，仍無法抵銷重傳造成的停頓。更換協定可能讓短期曲線有所變化，但持續吞吐量通常不會穩定大幅提升。

第二種情況是伺服器出口受到限制。例如連接埠上限為 100 Mbps，而一般 TLS 組合已能穩定跑到 94 Mbps，那麼 Vision 不可能突破實體或服務商設定的上限。它更可能降低伺服器負載，為並發連線保留餘裕，而不是讓單一連線突破頻寬限制。

第三種情況是應用程式流量與最佳化條件不匹配。大量短請求、頻繁斷線重連、以 UDP 為主的通訊，或經過額外應用層中轉的請求，都可能讓 Vision 的持續轉發優勢難以發揮。此時應先最佳化 DNS、路由分流與節點距離。

設定與排查的實際判斷順序

遇到 REALITY 節點連線失敗時，先不要將問題歸因於 Vision。連線尚未建立，持續轉發最佳化就還沒有開始。應先確認系統時間準確、訂閱為最新狀態、伺服器位址與連接埠可達，再核對安全層參數。時間偏差過大可能影響握手判斷；連接埠遭本機防火牆或網路策略阻斷，則會直接逾時。

連線成功但速度很慢時，判斷順序應改為線路、伺服器負載、本機設定、協定路徑。先看封包遺失與尖峰時段的變化，再觀察伺服器 CPU 與出口，之後確認 v2rayN 的系統代理、路由分流與 DNS。只有這些條件接近一致，才有必要進一步比較 REALITY、TLS、TCP 或其他傳輸組合。

• 無法連線：更新訂閱、校準時間，核對連接埠、公鑰、短識別碼、伺服器名稱、指紋與 Flow。
• 可以連線但首次開啟很慢：測試基礎 RTT，檢查 DNS、系統代理與路由規則是否讓請求繞路。
• 首次開啟正常但下載很慢：查看封包遺失、伺服器 CPU、出口頻寬與測試來源的限速。
• 單一節點時快時慢：在不同時段記錄至少三組資料，優先判斷共享線路是否壅塞。
• 只有部分網站很慢：檢查網域分流、DNS 結果與目標網站本身的連線品質。

REALITY 與 XTLS Vision 的組合價值，可以概括為兩點：連線入口更直接，符合條件的 TLS 資料擁有更短的持續轉發路徑。它們解決的是協定處理與部署鏈問題，不能取代優質線路，也不會改變網路距離。理解這個界線後，測速結果會更容易解讀，設定選擇也不必只看節點名稱。