單元 19 VLESS、Trojan 與分層組合
學習目標與問題
先讀 13 至 18。你應能把一組常見代理名稱拆成 protocol、encryption、transport、security、flow 及接管方式，辨認不相容組合，並分開協定保證與實作最佳化。這是評估代理最重要的習慣。
19.1 六個欄位分開看
| 欄位 | 回答的問題 | 例子 |
|---|---|---|
| 代理 protocol | 請求與認證如何表達目的地 | VLESS、Trojan |
| 協定內 encryption | 協定層是否提供額外資料保護 | 基礎 VLESS none、新 VLESS Encryption |
| transport | 同儕間怎樣承載 bytes | RAW/TCP、WebSocket、gRPC、XHTTP |
| transport security | 承載通道怎樣保護／驗證 | TLS、REALITY |
| flow | 特定實作如何處理資料流程 | XTLS Vision |
| 流量接管 | 應用資料怎樣進入代理 | 系統 proxy、SOCKS 入口、TUN、透明代理 |
這些詞不全屬 IETF 統一的設定模型。表格以 Xray 文件的概念拆分為案例；其他核心有自己的 schema。截至本版查閱日期，Xray 現行文件使用 method 與 raw；目前核心仍相容舊 network 鍵及 tcp 值，兩鍵並存時以 method 為準，舊教程則多用 network/tcp。設定須按核心版本比對，不可直接拼接。
19.2 VLESS 的基礎與新擴充
傳統 VLESS 以輕量請求與 UUID 等識別資訊完成代理認證，encryption:none 的基礎模式不在該層加密 payload，常由外層 TLS／REALITY 保護。UUID 是授權識別／祕密資料，不是拿來做公開身分簽章的完整 PKI。
此次查閱的 Xray 文件已列出可選 VLESS Encryption，因此「VLESS 永遠完全沒有協定內加密」已不適合作為無條件敘述。新擴充的握手、恢復、填充與相容性要按指定實作閱讀，不能把外層 TLS 欄位和協定內 Encryption 當同一開關。本課不以未經獨立安全分析的新功能名稱推導所有威脅皆已解決。
目的名稱可交給伺服器解析，或由客戶先送 IP；仍需記錄實際目的欄位和 DNS 策略。VLESS 不依 VMess 式時間認證，並不表示任何外層憑證、票證、時效政策都完全不受時鐘影響。
19.3 TLS、REALITY 與 Vision
TLS 提供承載通道的保護與驗證。REALITY 是 Xray 生態的 transport-security 機制，以特定握手／驗證與目標站點外觀為設計重點，不是單獨代理目的請求協定；其 client/server 參數、信任方式和 fallback 需獨立核對。正常 REALITY 驗證依預先分發的伺服器 key 材料與 shortId 等設定，不是單靠一般 WebPKI 信任鏈；設定分發管道是重要信任邊界。填充、外觀或 fingerprint 只改變部分可觀察特徵，不構成絕對不可辨識的保證。
Vision 是特定流程處理模式，不是 HTTP 代理協定，也不等同 TCP 的 rwnd/cwnd。特定平臺及條件下可減少重複封裝／資料複製，Linux splice 等最佳化需要實作條件；不能宣稱在所有系統、所有 payload 和所有 transport 都同樣有效。
相容性有三層：protocol↔transport、transport↔security、flow↔其餘條件。此次文件列 REALITY 可配 RAW、XHTTP、gRPC，不配 WebSocket；Vision 的 flow 是否適用仍須按指定核心、承載及 payload 條件另查。因此「每個欄位各自存在」不等於「任意組合可用」。具體執行前需固定核心版並用其 validator，不在本課假裝已部署驗證。
Vision 的 direct-copy 模式在符合內層 TLS 條件、完成切換後，可以繞過外層 TLS／REALITY 再加密，直接轉送已由內層 TLS 保護的記錄。此階段不能再畫成每個 byte 都有兩層加密；機密性依靠內層 TLS。非 TLS 或不符合條件的資料不能任意套用該結論。這是對此次原始碼與設計的分析，未在本課部署量測。
文件列 xtls-rprx-vision 可攔截 UDP/443 以促使應用改走 TCP HTTPS，另有-udp443 變體。分流與 QUIC 可用性需核對實際 flow 及應用 fallback，不能只看入口支援 UDP。
19.4 Trojan
Trojan 在 TLS 通道內傳代理認證與目的請求，服務端再轉送 TCP／UDP；TLS 提供資料保護，Trojan 請求格式提供代理語義。原 Trojan 的 UDP 在 TLS/TCP 串流承載，遺失時可受外層串流 HOL 影響，過期 UDP 仍可能晚到。名稱相同的原始 Trojan 與其他核心 transport 擴充可能不同，需查具體實作。密碼正確不能代替伺服器憑證／名稱驗證；fallback 網站也不是對所有主動探測的普遍防護。
19.5 完整分類例題
候選 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 相容表不支援此組合，不能當有效設定。候選 C：TUN＋WireGuard。TUN 只是 IP 介面，真正的 IP 隧道保護來自 WireGuard；它不屬候選 A 的同層替代欄位。
例題是分類模型，不是可直接執行的 JSON 模板。若讀者安裝其他核心，先用該版官方 schema 重建，再於隔離環境驗證；不要把教學概念表貼進生產服務。
延伸：AnyTLS 與 NaïveProxy
AnyTLS 參考專案處理 TLS 通道中的代理資料、填充及連線重用；NaïveProxy 使用 Chromium 網路堆疊及 HTTP/2／3 CONNECT 等機制。前者的 padding 與 session 策略、後者的瀏覽器堆疊及 HTTP 承載都屬實作／協定設計，不能排在 TUN／系統 proxy 的「接管方式」欄。
兩者都需分析 TLS 驗證、出口目的、重用造成的共享狀態和資源。參考程式的預設／示例不一定是理想部署設定。瀏覽器外觀相近也不能由此推出匿名或無法封鎖；效能結論需同條件測量。
實驗、習題與檢核
L14 逐欄分類，L10 計算多層開銷預算。
- VLESS、TLS、Vision、TUN 分別屬什麼角色？
- 新 VLESS Encryption 為何需和 encryption:none 分開教？
- 若某 transport 能用 REALITY，是否一定能用所有 Vision 設定？
- 完整 TLS 驗證與 padding 各解決什麼問題？
檢核：任何效能或安全主張都能指出版本、組合、端點與條件。來源：VLESS 設定、Xray transport 相容表、Trojan 協定、AnyTLS、NaïveProxy。另見 Vision 設計、VisionReader/Writer 與 UnwrapRawConn、REALITY 設定。文件查閱 2026-10-03，第三方核心未在本課實測。