実在の接続先をカバーにする
REALITY 認証で自分の通信を区別し、未認証のリクエストは設定した実在サイトへ転送します。鍵と到達可能な TLS 1.3 サイトは必要ですが、ノード用 CA 証明書は不要です。カバーは検知されないことを保証しません。
仕組みと選び方
実在サイトによるカバー、Vision、通信方式の選択が接続にどう関わるかを確認できます。Umbra は自分で運用する CLI クライアントとサーバーであり、運用代行型のプロキシサービスではありません。
REALITY 認証で自分の通信を区別し、未認証のリクエストは設定した実在サイトへ転送します。鍵と到達可能な TLS 1.3 サイトは必要ですが、ノード用 CA 証明書は不要です。カバーは検知されないことを保証しません。
TCP mux は複数のストリームで接続を共有します。mux=false の場合、Vision は認証後、条件を満たす内側の TLS 1.3 通信に限り、重複する外側の暗号化を省きます。非 TLS 通信の暗号化は継続します。
通信方式は明示的に選択し、自動フェイルオーバーは行いません。QUIC には UDP の疎通と、到達可能な実在の QUIC フォールバック先が必要です。高速化や、あらゆるヘッドオブラインブロッキングの解消を保証するものではありません。
Umbra と Xray はソフトウェアプラットフォーム、VLESS・VMess・Trojan・Shadowsocks はプロトコル、REALITY と Vision は仕組みです。実際の動作は実装と設定で変わります。同条件の競合比較測定がないため、速度の順位付けはしません。ひとことで言えば、カバーと二つの転送経路と SOCKS5 を、自分で管理する一組の構成としてまとめて受け取りたいなら Umbra が向いており、各種エコシステムが必要なら他の選択肢が向いています。
REALITY、TCP mux/Vision、QUIC、SOCKS5 を統合したセルフホスト型の alpha です。クライアントとサーバーが一組として提供され、両端を自分で管理します。
最も近い選択肢です。REALITY と Vision はこちらでも使えるため、選択のポイントは独自技術ではなく梱包とワークフローにあります。
AEAD を使うプロキシプロトコルで、既存クライアントが対応している場合の選択肢です。TLS や WebSocket は追加の構成要素であり、暗号化の必須条件ではありません。
一般的な TLS 構成で運用したい方向けの、TLS ベースのプロキシプロトコルです。フォールバックの動作は実装と設定によって異なります。
シンプルな構成に適した軽量な暗号化プロキシです。ブラウザーの模倣や実在サイトによるカバーは、AEAD・2022 の基本プロトコルには含まれません。
QUIC を中心とし、独自の輻輳制御設計を持つ方式です。UDP が安定して通る環境で検討できます。