REALITY 與 XTLS Vision 原理解析：VLESS 新傳輸方案為何更快

VLESS、REALITY、Vision：三個名稱代表三種分工

節點清單中的「VLESS + REALITY + Vision」不是三種代理協定疊加。VLESS 是代理協定；REALITY 是安全層方案；Vision 是 Xray 的一種流量控制模式，設定值通常為 xtls-rprx-vision。底層還需要傳輸通道，常見組合使用 TCP，部分新版介面或設定會將這類傳輸標示為 RAW。

最直接的理解方式，是分清「如何指定目標位址」、「如何確認對端身分」及「如何傳送後續資料」。VLESS 請求會帶上使用者識別資訊與目標資料，但 UUID 並不是能加密所有內容的密碼。常見設定中的 VLESS encryption=none，表示這一層不額外加密，不代表整條連線以明文傳輸。

本文討論的是 Xray 的實作。v2rayN 可使用不同核心，請確認該節點實際由支援此組合的 Xray 執行；v2rayNG 使用 Xray 核心。v2flyNG 使用 V2Fly 核心，不能因為也能匯入部分 VLESS 資訊，就推斷它相容於 Xray 的 REALITY 與 Vision。訂閱能顯示節點，和核心能成功建立連線，是兩回事。

TLS 疊 TLS：重複加密發生在哪裡

使用瀏覽器瀏覽 HTTPS 網站時，瀏覽器會與目標網站建立 TLS 連線。代理通常只轉送位元組，不會解密 HTTPS 內容。如果瀏覽器流量又被包進受 TLS 保護的代理通道，同一段資料就可能先由網站連線加密，再由代理通道加密。這就是常說的「內層 TLS」與「外層 TLS」。

上述流程說明的是各環節的處理職責，不表示所有握手都會嚴格依序進行。建立連線時，客戶端與代理伺服器需要交換握手資訊，代理伺服器也必須連上目標網站。即使省去部分重複加密作業，網路往返、目標網站回應時間，以及 TCP 封包遺失後的重傳等成本仍然存在。

• 內層保護：瀏覽器與目標網站之間的 TLS 負責保護網站內容；代理伺服器轉送的通常是加密記錄。
• 外層保護：本機用戶端與代理伺服器之間的安全通道，負責保護代理請求及通道內的資料。
• 額外負擔：重複加解密、記錄封裝、緩衝區處理與資料複製，都可能消耗 CPU 資源並影響傳輸效能。
• 最佳化適用範圍：非 TLS 流量不能直接套用「已有內層加密，因此外層可以少做處理」的判斷。

因此，Vision 的效能收益較可能出現在持續傳輸 HTTPS 資料，且用戶端或伺服器處理能力成為瓶頸的情境。如果線路本身頻寬有限，或尖峰時段封包遺失明顯，改用另一種封裝方式並不會自動解決壅塞問題。

XTLS Vision：流量辨識、填充與直傳最佳化

Vision 會檢視代理承載的內層 TLS 流量，在連線初期依協定規定進行填充，並判斷後續是否符合最佳化條件。對於實作能辨識且符合要求的內層 TLS 加密應用資料，可切換至專用直傳路徑，減少外層重複加密及部分緩衝處理。

「直傳」不代表繞過代理伺服器，也不代表將 HTTPS 解密成明文。資料仍會沿著用戶端、代理伺服器、目標網站這條路徑傳送；減少的是不必要的重複處理。也不能將它理解為從連線的第一個位元組起就完全取消安全層：握手、代理請求，以及不符合直傳條件的資料，仍有各自的保護與處理方式。

1. 先建立安全連線。用戶端與伺服器確認安全參數，VLESS 請求則提供使用者與目標資訊。
2. 接著處理初期流量。Vision 會填充初始資料，並辨識內層 TLS 握手與記錄。
3. 符合條件才進行最佳化。符合實作要求的內層加密應用資料會進入直傳路徑，不是所有位元組都一律走同一條捷徑。
4. 其他流量仍受保護。無法辨識或不符合條件的流量仍會依適用路徑處理，不能硬當成已加密內容。

Vision 也包含降低部分流量特徵的設計，但這不代表連線無法被辨識，或永遠都能使用。目標網站選擇、網路環境、伺服器設定與核心實作都會影響結果。速度與連線可用性也應分開測量，不能用一次測速取代長期觀察。

REALITY：免自備憑證，但不會取消身分驗證

一般 TLS 伺服器通常需要為自己的網域部署憑證，並定期更新。REALITY 的常見部署方式不要求代理伺服器為自己的網域申請這類憑證，而是結合目標網站的 TLS 特徵與額外的身分驗證機制來建立連線。用戶端設定中的伺服器公鑰、ServerName 與 Short ID 都有實際用途，不能只填一個看起來正常的網域名稱。

