Hysteria2はQUICをベースにしており、UDPが利用できる環境で、高遅延やランダムなパケットロスがある回線のスループットを比較検証する際に候補となります。ただし、すべてのネットワークで高速化するわけではありません。利用中のサービス提供元から接続情報を取得済みの方に向けて、通信の仕組みやネットワーク上の制約、Shadowrocketでの設定方法、比較テストの手順を解説し、プロトコル・ルール・回線のどこに問題があるかを切り分けます。
QUICで変わること
Shadowrocketでは、Hysteria2はプロキシプロトコルの選択肢の一つです。ルールモードや通信を高速化するスイッチではありません。UDPベースのQUICで暗号化接続を確立し、転送するリクエストをその上に載せます。ここでいうUDPはクライアントとサーバー間の外側の通信方式です。ブラウザー内のTCPリクエストの信頼性が失われるわけではありません。
QUICはプロトコル層で確認応答、パケットロス検出、再送を行い、TLS 1.3で安全なハンドシェイクを実施します。同じ接続内に、独立した複数の信頼性のあるストリームを載せられます。あるストリームでデータが欠けても、通常、ほかのストリームは同じトランスポート層のバイト列がそろうまで待つ必要がありません。これによりストリーム間のヘッドオブラインブロッキングを軽減できますが、同一ストリーム内のデータは順序どおりに届けられます。また、共有回線の混雑はほかのストリームにも影響します。
ポートはサービス提供元から指定された値を使用してください。ネットワークから 443/TCP のHTTPSサイトに接続できても、443/UDP が許可されているとは限りません。2つの通信方式ではファイアウォールのルールがまったく異なる場合があるため、「Webサイトは見られるのにHysteria2のハンドシェイクがタイムアウトする」ことは矛盾しません。
パケットロスが多い環境で速くなる可能性がある理由
通信性能を左右するのはQUICだけではなく、Hysteria2の輻輳制御や帯域幅パラメーターのネゴシエーションも関係します。従来のロス駆動型輻輳制御では、ランダムなパケットロスを輻輳と判断し、送信レートを下げることがあります。無線干渉など、輻輳以外の原因でパケットロスが起こる環境では、Hysteria2の帯域幅推定と送信制御によって、より高いスループットを維持できる可能性があります。実際の動作はクライアントとサーバーの設定、双方のネゴシエーション結果によって異なります。
パケットロスをすべて無視するわけではありません。回線の飽和が原因でパケットロスが発生している場合、さらにデータを送信するとキューや再送、遅延が増加します。高遅延のネットワークでは回線を使い切るために、より多くのデータを送信中の状態にする必要があります。しかし、プロトコルで物理的な距離を縮めたり、サーバー側の帯域や契約プランの速度制限を超えたりすることはできません。ファイルのダウンロードが速くなっても、ゲームの往復遅延が同じように下がるとは限りません。
- ランダムなパケットロス：無線干渉などによる散発的な損失です。回線容量を使い切っているとは限らず、比較テストを試す価値のある状況です。
- 輻輳によるパケットロス：ダウンロード中に遅延が上がり続け、ほかの端末も同時に遅くなる場合は、送信目標をさらに上げるのではなく、まず負荷を下げてください。
- UDPの速度制限：接続できても、長時間のスループットが制限されることがあります。ポート変更が有効とは限らず、利用中のネットワークの管理ポリシーを回避すべきではありません。
- サーバー側のボトルネック：サーバーの帯域、CPU、運用ポリシーに制限がある場合、クライアント側でプロトコルを変更しても利用可能なリソースは増えません。
まずUDPの疎通を確認し、その後に帯域幅を調整
別のネットワークに切り替えるとすぐ接続できる場合は、まず元のネットワークでUDPが利用できるか確認してください。接続は安定しているものの、最大負荷時に遅延が大きく上がる場合は、帯域幅の目標を下げて再テストします。証明書検証を無効にしたり、パスワードを何度も変更したりするのは避けてください。
適性を検証できるネットワーク環境
プロトコルが適しているかどうかは、接続成功率、持続的なスループット、通信時の遅延をあわせて確認します。地域をまたぐ回線、モバイル回線、無線環境などでランダムなパケットロスがある場合は、Hysteria2を比較検証できます。低遅延・低ロスで、すでに回線の上限まで使えているネットワークでは、変更しても大きな効果がないことがあります。UDPが制限されているゲストネットワークでは、再試行回数を増やすのではなく、まずネットワークのルールを確認してください。
| ネットワークの状態 | 考えられる原因 | 次の確認事項 |
|---|---|---|
| 高遅延でランダムなパケットロスがある | 通信方式や輻輳制御の違いが表れる可能性 | サーバーと対象ファイルを固定し、スループットと遅延を繰り返し測定する |
| パケットロスが少なく、既存の接続が回線上限に近い | プロトコルが主なボトルネックではない | 安定している設定を維持し、サーバー側の帯域とローカル回線を確認する |
| Wi-Fiではタイムアウトするが、モバイル回線では接続できる | 元のネットワークでUDPや特定の宛先ポートが制限されている可能性 | ネットワークポリシーを確認し、サービス提供元にサーバーの状態を問い合わせる |
| 接続できるが、ダウンロード中にWebページの表示が明らかに遅くなる | キューイング遅延、または高すぎる送信目標の可能性 | 帯域幅パラメーターを下げ、最大負荷時の遅延が改善するか確認する |
| どのネットワークでも証明書または認証エラーが表示される | 回線性能より、設定パラメーターの問題を優先して確認する | SNI、証明書のドメイン名、端末の時刻、認証情報を確認する |
1回の遅延テストだけでプロトコルの優劣を判断しないでください。短時間の測定で分かるのは、その時点での接続可否や応答時間が中心で、連続通信の安定性を示すものではありません。テスト中はほかの端末で大容量通信を停止し、ネットワークの種類も記録してください。そうしないと、Wi-Fiとモバイル回線の違いをプロトコルの差だと誤認する可能性があります。
Shadowrocketの設定手順
以下では、iPhone／iPadのHome画面を例に説明します。ほかのプラットフォームでは実際の画面に従ってください。接続情報、サブスクリプションURL、認証情報、サーバーのドメイン名とポートは、利用中のサービス提供元から取得してください。Hysteria2とHysteriaではパラメーターもプロトコルも異なるため、Typeで選ぶ名称を確認しましょう。
-
接続情報を確認
プロトコルがHysteria2であることを確認し、Server、Port、Passwordに加えて、サービス提供元から指定されたSNI、帯域幅、obfuscationパラメーターを用意します。ポートは443の場合もありますが、例示された値を実際のポートとして使わないでください。
-
Typeを選択
Home → 右上の「+」→ Type → Hysteria2の順に進み、接続情報を入力します。TLSを使用するという理由だけで、TypeにTrojanなど別のプロトコルを選ばないでください。
-
認証情報を確認
Passwordには、サービス提供元から案内された認証情報をそのまま入力します。区切り文字を含む値が案内されている場合は形式を変えず、ユーザー名とパスワードに分けないでください。また、サブスクリプションURL内のtokenを接続パスワードとして使わないでください。
-
セキュリティ設定を確認
SNIはサーバー証明書およびサービス提供元の案内に合わせます。ServerにIPアドレスを指定する場合でも、SNIにはドメイン名が必要なことがあります。証明書の検証は有効にしたままにしてください。証明書エラーが発生した場合は、ドメイン名、端末の時刻、証明書チェーンを確認します。
-
保存してテスト
保存後にHomeへ戻り、対象の項目を選択して、Global Routing → Proxyで短時間の比較テストを行います。リクエストが選択した接続を通ることを確認したら、Global Routing → Configに戻り、普段使うルール分岐を確認してください。
すでにサブスクリプションを利用している場合は、Home →「+」→ Type → Subscribeを開き、サービス提供元から取得したサブスクリプションURLを入力します。保存して更新した後、読み込まれた項目のTypeを確認してください。サブスクリプションは設定を配布する方法であり、サーバーの稼働を保証するものではありません。サブスクリプションの更新失敗と、個別のHysteria2項目の接続失敗は別の問題です。URLと接続情報をそれぞれ確認してください。
ルーティングモードがテストに与える影響
Hysteria2は接続の通信方式を決め、Global Routingはどのリクエストをプロキシに渡すかを決めます。役割の異なる設定です。項目が接続できても、すべてのWebサイトがその接続を使うとは限りません。以下で比較するのはShadowrocketのルーティング動作であり、プロトコルの性能ランキングではありません。
Config
推奨現在有効なConfigのルールとポリシーに従ってリクエストを処理します。Homeで選択した項目だけで判断せず、ルールの順序、マッチ結果、ポリシーが実際に選んだ項目を確認してください。
用途：接続テスト後の日常的なルール分岐
Proxy
Shadowrocketが処理するリクエストをプロキシに渡し、通常のルール分岐によるテストへの影響を抑えます。端末上のすべてのシステム通信が必ずプロキシを通ることを保証するものではありません。
用途：Hysteria2の接続と対象サイトへのアクセスを短時間で確認
Direct
Shadowrocketが処理するリクエストを直接接続し、同じ宛先に対するローカルネットワークの基準値を測定できます。この状態で対象サイトを開けても、Hysteria2が有効になっている証明にはなりません。
用途：ローカルネットワークの接続可否と直接接続の状態を比較
Global RoutingのSceneは、シーンごとの設定に基づいてルーティング動作を決める機能で、4つ目のプロキシプロトコルではありません。問題を調べる際は、現在のシーンで実行される動作を確認してください。Settings → On Demandは条件に応じた接続開始を管理する機能です。Hysteria2を選択するものでも、ルール分岐を置き換えるものでもありません。テスト中に接続状態が変わる場合は、On Demandの起動条件も確認してください。
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY以下はルール構文の例であり、Config全体ではありません。DOMAIN-SUFFIXはドメインの末尾、IP-CIDRはアドレス範囲、GEOIPはIPアドレスの地域情報に基づいてマッチし、FINALはほかに一致するルールがない場合の処理を指定します。通常は上から順にマッチする項目を探します。ここでのPROXYはポリシー名で、Hysteria2のプロトコル名ではありません。実際に使われる接続は、ポリシーの選択内容によって決まります。リクエストログで宛先、マッチしたルール、実際のポリシーを確認し、直接接続の速度をプロトコルの測定結果と取り違えないようにしてください。
再現可能なテストで問題を切り分ける
比較テストでは、クライアント端末、サーバー、対象リソース、テスト時間帯を固定します。サービス提供元が比較可能な接続方法を用意している場合は、できるだけ同じ出口を使ってください。出口が異なる接続同士の速度差だけでは、特定のプロトコルが優れているとは判断できません。以下の時間や回数は手順の目安であり、性能を保証するものでも実測結果でもありません。
- 基準値を記録：バックグラウンドのダウンロードを停止し、Wi-Fiかモバイル回線か、現在のルーティング動作、選択中の項目、対象リソースを記録して、まず対象に接続できることを確認します。
- 3回繰り返す：各回で約60秒間連続して通信し、安定時の速度、通信が途切れるか、同時にWebページへアクセスした際の応答を記録します。開始直後のピーク速度だけを記録しないでください。
- 変更は1項目ずつ：まずサービス提供元の初期設定を維持します。調整する場合はアップロードまたはダウンロードの目標値のどちらか一方だけを変更し、同じ条件で再テストしてください。
- エラーの段階を切り分ける：ハンドシェイクのタイムアウトはUDPとポート、認証失敗はPassword、証明書エラーはSNI・証明書チェーン・端末の時刻を確認します。接続後に遅くなる場合は、輻輳とサーバー側の帯域を調べてください。
- 普段の設定に戻す：テスト終了後、Global Routing → Configに戻ってルール分岐を確認し、On Demandの設定が元の状態か確認してください。
サービス提供元に問い合わせる場合は、ネットワークの種類、エラーが起きた段階、発生した時間帯、個人情報を伏せたログを伝えます。サブスクリプションURL全体やPassword、tokenを含むリンクを公開しないでください。同じ設定が特定のネットワークだけで失敗する場合は、接続できるネットワークとの比較結果も添えると、すべての項目を何度も変更するより原因を特定しやすくなります。
持続的なスループットと最大負荷時の遅延をあわせて判断
繰り返しテストしてスループットが改善し、通信の途切れが増えず、通信時の遅延も許容範囲に収まる場合に限り、新しいパラメーターを使い続けてください。一時的なピーク速度だけが上がってWebページの表示が遅くなる場合は、元の設定に戻して回線のボトルネックを調べます。