Hysteria2はUDPベースのQUICを使用します。UDPが利用できる環境で、高遅延またはランダムなパケットロスがある回線を比較テストする際に候補となります。他のプロトコルより必ず速いわけではなく、あらゆるUDP制限を回避できるわけでもありません。本記事では、サービス提供元とサブスクリプションをすでに利用しているShadowrocketユーザー向けに、通信の仕組み、帯域幅の設定、インポート後の確認方法、ルールの問題・認証失敗・ネットワーク制限の見分け方を説明します。
Hysteria2・QUIC・UDPの関係
Hysteria2はプロキシプロトコル、QUICはその通信基盤、UDPはQUICのパケットを運ぶ役割を担います。それぞれ異なる階層にあり、アプリからのリクエストはプロキシ用にカプセル化されたうえで、QUIC接続を通じてサーバーへ送信されます。基盤がUDPだからといって、Hysteria2がパケットロスを処理せず送信するだけの通信路だと考えるのは誤りです。
UDP自体には、順序どおりの到達や確実な配送を保証する仕組みがありません。一方、QUICはUDP上で接続管理、信頼性のあるストリーム、パケットロスからの回復、輻輳制御を実現します。通常TCPを使うWeb通信も、プロキシ経由でQUICストリームに転送できます。アプリの通信がUDPを使うかどうかと、クライアントからサーバーまでの接続にUDPを使うかどうかは別の問題です。
QUICはHTTP/3と密接に関係していますが、両者は同じものではありません。QUICを使っても、すべてのプロキシ通信が通常のWebリクエストになるわけではなく、ネットワーク機器で必ず許可されるわけでもありません。ブラウザーでTCP 443を使ってWebサイトを開けても、同じ宛先のUDP 443でHysteria2接続を確立できるとは限りません。
速くなることがある理由：回復機能と輻輳制御
「速さ」は、ハンドシェイクにかかる時間、最初の応答までの時間、継続的なスループット、通信の安定性に分けて考える必要があります。QUICにはセキュアなハンドシェイクが組み込まれ、複数の独立したストリームを利用できます。あるストリームで失われたデータを待つ間も、同じトランスポート層の順序付きバイトストリームを共有する場合のように、他のストリームまで一律に待たされることはありません。ただし、各ストリームは接続の輻輳制御と実際の回線容量を共有するため、互いに完全に独立しているわけではありません。
Hysteria2のスループットは輻輳制御にも左右されます。プロトコル仕様では、目標帯域幅を基準に送信するBrutalの考え方に対応し、BBR系の輻輳制御を利用できる場合もあります。実際の挙動はクライアントの実装、帯域幅パラメーター、サーバー側の制限によって異なります。プロトコル名だけで現在の接続に使われるアルゴリズムを判断することはできません。また、特定の実装にある任意のパラメーターが、Shadowrocketにも必ず設定項目として存在すると考えないでください。
- ランダムなパケットロス：回線に空き容量があれば、積極的な送信や回復処理によって高いスループットを維持できる場合があります。ただし、再送が不要になるわけではありません。
- 実際の輻輳：ボトルネックがすでに容量上限に達している状態で送信量を増やすと、キューの滞留やパケットロス、遅延が増え、通話やWebの操作に影響することがあります。
- 高い往復遅延：ハンドシェイクやパケットロスからの回復に伴う待ち時間が目立ちます。プロトコルの仕組みで使い勝手が改善する場合はありますが、物理的な距離や経路の遠回りによる遅延は解消できません。
- サーバー側の速度制限：サーバーの帯域幅、負荷、出口の制限が上限になります。クライアントの設定値を上げても、サーバーの実際の処理能力は増えません。
試す価値のある環境と、先にネットワークを確認すべき環境
高遅延、ランダムなパケットロス、UDPへの到達性は、Hysteria2を試す目安であり、速度を保証するものではありません。家庭用ブロードバンド、公衆Wi-Fi、モバイル回線ではUDPの扱いが異なる場合があります。同じサーバー回線でも、接続するネットワークによって安定して通信できる場合、短時間しか接続できない場合、タイムアウトが続く場合があります。
| ネットワークの症状 | まず確認する点 | 確認方法 |
|---|---|---|
| 遅延が大きく、ときどきパケットロスが発生する | 比較テストの候補。ただしUDPが利用できるか要確認 | サーバーとテスト内容を固定し、最初の応答、スループット、中断回数をそれぞれ記録する |
| Webサイトには直接接続できるが、Hysteria2はタイムアウトが続く | TCPで接続できても、UDPで接続できるとは限らない | 実際のUDPポートを確認し、Wi-Fiとモバイル回線を切り替えて再テストする |
| ダウンロード開始直後は速いが、その後大きく遅くなる | キューの滞留、速度制限、サーバー負荷の可能性 | 他のダウンロードを停止し、帯域幅の設定値を確認して、同じファイルでもう一度テストする |
| 低遅延・低パケットロスで、現在の接続も安定している | プロトコルを変更しても改善するとは限らない | 一度の最高速度だけでなく、安定性を優先して比較する |
| ネットワークを切り替えると接続が切れる | アドレスの変化、NATの状態、ネットワークポリシーが接続に影響している可能性 | 接続を再確立してログを確認する。QUICの接続移行機能を、通信が必ず途切れない保証と捉えない |
結論：まずUDPの到達性を確認し、その後にスループットを比較
同じ設定がモバイル回線では使えても、現在のWi-Fiではタイムアウトが続く場合は、まずネットワークごとの差を記録し、UDPが許可されているか確認してください。この状態で帯域幅の設定値を繰り返し上げても、接続確立の失敗は解決しません。
ShadowrocketにHysteria2をインポートして確認する
サブスクリプションと接続パラメーターは、利用中のサービス提供元から入手してください。手入力のミスを減らすため、提供元から受け取った設定をそのままインポートするのがおすすめです。サブスクリプションを更新しても、サーバーに接続できるとは限りません。更新後は、選択中の項目、プロトコル、認証情報が変わっていないことも確認してください。
-
サブスクリプションをインポート
Homeの右上にある「+」を選択し、Add Serverを開いてTypeをSubscribeに設定します。自分のサブスクリプションURLを入力して保存してください。Homeに戻り、サブスクリプションを更新してから、追加された項目を確認します。
-
プロトコルを確認
Homeで対象項目の編集画面を開き、TypeがHysteria2になっていることを確認します。サーバーアドレス、ポート、認証情報を一つずつ照合してください。以前のプロトコルで使っていたパスワードやポートを、新しい項目にそのまま使わないでください。
-
セキュリティ設定を確認
サービス提供元の案内に従い、TLS、SNI、任意の難読化パラメーターを確認します。接続先アドレスと証明書に使われるドメイン名は異なる場合があります。SNIはサーバー側の指定に合わせてください。証明書エラーが出た場合は、ドメイン名、システム時刻、証明書チェーンをまず確認します。
-
テスト経路を固定
Home → Global Routingで一時的にProxyを選択し、テストするHysteria2項目を指定します。ConfigのルールによってテストリクエストがDIRECTへ送られる影響を抑えられます。テスト後は、元の利用設定に戻してください。
-
接続結果を記録
接続を開始して、決めたテスト先にアクセスします。接続が確立できるか、最初の応答に時間がかかるか、通信が中断されるかをそれぞれ記録してください。接続が自動で再確立される場合は、Settings → On Demandも確認し、オンデマンド接続の作動を手動操作の失敗と誤認しないようにします。
ポートはサーバーの設定と一致させる必要があります。たとえば、サーバーがUDP 443を使用する指定なら、項目のポートが443になっていることと、サーバー側でそのUDPポートが許可されていることを確認してください。難読化パスワードが指定されている場合、接続認証用パスワードとは用途が異なることがあるため、自由に置き換えないでください。トラブルの切り分けを目的に、証明書検証を長期間無効にしないでください。まず不一致のパラメーターを修正します。
Global Routingの設定とプロトコル性能を切り分ける
プロトコルはクライアントからサーバーまでの通信方法を決め、Global Routingはリクエストがプロキシ経由で送られるかどうかを決めます。Home → Global RoutingにあるProxy、Direct、Config、Sceneは、4種類のプロトコルではありません。Sceneの結果は既存のシーン設定に左右されます。切り分けの際は、実際に適用されている設定を先に確認し、テスト中に経路が条件によって変わらないようにしてください。
Config
おすすめ現在のConfigルールに従ってリクエストを処理します。宛先がDIRECTに一致すると、Hysteria2項目を選んでいても、その接続経由には自動で切り替わりません。ルールを確認したうえでの日常利用に適しています。
適した用途：ルールを確認済みで、宛先ごとに通信を振り分ける日常利用
Proxy
リクエストを現在のプロキシ経路に送ります。テスト時にConfigルールの影響を一時的に減らす用途に適しています。選択中の項目や、通信経路に影響するその他の設定も確認してください。
適した用途：プロキシ項目を固定し、プロトコルの接続性を短時間テストする
Direct
直接接続の経路を使用するため、Hysteria2サーバーのスループットは測定できません。ローカルネットワークの比較には使えますが、テスト先への接続可否も結果に影響します。
適した用途：ローカルネットワークと直接接続先が正常か確認する
Configでは、DOMAIN-SUFFIXがドメインのサフィックス、IP-CIDRがアドレスのネットワーク範囲、GEOIPがIPアドレスの位置情報データベースに基づいて一致を判定します。FINALはそれ以前のルールに一致しなかったリクエストを処理します。ルールの順序と各ルールに設定されたポリシーの両方で経路が決まります。テスト先がDIRECTに一致する場合は、Hysteria2の速度の問題と考える前に、まずルールを確認してください。
よくある質問：タイムアウト、証明書、帯域幅の設定
同じ項目なのに、Wi-Fiを変えるとタイムアウトするのはなぜ？
項目の設定を変えずに、Wi-Fiとモバイル回線それぞれで接続を再確立してください。一方のネットワークだけで失敗する場合は、発生時刻、サーバーポート、エラー内容を記録し、そのネットワークでUDPが制限されていないか確認します。Webサイトを開けるかどうかだけで、UDPの到達性を判断しないでください。
証明書エラーが表示されたら、そのまま無視してよい？
まずデバイスの時刻を確認し、サービス提供元が指定したSNIと証明書のドメイン名を照合してください。接続先アドレスがIPアドレスでも、証明書がそのIPアドレスに対応しているとは限りません。それでも一致しない場合は、設定を確認するためサービス提供元に問い合わせてください。検証を長期的に省略して解決しようとしないでください。
帯域幅の値を大きくすれば、ダウンロードは速くなる？
いいえ。まず入力単位を確認し、上り・下りの値がクライアント側の向きに合わせて設定されているか確認してください。サービス提供元の指定値、または実際の回線に合った控えめな値でテストします。一度に変更する項目は一つにし、Webの応答と継続的なダウンロード速度を観察してください。瞬間的な最高速度だけで判断しないでください。
遅延テストでは数値が出るのに、Webページが開かないのはなぜ？
テスト結果が、Webサイトへのリクエスト全体を反映しているとは限りません。Homeに戻って選択中の項目を確認し、Global Routingの設定も確認してください。ルールの影響を切り分ける場合は、一時的にProxyを選択します。その後、DNSの名前解決エラー、TLSエラー、接続タイムアウトを区別し、エラーの種類に応じて設定を確認してください。
再現できる条件で比較テストする
プロトコルを比較するときは、できるだけ変更する条件を一つに絞ってください。サーバー、出口、時間帯が異なる場合の速度差を、そのままQUICの効果と見なすことはできません。サービス提供元が複数のプロトコル接続先を提供していても、同じ回線と同じ帯域制限を使っているか、まず確認してください。これらの条件がそろっていなければ、テストで分かるのは2つの接続全体の違いに限られます。
- 環境を固定：同じデバイス、同じ接続ネットワーク、同じテスト先を使い、バックグラウンド更新や他の大容量通信を停止します。
- 繰り返し測定：各条件で少なくとも3回テストし、日時、最初の応答、継続速度、失敗回数を記録します。これらは記録項目の提案であり、本記事が実測結果を示すものではありません。
- 負荷時の遅延を確認：ダウンロードを続けながら通常のWebページを開きます。スループットが上がっても操作時の反応が明らかに遅くなる場合は、帯域幅の目標値や回線のキュー滞留を確認してください。
- エラーの種類を記録：タイムアウト、認証失敗、証明書エラー、通信中断をそれぞれ記録し、すべてを「遅い」とひとまとめにしないでください。
- 認証情報を保護：記録を共有する前に、サブスクリプションURLに含まれるtoken、認証パスワード、難読化パスワードを削除し、切り分けに必要なネットワーク情報とエラー内容だけを残してください。
最終的には、現在のネットワークで再現できる結果を基準にしてください。UDPに到達でき、設定が正しく、通信が安定していて初めて、スループットの優位性を検討できます。Hysteria2は、利用中のサービス設定で選べる通信方式の一つです。高いパケットロスや遅延はテストする理由にはなりますが、必ず速くなる根拠ではありません。