Umbra 與主流代理方案比較

概覽

選代理方案，先看它是否適合你的網路、應用程式和維護方式，而不是演算法數量或測試覆蓋率。Umbra 的定位是自建隱私傳輸：把真實站點掩護、TCP/Vision、QUIC 與本地 SOCKS5 入口整合在一套用戶端和伺服器端裡。

比較範圍： Umbra 1.0.0-alpha；其他專案以 2026-09-16 查閱的官方資料為準。這是功能與部署方式對照，不是速度測試、安全排名或匿名性保證。後續版本和不同用戶端可能改變具體行為。

Xray 是支援多協議與路由的代理平台；VMess、VLESS 和 Trojan 是協議。為了可比，下文將 Xray 明確限定為常見的 VLESS + REALITY + Vision，RAW/TCP 外層。不能把一種設定的限制說成整個 Xray 的限制。

選型速覽

優勢與侷限

這裡的每個方案都有各自適合的情境和代價。下面的清單濃縮了各方案的優勢與侷限，方便你按自己的網路條件和維護意願來匹配。

• Umbra — 優勢：一個入口同時承載兩條路徑（TCP Vision 與 QUIC UDP），用戶端只需設定一個本地 SOCKS5 節點；身分金鑰與臨時憑證綁定免去了公網憑證的申請和續期；掩護、傳輸與 SOCKS5 以一套經過測試的用戶端和伺服器端整體交付。侷限：目前為 alpha 且僅有 CLI；不能匯入 VLESS、VMess 或 Trojan 節點；版本間的協議變化要求兩端同步升級。
• Xray + VLESS + REALITY + Vision — 優勢：成熟的多協議平台，路由能力豐富、現成用戶端多、社群說明文件完善；REALITY 和 Vision 在這裡同樣可用。侷限：整套堆疊要自己組裝和維護——核心設定、傳輸層、路由規則和匹配的用戶端；共享機制不等於與 Umbra 互通。
• VMess AEAD — 優勢：各平台用戶端覆蓋很廣，包括較舊和低效能裝置。侷限：協議負責加密，偽裝要另加——掩護完全取決於你疊加的傳輸層；舊的非 AEAD 模式已淘汰，請選用實作 AEAD 的用戶端。
• Trojan（原始 TLS 方案） — 優勢：真實 TLS 握手，回落行為有文件說明，設計多年穩定。侷限：常見部署要維護網域並續期公開可信的憑證；UDP 封裝在 TLS over TCP 內，UDP 時延跟隨 TCP 路徑。
• Shadowsocks AEAD / 2022 — 優勢：元件最少——金鑰加匹配用戶端即可，無需網域或憑證；原生支援 TCP 和 UDP。侷限：基礎協議提供加密而非偽裝，需要掩護時外掛要單獨評估；不能把僅轉發 TCP 的 SIP003 外掛當成 UDP 偽裝。
• Hysteria 2 — 優勢：面向有損網路設計的不可靠資料報 UDP 路徑，壅塞控制針對惡劣條件調校；未認證時表現為 HTTP/3 網站。侷限：UDP 被封鎖或受限時失去主要優勢；TCP 仍以 QUIC 串流承載，丟包同樣可能阻塞串流，其設計也不保證在你的網路上更快。

Umbra 值得考慮的地方

把兩條傳輸路徑放進一個入口

一個 Umbra 用戶端可以設定 transport = "tcp"、udp_transport = "quic"、mux = false，讓 TCP 使用 Vision、UDP 使用 QUIC；同一個伺服器端同時開放 TCP 與 UDP。現有用戶端只連線一個本地 SOCKS5 節點，不必把兩條路徑拆成兩套 Umbra 行程。

這是設定和使用上的便利，不代表其他平台無法透過不同出站或路由達到相近效果。Umbra 不會自動判斷哪條路徑最快，也不提供自動 TCP/QUIC 故障切換。

減少符合條件流量的重複處理

TCP/Vision 在完成認證邊界交換後，可以直接轉發符合條件的內層 TLS 1.3 加密記錄，省去後續外層 TLS 加密與額外封裝。非 TLS 和不支援的 TLS 仍保持加密。TCP mux 則讓多個請求共用外層連線，減少重複建立連線的需求。

REALITY 和 Vision 都不是 Umbra 獨有的概念，不能用它們聲稱全面優於 Xray。這裡是使用者態轉發，不是核心零複製；沒有統一環境下的競品基準測試，就不寫「更快多少」。

不必自行維護節點的公網憑證

