Hysteria2の利点は、QUICの通信方式と帯域に応じた輻輳制御によるもので、UDP自体に速度保証があるわけではありません。サービス設定をすでにお持ちの方に向けて、回線条件、認証・TLS設定、Shadowrocketでの設定手順、UDPの通信不可・証明書エラー・ルールによる振り分けの見分け方を解説します。まず接続を確立し、その後にスループットを確認しましょう。
Hysteria2・QUIC・UDPの役割
ShadowrocketのHysteria2は、プロキシプロトコルの選択肢のひとつです。QUICをベースとし、そのパケットはUDPで運ばれます。この3つは同じものではありません。UDPはデータグラムを転送し、QUICはその上で暗号化、接続管理、信頼性のあるストリームを実現します。Hysteria2はさらに、プロキシ認証やリクエスト転送、関連する通信動作を定めています。サーバーが該当プロトコルに対応している必要があり、既存の設定のTypeをHysteria2に変えるだけでは切り替えられません。
UDP自体には、データの到達や順序を保証する機能はありません。ただし、Hysteria2経由でWebページを開いたときにページ内容が失われるという意味ではありません。信頼性が必要なデータはQUICのストリーム機構が確認応答と再送を行います。プロキシ経由のUDPトラフィックはデータグラム機構で運べますが、その性質は信頼性のあるバイトストリームとは異なります。プロトコルの性能を判断するときは、外側の転送方式と、内部アプリケーションが実際に使用する接続を区別してください。
ポートは、現在お持ちのサービス設定に従ってください。同じ番号でもTCPポートとUDPポートは別の通信方式です。サーバーのTCP 443に接続できても、UDP 443が使えるとは限りません。通常のWebページが開けても、そのページに使われた経路が利用可能だと分かるだけで、Hysteria2のハンドシェイク確認にはなりません。
高遅延・パケットロスのある回線で効果が期待できる理由
ネットワークのスループットは、公称帯域だけでなく、往復遅延、パケットロス、送信ウィンドウ、輻輳制御にも左右されます。パケットロスを基準とする従来の制御方式では、無線干渉によるランダムなロスも輻輳と判断し、送信速度を下げる場合があります。Hysteria2独自の輻輳制御は、このような条件でも回線容量をより積極的に活用することを目指します。ただし、この制御が使われるかどうかや実際の効果は、クライアント、サーバー、帯域のネゴシエーション設定にも左右されます。
QUICのマルチストリーム機能は、ストリーム間で発生するトランスポート層のHead-of-Line Blockingを軽減します。あるストリームでパケットロスの再送を待つ間、同じ順序付きバイトストリームの欠落によって、ほかのすべてのストリームまで直接停止する必要はありません。ただし、パケットロスがなくなるわけではなく、信頼性のある同一ストリームでは欠落データの補完を待つ必要があります。また、複数のストリームは回線容量や輻輳状態を共有します。したがって、「QUICを使えばどのネットワークでも速くなる」とは限りません。
- 高遅延でランダムなパケットロスがある：UDPで通信でき、サーバーのリソースにも余裕があれば、積極的な送信制御によって継続通信のスループットが向上する可能性があります。
- 低遅延でパケットロスが少ない：ボトルネックがアクセス回線の帯域、サーバーの送信帯域、接続先サイトにある場合、プロトコルを変えても体感できる差が出ないことがあります。
- 回線自体が輻輳している：送信量をさらに増やすと、キューイングやジッター、パケットロスが増える可能性があります。パケットロスのすべてを無線干渉のせいにすることはできません。
- UDPが遮断または帯域制限されている：ハンドシェイクのタイムアウトや、接続後の継続的な通信制限が起きることがあります。プロトコルの仕組みで経路上の制限を解消することはできません。
結論：まずUDPの到達性を確認し、その後で帯域を調整
接続がハンドシェイクの段階で止まる場合は、まずサーバーアドレス、UDPポート、利用中のネットワークを確認してください。到達性の問題を帯域の数値を上げて解決しようとしてはいけません。安定して接続できてから、スループットや遅延を比較しましょう。
設定前に、アドレス・認証・TLSを確認
Hysteria2の設定には、正しいサーバーアドレス、ポート、認証情報が必要です。TLSによる接続先確認、obfuscation、帯域の設定は、現在お持ちのサービス設定に合わせてください。サブスクリプションに含まれる設定は確認の出発点として使い、すべてを経験だけで上書きしないようにしましょう。特に、サーバーの接続先アドレス、証明書名、認証パスワードは別々の項目です。
| 項目 | 入力・確認方法 | よくある誤解 |
|---|---|---|
| サーバーアドレスとPort | 既存の設定に従ってドメイン名またはIPアドレスと、対応するUDPポートを入力します。ポート番号の範囲は1～65535です。 | すべてのサービスが443を使うと思い込む、またはTCPで接続できることをUDPでも接続できる証拠とみなす。 |
| 認証情報 | 大文字・小文字や文字列全体をそのまま保持します。サービス側で組み合わせ形式が指定されている場合は、指定どおりに入力してください。 | 複合形式の認証情報の一部しか入力しない、またはコピー時に空白や改行が混入する。 |
| SNIと証明書 | サービスの設定に従ってTLS名を入力し、証明書および接続先との関係を確認します。 | IPアドレスを直接入力して名前の不一致が起きたため、証明書の検証を無効にする。 |
| obfuscation | サーバー側で必要な場合のみ設定します。たとえばSalamanderを使う場合、クライアントとサーバーで方式とパスワードを一致させる必要があります。 | 必要がないのにobfuscationを追加する、またはobfuscationのパスワードを認証パスワードと間違える。 |
| 帯域 | 実際に利用できる上り・下りの速度とサービス側の指定に合わせ、画面上の単位も確認します。 | 数値を速度の倍率だと思い込む、またはMbpsとMB/sを混同する。 |
たとえば、現在の設定で接続先にIPアドレス、TLSの識別にドメイン名を使っている場合、アドレス欄とSNIが異なるのは正常です。無理に一致させず、元の設定を確認してください。証明書エラーが起きたら、システム時刻、SNI、証明書の有効性、サービス設定を確認します。証明書検証は有効のままにし、検証をスキップしてエラーを隠さないでください。
Shadowrocketに追加して、最初の確認を行う
以下の手順は、ご自身のHysteria2設定情報をすでにお持ちであることを前提としています。既存のサブスクリプションを使う場合は、Home右上の「+」からTypeをSubscribeに設定し、ご自身のサブスクリプションURLを入力して保存します。更新後、生成された設定のTypeと各項目を確認してください。サブスクリプションの取得失敗とHysteria2のハンドシェイク失敗は別の問題です。前者は設定の取得中、後者は個別の設定で接続を確立するときに発生します。
-
既存の設定情報を確認する
アドレス、UDPポート、認証情報に加え、サービス側で指定されているSNI、obfuscation、帯域の設定を用意します。旧Hysteriaのプロトコル設定を、そのままHysteria2の設定として扱わないでください。
-
設定を追加する
Homeの右上にある「+」をタップし、TypeからHysteria2を選択します。既存のサーバーアドレスとPortを入力し、数字の抜けや桁の入力間違いがないか確認します。
-
認証情報を入力する
認証情報全体をコピーし、obfuscationの設定は元の設定どおりに入力します。認証パスワードとobfuscationのパスワードは別々に確認してください。どちらもパスワード欄があるからといって、同じ値を入力しないようにしましょう。
-
TLSを確認する
SNIと証明書の検証設定を確認し、帯域の項目は画面に表示される単位で入力します。既存のサブスクリプションですでに設定されている場合は、最初のテストで複数の項目を同時に変えないよう、まず元の値を維持してください。
-
保存してテストする
保存後にHomeへ戻り、対象の設定を選択してGlobal Routingを確認してから接続を有効にします。初回の有効化時は、システムの案内に従ってVPN構成の追加を許可してください。その後、遅延の数値だけで判断せず、実際にWebページへアクセスして接続を確認します。
サブスクリプションを更新すると、そこから生成された設定が変更されることがあります。混乱を避けるため、テスト前に現在の設定とサブスクリプションの更新時刻を記録してください。手動で変更した場合は、更新後にもう一度確認します。トラブルの情報を共有するときは、認証情報とサブスクリプションのtokenを隠し、エラーの種類、ネットワークの種類、ポートだけを記載してください。認証情報をすべて公開の場に貼り付けてはいけません。
トラブルシューティングでGlobal Routingを選ぶ
プロトコル接続、ルーティングの状態、ルールの適用はそれぞれ異なる階層のものです。HomeでHysteria2の設定を選んでも、すべてのリクエストがその設定を使うとは限りません。Global RoutingやConfigのポリシーによって、リクエストがDIRECTで送信されたり、別のポリシーが選ばれたりすることがあります。特定の設定を調べるときは、まずルールの影響を減らし、確認後に普段の設定へ戻してください。
Proxy：ルールの影響を切り分ける
推奨短時間の切り分けにはProxyを使い、テスト対象のHysteria2設定が選択されていることを確認します。クライアントが処理する接続をプロキシ経由にできるため、Configのルールによる影響を減らせます。ただし、LANの除外など独立した設定には注意してください。
適した用途：設定の初回確認、プロトコルとルールの問題の切り分け
Config：普段の振り分けを確認
接続が有効だと確認できたらConfigに戻り、実際のリクエストに適用されるルールとポリシーを確認します。DOMAIN-SUFFIX、IP-CIDR、GEOIPなどのルールが通信先を決め、FINALは前のルールに一致しなかった場合の最終ポリシーを指定します。
適した用途：ルールを設定済みで、接続先に応じた振り分けが必要な場合
Direct：直接接続の状態を確認
Directは、直接接続でアクセスできるかを確認するためのもので、Hysteria2の設定が使える証明にはなりません。この状態でWebページが開いても、該当する直接接続のリクエストが成功したことしか分からず、プロキシのハンドシェイク完了を示すものではありません。
適した用途：ローカルのアクセス回線と接続先への直接接続を比較する
Proxyではアクセスできるのに、Configに戻すと特定のリクエストが失敗する場合は、すぐにHysteria2のパスワードを変更せず、Configのルール順と接続先のポリシーを確認してください。ルールは上から順に評価されるため、上位の広いルールが後続の詳細なルールより先に適用されることがあります。FINALはルール一覧の末尾に配置してください。また、PROXYが実際に使用する設定やポリシーグループが、テスト時と同じかも確認します。
よくあるトラブル：発生段階を見極め、変更は一度に1項目だけ
「接続スイッチがオン」「遅延テストに数値が出る」「接続先のWebページが開く」は、それぞれ異なる状態を示します。システムのVPN接続状態は、すべての接続先への通信が成功したことを意味しません。また、1回の遅延テストだけでは継続的な通信性能は分かりません。以下では観察できる現象をもとに切り分け、原因が必ずプロトコルにあるとは決めつけません。
Wi-Fiではタイムアウトするのに、モバイル通信では使える場合
同じ設定、同じポート、同じ接続先へのリクエストを使い、アクセス回線だけを切り替えて再テストします。差が繰り返し確認できる場合は、まずWi-Fi経路のUDP到達性、帯域制限、ファイアウォールのポリシーを確認してください。別の経路ですでに同じ設定で接続できているため、先にパスワードを変更する必要はありません。モバイルデータ通信の使用量にも注意してください。
証明書またはTLSエラーが表示されたら、検証を無効にする？
まずデバイスの時刻、設定内のSNI、現在お持ちのサービス設定を確認し、ドメイン名が想定したアドレスに解決されているかも確認してください。名前の不一致や証明書の期限切れは、該当する設定を修正します。証明書の検証を無効にすることを通常のトラブルシューティング手順にせず、ハンドシェイクのタイムアウトをすべて証明書エラーとみなさないでください。
小さなページは開くのに、大きなファイルの転送が頻繁に止まる場合
まず高すぎる帯域設定を下げ、同じネットワークで同じリクエストを再試行します。それでも同じ現象が起きる場合は、発生するタイミングを記録し、経路のMTU、UDPフラグメンテーション、帯域制限を確認してください。この現象だけを根拠にMTUを変更しないでください。サーバーの送信帯域や接続先サイト側の制限も考慮します。
手動接続は正常なのに、自動接続が期待どおりに動かない場合
Settings → On Demandで、スイッチと設定済みのネットワーク条件を確認し、現在のWi-Fiまたはモバイル通信環境が条件に合っているかを確かめます。プロトコルをテストするときは、On Demandによる切断や再接続で確認が妨げられないよう、まず手動で接続してください。プロトコルとルーティングが正常だと確認してから、On Demandを個別にテストします。
性能を比較するときは、デバイス、アクセス回線、設定、接続先のリソース、テスト時間帯をそろえ、1回につき1項目だけ変更してください。ハンドシェイクの成否、Webページの最初の応答までの時間、継続通信の安定性、負荷時に遅延が大きく上昇するかを記録します。異なる接続先への2回のダウンロードを比べて、特定のプロトコルが常にどれだけ速いかを結論づけないでください。
- まず確認：アドレス、UDPポート、認証、TLS、obfuscationが既存の設定と一致しているか確認します。
- 次に切り分け：手動接続と明示的なGlobal Routingの状態を使い、自動動作やルールによる影響を除外します。
- 最後に比較：再現可能な条件でスループットとジッターを観察し、変更によって実際に改善したか確認します。