Hysteria2とは？QUICで高速化する仕組みとShadowrocketでの使い方

Hysteria2とQUIC・UDPの関係

ShadowrocketのHysteria2は、プロキシプロトコルの種類のひとつです。クライアントとサーバーはUDPベースのQUIC接続でデータをやり取りし、サーバーが接続先のアドレスに接続します。ここでいうUDPはクライアントとサーバー間の外側の通信を指します。ブラウザでアクセスするすべてのサイトがUDPに切り替わるわけではなく、アプリ本来のTCPデータを信頼性のある転送なしに破棄できるという意味でもありません。

QUICは信頼性のあるデータ転送、ストリーム管理、TLSハンドシェイクを組み合わせています。確実な配信が必要なデータでは、失われたデータを再送などで回復する必要があります。UDP自体に再送機能はなく、その仕組みはQUICが担います。Hysteria2はTCP接続とUDPデータを運べますが、運び方はそれぞれ異なります。「外側がUDPだから、すべての通信が必ず届く」と解釈することはできません。

QUICの多重化により、あるストリームのデータ損失がほかのストリームの順序どおりの配信を直接妨げる事態を避けられます。ただし、各ストリームは接続全体の輻輳や帯域を共有します。回線がひどく混雑していると、すべての通信に影響が出る可能性があります。また、QUICとHTTP/3は同じものではありません。HTTP/3はQUIC上で動作するアプリケーションプロトコルです。どちらもQUICを使うからといって、同じ用途とみなすことはできません。

高速化することがある理由：輻輳制御と帯域推定

長距離回線では往復時間が長くなるため、利用可能な帯域を活用するには、送信側が十分な量のデータを転送中の状態に保つ必要があります。パケットロスが発生すると、信頼性のある転送ではデータを回復する処理が行われます。一部の輻輳制御アルゴリズムは、これを受けて送信速度を下げます。パケットロスの主な原因が回線の混雑ではなく無線干渉の場合、速度を下げすぎるとスループットが低下することがあります。Hysteria2は、こうした状況に応じて送信動作を調整することを設計上の重点のひとつとしています。

Hysteria2で使われるBrutal輻輳制御は、帯域の目標値を重要な入力として、フィードバックに応じて送信を調整し、パケットロスの影響を補うことを試みます。実際にどの制御方式が使われるかは、クライアントとサーバー双方の実装、ネゴシエーションの結果、帯域設定などにも左右されます。TypeがHysteria2だからといって、特定の制御方式が必ず有効になるとは限りません。また、QUIC自体が一定の速度向上を保証するわけでもありません。

• 目標帯域が低すぎる：回線に余裕があっても、設定によって送信速度が制限され、ダウンロードを続けると早い段階で速度が頭打ちになることがあります。
• 目標帯域が高すぎる：実際の回線容量を超えて送信すると、キューが発生して遅延やパケットロスが増え、かえってWebサイトの応答やリアルタイム通信に悪影響を与える可能性があります。
• 上下の帯域が非対称：家庭用回線では、アップロード速度がダウンロード速度を大きく下回る場合があります。ダウンロードの速度測定値を、そのままアップロードの目標値に設定しないでください。
• 単位の違い：Mbpsはメガビット毎秒、MB/sはメガバイト毎秒を表します。たとえば80 Mbpsは、オーバーヘッドを考慮しない場合、約10 MB/sです。これは単位換算であり、速度を保証するものではありません。

「速さ」は、Webページを最初に開くまでの待ち時間、ダウンロードを続けたときのスループット、リアルタイム通信の揺らぎなど、別々の指標で考える必要があります。スループットが上がっても、DNSの応答が速くなるとは限りません。また、接続先Webサーバーの応答時間が改善するとも限りません。地域間の遠回りな経路、サーバーの負荷、接続先サイトの速度制限もボトルネックになり得ます。

どのようなネットワークに適しているか：まずUDPを確認し、通信品質を比較