Umbra 使用身分金鑰和臨時憑證綁定，部署時不要求自己申請或續期公網 CA 憑證。你仍要管理伺服器端秘密、用戶端認證資料和可存取的真實目標站點。啟用 QUIC 時還要滿足真實 QUIC 回落與 UDP 可達性要求。

同樣，REALITY 組合也能減少這類憑證維護，Shadowsocks 原生部署也不依賴網站憑證。這是一種部署取捨，不是 Umbra 獨佔的優勢。

按現有方案判斷是否遷移

• 已經使用 Xray / VLESS / REALITY： 若依賴多協議、複雜路由與現有用戶端生態，不必只為同類掩護機制遷移。選擇 Umbra 的理由應是它的單一執行個體雙傳輸方式適合你的使用，而不是「REALITY 更高級」。
• 已經使用 VMess： 先確認實際是何種 TLS、WebSocket 或其他承載。不能僅憑 VMess 名稱推斷明文、缺少偽裝或無法傳輸 UDP。Umbra 不能直接匯入 VMess 節點。
• 希望維護標準 TLS 服務： Trojan 的真實 TLS 和回落有明確部署方式；不要把它描述成沒有探測抵抗。它與 Umbra 的區別包括憑證維護和 UDP 承載路徑。
• 只需要輕量加密代理： Shadowsocks 可能更貼近需求。AEAD 與 2022 應按版本討論，2022 包含完整重放保護；外掛能力不等於基礎協議能力。
• 主要考慮 QUIC 與有損網路： 可以同時評估 Hysteria 2。它的 UDP 使用不可靠資料報，Umbra 目前把 UDP 關聯資料封裝在可靠 QUIC 串流內；丟包時同一串流仍可能等待重傳，不能宣傳「所有 UDP 都沒有隊頭阻塞」。是否更適合遊戲、通話或下載，需要實際路徑測試。
• 需要成熟圖形介面、行動端或現成訂閱： 先確認具體用戶端與版本。Umbra 目前是 CLI 傳輸工具，可接入支援 SOCKS5 的規則用戶端，但不自帶這些生態能力。

已實作的連線流程

1. 建立外層握手。 TCP 用戶端自行建構 TLS 1.3 ClientHello 與記錄；原生 QUIC 使用 Quinn。認證資料與 ClientHello 綁定，放入 legacy_session_id。
2. 判斷連線身分。 伺服器端在選擇認證傳輸路徑前檢查資料；未認證連線走設定的真實目標。用戶端驗證臨時憑證的綁定資訊，避免把一般真實站點當成 Umbra 伺服器端。
3. 傳輸應用程式請求。 認證後的連線根據模式承載位址、串流與填充；Vision 只在滿足條件並完成協商後切換轉發方式。

真實站點回落不保證永遠無法識別。目標站點故障、網路條件、逾時及觀察者能力都會影響實際表現，伺服器 IP 也可能被直接封鎖。

瀏覽器指紋與後量子邊界

• chrome-latest 仍使用歷史 Chrome 150 設定檔。擴充順序、GREASE、JA3/JA4 檢查和 Chrome 153 實際取樣，均不能單獨證明與目前瀏覽器完整等價。
• ML-DSA-65 用於臨時憑證公鑰的簽章綁定，不意味著所有認證環節都變成後量子認證。
• 程式碼具有 X25519 + ML-KEM-768 混合交換路徑，但只有實際協商混合群組時才使用該共享秘密。目前標準 CLI 的目標探測使用不支援 ML-KEM 的 ring 提供者，伺服器端跟隨探測群組，因此不能宣稱預設連線已經啟用混合後量子交換。
• 目前 Xray REALITY 官方設定也包含可選 ML-DSA，以及與目標站點協商群組相關的混合交換支援。不能將後量子能力宣傳為 Umbra 獨有。
• 目前 Umbra 不支援 Geneva DSL 傳送、0-RTT 或回落預連線；協議設計中的規劃不等於現有產品能力。

官方比較依據

下列連結為本頁其他方案的依據，查閱於 2026-09-16。Umbra 的依據為本頁中繼資料所列的 README、使用指南、效能說明和執行程式碼。

• Xray：REALITY 官方範例（固定修訂）、REALITY 設定與後量子選項（固定修訂）、VLESS / Vision 設定、路由。
• VMess：V2Fly 協議說明、Xray 傳輸分層。
• Trojan：協議、TLS 與伺服器端設定。
• Shadowsocks：AEAD、2022 / SIP022、SIP003 外掛邊界。
• Hysteria 2：協議規範、伺服器端部署、用戶端模式。

下一步

• 判斷 Umbra 是否適合你
• 選擇傳輸模式
• 接入應用程式與既有用戶端
• 瞭解安全模型