Hysteria2 vs TUIC v5：
2026年、どちらの検閲迂回プロトコルがより速い？実測比較

1 比較の前提とゴール

「検閲迂回プロトコル」という括りは広く、実務ではノードの地理、BGP、ホストの帯域契約、クライアント実装の成熟度が結果を支配します。したがって本稿のゴールは、どちらが常に勝つと断言することではなく、同じ測り方で並べたときに何が速く見えるかと、その理由を設計レベルまで戻して読むことです。Hysteria2 と TUIC v5 はともに UDP を主運搬路にし、多重ストリームでヘッドオブライン待ちを減らす思想を共有しますが、輻輳時の振る舞いや帯域の「食い方」は一致しません。

ここでいう「速さ」も一つではありません。ブラウザ体感に効くのは往復遅延（RTT）と TLS レイヤの完了時間、大容量転送ではスループット、モバイル回線では短いバースト損失にどれだけ強いか、の三つに分解するのが実務的です。以降では、いずれも同一 VPS 上の二つのインバウンドを用意し、同じクライアント端末から同じ測定コマンドを投げる手順を軸に整理します。ノードや回線が違えば数字は変わりますが、差の向きは再現しやすいはずです。

Clash 互換クライアント側では、これらのトランスポートをルールと一緒に運用するのが普通です。デスクトップで TUN とシステムプロキシを切り替える手順は Clash Verge Rev の TUN ガイドに譲り、サーバー常駐の Mihomo を試す場合は Linux に Mihomo を載せる手順と組み合わせると、測定と本番の両方で迷いが減ります。

2 二つのプロトコルの輪郭（速度に効く部分だけ）

Hysteria2 は QUIC をベースに、帯域が潤沢な路で積極的にウィンドウを広げる設計思想が強く、サーバー側の帯域上限を明示する bandwidth まわりのチューニングがスループットに直結しやすいです。コミュニティでは「同じサーバーでも Hy2 の方が単純ダウンロードの天井が高い」という報告が多く、それはブライトフィールド回線と相性が良い一方、共有ホストで隣人と帯域を奪い合うと振る舞いが荒く見えることもあります。

TUIC v5 も QUIC 系の多重化を活かしますが、実装とデフォルトの輻輳反応は Hysteria2 と一致しません。体感としては、軽負荷時の RTT や小さなオブジェクトの取得が素直に伸びるケース、UDP が局所的に詰まる環境で再接続が穏やかなケースが報告されています。どちらが「速い」かは、測る指標を一つに絞った瞬間に答えが変わる、と覚えておくと後述の表が読みやすくなります。

3 実測環境と手順（再現性優先）

本稿で想定する最小構成は次のとおりです。(1) 同じリージョンの VPS に Hysteria2 と TUIC v5 のリスナーを並列で立てる。(2) クライアントは同じ PC／同じ OS ビルドから、同じ Clash Meta 系コアに二つのプロファイルを順番に読み込む。(3) 各プロファイルで単一アウトバウンドのみを有効にし、ほかのルールは極力単純化する。これにより「ルールのせいで片方だけ遠回り」というノイズを減らせます。

測定コマンドは用途別に分けます。RTT は curl -w '%{time_connect} %{time_starttransfer}\n' -o /dev/null -s のように TLS 完了までを複数回取得し中央値を取る。スループットは同一ファイルを curl --http1.1 と HTTP/2 の両方で取得し、キャッシュを避けるためにクエリ文字列を回す。UDP 損失は可能ならルーター側の簡易トラフィックコントロールで 1〜3% のドロップを人工的に入れ、同じスクリプトを再実行します。いずれも「一度きりのヒット」ではなく、最低でも各 20 ラウンド程度が目安です。

for i in $(seq 1 20); do
  curl -w "%{time_starttransfer}\n" -o /dev/null -s "https://example.test/1mb.bin?r=$i"
done | sort -n | awk 'NR==10||NR==11{sum+=$1;n++} END{print sum/n}'

中央値を使うのは、TCP と違って QUIC 系は初回と再開で分布が肥えるためです。平均だけを見ると、たまたまの再ハンドシェイクが勝敗を決めてしまいます。Wi-Fi 測定では電波状況の差が出やすいので、可能なら有線に固定し、測定中はバックグラウンドのクラウド同期を止めてください。

4 指標別の読み方と今回の傾向（参考値）

以下の表は、著者環境で同一 VPS・同一クライアントから取得した中央値ベースのサンプルです。絶対値は読者の回線では意味を持たず、同条件での相対比較として読んでください。単位は RTT がミリ秒、ダウンロードが Mbps 表記です。

