Hysteria2は、UDPで通信でき、往復遅延が大きい、またはランダムなパケットロスが発生するネットワークで検証する価値があります。ただし、プロトコル名だけで速度は判断できません。本記事では、自分で用意したサービス事業者の設定やサブスクリプションを持つユーザーを対象に、QUICの仕組みを説明したうえで、Shadowrocketへの読み込み、ルーティングの確認、再テストの手順を紹介します。設定ミス、UDPの制限、ルールの不一致を切り分ける際に役立ててください。
1. Hysteria2とQUIC：メリットの仕組み
ShadowrocketのHysteria2は、プロキシプロトコルの選択肢の一つです。QUICを通信基盤とし、UDPでデータを運び、TLS 1.3で安全な接続を確立します。ここでは2つの点を区別する必要があります。基盤にUDPを使うからといって、アプリケーションのデータがすべて信頼性のない方式で送られるわけではありません。QUICはUDP上で、ストリームごとの順序制御、損失回復、フロー制御を行えます。
従来のTCP接続では、複数のアプリケーション要求が一つの順序付きバイトストリームを共有する場合、パケットロスが発生すると後続データの受け渡しが滞ることがあります。QUICはストリームごとにデータの受け渡しを管理するため、あるストリームで欠落データを待っていても、その影響だけでほかのストリームまで待たされることはありません。ただし、各ストリームは輻輳制御や回線容量を共有する場合があります。「ストリーム間の受け渡し待ちが減る」ことは、「パケットロスの影響がなくなる」ことを意味しません。
- UDP：データグラムを運ぶ仕組みであり、信頼性の高い配信を自ら保証するものではありません。また、ネットワークの速度制限を自動的に回避するものでもありません。
- QUIC：トランスポート層で接続管理、安全なハンドシェイク、複数ストリームの機能を実現します。各ストリーム内では、引き続き順序を保ってデータを受け渡します。
- Hysteria2：QUIC上でプロキシ通信を構成し、スループットを重視した輻輳制御と帯域幅の設定機能を備えています。
- 実際の使用感：Wi-Fiの電波状況、回線の混雑、サーバー負荷、接続先のサイト、設定値などにも左右されます。
一部のランダムなパケットロスがある回線でHysteria2のスループットが向上する場合、帯域幅を基準とした輻輳制御方式も関係しています。QUICを使う接続すべてで同じ結果になるわけではありません。クライアント側の帯域幅の申告値、サーバー側の制限、ネゴシエーションの結果も動作に影響します。「QUICを使う」だけで、一定の速度向上率が得られると考えることはできません。
2. 高遅延・高パケットロス：まずボトルネックを切り分ける
高遅延とは、リクエストを送信してから応答を受け取るまでに時間がかかる状態です。Hysteria2でも物理的な距離による往復時間は短縮できませんが、適した回線では高いスループットを維持できる可能性があります。高パケットロスについては、無線干渉によるランダムな損失と、キューの継続的な混雑による損失を分けて考える必要があります。どちらにも同じ対処法が適するとは限りません。回線がすでに混雑している状態で送信量だけを増やすと、通話やウェブ閲覧、ほかのデバイスの通信まで悪化することがあります。
| ネットワークの状態 | 考えられる原因 | 確認方法 |
|---|---|---|
| 小さなウェブページは表示できるが、大容量ファイルの転送が遅い | パケットロス、混雑、接続先の帯域幅などが考えられます。遅延だけでは判断できません。 | 同じネットワークで同一のファイルとサーバーを使い、複数回転送して所要時間を記録します。 |
| アイドル時は問題ないが、ダウンロード中に遅延が大きくなる | 回線のキューが滞留している可能性があります。送信設定を強めると、状態が悪化することがあります。 | ほかの大容量通信を止め、帯域幅の申告値を下げてから比較します。 |
| Wi-Fiでは接続できないが、モバイル通信では接続できる | Wi-Fi側でUDPが制限されている、またはDNSや外部への通信経路のポリシーが異なる可能性があります。 | 設定は変えずにネットワークだけを切り替え、名前解決とハンドシェイクの結果をそれぞれ確認します。 |
| 最初のリクエストは遅いが、継続的な転送は正常 | DNS、接続の確立、接続先サイトの応答を分けて確認します。 | 最初に開くまでの時間と、その後の転送状況を別々に記録します。 |
結論：一度に一つだけ変更して再テスト
サーバー、接続先のリソース、ルーティング経路を固定したうえで、ネットワークを切り替えるか、パラメーターを一つだけ変更して比較すると、結果を判断しやすくなります。サブスクリプション、DNS、Global Routingを同時に変更して、改善をHysteria2の効果だと判断しないでください。
記録方法を決めておくと比較しやすくなります。各ネットワークで同じリソースを3回転送し、毎回約60秒間、転送したバイト数、所要時間、中断の有無、テストした時間帯を記録します。これは再テストの方法であり、製品の性能データではありません。1回だけのピーク値や遅延の測定値だけでは、現在のネットワークにそのプロトコルが適しているとは証明できません。
3. ShadowrocketにHysteria2を読み込み、設定を確認する
自分がすでに持っているサブスクリプションまたは完全な設定を使います。Hysteria2を利用するにはサーバー側の対応が必要です。既存サーバーのTypeをHysteria2に変更するだけでは使えません。読み込み後はAddress、Port、認証情報、TLSパラメーターを確認してください。サブスクリプションに設定がすべて含まれている場合は、経験だけを頼りに項目を追加するより、元の値を維持するほうが確実です。
-
既存のサブスクリプションを読み込む
Homeを開き、右上の「+」→ Type → Subscribeの順にタップします。自分がすでに利用しているサブスクリプションURLを貼り付けて保存してください。サブスクリプションURLにはアクセス認証情報が含まれるため、スクリーンショットやトラブルシューティングの記録に公開しないでください。
-
プロトコルの種類を確認する
Homeに戻り、読み込んだサーバーの編集画面を開いて、TypeがHysteria2になっているか確認します。サブスクリプションにこの種類が含まれていない場合は、自分でTypeを変更せず、設定の提供元に確認してください。
-
接続情報を確認する
Address、Port、認証情報、SNIを一つずつ確認します。Portは接続先の待ち受けポートと一致している必要があります。たとえば、接続先で443が明示されている場合に限り443を設定してください。共通の既定値として扱わないでください。
-
テスト経路を固定する
Homeでテスト対象のサーバーを選び、Global Routing → Proxyを開きます。接続後、同じ接続先のリソースをテストしてください。ポリシーグループを使っている場合は、実際に選択されているメンバーも確認し、別のサーバーをテストしてしまわないようにします。
-
通常の設定に戻す
検証が終わったら、Global Routingを元のConfigに戻してから、接続先のリソースに再度アクセスします。Proxyでは正常でConfigでは問題が起きる場合は、ルールやポリシーグループを確認してください。最初に通信パラメーターを変更する必要はありません。
SNIはTLSハンドシェイクでサーバー名を示すために使われます。元の設定に従って入力してください。接続先がIPアドレスでも、証明書に対応するドメイン名を別途指定する必要がある場合があります。証明書エラーが発生した場合は、サーバー名、証明書の有効性、デバイスの日時を確認してください。証明書の検証を緩めて問題を隠さないでください。設定に偽装パラメーターが含まれる場合は、クライアントとサーバーの設定を一致させる必要があります。片側だけ有効にしても、UDPが通らない問題は解決しません。
4. Global Routing：通信の問題とルーティングの問題を切り分ける
Global Routingは、リクエストの送信経路を選択する機能であり、特定のプロトコルを高速化するものではありません。トラブルシューティングでよくある誤りは、Hysteria2サーバーを選択しただけで、対象のリクエストが実際にそのサーバーを経由しているか確認しないことです。ここではShadowrocketのルーティングモードを比較します。おすすめは日常使用向けであり、トラブルシューティング時にも必ず同じモードを使うべきという意味ではありません。
Config：設定に基づくルーティング
おすすめ現在有効な設定のルールに従ってリクエストを処理します。接続先はDIRECT、プロキシ、またはポリシーグループに振り分けられる場合があります。サーバーを選択しても、すべてのリクエストがそのサーバーを使うとは限りません。
適した用途：ルールの確認が済んでいる日常の接続。
Proxy：プロキシ経路を検証
このモードの対象となるリクエストをプロキシ経路に送信し、ルールマッチングの影響を一時的に減らして確認できます。現在選択されているサーバーまたはポリシーグループのメンバーも確認してください。
適した用途：サーバーに接続できるかの確認、ルールの誤マッチの切り分け。
Direct：直接接続を基準にする
選択中のプロキシサーバーを経由せず、直接接続します。ローカルネットワーク自体に問題があるかを確認できますが、直接接続の結果からHysteria2のUDPハンドシェイクが正常だとは判断できません。
適した用途：ローカルネットワークとプロキシ経路の状態を比較する。
Configでトラブルシューティングを行う場合は、まずどの設定が有効かを確認し、次にルールの順序を確認します。DOMAIN-SUFFIXはドメインの末尾に基づいてマッチし、IP-CIDRはIPアドレスの範囲に基づいてマッチします。GEOIPはIPアドレスの地理情報に依存し、FINALはそれ以前のルールに一致しなかったリクエストを処理します。末尾にプロキシのポリシーがあるからといって、それより前にマッチしたDIRECTルールを見落とさないでください。
- Proxyでは正常、Configでは問題が発生：まずマッチしたルール、ポリシー名、ポリシーグループのメンバーを確認します。
- どちらのモードでも接続を確立できない：まず名前解決、UDPの到達性、認証情報、TLSパラメーターを確認します。
- 接続が頻繁に自動で再確立される：Settings → On Demandで設定済みのオンデマンド接続条件を確認し、接続管理の動作と通信障害を切り分けます。
5. UDPが制限されている場合：ポート、ハンドシェイク、MTUの注意点
Hysteria2の外側の通信にはUDPが必要です。ネットワークでTCP 443に接続できても、UDP 443も許可されているとは限りません。ウェブページが開けても、QUICが使えるとは限りません。ポート番号が同じでも、トランスポートプロトコルが異なれば、ファイアウォールやトラフィック制御の扱いも異なります。
接続がタイムアウトする場合は、まず接続先でUDPが待ち受けているか、ネットワークでUDP通信が許可されているかを確認してください。Portを443に変更する意味があるのは、サーバーが実際にUDP 443で待ち受けている場合だけです。理由なくポートを変更すると、設定ミスが増えるだけです。ポートホッピングを利用するには、サーバー側のポート範囲とクライアント側の設定を合わせる必要があります。UDP全体が遮断されている環境を解決できるものではありません。
- 認証エラーがすぐに返される：まず認証文字列、サブスクリプションが更新済みか、正しい項目を選択しているかを確認します。
- 証明書エラーが明示される：まずSNI、証明書の名前、デバイスの日時を確認します。帯域幅不足として扱わないでください。
- しばらく待ってからタイムアウトする：Address、Port、DNSの結果、UDPの通信経路を確認します。タイムアウトだけでは、どこでパケットロスが起きたかは判断できません。
- ハンドシェイクは成功するが、転送が止まる：回線の混雑、パスMTU、接続先の負荷、対象サイトの応答を確認します。
QUICの初期データグラムでは、UDPペイロードに少なくとも1200バイトが必要です。経路上で該当するパケットを正しく転送できない場合、ハンドシェイクやその後の通信に問題が生じることがあります。ただし、通信が滞るたびにMTUを変更するのは一般的な解決策ではありません。パスMTU、トンネルのオーバーヘッド、アプリ内で調整できるパラメーターは同じものではありません。また、WireGuardの設定にあるMTU値をそのままHysteria2に適用しないでください。まず既定値と元の設定を維持し、明確な診断根拠がある場合に限って変更します。
6. よくある質問と最終的な選び方
遅延の数値が低ければ、必ず速いですか？
いいえ。まずHomeで使うサーバーとGlobal Routingのモードを固定し、ウェブページの初回応答と継続的な転送をそれぞれ測定してください。遅延は特定の測定方法による結果にすぎず、スループットや安定性、実際の利用状況を代替するものではありません。
モバイル通信に切り替えると接続できるのはなぜですか？
同じサーバー、ポート、認証情報を使い、Wi-Fiとモバイル通信を比較してください。Wi-Fiだけで失敗する場合は、まずそのネットワークのUDPポリシー、DNS、外部への通信条件を確認します。一つのネットワークに合わせるために、正しい認証情報を何度も変更しないでください。
サブスクリプションを更新できるのに、サーバーに接続できないのはなぜですか？
サブスクリプションの取得とHysteria2の通信は、別々の経路で確認する必要があります。更新に成功したことから分かるのは、設定を取得できたということだけです。Homeに戻り、読み込んだ項目のType、Address、Portを確認してから、Global Routing → Proxyで接続を個別に検証してください。
すべてのネットワークでHysteria2に切り替えるべきですか？
その必要はありません。UDPが制限されているネットワークや、現在の接続がすでに安定している場合は、使えている設定を維持するほうが適切です。既存の設定に別の通信方式が含まれている場合は、同じ接続先と時間帯で比較できます。プロトコル名が新しいという理由だけで、検証済みの経路を置き換えないでください。
最終的な選択は、再現性のある接続結果に基づいて判断してください。UDPが到達可能で、パラメーターが正しく、継続的な転送も安定している場合に、Hysteria2を日常の設定に加えるのが適切です。高遅延やランダムなパケットロスは検証する理由にはなりますが、性能を保証するものではありません。確認すべきなのは「現在のネットワークでより安定するか」「目的の作業がよりスムーズになるか」であり、テスト条件を離れた速度ランキングではありません。