Hysteria2 と TUIC プロトコル：高パケットロス環境での速度改善

Shadowsocks や VMess プロトコルを使ったことがあれば、おそらくこんな経験があるでしょう。ノードの遅延は 80ms しか表示されていないのに、実際のダウンロード速度は 2MB/s しか出ず、動画は頻繁にバッファリングする——。問題はノード自体ではなく、伝送プロトコルにあることがよくあります。従来のプロキシプロトコルは TCP ベースで、高パケットロス・高遅延のネットワーク環境では性能が急激に低下します。Hysteria2 と TUIC は QUIC ベースの新世代プロトコルであり、まさにこの問題を解決するために生まれました。

なぜ TCP プロキシは高パケットロス環境で遅いのか

TCP は信頼性の高い伝送プロトコルで、すべてのパケットに確認応答（ACK）が必要です。ネットワークのパケットロス率が上がると、TCP の輻輳制御アルゴリズムが送信レートを下げ、再送が発生し、悪循環に陥ります。さらに悪いことに、TCP には「ヘッドオブラインブロッキング」の問題があります。1 つのパケットが失われると、それ以降のすべてのパケットは再送が完了するまで処理を待たされてしまうのです。

プロキシのシーンでは、TCP の弱点はさらに顕著になります。

プロキシトラフィックは追加のカプセル化を経るため、各 TCP 接続が「TCP over TCP」となり、二重の輻輳制御が互いに干渉します
国際回線のパケットロス率はしばしば 5%〜15% に達し、この環境では TCP のスループットが帯域の 30% に満たないこともあります
高遅延がパケットロスの影響を増幅します——再送のたびに 1 RTT を待つ必要があります

これが、同じノードでも SS プロトコルでは 5MB/s しか出なかったものが、Hysteria2 に変えると 50MB/s 以上出せる理由です。

QUIC：現代の伝送プロトコルの基盤

QUIC（Quick UDP Internet Connections）は Google が提唱した UDP ベースの伝送プロトコルで、現在は HTTP/3 の標準トランスポート層となっています。TCP と比べた QUIC の主な利点は次のとおりです。

0-RTT 接続確立 — 以前の接続パラメータを再利用し、2 回目以降の接続はハンドシェイク不要です
ヘッドオブラインブロッキングがない — 各データストリームが独立して伝送され、1 つのストリームのパケットロスが他のストリームに影響しません
ユーザー空間の輻輳制御 — OS の TCP スタックの制限を受けず、より積極的に帯域を活用できます
コネクションマイグレーション — ネットワーク切り替え（Wi-Fi から 4G への切り替えなど）の際も接続が途切れません

Hysteria2 と TUIC はいずれも QUIC の上に構築されていますが、設計思想と最適化の方向性が異なります。

Hysteria2：力こそパワー

Hysteria2 の核心は利用可能な帯域をできる限り使い切るという考え方です。Brutal という輻輳制御アルゴリズムを使い、パケットロスの信号に頼ってレートを調整するのではなく、クライアントとサーバーが取り決めた帯域上限に従って直接送信します。これは高パケットロス・高遅延の回線で非常に大きな効果を発揮します。

Hysteria2 の主な特徴：

QUIC ベースで、TLS 1.3 暗号化と難読化を内蔵
Brutal 輻輳制御により、高パケットロス環境でも高いスループットを維持
ポートホッピング（Port Hopping）に対応し、UDP の速度制限やブロックに対抗
設定がシンプルで、サーバー側もクライアント側も導入が容易
サーバーの帯域への要求が比較的高い——設定した帯域上限を本当に使い切ろうとします

Clash での Hysteria2 ノードの設定例：

- name: "HY2-Node"
  type: hysteria2
  server: example.com
  port: 443
  password: your-password
  sni: example.com
  skip-cert-verify: false
  up: 50        # 上り帯域 Mbps
  down: 200     # 下り帯域 Mbps

up と down は Hysteria2 の重要なパラメータで、Brutal アルゴリズムにあなたの帯域上限を伝えます。低く設定しすぎると性能を無駄にし、高く設定しすぎるとパケットロスが悪化することがあります。実際の帯域の 70%〜80% から始めてテストし、調整することをおすすめします。

Hysteria2 の up/down パラメータはクライアント側の帯域宣言であり、サーバー側の設定と完全に一致させる必要はありませんが、実際のネットワーク帯域に近い値にすべきです。

TUIC：バランス型の選択

TUIC（The Universal Implicit Congestion Control）も同じく QUIC ベースですが、異なる道を選んでいます。sing-box プロジェクトの作者によって開発され、極限の速度をひたすら追求するのではなく、低遅延と安定性のバランスを取ることを設計目標としています。

TUIC の主な特徴：

QUIC ベースで、ネイティブの TLS 1.3 暗号化
標準の QUIC 輻輳制御（BBR/Cubic）を使用し、よりおだやかな挙動
UDP over Stream モードに対応し、互換性と安定性がより高い
0-RTT ハンドシェイクに対応し、接続確立が非常に高速
サーバーのリソース使用量が比較的低い

Clash での TUIC ノードの設定例：

- name: "TUIC-Node"
  type: tuic
  server: example.com
  port: 443
  uuid: your-uuid-here
  password: your-password
  sni: example.com
  alpn: [h3]
  skip-cert-verify: false
  congestion-controller: bbr
  udp-relay-mode: native