REALITY 伺服器會保管私鑰，用戶端則使用伺服器提供的對應公鑰等參數驗證連線。它不是只要「看到某個網站的憑證」就信任代理伺服器。對於未通過驗證的連線，伺服器通常會依設定轉交給目標網站處理；這不代表已驗證使用者的所有業務流量都必須經過該目標網站。

• 位址與連接埠：指向實際的代理伺服器。伺服器監聽哪個連接埠，用戶端就填哪個，不能一律改成 443。
• ServerName：介面常標示為 SNI，應使用伺服器允許的名稱；此名稱可以與節點連線位址不同。
• 公鑰：使用伺服器提供的對應值。私鑰應保留在伺服器端，不能拿私鑰取代用戶端的公鑰欄位。
• Short ID：必須符合伺服器允許的值；伺服器是否接受空值，則視實際設定而定。
• 指紋：例如 chrome，用來選擇模擬 TLS ClientHello 的特徵，不會讓整個用戶端變成瀏覽器。

伺服器端需要檢查目標網站的 TLS 相容性、可連線性與回應狀況。隨意更換 ServerName 不是可靠的修復方式。系統時間也會影響相關驗證；若時間偏差過大，應先啟用系統時間同步，再重新連線。

v2rayN 與 v2rayNG：逐項核對欄位，別憑名稱猜設定

建議優先透過現有訂閱匯入完整節點。手動編輯時，先確認安全層，再核對 Flow、傳輸方式、ServerName、公鑰與 Short ID。以下兩張卡片比較的是不同安全層下的常見組合，並非可直接複製使用的完整節點；位址、使用者識別資訊與驗證參數都應以伺服器提供的資料為準。

1. 在桌面端核對節點。在 v2rayN 節點清單中雙擊目標 VLESS 節點，逐項檢查協定、傳輸方式、安全層與 Flow；確認該節點使用支援這些功能的 Xray 核心。不同版本的欄位名稱可能略有差異。
2. 檢查本機入口。進入 v2rayN「設定」→「參數設定」，核對本機監聽連接埠相關設定。例如用戶端實際監聽 127.0.0.1:10808 時，手動設定應用程式代理也應使用相符的位址、連接埠與代理類型。10808 在此僅為檢查範例，並非所有安裝版本的固定值。
3. 在 Android 端核對欄位。在 v2rayNG 節點清單中開啟目標節點的編輯畫面，確認傳輸方式、安全設定與流量控制。儲存後重新選取節點並啟動連線，避免測試的仍是另一組設定。
4. 分清入口與出口。桌面系統代理或 Android VPN 接管設定，決定應用程式流量能否進入用戶端；節點安全參數決定代理連線能否建立；路由規則則決定流量最後走代理還是直連。

不要為了排除 REALITY 連線錯誤而啟用略過憑證驗證，也不要刪除公鑰或任意修改 Short ID。這些修改無法取代正確的伺服器參數，反而會讓診斷方向失焦。分享畫面截圖時，請遮蔽訂閱網址、使用者識別資訊與其他敏感設定。

速度與連線問題：透過對照測試找出原因

「為什麼更快」只能說明原理，無法保證每條線路都會有相同結果。比較 Vision 與其他組合時，應盡量使用同一台伺服器、相近的測試時間與相同目標資源，並區分首次連線延遲、持續下載吞吐量與 CPU 使用率。位於不同地區的兩個節點，即使協定名稱不同，也無法構成有效的協定效能對照。

• 固定測試條件：保持網路、目標資源與路由一致，並暫停背景下載。先確認測試應用程式的流量確實經過待測節點。
• 分開記錄數據：首次請求耗時以毫秒記錄，持續吞吐量則以 MB/s 或 Mbit/s 記錄並註明單位；兩者相差約 8 倍，不可混為一談。
• 重複取樣：每組進行 3 次、每次持續 30 秒的傳輸，記錄中位數與明顯波動。這是建議的測試方法，並非本文提供的實測結果。
• 觀察資源使用情況：同時檢查用戶端與伺服器的 CPU 使用率。若 CPU 已接近滿載，減少重複處理可能有效；若吞吐量偏低但 CPU 使用率很低，應優先檢查線路與目標服務。

最後應分開回答三個問題：安全握手是否成功、應用程式流量是否走對出口，以及持續傳輸時是否減少了處理負擔。REALITY 免去常見部署方式中的自備憑證維護，Vision 可減少合適內層 TLS 流量的重複處理，VLESS 則負責承載代理請求。只有設定欄位正確、核心相容且測試條件一致，才能判斷這套組合是否適合目前的網路。