解釈の要点は二つです。第一に、スループット勝負ではサーバー側の宣言帯域とクライアントの実装が効き、Hy2 が「数値上の勝ち」を取りやすい場面があること。第二に、インタラクティブ用途では RTT と再送パターンが支配的で、TUIC が安定して見えるラウンドが混じることです。どちらか一方だけを見て「最速プロトコル」と呼ぶのは早計です。

5 損失と輻輳のときに起きること

UDP ベースのトランスポートは、軽いランダム損失でもスループット曲線がガタつきます。Hysteria2 は積極的に帯域を使う設定だと、損失が増えた瞬間に再送が膨らみ、グラフが「鋸刃状」になることがあります。TUIC v5 側は、同じ損失でも完了時間のばらつきが小さく見えることがありますが、ピーク帯域は抑え気味に出る、というトレードオフが出やすいです。

輻輳は損失だけではありません。共有 VPS で隣テナントがディスク I/O を奪っていると、暗号処理とディスクログがボトルネックになり、プロトコル差より OS キューの深さが支配します。疑わしいときは iperf3 の UDP モードでベースラインを取り、プロキシを挟まない裸の UDP で同じ悪化が出るかを先に確認してください。

6 Clash / Mihomo での運用観点

Mihomo（Clash Meta）では、両プロトコルとも単一のアウトバウンドとして宣言でき、セレクタや URL-Test で並べて自動選択することも可能です。ただし URL-Test のデフォルト URL が片方のプロトコルにだけ不利な場所にあると、常に誤った「最速」が選ばれます。テスト URL は自分が日常で使う CDN 近傍に寄せ、TLS と小さなペイロードの両方を含む複数 URL をローテーションするのが安全です。

DNS が二重管理になっていると、同じドメインでも片方のアウトバウンドだけ別リゾルバに触れてしまい、結果として RTT 比較が崩れます。TUN を使う構成では、仮想 NIC と Clash の DNS モードの整合を先に取ってからプロトコル比較に入ると、手戻りが減ります。手順の骨格は前述の TUN ガイドに沿えば足ります。

モバイル回線で切り替える場合は、キャリアの UDP 制限や IPv6 の有無がプロトコルより強く効くことがあります。数値が日によってブレるときは、プロトコルを疑う前に「IPv4 のみ」「別 APN」「別デバイス」での再現性を確認してください。

7 よくある誤解

• 「速いプロトコル＝検閲に強い」ではない： 検出リスクはトラフィック形状やポート、運用パターンに依存し、スピード指標と直結しません。
• 数値が良い方を常時選択すると逆に不安定になることがある： ピーク帯域を取りに行く設定は、混雑時に再送が増え、体感が悪化することがあります。
• クライアントのバージョン差は無視できない： 同じ名前でも実装差が出るため、比較前にコアとフロントエンドを揃えてください。
• TCP ベースのトロヤンが必ず遅いわけではない： ルートが直で、輻輳が少ない環境では従来型でも十分速く、UDP が制限されるネットでは逆転します。

8 まとめ

2026 年時点で Hysteria2 と TUIC v5 を並べるとき、実務的な答えは「指標を分けて測れば、どちらも勝ち筋がある」に落ち着きます。大きな単発転送やサーバー帯域に余裕がある環境では Hy2 が数値を伸ばしやすく、軽負荷のレスポンスや損失に対する完了時間の安定では TUIC が前に出るラウンドが観測されやすい、というのが本稿のサンプルでも一貫した傾向でした。どちらか一方だけを盲信せず、セレクタと URL-Test で現実のワークロードに合わせて寄せるのが安全です。

測定の再現性を高めるには、ルールと DNS を単純化し、TUN とシステムプロキシのどちらで測るかを固定し、ラウンド数と中央値で評価することが重要です。インフラ側の手順は Linux の Mihomo 記事、クライアント側の透過プロキシは TUN ガイドと組み合わせると、プロトコル比較から日常運用まで一気通貫で整えられます。

単体の「速いトンネル」より、ルール分流と DNS を一体で扱える Clash 互換スタックの方が、長時間セッションや開発者ネットワークではトラブルが少ない場面が多いです。プロトコル選定は最後の一押しであり、その前に出口設計を整える価値の方が大きい、と捉えると運用が楽になります。

→ 無料で Clash をダウンロードし、Hy2 / TUIC を同じルールで試す