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

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

關鍵要點

VLESS、REALITY、Vision、傳輸、路由及 TUN 擷取屬於不同層。

比較憑證或線路行為前，必須先確認 Shadowsocks 是傳統 AEAD 還是 2022 版本。

REALITY 伺服器認證與 VLESS 用戶授權發生於不同階段。

兩邊都要有明確的擷取及路由方案，才可形成全機涵蓋。

應選擇團隊能版本化、觀察及恢復其組件邊界的完整堆疊。

VLESS Reality 與 Shadowsocks 在哪些方面不同？

維度	VLESS plus REALITY	Shadowsocks
系統模型	採用 VLESS `decryption: none` 及 REALITY 數據流安全的 Xray 基準堆疊；VLESS Encryption 是不納入本次比較的另一設定	傳統 AEAD 與 2022 版本具有不同線路格式及密鑰規則的代理協議系列
流量入口	本機 Xray 入站接收應用程式流量；廣泛涵蓋另需路由或 TUN	應用程式連接本機代理；廣泛涵蓋另需 TUN 或截取層
信任材料	VLESS 用戶 ID、REALITY 密鑰參數、伺服器名稱及 short ID	所選 Shadowsocks 版本定義的密碼、方法或密鑰規則
外層載體	另選 Xray 傳輸，由 REALITY 提供數據流安全	所選版本的 TCP 格式及支援時的 UDP 中繼
設定證據	入站、傳輸、REALITY、Vision、路由及出站	版本、方法、密鑰、UDP、擷取及繞過規則

VLESS、REALITY、XTLS Vision、所選傳輸及本機 TUN 是不同組件；把它們合稱為一個協議會掩蓋重要故障邊界。［1］［2］

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

兩邊通常都從代理堆疊開始，而非原生第三層 VPN 介面。涵蓋範圍取決於本機入站及其接入方式：應用程式可以指向 SOCKS/HTTP 代理，也可由獨立 TUN 或攔截組件擷取更廣的流量。比較時必須列出這個組件，否則「VLESS 涵蓋」或「Shadowsocks 涵蓋」會掩蓋真正選擇流量的規則。

對這組方案，應分別記錄 Xray 入站、VLESS 所選外層傳輸及路由規則，以及 Shadowsocks 的本機代理、協議版本和 UDP 支援。單一應用程式的 TCP 請求成功，不能證明 UDP 可用或全機流量已涵蓋；IPv4、IPv6、DNS 與區域網絡例外都要作為獨立分支驗證。［1］［3］

範圍檢查點

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

VLESS REALITY 分層如何改變身份與信任？

VLESS 用戶身份獨立於 REALITY 的伺服器私鑰及客戶端公開參數；Shadowsocks 則按所選版本的方法與憑證定義授權及加密行為。不能把這些欄位統稱為「密碼」，否則既看不出哪個組件拒絕連線，也無法判斷應輪換哪項資料。［1］［2］［3］［4］

這組堆疊的拒絕訊號必須對應具體組件：先判斷所選傳輸能否建立，再判斷 REALITY 伺服器認證、VLESS 用戶授權或 Shadowsocks 密鑰核對是否失敗，最後檢查路由及目的地。日誌只記錄階段與非敏感識別資料，不能寫入 UUID、密碼、私鑰或 short ID。［1］［2］［3］

信任檢查點

應為 VLESS + REALITY 與 Shadowsocks 的精確組合分別建立憑證資料清單。VLESS 身份、REALITY 密鑰資料、short ID、傳輸設定及 Shadowsocks 憑證資料仍是不同設定項目。同時記錄哪一方認證哪一方、每項秘密或公開參數如何發放及輪換，以及哪項日誌事件能區分傳輸安全失敗與代理授權失敗。欄位名稱相似，不代表信任模型相同。

Shadowsocks 協議版本如何影響傳輸行為？

比較外層行為時，要寫明 VLESS 選用了哪種 Xray 傳輸、REALITY 採用哪些公開參數，以及 Shadowsocks 是經典 AEAD 還是 2022 版。觀察者仍可能看到地址、連接埠、時序及回應；任何項目的抗識別目標都不能取代對目前版本、設定與網絡的實際驗證。

速度測試應固定本機擷取範圍、目的地、端點位置、位址族、負載及時段，同時記錄 Xray 的傳輸與 flow，以及 Shadowsocks 的版本和 UDP 模式。否則結果可能主要反映 TUN 規則、傳輸選擇或版本不符，而非兩種代理設計本身。

傳輸檢查點

應把外層連線與內層應用程式流量分開觀察。REALITY 提供數據流安全，但不決定所有外層傳輸；Shadowsocks 行為必須連結至傳統 AEAD 或 2022 規格。測試應涵蓋建立連線失敗、IPv4 與 IPv6、對 MTU 敏感的傳輸、依賴 UDP 的應用程式，以及路徑切換後的恢復。不能單憑連接埠、加密或項目目標推斷速度及抗識別效果。

代理路由接入及營運會有甚麼改變？

VLESS 加 REALITY 的路由由 Xray 設定及本機入站共同決定；Shadowsocks 則依賴應用程式代理、系統代理或額外 TUN 接入。應為每一層指定維護者，分別檢查 DNS 與私人網絡例外，並確認客戶端結束後不會遺留可令流量繞過預期路徑的規則。