遅延が大きくランダムなパケットロスがある一方、安定したUDP通信が可能な回線は、Hysteria2を試す価値のある環境です。モバイル回線の電波変動や混雑したWi-Fiでは、パケットロスが起こることがあります。ただし、「モバイル回線だから」というだけでは特定のプロトコルをすすめる理由になりません。場所、時間帯、接続ネットワークによってUDPの扱いは異なるため、実際に使う場所で繰り返しテストしてください。

各回で同じ観察時間を設定してテストできます。たとえば60秒間の通信を3回繰り返し、ネットワークの種類や中断の有無を記録します。これはテスト方法の提案であり、この記事での実測結果ではありません。サーバー、DNS、ルールを同時に変更して速度を比較すると、変化の原因を特定できなくなります。

Shadowrocketへの追加手順と設定項目の確認

以下の手順は、利用者自身がサービス事業者の接続情報とサブスクリプションを持っていることを前提としています。サブスクリプションを読み込めば手入力のミスを減らせますが、読み込み後もプロトコルの種類や各項目が正しく設定されているか確認してください。アプリの項目表示は現在の画面によって異なる場合があります。サーバーから提供された接続情報をひとつずつ対応させ、別のプロトコルの設定を流用しないでください。

1. タイプを確認

   Home → 右上の「+」 → Typeを開き、手動で設定する場合はHysteria2を選択します。既存のサブスクリプションを使う場合は、TypeでSubscribeを選び、自分のサブスクリプションURLを入力して保存します。その後Homeに戻ってサブスクリプションを更新し、読み込まれた項目のタイプを確認してください。

2. アドレスを入力

   手元の接続情報に従ってAddressとPortを入力します。Addressはサーバーのホスト名またはIPアドレスであり、サブスクリプションURLではありません。Portにはサーバーが実際に待ち受けているUDPポートを指定します。たとえばサーバーが443を使う場合は443を入力します。Webサイトでよく使われるポートだからといって、独自にこの値へ変更しないでください。

3. 認証情報を確認

   Passwordを入力し、大文字と小文字、前後の空白、コピー漏れがないか確認します。Hysteria2の認証情報は該当するサーバーから提供されたものを使ってください。サブスクリプションURLのtokenを接続パスワードとして使ったり、別のプロトコルの認証情報を流用したりしないでください。

4. TLSを確認

   現在の項目にあるTLS関連の設定を開き、手元の情報をもとにSNIと証明書検証に使う名前を確認します。AddressにIPアドレスを指定し、証明書がドメイン名に対して発行されている場合は、名前の設定を特に確認してください。検証エラーが発生したときは、証明書、名前、有効期間を確認します。

5. 保存してテスト

   項目を保存し、Homeに戻って選択したら、Global Routingの現在の設定を確認して接続します。まず明確なテスト対象を開き、読み込みが完了するかを確認してから、継続的な通信をテストします。設定を変更する前に元の値を記録し、複数の項目を同時に変えないようにしてください。

サーバーでSalamanderなどの任意の難読化が有効になっている場合は、クライアント側の設定もサーバーと一致させる必要があります。難読化用パスワードと接続認証用パスワードは、用途の異なる設定項目です。サーバー側で有効になっていない場合は、独自に追加しないでください。また、難読化によって完全に遮断されたUDP通信が可能になるわけではありません。

• Address：最初に接続するサーバーを指定します。ドメイン名を使う場合は、ローカル環境でそのドメインを名前解決できる必要があります。
• SNI：TLSハンドシェイクでサーバー名を伝えるために使われます。既存のサーバー設定に合わせてください。サーバーアドレスの代わりに使える汎用的な設定ではありません。
• 証明書の検証：接続先が想定どおりの相手か確認します。名前が一致しない場合は設定値または証明書を修正してください。検証をスキップする設定を常用しないでください。
• 任意の設定：帯域、難読化、ポート範囲などは、サービス側で明確に指定され、現在の画面で設定できる場合にのみ入力します。既定値を推測したり、ポートを手当たり次第に試したりしないでください。

