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 より全面的に優れているとは主張できません。ここで行うのはユーザー空間での転送であり、カーネルのゼロコピーではありません。同一環境での競合ベンチマークがない以上、「どれだけ速いか」は示せません。

ノードの公開 CA 証明書を自分で保守しなくてよい

Umbra は認証鍵と一時証明書の暗号学的な結び付けを使うため、導入時に公開 CA 証明書を自分で取得・更新する必要がありません。ただし、サーバーの秘密情報、クライアントの認証情報、到達可能な実在の宛先サイトは引き続き管理する必要があります。QUIC を有効にする場合は、実在する QUIC フォールバック先と UDP の到達性という要件も満たす必要があります。

同様に REALITY を使う構成でも証明書の保守を減らせますし、Shadowsocks のネイティブな構成も Web サイトの証明書に依存しません。これは導入時のトレードオフの一つであり、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 も併せて評価できます。Hysteria 2 の UDP は信頼性を保証しないデータグラムを使う一方、現在の Umbra は UDP アソシエーションのデータを信頼性のある QUIC ストリーム内にカプセル化します。損失時には同一ストリーム内で再送を待つ可能性があるため、「すべての UDP でヘッドオブラインブロッキングがない」とは宣伝できません。ゲーム、通話、ダウンロードのどれに向いているかは、実際の経路でテストする必要があります。
• 成熟した GUI、モバイル対応、利用可能なサブスクリプションが必要： まず具体的なクライアントとバージョンを確認してください。現在の 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 が自分に合うか判断する
• トランスポートのモードを選ぶ
• アプリと既存クライアントを接続する
• セキュリティモデルを理解する