版本兼容尤其重要：VLESS 選項、REALITY 參數、Vision flow 及傳輸能力必須在所選 Xray 客戶端之間一致；Shadowsocks 兩端則必須使用相同協議版本與方法。每次只回復一個具名層，並保留上一份可用組件圖，不應一次同時替換多項憑證及傳輸。

營運檢查點

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

如何按實際需要作出選擇？

只有當需要確實受益於其分開的代理身份與串流保安設計，而且受支援的客戶端提供所需的傳輸和 flow 時，才選擇 VLESS 加 REALITY。所選版本和較簡單的代理整合已能符合流量政策時，選擇 Shadowsocks。兩種情況下，只要某個方案的本機擷取、UDP 行為、位址族支援或復原工具未能符合必要要求，便應否決。

結論應寫出完整的勝出設定，而不只是「REALITY」或「Shadowsocks」。保留 Xray 的傳輸和 flow、Shadowsocks 版本、擷取方式、路由、版本號及失敗階段的證據。這份記錄令之後的改動可以覆核，也能防止一個項目名稱變成有關保安或可達性的無根據說法。［1］［2］［3］［4］

選擇檢查點

實際選擇必須附帶條件。先確定需要的是 Xray 分層堆疊，還是邊界較小的 Shadowsocks 代理，再驗證具體接入方式。任何無法滿足平台、位址族、流量範圍、外層傳輸或信任要求的候選都應先淘汰；其餘方案再於相同端點及負載下比較結果分佈和故障恢復，不能把一次速度測試寫成永久排名。

故障演練應證明甚麼？

應畫出實際組件鏈，而不是測試一個組合標籤。VLESS plus REALITY 要分別記錄本機入站、VLESS 用戶 ID、可選 flow、REALITY 密鑰與 short ID、所選傳輸、路由規則和出站；Shadowsocks 則記錄版本、方法、密鑰資料、UDP 支援和本機擷取方式，再把每個故障對應到具體環節。［1］［2］［3］［4］

為流量擷取、DNS、傳輸建立、REALITY 伺服器認證、VLESS 或 Shadowsocks 授權及目的地連線設定獨立成功訊號。這樣不會把 REALITY 當作傳輸、把 Vision 當成獨立協議，或把所有 Shadowsocks 版本當成同一線路格式。

重新啟動客戶端並每次只輪換一種憑證資料，確認舊狀態已清除；日誌應指出失敗層，同時不得輸出 UUID、密碼、私鑰或 short ID。

VLESS/REALITY 與 Shadowsocks 的比較能否描述 AethoVPN？

如果你不想自己維護這兩套方案，可以在自建方案表現欠佳的那個網絡上，把 AethoVPN 當作託管對照：安裝客戶端，選擇負載指示為綠色的位置，把連線耗時和斷線情況記在你先前比較的那套方案筆記旁邊。AethoVPN 沒有公開任何資料把它的連線對應到 VLESS 加 REALITY 的分層組合或某個 Shadowsocks 版本，所以這份紀錄比較的是你網絡上的結果，而不是協議堆疊。以電郵開始 3 天免費試用，收集這組對照數據。

總結

VLESS 授權與 REALITY 伺服器認證是兩項獨立檢查。
傳輸、Vision flow、路由及 TUN 擷取仍是獨立的 Xray 選擇。
Shadowsocks 比較必須明確傳統 AEAD 或 2022 版本。
兩邊的全機行為都由接入層實現。
最終應選擇完整、可版本化的組件圖，而非協議暱稱。

常見問題

REALITY 是 VLESS 使用的傳輸嗎？

不是。REALITY 在這個堆疊中提供串流安全；所選傳輸、VLESS 身份、Vision flow、路由和本機擷取仍是獨立設定。

經典 AEAD Shadowsocks 與 Shadowsocks 2022 能互換嗎？

不能。兩者的密鑰、工作階段和重播規則不同，必須記錄客戶端與伺服器共同支援的準確版本。

哪項訊號能證明 REALITY 成功而 VLESS 失敗？

應分別記錄經遮罩處理的 REALITY 伺服器認證與 VLESS 用戶授權結果。籠統的「認證失敗」無法指出需要修復的設定項目。

同一項 TUN 規則可原樣套用於兩套堆疊嗎？

只有核對入站目標、繞過清單、DNS 路徑、IPv4/IPv6 行為及清理邏輯後才可以。代理協議不會代你驗證這些本機規則。

比較記錄應列出哪個 Shadowsocks 版本？

必須記錄兩端實際實現的版本。傳統 AEAD 與 Shadowsocks 2022 的密鑰、工作階段及重播語義不同，不能互換。［3］［4］

最小的安全升級單位是甚麼？

每次只改變一個具名層：客戶端版本、傳輸、REALITY 參數、VLESS 用戶資料，或 Shadowsocks 版本與憑證；同時保留上一份組件圖作回復用途。

適配報告至少要包含甚麼？

應包含完整組件圖、擷取範圍、位址族、UDP 行為、端點、各階段失敗數、憑證輪換及回復結果，不能只以協議名稱作勝負結論。

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

來源：

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
Shadowsocks, Protocol: https://github.com/shadowsocks/shadowsocks-org/wiki/Protocol
Shadowsocks 2022 Edition specification: https://github.com/Shadowsocks-NET/shadowsocks-specs/blob/main/2022-1-shadowsocks-2022-edition.md

Sources checked 2026 年 9 月 13 日。

延伸閱讀：

VLESS Reality 與 Shadowsocks：主要分別