接続後にプロトコルの問題とルーティングの問題を切り分ける

項目を保存できても認証に成功したとは限りません。また、接続に成功しても、Webサイトへの通信にその接続が使われているとは限りません。ShadowrocketのGlobal Routingで、通信の経路が決まります。トラブルシューティングでは、まず現在の設定がConfig、Proxy、Direct、Sceneのどれかを確認し、テスト通信がどのルールまたはシーン設定に一致したかを特定してください。

Sceneを使っている場合は、現在有効なシーンの設定を確認してください。シーン名だけでプロキシの動作が決まるわけではありません。Configを使う場合、ルールは上から順に適用されるため、具体的な条件を前に置き、ルールの末尾にFINALを置きます。以下は構文の関係を示す例です。そのまま置き換えるための完全な設定ではなく、現在のネットワークから各接続先にアクセスできることを示すものでもありません。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレスの範囲、GEOIPはIPの地理データベースに基づいて照合します。接続先のドメインが上位のルールでDIRECTに一致すると、Hysteria2の項目に切り替えても、その通信は直接接続のままです。まずリクエストに適用される経路を確認してから、プロトコルの速度を評価してください。

症状別の対処：タイムアウト、認証エラー、通信の停止、更新後の不具合

遅延テストで数値が表示されても、それはその時点でテストに応答があったことを示すだけで、実際の通信をすべて確認できるわけではありません。特にTCPポートの疎通確認では、Hysteria2に必要なUDPハンドシェイクは確認できません。問題が起きたら、帯域設定を何度も変えるより、失敗した段階に沿って確認しましょう。

1. 接続が常にタイムアウトする：まずAddressとPortを確認し、サーバーのUDPリスニング設定とファイアウォールのルールを確認します。ドメイン名を使っている場合は、サーバーのドメイン名を名前解決できるか確認してください。その後、自分が使える別の接続ネットワークでも比較します。
2. TLSエラーが発生する：デバイスの時刻、SNI、証明書名、有効期間を確認します。AddressにIPアドレスを指定している場合は、特に証明書が検証に使う名前をカバーしているか確認してください。
3. 認証エラーが発生する：Passwordが該当するHysteria2の項目用か確認し、コピー時の空白、認証情報の変更、任意の難読化設定がサーバーと一致しているかを確認します。
4. 接続できてもWebページを開けない：Global Routing、ルールの照合結果、DNSを確認します。一部のドメインだけ失敗する場合は、プロトコル全体の問題と決めつけず、まず名前解決や接続先への到達性を確認してください。
5. 通信中に停止する：UDPの速度制限、無線信号、サーバー負荷、経路MTUなどを確認します。帯域目標を設定している場合は、まず元の値を記録し、目標を下げて一項目ずつテストしてください。
6. サブスクリプションの更新後に設定が変わった：読み込まれた項目のタイプ、ポート、認証情報、TLS設定を確認します。手動で編集した値が更新内容に置き換わっている可能性があります。項目名だけでなく、現在保存されている設定を確認してください。

On Demandは、条件に応じて接続を確立する動作を制御する機能であり、Hysteria2の輻輳制御を切り替えるものではありません。自動接続の問題を調べるときはSettings → On Demandを開き、関連する条件を確認してください。通信速度を調べるときは、接続状態とネットワークを一定に保ち、自動再接続による待ち時間をスループットの低下と取り違えないようにします。

最終的には実際の通信結果で判断します。UDPで通信できること、設定が一致していること、ルールが正しく適用されていることを確認してから、複数回のテスト結果を比較してください。現在のネットワークでUDPが継続的に遮断または強く制限されている場合、帯域の数値を変えても根本的な解決にはなりません。接続が安定し、必要な通信品質を満たしているなら、1回の速度測定の最高値を追って設定を何度も変更する必要はありません。