VLESS Reality 與 Hysteria2 不能簡化為一場速度排名。VLESS plus REALITY 與 Hysteria2 的系統模型、流量入口、信任關係及營運責任並不相同，正確選擇應從需要解決的問題出發。［1］［2］［3］

完整 VPN 指南解釋通用隧道模型。本文把判斷限定於精確協議版本及實際部署堆疊。

關鍵要點

VLESS + REALITY 側重分層授權與數據流安全；Hysteria2 把傳輸基礎固定為 QUIC。

Hysteria2 在 HTTP/3 認證後提供 TCP 及 UDP 代理命令。

QUIC 數據報及擠塞控制處理傳輸問題，但不保證速度勝出。

外層 UDP 可達是 Hysteria2 的必要前提。

應比較實際量得的封包遺失、路徑變更或握手責任，而非協議熱度。

如何一眼比較 VLESS Reality 與 Hysteria2？

維度	VLESS plus REALITY	Hysteria2
系統模型	採用 VLESS `decryption: none` 及 REALITY 數據流安全的 Xray 基準堆疊；VLESS Encryption 是不納入本次比較的另一設定	建基於 QUIC、提供 TCP 與 UDP 代理指令並採用 HTTP/3 認證語義的協議
流量入口	Xray 入站接收應用程式流量；廣泛涵蓋另需路由或 TUN	Hysteria2 客戶端提供代理或擷取接入
信任材料	VLESS 用戶 ID、REALITY 密鑰、伺服器名稱、short ID	QUIC/TLS 伺服器信任、HTTP/3 認證資料
外層載體	另選 Xray 傳輸，由 REALITY 提供數據流安全	UDP 上的 QUIC；外層 UDP 不可用便無法連線
數據及失敗重點	分開觀察傳輸、REALITY、VLESS、路由及出站	TCP 用 QUIC 流，UDP 用不可靠數據報；量度丟包及分片

Hysteria2 以 QUIC 為傳輸核心，但這項設計目標不等於所有路徑都更快；REALITY 同樣不能固定描述為一種傳輸。［2］［3］［4］

兩種設計分別涵蓋哪些流量？

兩邊都需要本機入站或擷取接入，應用程式才可使用。Hysteria2 的 TCP/UDP 代理命令說明已認證連線可承載甚麼，並不自動決定裝置上哪些程式會被擷取；VLESS + REALITY 同樣把本機入站、路由及所選外層傳輸保留為獨立設定。［1］［3］

Hysteria2 的外層固定為 UDP 上的 QUIC：應用程式 TCP 使用串流，代理 UDP 使用不可靠數據報；VLESS 加 REALITY 的外層傳輸則另行選擇。記錄時要同時寫清內層業務、外層 UDP 可達性、本機擷取方式、DNS 與位址族；一個 QUIC 連線成功並不能證明所有應用程式都已涵蓋。［1］［3］

範圍檢查點

比較 VLESS + REALITY 與 Hysteria2 時，先畫出實際入口路徑：應用程式、流量擷取機制、路由、DNS、出站及目的地。記錄每項規則由誰安裝，並為每個預期分支選一個已知目的地覆測。這樣，涵蓋範圍便由產品名稱變成可觀察證據，也能分清原生 IP 介面、明確代理及額外 TUN 接入。

身份與信任模型有何不同？

Hysteria2 在 QUIC/TLS 建立後透過 HTTP/3 請求認證，伺服器以 HTTP 狀態表示接受或拒絕。VLESS + REALITY 則把 VLESS 用戶與 REALITY 伺服器認證資料分開。監察時必須區分這些順序，因為 HTTP 認證拒絕並不等於 REALITY 或 VLESS 拒絕。［1］［2］［3］

Hysteria2 的診斷次序應區分外層 UDP、QUIC/TLS、HTTP/3 認證、代理串流或數據報與目的地；VLESS 加 REALITY 則要分開所選傳輸、REALITY 伺服器認證及 VLESS 用戶授權。日誌應指出具體階段但隱藏認證資料，否則同一個「認證失敗」無法指導恢復。［1］［2］［3］

信任檢查點

應為 VLESS + REALITY 與 Hysteria2 的精確組合分別建立憑證資料清單。VLESS 與 REALITY 參數不同於 Hysteria2 的認證及證書信任，即使同一客戶端同時提供兩者。同時記錄哪一方認證哪一方、每項秘密或公開參數如何發放及輪換，以及哪項日誌事件能區分傳輸安全失敗與代理授權失敗。欄位名稱相似，不代表信任模型相同。

