截至2026年，VLESS仍是輕量、無狀態的代理協議，但「VLESS本身沒有加密」已不是完整描述。Xray-core現已提供可選的VLESS Encryption；實際部署還可按威脅模型搭配TLS、REALITY、XTLS Vision、XHTTP與XUDP。這些技術各自處理不同問題，不能混為同一個「協議」。

資料口徑：本文核對Project X、Xray-core、sing-box與AnyTLS的一手文件。GitHub PR／Discussion反映維護者的設計與實作說明，不等同獨立安全審計。文中「對SingLink的參考」也不是星連VPN已採用相關技術的產品聲明。

一、一張清單看懂現代VLESS技術棧

  • VLESS：身份、連線指令與目標地址的輕量協議層。

  • VLESS Encryption：Xray-core現行的可選協議負載加密層。

  • TLS 1.3／REALITY：外層傳輸安全、身份驗證與網絡外觀。

  • XTLS Vision：流控與資料路徑最佳化，不是另一種加密算法。

  • RAW／XHTTP／gRPC／WebSocket：承載VLESS資料的傳輸方式。

  • XUDP：Xray生態中的UDP封裝選項。

  • XMUX／其他MUX：讓多個邏輯請求共用底層連線的機制。

  • Padding／FinalMask／Browser Dialer：處理長度、時序、最外層傳輸參數或真實瀏覽器網絡棧。

因此，常見連線可以抽象為：應用流量 → VLESS身份與目標 → 協議／外層安全 → Vision流控 → RAW或XHTTP等傳輸 → TCP或UDP網絡。並非每種組合都需要或兼容所有模組。

二、VLESS基礎協議負責甚麼？

Project X VLESS文件把VLESS定義為輕量、無狀態的傳輸協議；它不依賴系統時間，身份驗證使用UUID或映射後的ID。公開的Xray-core編碼實作顯示請求會攜帶版本、用戶ID、附加資料、命令、目標端口、地址及後續資料。

最簡單的理解是：VLESS核心回答「我是誰、要建立甚麼連線、要前往哪個地址」。智能選路、節點負載、套餐權限及用戶端自動重連通常屬於更高層的產品或控制系統。

傳統配置常見`encryption: "none"`。官方文件現在明確要求：除非對端位於可信私有網絡，否則必須使用外層傳輸安全，或啟用VLESS Encryption。

三、VLESS Encryption改變了甚麼？

VLESS Encryption是Xray-core在2025年合併的可選原生加密層。合併PR #5067與現行VLESS配置文件列出`mlkem768x25519plus`握手、`native`／`xorpub`／`random`流量外觀、`1rtt`／`0rtt`會話模式及可變Padding。

設計目標與證據邊界

  • 以ML-KEM-768與X25519組合建立會話密鑰；

  • 讓協議負載在沒有外層TLS時仍可受保護；

  • 用Ticket支援後續0-RTT恢復，並以短期狀態降低重放風險；

  • 用可變Padding與可選XOR模式調整固定長度或公鑰外觀。

上述是Xray維護者公開的設計與實作說明；本文沒有找到一份可證明所有安全性主張的獨立密碼學審計，因此不使用「完美防重放」或「絕對抗量子」等表述。

它不能自動取代甚麼？

VLESS Encryption保護協議負載，但不會自動產生普通HTTPS網站的握手、證書、HTTP／2或HTTP／3行為，也不自動解決CDN兼容。因此它不等於TLS或REALITY。

四、TLS 1.3與REALITY有何分工？

TLS提供標準證書驗證、密鑰交換、完整性與傳輸加密。它可搭配RAW、XHTTP、gRPC、WebSocket等傳輸；實際TLS版本、ALPN及證書驗證仍取決於配置和對端能力。

REALITY官方文件則描述一種經修改的TLS式安全層，配置包含目標、serverNames、X25519密鑰與shortId；目前亦有可選ML-DSA-65驗證資料。REALITY可與RAW、XHTTP及gRPC配合。

REALITY的價值不應簡化成「免證書」。它同時涉及合法客戶端身份驗證與對外握手外觀。其效果仍受目標、客戶端指紋、傳輸方式及部署品質影響，不能保證對所有識別方法不可見。

五、XTLS Vision不是加密協議

VLESS／Vision文件把Vision列為flow control。符合條件時，它可辨識內層TLS流量，減少額外加解密或資料複製；在Linux、TCP及相容路徑下，核心會嘗試使用splice讓內核直接轉移資料。

因此較準確的說法是：TLS／REALITY／VLESS Encryption處理安全，Vision處理資料如何更有效率地穿過代理層。並不是所有作業系統、傳輸或流量都能使用splice。

六、XHTTP的三種模式

XHTTP維護者設計說明把XHTTP描述為可在HTTP／1.1、HTTP／2及HTTP／3環境中承載流量的傳輸體系，並提供三種主要模式：

  • packet-up：上行拆成多個POST，下行使用持續回應；偏向中間盒與CDN兼容。

  • stream-up：上行流式POST、下行獨立流式GET；上下行仍分離。

  • stream-one：單一雙向流式請求；效率和兼容性取決於代理與中間盒。

XHTTP也可加入Header Padding、上下行分離和XMUX。是否能經過特定CDN，取決於模式、HTTP版本、反向代理限制與服務商配置，不能只寫成「XHTTP一定支援CDN」。

七、XMUX、傳統MUX與隊頭阻塞