congestion-controller は bbr または cubic を選べます。BBR は高遅延の回線でより良い性能を発揮し、Cubic はより保守的で安定しています。一般にはまず BBR を使い、不安定になるようなら Cubic に切り替えることをおすすめします。

Hysteria2 vs TUIC：どう選ぶか

2 つのプロトコルに絶対的な優劣はなく、あなたのネットワーク環境と利用シーンが鍵となります。

高パケットロス・高遅延の国際回線 → Hysteria2。Brutal アルゴリズムが帯域を強制的に活用でき、速度向上が最も顕著です
ネットワーク品質が中程度で、安定性を重視 → TUIC。標準の輻輳制御はより予測しやすく、長時間使っても異常が起きにくいです
ストリーミング視聴、大容量ファイルのダウンロード → Hysteria2。限界スループットがより高くなります
日常のブラウジング、SNS、仕事 → TUIC。低遅延な接続確立で、より快適な体験が得られます
サーバーの帯域が限られている → TUIC。Hysteria2 のように帯域を使い切ろうとはしません
サーバーの帯域が十分にある → Hysteria2。大きな帯域の優位性を実際の速度に変換できます

実際の利用では、多くのユーザーがサブスクリプションに両方のプロトコルのノードを残しておき、その時々のネットワーク状況に応じて柔軟に切り替えています。Clash の url-test プロキシグループは遅延が最も低いノードを自動選択できますが、現在のネットワークでどちらのプロトコルが速いかを自動判定することはできません——これは何度か手動でテストして経験を積む必要があります。

Clash で QUIC プロトコルの体験を最適化する

コアのバージョンが十分に新しいことを確認する

Hysteria2 と TUIC はどちらも Mihomo コアのサポートが必要です。クライアントの設定でコアのバージョンを確認し、最良の互換性と性能を得るために v1.18 以上のバージョンの使用をおすすめします。

UDP の疎通性

QUIC は UDP ベースのため、ネットワーク環境が UDP トラフィックをブロックしたり速度制限していたりすると、どちらのプロトコルも機能しなくなります。Hysteria2 のポートホッピング機能は、ある程度ブロックを緩和できます——複数のポート間でローテーションすることで、単一ポートがブロックされる確率を下げます。

- name: "HY2-Hopping"
  type: hysteria2
  server: example.com
  port: 443
  ports: 443,8443,2053,2083,2087,2096
  password: your-password

TUN モードとの組み合わせ

QUIC プロトコルは TUN モードでも良好に動作しますが、DNS 設定が正しいことを確認する必要があります。fake-ip モードを使い、udp サポートを有効にすることをおすすめします。そうしないと、一部の QUIC 接続が DNS 解決の問題で失敗することがあります。

難読化を重ねすぎない

QUIC 自体がすでに TLS 暗号化を備えているため、その上にさらに obfs の難読化を重ねる必要はありません。余分なカプセル化層はオーバーヘッドを増やし、性能を下げるだけです。トラフィックの特徴が気になる場合は、Hysteria2 の Salamander 難読化で十分です。

よくある問題のトラブルシューティング

ノードがタイムアウトする、または接続できない

まず UDP が通っているか確認してください——コマンドラインで nc -u example.com 443 を実行して UDP の疎通をテストします。UDP がブロックされている場合は、サービス提供者に TCP フォールバックに対応しているか確認するか、TCP 系プロトコルのノードに切り替える必要があります。

Hysteria2 の速度が期待に届かない

up/down パラメータが低すぎないか確認してください。また、Brutal アルゴリズムはパケットロス率が 20% を超えると著しく速度が落ちます——これはプロトコルの問題ではなく、物理回線の限界です。異なる回線のノードに切り替えて比較してみてください。

TUIC が頻繁に切断される

congestion-controller を BBR から Cubic に変更してみてください。udp-relay-mode: native を使っている場合は、quic に変更すると安定性が改善することもあります。サーバー側で単一 IP あたりの接続数が制限されていないか確認しましょう。

どちらのプロトコルも SS/VMess より遅い

これは、あなたのネットワーク環境が UDP に適していないか、ノードのサーバーが遠すぎることを示しています。QUIC の優位性は中〜高パケットロスの回線でこそ発揮されます——パケットロス率が 1% 未満、遅延が 50ms 未満であれば、従来の TCP プロトコルのほうがかえって安定することもあります。速度計測ツールで同じノードの異なるプロトコルを比較し、実際に最速のものを選びましょう。

まとめ

Hysteria2 と TUIC は、プロキシプロトコルが TCP から QUIC へと進化していく方向性を体現しています。Hysteria2 は Brutal 輻輳制御で極限の速度を追求し、高パケットロス・大帯域のシーンに適しています。TUIC は標準の QUIC 輻輳制御でバランスと安定性を追求し、日常利用に適しています。どちらも Mihomo コアのサポートが必要で、Clash では設定がシンプルで、サブスクリプションや設定ファイルに対応するノードを追加するだけで使えます。

サブスクリプションに複数のプロトコルのノードを残しておき、実際のネットワーク環境でテストして比較し、自分に最も合ったプロトコルの組み合わせを見つけることをおすすめします。新しいプロトコルに対応したコアのバージョンを確保するため、当サイトから最新版の Clash クライアントをダウンロードするのもお忘れなく。