Hysteria2 QUIC 傳輸與 VLESS REALITY 傳輸選擇有何不同？

Hysteria2 明確使用 QUIC over UDP，測試時可觀察 QUIC 建立、串流、數據報、封包遺失及路徑切換；VLESS 加 REALITY 則必須先寫明所選外層傳輸。加密不會隱藏地址、連接埠、時序與封包長度，這些可見特徵亦不能單獨證明某一方案在所有網絡都較快或無法識別。

Hysteria2 會交換接收速率資料，並可用 BBR 或 Cubic 等擠塞控制算法調整傳送；其 UDP 代理路徑會為 QUIC 數據報分片，任何分片遺失都會丟棄完整的代理 UDP 封包。這些機制值得在弱網絡測試，但結果仍受路徑、速率設定、端點、負載及實現影響。［3］

傳輸檢查點

應把外層連線與內層應用程式流量分開觀察。Hysteria2 基於 QUIC over UDP 提供 TCP 與 UDP 代理指令；REALITY 是數據流安全選擇，本身並不固定某種傳輸。測試應涵蓋建立連線失敗、IPv4 與 IPv6、對 MTU 敏感的傳輸、依賴 UDP 的應用程式，以及路徑切換後的恢復。不能單憑連接埠、加密或項目目標推斷速度及抗識別效果。

路由及營運責任如何改變？

Hysteria2 需要明確誰維護擷取規則、QUIC 連線、代理串流、數據報及路徑切換後的恢復；VLESS 加 REALITY 則要分別落實 Xray 入站、所選傳輸、路由與出站的負責人。兩邊都應在故障後複查 DNS、私人網絡例外及殘留規則，但不能把這些路由問題誤判為 QUIC 封包遺失。

容量及可觀察性也有分別。Hysteria2 應監察 QUIC 連線、數據流建立、數據報遺失、速率設定與擠塞行為；Xray 一側則要跨傳輸建立、REALITY 認證、VLESS 用戶、路由及出站定位問題。應比較能夠實際部署的監察，而非設定鍵數量。

營運檢查點

應把 VLESS + REALITY 與 Hysteria2 視為兩套有明確版本的系統來營運：固定客戶端與伺服器版本、列明設定擁有人、分階段變更，並保留可恢復路由與 DNS 的回復方案。比較監察、密鑰輪換、平台兼容及故障隔離，而不只是比較設定檔行數。

弱網代理何時可解決實際需要？

先寫出一份經過量度的問題陳述。如果需要評估 QUIC 在有丟包或不斷變化的路徑上的表現，而外層 UDP 可用，Hysteria2 直接回應這個傳輸問題。如果需要的是分開的 VLESS 授權與 REALITY 伺服器認證，並可選擇 Xray 傳輸，便應評估那一整套組合。無論哪種選擇，都仍須核實擷取範圍和目的地路由。

保留丟包條件、速率設定、擠塞控制器、外層 UDP 可達性、端點、工作負荷、客戶端／伺服器建置及復原觀察。對於 Xray 方案，還要保留所選的傳輸和 flow。這份記錄回答的是哪種設計解決了被測試的問題，而不會把一個環境變成通用的協議排名。［1］［2］［3］

選擇檢查點

實際選擇必須附帶條件。實測封包遺失路徑需要 QUIC 行為時考慮 Hysteria2；需要分層身份與握手設計時考慮 VLESS plus REALITY。任何無法滿足平台、位址族、流量範圍、外層傳輸或信任要求的候選都應先淘汰；其餘方案再於相同端點及負載下比較結果分佈和故障恢復，不能把一次速度測試寫成永久排名。

如果兩套方案你都不想自行營運，託管服務會改變選擇的問題本身。使用 AethoVPN 時，在 App 中選擇伺服器位置即可連線：Windows、Linux 和 Android 有安裝檔，iPhone 和 Mac 則在 Pro 或 Premium 計劃下透過官方設定精靈取得設定；把它放在與自建候選相同的獲准網絡和負載下運行，看它能否滿足你實測的需要。其公開文件沒有列明任何協議，所以這個結果不能說明 VLESS 加 REALITY 或 Hysteria2 的行為。可開始 3 天免費 Pro 試用，把它加入比較。

