單元 25 TLS、REALITY 與 Vision 的組合

學習目標與問題

先讀 19 的 TLS 驗證與 24 的六欄分類。本單元聚焦 security 與 flow 兩欄及欄位組合：你應能說明 TLS 與 REALITY 各靠什麼驗證伺服器、Vision 在什麼條件下改變保護邊界，辨認不相容組合，並分開協定保證與實作最佳化。

問題：在 24 例題的基礎 VLESS 加上 Vision，或把 TLS 換成 REALITY，各改變哪一欄？Vision 完成切換後，資料還有幾層加密？各欄名稱都存在，能否推出整組設定可用？

25.1 TLS、REALITY 與信任

24 例題的基礎 VLESS 沒有 flow。本節先看 security 欄的 TLS 與 REALITY，25.2 加入 Vision，25.3 再看各欄能否任意組合。

TLS 提供承載通道的保護與驗證。REALITY 是 Xray 生態的 transport-security 機制，以特定握手／驗證與目標站點外觀為設計重點，不是單獨代理目的請求協定；其 client/server 參數、信任方式和 fallback 需獨立核對。正常 REALITY 驗證依預先分發的伺服器 key 材料與 shortId 等設定，不是單靠一般 WebPKI 信任鏈；設定分發管道是重要信任邊界。填充、外觀或 fingerprint 只改變部分可觀察特徵，不構成絕對不可辨識的保證。

25.2 Vision 與 direct-copy

Vision 是特定流程處理模式，不是 HTTP 代理協定，也不等同 TCP 的 rwnd/cwnd。特定平臺及條件下可減少重複封裝／資料複製，Linux splice 等最佳化需要實作條件；不能宣稱在所有系統、所有 payload 和所有 transport 都同樣有效。

Vision 的 direct-copy 模式在符合內層 TLS 條件、完成切換後，可以繞過外層 TLS／REALITY 再加密，直接轉送已由內層 TLS 保護的記錄。此階段不能再畫成每個 byte 都有兩層加密；機密性依靠內層 TLS。非 TLS 或不符合條件的資料不能任意套用該結論。這是對此次原始碼與設計的分析，未在本課部署量測。

文件列 xtls-rprx-vision 可攔截 UDP/443 以促使應用改走 TCP HTTPS，另有 -udp443 變體。分流與 QUIC 可用性需核對實際 flow 及應用 fallback，不能只看入口支援 UDP。

25.3 組合的相容性

相容性有三層：protocol↔transport、transport↔security、flow↔其餘條件。此次文件列 REALITY 可配 RAW、XHTTP、gRPC，不配 WebSocket；Vision 的 flow 是否適用仍須按指定核心、承載及 payload 條件另查。因此「每個欄位各自存在」不等於「任意組合可用」。具體執行前需固定核心版並用其 validator，不在本課假裝已部署驗證。

25.4 完整例題：分類與相容性

候選 A：VLESS 基礎 none＋RAW＋TLS＋Vision，應用經 SOCKS 入口。分類為 protocol=VLESS，協定內 encryption=none，承載=RAW/TCP，security=TLS，flow=Vision，接管=SOCKS。需要再查 TLS 名稱／信任、Vision 平臺及 payload 條件。

候選 B：VLESS＋WebSocket＋REALITY。各名字都存在，但此次 Xray transport 相容表不支援此組合，不能當有效設定。

例題是分類模型，不是可直接執行的 JSON 模板。若讀者安裝其他核心，先用該版官方 schema 重建，再於隔離環境驗證；不要把教學概念表貼進生產服務。

延伸：AnyTLS 與 NaïveProxy

AnyTLS 參考專案處理 TLS 通道中的代理資料、填充及連線重用；NaïveProxy 使用 Chromium 網路堆疊及 HTTP/2／3 CONNECT 等機制。前者的 padding 與 session 策略、後者的瀏覽器堆疊及 HTTP 承載都屬實作／協定設計，不能排在 TUN／系統 proxy 的「接管方式」欄。

兩者都需分析 TLS 驗證、出口目的、重用造成的共享狀態和資源。參考程式的預設／示例不一定是理想部署設定。瀏覽器外觀相近也不能由此推出匿名或無法封鎖；效能結論需同條件測量。

實驗、習題與檢核

L14 新增第 1 列的 flow 欄，以及第 2 列的分類與路徑判讀，併入 28 後一次評分。L10 首次完成 B（普通 TLS/TCP 代理的多層預算），只需 TLS 記錄與 TCP，併入 27 後連同主體一次評分。

基本：若某 transport 能用 REALITY，是否一定能用所有 Vision 設定？
基本：完整 TLS 驗證與 padding 各解決什麼問題？
分析：一份教學設定寫 VLESS＋RAW＋REALITY＋Vision。依 protocol↔transport、transport↔security、flow↔其餘條件三層，哪一層能由本單元引述的文件內容確認？還要查哪些條件，才能說這組設定可用？

專題里程碑：讀完本單元，交拓樸、端點、分層及威脅／信任表；26 至 28 的內容還沒讀，先列待驗假設，讀完 27、28 再修訂（§29.2）。

檢核：任何效能或安全主張都能指出版本、組合、端點與條件。來源：Xray transport 相容表、REALITY 設定、VLESS 設定、AnyTLS、NaïveProxy。另見 Vision 設計、VisionReader/Writer 與 UnwrapRawConn。文件查閱 2026-10-03，第三方核心未在本課實測。