不安定で損失の多い回線や、検閲環境下でのプロキシ選定に悩んでいませんか。海外 VPS と自宅・モバイル回線の間でスループットが伸びない、深層パケット検査（DPI）に引っかかって接続が切られる──こうした問題に直面したとき、どのプロキシ OSS を選べばよいのか判断するのは簡単ではありません。
近年は QUIC（UDP 上で動く高速トランスポートプロトコル）をベースにしたプロキシが次々と登場し、TUIC・sing-box・Xray-core など選択肢が増えました。それぞれ設計思想が異なるため、「自分の用途にどれが合うのか」を見極めるには、各プロジェクトの中核となる技術的な違いを理解する必要があります。
そこで本記事では、QUIC と独自の Brutal 輻輳制御、HTTP/3 トラフィック偽装を一体で提供するプロキシ OSS「Hysteria 2」を取り上げます。GitHub で約 20,900 のスターを集める活発なプロジェクトで、損失の多いネットワークでのスループット維持を強みとしています。
Hysteria 2 の仕組み、類似する TUIC・sing-box・Xray-core との違い、そしてサーバー・クライアントの設定手順の見取り図を、公式ドキュメントの記述に基づいて解説します。読み終えたとき、Hysteria 2 が自分の用途に合うかどうかを判断できる状態を目指します。
なお本記事は公式ドキュメントと README の記述に基づいて構成しており、筆者環境での動作検証は行っていません。掲載するコマンド・設定例はすべて公式ドキュメントからの抜粋であり、実際に導入する際は最新の公式ドキュメントを確認してください。また、検閲回避を含むプロキシの利用可否は各国の法令・利用規約に依存します。本記事は技術として何ができるかを中立的に解説するものであり、用途の合法性判断は読者にゆだねます。
Hysteria 2とは──QUICで検閲を突き抜けるプロキシOSS
Hysteria 2 は、apernet が開発する「強力・高速・検閲耐性を備えたプロキシ（powerful, lightning-fast and censorship-resistant proxy）」です。カスタマイズした QUIC プロトコルを採用し、トラフィックを標準的な HTTP/3 通信に偽装することで、DPI による検出・ブロックを困難にしている点が大きな特徴です。
ソースコードは apernet/hysteria（GitHub リポジトリ） で公開されており、より詳しい仕様や使い方は Hysteria 公式サイト にまとまっています。
GitHubリポジトリ概要（スター数・言語・ライセンス・更新状況）
執筆時点（リポジトリメタデータ取得時）のリポジトリ概要は以下のとおりです。
項目 | 内容 |
|---|---|
リポジトリ | apernet/hysteria |
主要言語 | Go |
ライセンス | MIT |
スター数 | 約 20,900 |
フォーク数 | 約 2,100 |
最終更新（pushed_at） | 2026-05-10 |
アーカイブ状態 | アーカイブされていない（active） |
フォークリポジトリか | いいえ（オリジナル） |
スター数が約 2 万に達し、フォークも約 2,100 ある点から、コミュニティの関心が高く採用実績のあるプロジェクトといえます。最終更新が比較的新しく、リポジトリはアーカイブされていない（active）うえ、フォークではないオリジナルのリポジトリであることから、メンテナンスは継続されていると判断できます。ライセンスは商用利用や改変の自由度が高い MIT が設定されているため、自社プロジェクトへ組み込む際のライセンス上のハードルは低めです。
公式 README では、Hysteria 2 の強みとして次の 6 点が挙げられています。
- 多彩なモード（SOCKS5 / HTTP プロキシ / TCP・UDP フォワーディング / Linux TProxy / TUN など）に対応
- カスタム QUIC により、不安定・ロスの多い回線でも高い性能を発揮
- HTTP/3 トラフィックへの偽装による検閲耐性
- 主要 OS・アーキテクチャ向けのクロスプラットフォーム対応
- 認証・トラフィック統計・アクセス制御を内蔵し、統合が容易
- 仕様とコードが整備され、活発なコミュニティを持つ
HTTP/3トラフィック偽装（Masquerade）の仕組み
Hysteria 2 の検閲耐性を支える中核機能が「Masquerade（マスカレード、偽装）」です。サーバーは外部から見ると通常の Web サーバーのように振る舞い、正規の HTTP リクエストへ応答を返します。これにより、Hysteria の通信パケットは標準的な HTTP/3 トラフィックに見せかけられ、検閲側からは「ありふれた HTTP/3 ウェブサーバー」と区別がつきにくくなります。
Masquerade には 3 つのモードがあります。
- File: 指定したディレクトリの静的ファイルを配信する
- Proxy: 別の実在サイトのリバースプロキシとして振る舞う
- String: 固定の文字列を応答として返す
プロトコルレベルの設計意図については Hysteria のプロトコル仕様書 に記載されています。QUIC/HTTP/3 自体がブロックされる環境向けには、後述する難読化機能（Obfs）を併用することで、さらに検出を回避しやすくなります。
Brutal輻輳制御──損失ネットで真価を発揮するアルゴリズム
Hysteria 2 を他の QUIC プロキシと差別化する最大のポイントが、独自の輻輳制御アルゴリズム「Brutal」です。輻輳制御とは、ネットワークの混雑度に応じて送信速度を調整する仕組みのことで、ここに Hysteria 独自の思想が表れています。
従来のQUIC輻輳制御との違い（固定レート型）
一般的な QUIC の輻輳制御は、パケットロスや遅延の増加を「ネットワークが混雑しているサイン」とみなして送信速度を落とします。安定した有線回線では合理的な挙動ですが、もともとパケットロスが多い無線回線や長距離の国際回線では、ロスのたびに速度を落としてしまい、本来出せるはずのスループットを発揮できないという弱点があります。
Brutal はこの前提を覆し、あらかじめ設定した帯域幅で積極的にパケットを送り続ける「固定レート型」のアルゴリズムを採用しています。パケットロスや RTT（往復遅延）の変動が起きても安易に速度を落とさず、ロス率を計算しながら送信レートを補正します。これにより、パケットロスの多い環境でも設定した帯域に近いスループットを維持しやすくなります。
なお、同じ Brutal アルゴリズムを TCP 上で実現する apernet/tcp-brutal という関連 OSS（カーネルモジュール）も公開されています。
Brutalが有効なシナリオと設定上の注意点
Brutal が効果を発揮するのは、パケットロス率が高い回線です。逆に言えば、Brutal を正しく使うには注意が必要です。固定レート型である以上、設定する帯域値（up/down）が回線の実際の最大速度とどれだけ合っているかが成否を分けます。
Hysteria の Full Server Config ドキュメント では、帯域値を実際に可能な速度より高く設定してはならないと明確に警告しています。設定値が回線の実力を超えると、かえって接続が遅く不安定になり、データを無駄に消費してしまうためです。逆に実際の速度より低く設定した場合は、単なる速度制限として機能するため問題は起きません。自分の回線の正確な最大速度を把握できていない場合は、BBR などの従来型輻輳制御を使うほうが安全だとドキュメントでは案内されています。
つまり Brutal は「回線速度を正確に把握できる前提で、損失の多いネットワークのスループットを最大化したい」というシナリオに向いた機能です。この点は、Hysteria 2 を採用するかどうかを判断するうえで重要な分かれ目になります。
Hysteria 2と類似プロキシOSSの違い
QUIC ベースのプロキシ OSS は複数あり、それぞれ設計思想が異なります。ここでは代表的な TUIC・sing-box・Xray-core と比較し、Hysteria 2 の立ち位置を整理します。
TUICとの違い（0-RTT低遅延 vs スループット優先）
TUIC は、QUIC ベースの軽量プロキシプロトコルです。スター数は約 3,200、Rust 実装で GPL-3.0 ライセンスです。
観点 | Hysteria 2 | TUIC |
|---|---|---|
輻輳制御 | Brutal（積極的・高速優先） | 標準 QUIC（安定性優先） |
接続遅延 | 1-RTT | 0-RTT（低遅延） |
設計思想 | スループット最大化（損失ネット向け） | 安定性・効率性（多重化重視） |
実装言語 | Go | Rust |
難読化 | Salamander / Gecko（オプション） | なし |
HTTP/3 偽装 | ネイティブ対応 | なし |
ライセンス | MIT | GPL-3.0 |
TUIC は 0-RTT による低遅延と安定性を重視し、プロトコル単体に近いシンプルさが特徴です。偽装・難読化・アクセス制御・帯域制御といった付加機能は持ちません。一方の Hysteria 2 は、Brutal による積極的なスループット最大化と HTTP/3 偽装を統合している点で方向性が異なります。「接続のたびのレイテンシを抑えて軽量に使いたいなら TUIC」「損失ネットでスループットを稼ぎ、偽装機能も欲しいなら Hysteria 2」という選び分けになります。
sing-boxとの違い（単一プロトコル vs ユニバーサル基盤）
sing-box は、Hysteria・TUIC・VMess・VLESS・Reality などさまざまなプロトコルをまとめて扱える「ユニバーサルプロキシ基盤」です。スター数は約 34,700、Go 実装です。
両者は競合というより階層が異なります。Hysteria 2 は単一プロトコルの実装であるのに対し、sing-box はそれを含む多数のプロトコルを統合したクライアント・サーバー基盤です。実際、sing-box 経由で Hysteria 2 を利用することもできます。「Hysteria 2 という単一プロトコルの最高速・ロス耐性を狙うなら Hysteria 本体」「複数プロトコルを状況に応じて切り替えたいなら sing-box」という選定軸になります。
Xray-coreとの違い（QUIC専用 vs 多プロトコル汎用）
Xray-core は V2Ray の拡張版で、VLESS + REALITY などの TCP ベースプロトコルを含む多機能プロキシ基盤です。スター数は約 39,300、Go 実装で MPL-2.0 ライセンスです。
観点 | Hysteria 2 | Xray-core |
|---|---|---|
プロトコル基盤 | QUIC のみ（UDP） | TCP / UDP 両対応（複数プロトコル） |
速度（損失ネット） | 非常に高速（Brutal） | 標準的 |
設定の複雑さ | シンプル | 高機能・複雑 |
偽装方式 | HTTP/3 偽装（ネイティブ） | TLS 偽装（Reality） |
主な用途 | 速度優先・損失ネット | 汎用・多機能・ステルス |
Xray-core の Reality はステルス性で Hysteria 2 に近い水準を狙えますが、Hysteria 2 特有の高速性と固定レート制御（Brutal）が差別化点です。Xray-core は幅広いプロトコルをサポートする汎用基盤であり、機能の網羅性で勝ります。整理すると、「QUIC に絞り、損失ネットの速度を最優先するなら Hysteria 2」「多様なプロトコルを使い分ける汎用基盤が欲しいなら Xray-core」という棲み分けになります。
Hysteria 2でQUICプロキシを構築する方法
ここからは、Hysteria 2 を実際に構築する流れを公式ドキュメントの設定例とともに確認します。以下のコマンド・設定はすべて公式ドキュメントからの抜粋であり、本記事では実行・動作確認は行っていません。導入時は必ず最新の公式ドキュメントを参照してください。
サーバー構築（Linux・ACME自動TLS）
Linux サーバーへの導入には、公式が提供するインストールスクリプトを使う方法があります。
# 出典: https://v2.hysteria.network/docs/getting-started/Installation/
bash <(curl -fsSL https://get.hy2.sh/)
このほか、各 OS 向けのプリコンパイル済み実行ファイル（Windows / macOS / Linux / Android / FreeBSD）、Docker イメージ、Arch Linux の AUR、ソースからのビルドといった手段が用意されています。インストール手段の一覧は Hysteria の公式インストールガイド にまとまっています。
サーバー設定では、ACME による TLS 証明書の自動取得を使う例が公式に示されています。
# 出典: https://v2.hysteria.network/docs/getting-started/Server/
listen: :443
acme:
domains:
- your.domain.net
email: your@email.com
auth:
type: password
password: Se7RAuFZ8Lzg
masquerade:
type: proxy
proxy:
url: https://news.ycombinator.com/
rewriteHost: true
この例では、443 番ポートで待ち受け、acme セクションで指定したドメインの TLS 証明書を自動取得します。auth でパスワード認証を設定し、masquerade で先述の偽装（この例では Proxy モードで別サイトのリバースプロキシとして振る舞う設定）を有効化しています。認証方式はパスワードのほか、ユーザー名＋パスワード、HTTP バックエンド、コマンド方式などから選べます。
クライアント設定（SOCKS5 / HTTPプロキシ）
クライアント側は、接続先サーバーと認証情報、帯域、ローカルで待ち受けるプロキシを設定します。
# 出典: https://v2.hysteria.network/docs/getting-started/Client/
server: your.domain.net:443
auth: Se7RAuFZ8Lzg
bandwidth:
up: 20 mbps
down: 100 mbps
socks5:
listen: 127.0.0.1:1080
http:
listen: 127.0.0.1:8080
bandwidth の up / down が Brutal 輻輳制御に渡す帯域値です。先に述べたとおり、ここを回線の実速度より高く設定すると逆効果になるため、自分の回線速度を正確に把握したうえで設定する必要があります。socks5 と http でローカルに待ち受けるプロキシのアドレスを指定すれば、アプリケーションからこのプロキシ経由で通信できます。
Salamander難読化の有効化
QUIC/HTTP/3 通信そのものがブロックされる環境向けに、Hysteria 2 はパケットを難読化する任意機能「Obfs」を備えています。代表的な方式が「Salamander」で、パケットをランダムなバイト列に変換することで、QUIC らしさを隠します。実験的な方式として、ハンドシェイクを分割・パディングする「Gecko」も用意されています。
難読化を使う場合は、サーバーとクライアントの双方に同じパスワードを設定する必要があります。なお、難読化はあくまで「QUIC 自体が遮断される網」向けのオプションであり、通常は前述の HTTP/3 偽装だけで十分なケースも多い点に留意してください。
Hysteria Realms──NATを突き抜けるP2Pホスティング
公式サイトでは、ポート転送やリレーを介さずに NAT を貫通できる「Hysteria Realms」という機能も紹介されています。これにより、グローバル IP を持たない自宅回線・モバイル回線・カフェの Wi-Fi などからでも、サーバーをホストできるとされています。
一般的に、NAT 配下の環境でサーバーを公開するにはポート開放や中継サーバーの用意が必要になりますが、この機能を使えばそうした手間を省ける可能性があります。固定 IP やルーターの設定変更が難しい環境でサーバーを立てたいケースでは、採用を後押しする要素になります。
まとめ──Hysteria 2を選ぶべきシナリオと向かないケース
Hysteria 2 は、QUIC ＋ Brutal 固定レート輻輳制御 ＋ HTTP/3 偽装を一体で提供する点が独自のプロキシ OSS です。最後に、採用判断の軸を整理します。
Hysteria 2 が向いているケース
- パケットロスの多い無線回線・長距離の国際回線で、スループットを最大化したい
- 自分の回線の最大速度を正確に把握しており、Brutal の帯域値を適切に設定できる
- DPI 環境で、HTTP/3 偽装による検閲耐性が欲しい
- 設定をシンプルに保ちたい（QUIC 単一プロトコルに絞れる）
- NAT 配下の環境からサーバーをホストしたい（Hysteria Realms）
Hysteria 2 が向かない・注意が必要なケース
- UDP を遮断する企業網・制限網（QUIC は UDP ベースのため、そもそも通信が成立しにくい。別手段との併用が現実的）
- 回線の最大速度を把握できない（Brutal の帯域値を誤ると、かえって遅く不安定になる）
- 0-RTT の低遅延を最優先したい（TUIC のほうが向く）
- 複数プロトコルを状況に応じて切り替えたい（sing-box や Xray-core のような基盤が向く）
QUIC ベースのプロキシは選択肢が増えていますが、Hysteria 2 は「損失ネットでのスループット」と「HTTP/3 偽装による検閲耐性」を両立したいという明確なニーズに応えるプロジェクトです。スター数約 2 万・継続的なメンテナンスという健全さも踏まえ、まずは自分の用途と回線環境が上記のどちらに当てはまるかを確認したうえで、Hysteria 公式サイト や GitHub リポジトリ で最新情報を確認することをおすすめします。
