Hysteria2の効果は、UDPの到達性やパケットロスの原因、帯域幅の設定によって異なり、プロトコルを変えれば必ず速くなるわけではありません。利用者自身が用意したサービス事業者の設定またはサブスクリプションを持つ方を対象に、QUICの通信、輻輳制御、パラメータの確認、Shadowrocketでのルーティングテストを順に解説します。プロトコルの制約、設定ミス、ネットワークのボトルネックを見分けるためのガイドです。
1. Hysteria2とQUIC・UDPの関係
Hysteria2はプロキシプロトコル、QUICはその基盤となるトランスポート、UDPはQUICパケットを運ぶトランスポート層のプロトコルです。それぞれ異なる階層を指すため、Hysteria2を「すべてのリクエストをUDPに変えるもの」と捉えるのは正確ではありません。アプリが送信するTCP接続はHysteria2のQUIC streamを介して転送でき、アプリのUDPトラフィックは対応するデータグラム転送方式で処理されます。
QUICはTLS 1.3を基盤に暗号化接続を確立し、独立したstreamを提供します。あるstreamでデータが失われても、単一のTCPバイトストリームで複数のリクエストを多重化する場合のように、他のstreamまで同じ欠落データを待つ必要はありません。ただし、同一stream内では引き続き順序どおりの配信が必要です。また、複数のstreamは経路の容量と輻輳制御を共有するため、パケットロスが他のリクエストにまったく影響しないとは限りません。
Hysteria2の外側の接続はUDPに依存します。WebサイトをHTTPSで利用できても、プロキシ接続がネットワークを通過できるとは限りません。TCP 443は許可されていてもUDP 443は制限される場合があります。同じポート番号でも、到達性は個別に確認してください。
2. 輻輳制御がパケットロスの多い回線に与える影響
輻輳制御は、送信側がデータを送るタイミングと速度を決めます。従来のパケットロスベースのアルゴリズムは、ロスを輻輳の兆候とみなして送信速度を下げることがよくあります。しかし、無線干渉や回線の揺らぎなどもパケットロスの原因になります。ロスが経路容量の逼迫を示していない場合、過度に速度を落とすと、残っている容量を活用できないことがあります。
Hysteria2では、設定された帯域幅の目標値と観測したパケットロスに応じて送信ペースを調整するBrutalを使用できます。パケットロスを無視するのではなく、失われたデータ量を補い、有効スループットを目標に近づけようとします。QUIC streamの信頼性は確認応答や再送などの仕組みで確保されます。「輻輳制御による補償」は、失われたデータを復元しなくてよいという意味ではありません。
- ランダムなパケットロスがあるものの、容量に余裕がある場合：帯域幅の目標値が適切なら、Brutalはパケットロスに応じて大きく速度を落とすアルゴリズムより、高いスループットを維持できる場合があります。
- 実際に輻輳している場合：ボトルネックの回線がすでに飽和しているときに目標速度を上げ続けると、キューイングやパケットロス、操作時の遅延が増える可能性があります。
- 容量が変動する場合：モバイル回線の利用可能な容量は、電波状況や混雑によって変化します。固定の目標値がある時間帯には適切でも、別の時間帯には高すぎることがあります。
- アルゴリズムのネゴシエーション：Hysteria2にはBBRを使用する動作経路もあります。具体的な方式はクライアントの実装、帯域幅の設定、サーバーとのネゴシエーションによって異なるため、プロトコル名だけでは現在のアルゴリズムを判断できません。
MbpsとMB/sの違いにも注意してください。一般に前者は毎秒メガビット、後者は毎秒メガバイトを表します。10進法で換算すると80 Mbpsは約10 MB/sですが、プロトコルのオーバーヘッドを差し引く前の値です。入力する前にフィールドの単位を確認し、ダウンロードアプリに表示されたMB/sの数値をそのままMbpsとして入力しないでください。
3. Shadowrocketで既存の設定を確認する
ShadowrocketのHysteria2設定には、利用者がすでに持っている接続情報を使用します。まずHomeで該当項目の編集画面を開き、プロトコルの種類とサーバーのパラメータを確認してください。項目がサブスクリプションから生成されている場合、手動で変更する前に元の値を記録しておきましょう。次回の更新でローカルの変更が上書きされることがあります。画面の表示は変更される場合があるため、以下の英語表記はパラメータの意味を確認するためのものです。すべてのバージョンで項目の配置が同じとは限りません。
接続と認証
- Type
- 項目名だけを変更せず、Hysteria2を選択します。
- Server
- 既存の設定に記載されたホスト名またはIPアドレスを入力します。
- Port
- サーバーが待ち受けているUDPポートと一致させます（例：443）。
- Password
- サーバーの認証情報と一致させます。余分なスペースや改行を追加しないでください。
ポート番号は例です。実際の値は、利用者がすでに持っている設定を確認してください。
暗号化と通信
- SNI
- 証明書の検証に必要なドメイン名と一致させます。
- Certificate
- 証明書の検証は有効のままにし、まずドメイン名、有効期間、デバイスの時刻を確認します。
- Obfuscation
- 設定でSalamanderが必要な場合は、モードとキーを両端で一致させます。
- Bandwidth
- 上り・下りの方向と単位を確認し、実際の容量に合わせて設定します。
SNIや証明書の設定ミスを隠すために、証明書の検証を無効にしないでください。
ServerとSNIは異なる役割を担う場合があります。前者は接続先を指定し、後者はTLSハンドシェイクのServer Name Indicationに使われ、通常は証明書の名前との照合にも関係します。接続先にIPアドレスを使用する場合でも、証明書に対応するドメイン名の設定が必要なことがあります。証明書エラーが発生したら、ポートを何度も変えるのではなく、デバイスの時刻とドメイン名が正しいかを先に確認してください。
- Homeで、テスト対象のHysteria2項目が実際に選択されていることを確認します。別の項目を編集したまま、もう一方に接続することを防げます。
- テスト中はGlobal RoutingでProxyを選び、ルールによる迂回が結果に影響しないようにします。元の設定を記録し、テスト後に戻してください。
- 接続を確立し、同じテスト先にアクセスして、表示できるか、最初の応答までの時間、継続転送時の状態をそれぞれ記録します。
- サブスクリプションを更新した場合は、更新後に種類、ポート、帯域幅の項目を再確認し、想定した設定でテストしていることを確かめてください。
4. まずルーティングを確認し、プロトコルが使われているか判断する
項目がHysteria2に対応していても、すべてのリクエストがHysteria2を経由するとは限りません。Global RoutingでDirectを選ぶと、プロキシ経由ではなく直接接続します。Configでは現在の設定に基づいてリクエストが処理され、Proxyはプロキシ経由のルーティングテストに使われます。Sceneは現在のシーン設定と合わせて確認してください。トラブルシューティングでは、まずルーティングの状態を固定します。そうしないと「プロトコルを変えても速度が変わらない」原因が、リクエストの直接接続にある可能性を見落とします。
以下はルールの照合順を説明するための最小限の例で、接続設定一式ではありません。PROXYはポリシーの宛先であり、Hysteria2というルールキーワードではありません。最終的にどのアウトバウンドが使われるかは、現在の選択と設定を確認してください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,PROXYはexample.comとそのサブドメインに一致します。構文の説明には予約済みのサンプルドメインを使用しています。IP-CIDRの行は、指定したプライベートアドレス範囲への接続を直接行います。no-resolveを指定すると、この行の照合のためにドメイン名を明示的に名前解決するのを避けられます。GEOIP,CN,DIRECTはIPの地理情報データベースに基づいて照合します。結果は宛先アドレスとデータベースの内容によって異なり、ドメインの所在地と同じとは限りません。FINAL,PROXYは、先行するルールに一致しなかった場合の最終ルールです。ルールは上から順に照合されるため、より具体的な例外は最終ルールより前に記述してください。
Settings → On Demandでは自動接続の条件を設定します。ドメインにHysteria2を割り当てたり、上記のルールの順序を変えたりする機能ではありません。再現性のある接続テストを行うには、まずOn Demandの設定を記録し、手動でテストしてください。ネットワークの切り替えによる自動再接続とパラメータの問題が混同されるのを防げます。
5. テストに向いているネットワークと効果を制限する条件
Hysteria2をテストするには、対象のUDPポートに到達でき、利用者が対応するサーバー設定をすでに持っていることが前提です。遅延が大きく、輻輳以外の原因でパケットロスがある一方、帯域幅に余裕がある経路は、スループットを確認する価値があります。ボトルネックがローカルのWi-Fi、サーバーの出口回線、または接続先Webサイトの速度制限にある場合、プロトコルを変えても上限は解消できません。
- 比較条件をそろえる：同じデバイス、同じネットワーク、同じテスト用ファイルを使い、近い時間帯に測定します。サブスクリプションの更新や複数のパラメータ変更を同時に行わないでください。
- 接続確立と継続転送を分けて確認する：ハンドシェイクが完了するかを記録した後、継続ダウンロードの状態を記録します。接続性テストで確認できるのは特定のプローブが成功したことだけで、スループット全体の測定にはなりません。
- 負荷時の遅延を確認する：ダウンロード中にWebページの応答も確認します。スループットが少し上がっても操作が明らかに重くなる場合は、帯域幅の目標値が高すぎるか、キューが輻輳している可能性があります。
- 別のアクセスネットワークでも確認する：同じ設定でWi-Fiでは失敗し、モバイル回線では成功する場合、アクセスネットワークのUDP制御、NAT、または経路品質の違いが考えられます。それだけで設定が正しいと断定することはできません。
- 一度に変更するのは1項目だけ：まず到達性を確認し、次に認証と証明書を確認してから、最後に帯域幅を調整します。変更するたびに、同じ条件でテストしてください。
6. よくある質問と確認の順序
ほかの接続は使えるのに、Hysteria2だけタイムアウトするのはなぜですか？
まずHomeでServerとPortを確認し、サーバー側の該当するUDPポートに到達できることを確かめてください。TCP接続が成功しても、UDPが許可されているとは限りません。設定を変えずに別のアクセスネットワークで再テストします。ネットワークによって結果が変わる場合は、まずネットワークの制限を確認し、その後に認証情報とサーバーの待ち受け状態を調べてください。
帯域幅の数値を大きくするほど速くなりますか？
いいえ。まずフィールドの単位と上り・下りの方向を確認し、利用者自身が安定して測定した値を基準に少しずつ調整してください。目標値を上げても遅延が大幅に増え、有効スループットが向上しない場合は、さらに数値を上げず、直前の設定に戻してください。
接続済みなのに、直接接続したような結果になるのはなぜですか？
Homeで選択中の項目を確認し、次にGlobal Routingを確認してください。Proxyを一時的に使ってテストの基準を作ります。Configに戻したときに動作が変わる場合は、Configで対象が先にDIRECTに一致していないか、FINALが想定したポリシーに設定されているかを確認してください。
ネットワークを切り替えた後に切断されました。すべてのパラメータを入力し直す必要がありますか？
すぐにパラメータを変更する必要はありません。まず新しいネットワークで接続できることを確認してから、トンネルを再確立し、Settings → On Demandの接続条件を確認してください。QUICには接続移行に関する機能がありますが、接続を維持できるかどうかは実装、NAT、経路のポリシーにも左右されます。ネットワークを切り替えても必ず切断されないという保証ではありません。
まずUDPの到達性を確認し、次に認証、証明書、ルーティングを確認してから、輻輳制御と帯域幅の目標値を検討してください。同じ条件でスループット、遅延、失敗時の状況を記録して初めて、Hysteria2が現在の経路に適しているか判断できます。Shadowrocketはクローズドソースの商用アプリであり、クライアントの買い切り購入と回線プランは別です。本サイトはノードやサブスクリプションを提供・販売・推奨していません。