本記事は、利用するサービスの設定情報やサブスクリプションをすでにお持ちで、ShadowrocketでHysteria2のパラメータを確認したい方を対象としています。まずQUICとUDPの役割を整理し、サーバー、ポート、認証情報、TLS、SNIを順に確認します。最後に、ネットワーク環境とリクエストを固定して、通信・認証・ルーティングのどの段階で問題が起きているかを切り分けます。ノードやサブスクリプションの提供・販売・推奨は行っていません。
Hysteria2、QUIC、UDPの関係
ShadowrocketのHysteria2はプロキシプロトコルの一種です。Global Routingのモードではなく、有効にするだけですべての通信に適用される高速化機能でもありません。該当する項目を選択し、リクエストがその項目、またはその項目を含むポリシーにルーティングされた場合にのみ、その接続を通じて通信します。
Hysteria2はQUICをトランスポートとして利用し、QUICはUDP上で動作します。UDP自体には再送や順序どおりの配送を行う機能がありませんが、QUICはその上で暗号化、ストリーム管理、信頼性の高い転送などを実現します。そのため、「UDPベース」だからといってWebデータが失われてもよいわけではなく、アプリ本来のTCP通信の信頼性が失われるわけでもありません。
内側の通信と外側の通信を区別する必要があります。アプリがWebサイトにアクセスするときはTCPを使う場合がありますが、ShadowrocketがそのリクエストをHysteria2に渡すと、デバイスからプロキシサーバーまではUDPベースのQUIC接続になります。接続先のWebサイトがQUICに対応している必要はありません。プロキシサーバーから接続先までの通信と、デバイスからプロキシサーバーまでの外側の通信は別の区間です。
- UDP：データグラムを運ぶ役割を担います。利用中のネットワークで、デバイスとサーバー間の該当するUDPポートが通信可能である必要があります。
- QUIC：接続、暗号化、ストリーム転送を担います。ストリーム間では、従来の単一TCP接続でパケットロスが起きた際に生じる連鎖的なブロックを軽減できますが、同じ信頼性のあるストリームはパケットロスからの回復の影響を受けます。
- Hysteria2：上記の転送方式を基盤として、認証、プロキシリクエスト、データ転送の方法を定めます。クライアントとサーバーのパラメータを一致させる必要があります。
パケットロスが多い環境での特性と適用範囲
Hysteria2は、高遅延で損失のある回線を想定した輻輳制御の考え方を取り入れています。Brutalの仕組みは設定された帯域幅の値に関係します。スループットが安定するかどうかは、回線容量、パケットロスの原因、サーバー負荷、実際に使用される輻輳制御方式によって異なります。プロトコル名だけから一定の速度が出るとは判断できず、パケットロスが多いほど効果が高いとも限りません。
特に、ランダムなパケットロスと輻輳によるパケットロスは区別が必要です。無線信号の変動による少量のランダムロスなら、適切な転送方式によって回線の利用効率が改善する場合があります。一方、回線の出口がすでに混雑していると、送信量を増やすことでキューや遅延、パケットロスが増える可能性があります。帯域幅の値を利用可能な上り速度より大幅に大きくしても、回線容量は増えません。
判断のポイント：まずUDPの疎通を確認し、その後で帯域幅を調整
同じ設定がモバイル通信では使えて、特定のWi-Fiではハンドシェイクが繰り返しタイムアウトする場合は、まずそのWi-FiからサーバーのUDPポートまでの経路を確認してください。通信できない問題に対して、帯域幅を上げたり証明書検証を無効にしたりしないでください。
- 検討できる環境：UDPで通信でき、サーバーのパラメータが明確で、現在の回線に高遅延やランダムなパケットロスがある場合。
- 慎重な検討が必要な環境：UDPが厳しく制限されているネットワーク、出口が常時混雑している環境、またはデータ通信量やバッテリー消費を抑えたい場合。
- 直接解決できない問題：認証情報の誤り、証明書の期限切れ、ルールの誤り、接続先Webサイト自体の障害。
ShadowrocketでHysteria2の設定項目を確認する
既存のサブスクリプションには通常、サーバーのパラメータが含まれています。まずインポート結果を確認し、異なる項目の設定を組み合わせないでください。手動で追加する場合は、Homeの追加ボタンをタップし、TypeでHysteria2を選択して、お手持ちの設定に従って入力します。項目の並びや表示される選択肢はアプリの画面によって異なる場合があります。表示されていない詳細設定を、別の項目で代用しないでください。
| 項目・パラメータ | 入力時の基準 | よくある間違い |
|---|---|---|
| Type | サーバーで使用しているプロトコルと一致するHysteria2を選択します。 | HysteriaとHysteria2を同じタイプとして扱う。 |
| サーバーアドレス | 既存の設定に記載されたホスト名またはIPアドレスを入力します。 | パスやクエリパラメータを含むサブスクリプションURL全体をアドレス欄に入力する。 |
| ポート | サーバーが実際に待ち受けているUDPポートを入力します。設定に443と明記されている場合は、443を指定します。 | すべてのサーバーが443を使うと思い込む、またはTCPの443番ポートに接続できることだけを確認する。 |
| 認証情報 | 既存の設定に記載された認証情報を一字一句そのまま入力します。 | コピー時に余分なスペースが入る、またはサブスクリプションのtokenを接続用パスワードとして扱う。 |
| TLS / SNI | 証明書検証を有効にし、SNIには設定で指定されたサーバー名を使用します。 | 接続先がIPアドレスの場合に、そのIPアドレスを証明書名として指定してしまう。 |
| obfs | サーバーで有効になっており、対応するパラメータが指定されている場合にのみ設定します。 | obfuscation passwordと認証情報を混同する、またはクライアント側だけで有効にする。 |
| 帯域幅のパラメータ | 画面に項目がある場合は、実際の上り・下り速度と既存の設定に従って入力し、単位も確認します。 | MbpsとMB/sを混同する、または持続可能な回線容量の代わりに理論上の最大速度を使う。 |
SNIはTLSハンドシェイクでサーバー名を通知するために使用されます。証明書検証では、サーバーの身元が想定した名前と一致するかも確認します。サーバーアドレスは接続先を決め、SNIと証明書名は検証対象を決めます。両者が異なる場合もありますが、明確な設定根拠が必要です。証明書エラーが発生した場合は、名前、デバイスの日時、サーバー証明書を確認し、検証をスキップする設定を常用しないでください。
Hysteria2は旧バージョンのHysteriaとプロトコルやパラメータに互換性があるとは限りません。サブスクリプション更新後にタイプの認識に問題がある場合は、元の項目でHysteria2が明示されているか、アプリがそのサブスクリプション形式を認識できるかを確認してください。項目名を変更しても、実際のプロトコルは変わりません。
既存のサブスクリプションのインポート・更新と初回接続確認
サブスクリプションURLは設定情報を取得するためのもので、プロキシサーバーのアドレスではありません。設定を読み込むための認証情報が含まれる場合があるため、機密情報として扱ってください。以下のURLは構造を確認するための例であり、実際の接続には使用できません：https://example.com/sub?token=xxxx。実際のサブスクリプションURLを公開スクリーンショットやトラブル対応の記録に載せないでください。
- 既存のサブスクリプションをインポート：Homeで追加ボタンをタップし、TypeでSubscribeを選択します。自分のサブスクリプションURLをURL欄に入力して保存します。Homeに戻り、該当するグループと、判別可能なHysteria2項目が表示されていることを確認します。
- 更新結果を確認：更新が必要な場合は、そのサブスクリプションでUpdateを実行します。完了後、項目のタイプ、サーバー、ポートを確認してください。取得に失敗した場合は、サブスクリプションのURLに接続できない問題とプロキシサーバーに接続できない問題を切り分け、混同しないでください。
- テストする項目を選択：Homeで確認対象のHysteria2項目を選び、その名前とポートを記録します。ポリシーグループで接続先を選ぶ場合は、実際にその項目が選択されていることも確認してください。
- ルーティング条件を固定：Global Routingで一時的にProxyを選択し、選んだ接続先を確認します。テスト後は元のルーティングモードに戻してください。Directではプロキシ経路を確認できません。Configの場合は、現在の設定にあるルールを踏まえて判断する必要があります。
- 接続してリクエストを送信：接続スイッチをオンにします。初回利用時は、システムの案内に従ってVPN構成を許可してください。その後、正常にアクセスできることが分かっているページを開き、ハンドシェイク、認証、証明書、名前解決に関するエラーがないか確認します。
- 通常の設定に戻す：Global RoutingでConfigに戻し、同じリクエストに適用されるルールとポリシーを確認します。Proxyでは使えても、ルールに戻すと別の接続先に振り分けられていないか確認してください。
ハンドシェイクのタイムアウト、証明書エラー、ルーティングの問題を切り分ける
原因を調べるときは、設定項目を一度に何度も変更するより、接続の段階ごとに分類するほうが問題を特定しやすくなります。現在のネットワーク、選択中の項目、Global Routingのモード、エラーメッセージを記録し、一度に変更するのは1項目だけにしてください。遅延テストで結果が出ても、そのテストで応答が確認できた範囲を示すにすぎません。実際のWebリクエストの代わりにはならず、あらゆるUDP転送が正常だと証明するものでもありません。
同じ項目がWi-Fiではタイムアウトし、モバイル通信では使える場合
サーバー、ポート、認証情報はそのままにして、ネットワークだけを切り替えて再テストします。差が一貫して現れる場合は、Wi-FiのUDP送信制限、ルーティング、ファイアウォールを優先して確認してください。TCPの443番ポートに接続できても、UDPの443番ポートが使えるとは限りません。UDPが遮断されてもHysteria2が自動的にTCP接続へ切り替わることはありません。
証明書の名前が一致しないと表示された場合、どこを確認すればよいですか？
Homeに戻って該当項目を編集し、既存の設定と照らし合わせてサーバーアドレスとSNIを確認します。デバイスの日付と時刻が正しいことも確認してください。アドレスがIPアドレスで、証明書がドメイン名に発行されている場合は、設定で指定された名前を使って検証します。それでもエラーが出る場合は、検証を無効にせず、サーバー側で証明書を確認する必要があります。
Proxyでは開けるのに、Configでは開けない場合
Configで現在使用中の設定を確認し、ルールの順序と接続先ポリシーを調べます。ルールは通常、上から順に照合されます。DOMAIN-SUFFIX、IP-CIDR、GEOIP、FINALによって、同じリクエストでも異なるポリシーに振り分けられる場合があります。まず実際に適用されたルールを確認し、この結果だけでHysteria2のハンドシェイクに失敗したと判断しないでください。
接続直後は正常でも、データ転送を続けると遅延が大きくなる場合
まず、上り回線を使用する他のタスクを停止します。次に既存の設定にある帯域幅のパラメータと単位を確認し、同じリクエストで再テストしてください。画面で調整可能な項目があれば、少しずつ値を下げてキューによる遅延の変化を確認します。ポート、SNI、認証情報を同時に変更すると、どの変更が影響したのか判断できません。
一部のWebサイトだけに接続できない場合は、DNS名前解決、ルールの適用先、接続先サービスの制限をそれぞれ切り分けてください。接続スイッチがオンでも、システムのVPNが該当状態にあることを示すだけで、すべてのドメインが同じ接続先を経由するとは限りません。自動接続を設定する場合、Settings → On Demandは接続を開始するための設定であり、Hysteria2の認証情報やポートの誤りを修正する機能ではありません。
条件を固定して、現在のネットワークに合うか評価する
評価では、1回の最高速度ではなく、日常的に使用するネットワークを基準にします。デバイス、サーバー、接続先、Global Routingのモードをそろえ、近い時間帯に繰り返しテストしてください。Wi-Fiとモバイル通信の結果は分けて記録します。同じ条件でのデータがなければ、「何パーセント向上した」と判断することはできません。
- 接続成功率を記録：例として、毎回切断してから5回連続で接続を試し、成功回数と失敗した段階を記録します。これはテスト方法であり、プロトコルの実測データではありません。
- 応答遅延を記録：ページを開いたときの最初の応答と、データ転送中の操作感を確認します。平均スループットが高くても、ページを最初に開く速度が速いとは限りません。
- ネットワーク切り替えの影響を記録：Wi-Fiからモバイル通信に切り替え、リクエストを再送します。通信セッションを継続できるかはネットワークや実装によって異なるため、QUICという名称だけで継続を保証することはできません。
- 通信量と消費電力を記録：データ通信量とデバイスのバッテリー消費に注意します。再送や追加の通信によって、統計値がアプリ内のコンテンツ容量を上回る場合があります。実際の使用状況に基づいて判断してください。
安定して再現できる設定を保管したうえで、通常のConfigルーティングに戻します。特定のネットワークだけで失敗する場合は、その通信経路を優先して調査してください。Hysteria2を選ぶ際は、UDPの疎通、パラメータの正確さ、繰り返しテストした結果を基準にします。あらゆる通信問題を解決する手段として、プロトコルの種類だけで判断しないでください。