故障演練應證明甚麼？

對 Hysteria2，應分別觀察外層 UDP 可達性、QUIC 建立連線、HTTP/3 認證請求、TCP 代理串流、UDP 數據報和路徑切換後的恢復。代理 UDP 封包因使用 QUIC 不可靠數據報通道，過大時可能需要分段；規範要求任何分段遺失時丟棄整個封包。［3］［4］［5］

記錄設定的接收速率訊號，並確認何時由 BBR、Cubic 等擁塞控制決定傳送速率。這些機制說明為何需要實測丟包路徑，但不能保證 Hysteria2 在所有網絡勝出；UDP 過濾可能在負載傳輸前已阻止外層連線。［3］

VLESS plus REALITY 一方應先記錄獨立選擇的外層傳輸，再分別測試 REALITY 伺服器認證與 VLESS 授權。雙方必須使用相同應用程式流量和涵蓋範圍，否則流量擷取或路由差異會被誤寫成 QUIC 結果。［1］［2］

UDP 路徑可用，能說明服務用的是哪種設計嗎？

不能。UDP 路徑可用只表示外層 UDP 可達，並不能反映 Hysteria2 的 QUIC 認證，也不能反映 VLESS、REALITY 或 Xray 傳輸的任何階段。服務使用甚麼協議，應以它自己的文件為準；沒有列明的就視為未知，不要憑可達性推斷。

總結

Hysteria2 是外層必須使用 UDP 的 QUIC TCP/UDP 代理。
HTTP/3 認證、數據流、數據報及擠塞行為構成其傳輸導向設計。
VLESS + REALITY 將用戶授權、伺服器認證與所選 Xray 傳輸分開。
封包遺失處理機制必須實測，不能推導出通用速度結論。
應選擇能解決已觀察路徑或握手問題並可營運恢復的完整堆疊。

常見問題

外層 UDP 被阻擋時 Hysteria2 能運作嗎？

其協議建立在 UDP 上的 QUIC，因此外層路徑被阻擋會令 Hysteria2 無法建立連線。［3］［4］

QUIC 能保證 Hysteria2 更快嗎？

不能。封包遺失、速率設定、擠塞控制、端點、過濾、CPU 和負載都會改變結果，應比較等價應用程式流量。

Hysteria2 的 UDP 負載像 TCP 數據流一樣可靠嗎？

不是。代理 UDP 封包使用不可靠的 QUIC 數據報；Hysteria2 可把大封包分片，任何分片遺失都會令整個代理封包被丟棄。［3］

Hysteria2 的 HTTP/3 認證證明了甚麼？

它證明伺服器接受該 QUIC 連線的認證請求，不能證明本機擷取、DNS、遠端連線或其後每項代理命令均正常。［3］［5］

哪些指標可檢驗弱網絡假設？

在受控封包遺失與速率設定下，記錄建立連線成功率、吞吐分佈、延遲、數據報遺失、路徑切換恢復及資源使用；一次峰值吞吐不足以得出結論。

REALITY 可按定義直接放到 Hysteria2 的 QUIC 上嗎？

不能這樣推導。REALITY 與 Xray 傳輸是獨立設定概念，Hysteria2 則定義自己的 QUIC 協議；只可比較受支援的完整實現。

哪些情況應在速度測試前淘汰 Hysteria2？

所需網絡沒有可用外層 UDP、客戶端缺少所需擷取模式，或團隊無法觀察及恢復 QUIC 與認證階段時，便應先淘汰它。

免責聲明：本文只提供架構層面的通用資訊，並非效能基準，也不保證在任何網絡上均可使用。

來源：

Project X, VLESS inbound configuration: https://github.com/XTLS/Xray-docs-next/blob/main/docs/en/config/inbounds/vless.md
XTLS REALITY, README: https://github.com/XTLS/REALITY/blob/main/README.en.md
Hysteria 2, Protocol specification: https://v2.hysteria.network/docs/developers/Protocol/
RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport: https://www.rfc-editor.org/rfc/rfc9000
RFC 9114, HTTP/3: https://www.rfc-editor.org/rfc/rfc9114

Sources checked 2026 年 9 月 13 日。

延伸閱讀：

VLESS Reality 與 Hysteria2：分別解決甚麼問題？