XMUX是XHTTP的連線管理與多路復用機制，可控制並發請求、底層連線數、重用次數、壽命及保活。它的目標不是永遠只保留一條連線，而是在握手成本、併發與固定長連線特徵之間取捨。

sing-box Multiplex文件另外列出smux、yamux與h2mux。多路復用可以減少握手，但一條底層TCP連線的丟包或阻塞也可能影響多個stream。HTTP／3避免TCP層跨stream的隊頭阻塞，但單一QUIC stream仍會受丟包與重傳影響。

八、XUDP處理的是UDP封裝

sing-box VLESS文件把`xudp`列為VLESS的packet encoding選項，另有`packetaddr`及關閉額外封裝的模式。這足以證明XUDP是可配置的UDP承載方式，但不是一份完整、版本化的XUDP封包規格。

所以本文只作保守定義：XUDP讓UDP資料經代理通道傳送。實際會話、邊界、地址與遷移行為應以所用核心版本及程式碼為準，不把未有穩定規格支撐的細節寫成普遍標準。

九、Padding、FinalMask、ECH與Browser Dialer

  • Padding：改變長度或發送時序，不能代替加密。

  • FinalMask：官方配置顯示它位於外層傳輸處理階段，可配置TCP、UDP及QUIC相關參數；是否使用需視核心版本與實驗目的。

  • ECH：sing-box TLS文件提供Encrypted ClientHello配置，用於保護ClientHello中的部分資料；ECH不會取代VPN通道加密。

  • Browser Dialer：Project X文件讓真實瀏覽器建立TLS與HTTP連線，換取更完整的瀏覽器網絡行為，但會增加部署限制及性能成本。

十、Fallback能做甚麼，不能做甚麼？

Project X Fallback文件說明不匹配的SNI、路徑或協議流量可轉交Nginx、Caddy或正常網站，使同一入口同時承載代理與一般服務。

Fallback可避免認證失敗時直接回傳單一明顯錯誤，但它不是「主動探測免疫」。整體可識別性仍取決於TLS、傳輸、回應、時序和服務配置。

十一、AnyTLS是比較對象，不是VLESS元件

AnyTLS協議文件描述的流程是TCP → TLS → `SHA-256(password)`驗證 → Session → 多個Stream。Frame由Command、Stream ID、Data Length與Data組成，並包括SYN、PSH、FIN、Settings、Padding、心跳及version 2的SYNACK等命令。

AnyTLS的Session、多stream、動態Padding與健康檢測值得比較，但它是一套獨立協議。把它列入本文是為了說明不同設計取捨，不代表VLESS會自動包含AnyTLS能力。

十二、常見組合應如何理解？

  • VLESS + REALITY + Vision + RAW：偏向直連性能與TLS式外觀；不依賴CDN。

  • VLESS + TLS／REALITY + XHTTP：偏向HTTP承載、反向代理與條件式CDN兼容。

  • VLESS Encryption + Vision：在協議層保護負載，可用於中轉或非標準外層安全場景，但不自帶普通HTTPS外觀。

  • VLESS + TLS + XHTTP + Browser Dialer：使用真實瀏覽器網絡棧，部署與資源成本較高。

  • AnyTLS + TLS：採用獨立Session／stream與Padding設計，不是VLESS組合。

沒有一套配置能同時在性能、兼容、可維護性、外觀與安全上永遠最佳。選型需要先定義威脅模型、網絡路徑、CDN／代理限制、用戶端平台和可觀測性要求。

十三、對SingLink協議研究的參考邊界

VLESS與AnyTLS公開資料可為身份、密鑰交換、會話、stream、UDP、Padding、多路復用、恢復與版本協商提供設計參考。然而，本文沒有證據證明SingLink 2.0基於VLESS、REALITY、XHTTP或AnyTLS。

星連VPN應把已公開的功能、仍在研究的方向及尚未披露的核心實作分開標示。讀者可另參閱星連VPN開源計畫了解目前公開範圍。

十四、常見問題

VLESS本身會加密流量嗎？

傳統`encryption: "none"`不提供協議層負載加密，需要可信私網或外層安全。現行Xray-core可選VLESS Encryption，因此答案取決於具體實作與配置。

VLESS Encryption可以取代TLS或REALITY嗎？

不能直接等同。它保護VLESS負載，但不自動提供標準HTTPS證書、握手及網站外觀。

REALITY與普通TLS有甚麼不同？

普通TLS使用標準證書體系；REALITY是Xray的TLS式安全層，具有自己的目標、密鑰、shortId與客戶端驗證配置。

XTLS Vision負責加密嗎？

不是。Vision主要是流控與資料路徑最佳化；安全由TLS、REALITY或VLESS Encryption等層處理。

XHTTP三種模式如何選？

packet-up偏兼容，stream-up提供分離的流式上下行，stream-one使用單一雙向流；仍需按CDN、反向代理和網絡環境測試。

目前公開證據不足以證明這種關係。本文僅作技術比較及研究參考，不是產品實作聲明。

十五、結論與資料版本

現代VLESS是一個可組合技術棧：VLESS處理身份與目標，VLESS Encryption提供可選協議層保護，TLS／REALITY處理外層安全，Vision最佳化流控，XHTTP與XUDP負責承載，MUX、Padding及其他工具再處理連線與外觀。

原始發布日期：2026年5月20日。技術資料核對日期：2026年7月28日。由於相關核心仍持續更新，部署前應重新核對所用版本的官方文件、變更紀錄與相容性。