Hysteria2はQUICを基盤とし、UDPで通信します。利用中のサービスが対応していることを前提に、高遅延やパケットロスのある経路での利用を検討できます。本記事では、速度面で効果が見込める条件、帯域幅や証明書の設定確認方法、Shadowrocketでプロトコルの不具合・ルールの問題・バッテリー消費の変化を切り分ける手順を解説します。プロトコル名だけで速度が保証されるわけではありません。
Hysteria2とQUICの関係
Hysteria2はプロキシプロトコル、QUICはその基盤となる通信方式です。ShadowrocketでHysteria2を選ぶと、対応するサーバーへの接続と、双方で一致する認証情報および通信パラメータが必要になります。既存設定のTypeをHysteria2に変更するだけで、サーバーが自動的に対応するわけではありません。
QUICはUDPを基盤としていますが、「UDPベース」だからといって信頼性確保をすべてアプリに委ねているわけではありません。QUIC自体が暗号化ハンドシェイク、信頼性のあるストリーム、パケットロスの検出や再送などの仕組みを備えています。Hysteria2はこれらを利用してプロキシ通信を行います。接続先のWebサイトがTCPを使っていても、クライアントからプロキシサーバーまでの区間はQUICで通信できます。2つの通信レイヤーは分けて考える必要があります。
QUICとHTTP/3は同じものではありません。HTTP/3はQUIC上で動作するHTTPのマッピングで、Hysteria2には独自の認証方式とプロキシデータの転送方法があります。ブラウザーでHTTPSページにアクセスできても、そのページへの経路が使えることを示すだけです。同じアドレスのHysteria2認証、UDPポート、データ転送が正常であることの証明にはなりません。
パケットロスのある経路で速くなる可能性がある理由
速度差には、輻輳制御、パケットロスからの復旧、多重化が関係します。従来のTCP輻輳制御では、通常、パケットロスをネットワーク混雑の兆候とみなし、送信ウィンドウを縮小します。ロスの主因が無線干渉や回線品質で、出口の混雑ではない場合、送信を抑えることで利用可能な帯域を十分に活用できないことがあります。Hysteria2の帯域幅パラメータと輻輳制御は、こうした経路に異なる送信方法を提供します。
QUICの独立したストリーム機構により、ストリーム間のヘッドオブラインブロッキングも軽減できます。あるストリームのデータが失われても、ほかのすべてのストリームが同じデータの再送を待つ必要はありません。ただし、同じ接続上のストリームは回線容量を共有し、輻輳制御の影響も受けます。また、信頼性のある同一ストリーム内では、データを順番どおりに届ける必要があります。パケットロスの影響がなくなるわけではありません。
- 高遅延かつランダムなパケットロスがある場合：復旧待ちや送信ウィンドウの変化が速度に影響しやすく、Hysteria2で持続的なスループットが安定する可能性があります。
- 低遅延かつパケットロスが少ない場合：回線帯域をすでに十分活用できていれば、プロトコルを変えても効果が目立たないことがあります。サーバー負荷や経路品質のほうが重要な場合もあります。
- UDPが遮断または継続的に制限されている場合：ハンドシェイクがタイムアウトしたり、接続できてもスループットを維持できなかったりする可能性があります。帯域幅の値を大きくしても、ネットワークの制限は解除できません。
- 出口がすでに混雑している場合：送信目標を高くしすぎると、キューやパケットロス、再送が増え、ほかのリクエストへの応答が遅くなることがあります。
結論：同じ経路で繰り返しテストして判断する
サーバー、接続先のリソース、ルーティング設定を固定してから、初回応答、持続的なスループット、接続の安定性を比較します。出口を変えた後の速度差をHysteria2の効果と混同したり、一定の改善率を当てはめたりしないでください。
Homeでのパラメータ入力と確認
以下の手順は、サービス提供元から接続パラメータを受け取っていることが前提です。サブスクリプションは利用中のサービス提供元から取得してください。サブスクリプションのインポートと手動入力は別々の設定方法です。インポートの場合は結果を確認し、手動入力の場合は項目ごとに設定します。問題の切り分け中にサブスクリプションの更新、認証情報の変更、帯域幅の調整を同時に行うと、どの変更が影響したか判断しにくくなります。
-
接続パラメータを確認
サーバーアドレス、ポート、認証情報、証明書の検証に使う名前、obfuscationの有効・無効を確認します。帯域幅の値と単位もサービス提供元の案内に従ってください。ドメイン名やポート番号から、ほかのパラメータを推測しないでください。
-
プロトコルを選択
Home → 右上の「+」→ Add Server → Type → Hysteria2の順に選択します。アドレスとポートを入力してください。サブスクリプションからインポートした場合は、該当項目の編集画面を開き、TypeがHysteria2になっていることを先に確認します。
-
認証情報を確認
サービス提供元から指定された値を省略せずPasswordに入力し、大文字・小文字や記号もそのまま保持します。認証情報がユーザー名とパスワードの組み合わせ形式の場合も、独自に分割したり区切り記号を削除したり、空白を加えたりせず、指定どおりに入力してください。
-
TLSを確認
SNIとサーバー証明書の名前が一致しているか確認します。接続先アドレスにIPアドレスを指定し、証明書の検証にはドメイン名を使う場合があります。この2つは役割が異なります。obfuscationの種類とキーもサーバー側と一致させてください。
-
保存して接続テスト
保存してHomeに戻り、該当項目を選択します。Global Routingを確認してから接続を有効にしてください。初回設定では、システムの案内に従ってVPN構成を許可します。接続先を固定してアクセスし、成功、タイムアウト、証明書エラーなどの状況を記録してください。
帯域幅の入力は特に単位を間違えやすい項目です。入力欄の単位がMbpsの場合、20 Mbpsはバイト換算で約2.5 MB/sです（プロトコルのオーバーヘッドを除く）。20 MB/sをそのまま20 Mbpsとして入力しないでください。上りと下りは別々に確認します。実際の回線を大きく上回る値を入力しても、性能が確保されるわけではありません。最終的な動作はサーバー側の制限、双方の設定、実装によって決まり、入力値だけから実際の送信速度を判断することはできません。
Global Routing：プロトコルとルールを切り分ける
Homeで接続成功と表示されても、特定のリクエストが選択したHysteria2の項目を経由したとは限りません。Global Routingでトラフィックのルーティング設定を選び、Configのルールでリクエストごとの処理方法を決めます。「プロトコルを変えても速度が変わらない」場合は、まずテスト対象のリクエストが実際にどの経路を通っているか確認してください。
Config
ルールに従う現在有効なConfigのポリシーに従います。ルールは上から順に照合され、最初に一致した項目の処理が適用されます。一致するルールがないリクエストはFINALで処理されます。普段使う前に、対象のポリシーが意図した接続先を指していることを確認してください。
適した用途：ルールを設定済みの日常利用
Proxy
クライアントが処理するトラフィックをプロキシ経由にします。通常の振り分けルールの影響を一時的に切り分ける際に便利です。ただし、すべてのシステム通信が同じ接続を通ることを示すものではなく、サーバーの認証エラーやUDPの通信障害を解決するものでもありません。
適した用途：プロキシ経路とプロトコルの接続確認
Direct
クライアントが処理するトラフィックを直接接続として扱います。この状態でアクセスできても、Hysteria2サーバーが利用可能であることの証明にはなりません。直接接続経路との比較に使い、テスト後は元の設定に戻してください。
適した用途：ローカルネットワークと接続先への到達性の比較
Global RoutingのSceneでは、利用状況に応じたルーティング動作を設定します。別の通信プロトコルではありません。問題の切り分け中は、現在のSceneが選択に影響していないか確認してください。Configを使う場合は、有効なファイルに加え、DOMAIN-SUFFIXやIP-CIDRなどのルールによってDIRECTやほかのポリシーが先に適用されていないか確認します。プロトコルのパラメータとルールの選択は、別々に確認する必要があります。
接続失敗や速度の不安定さを確認する手順
まず症状を分類し、該当するパラメータを確認してください。TCPポートのテストに成功しても、同じ番号のUDPポートが使えるとは限りません。逆に、一般的なUDP疎通確認で応答がなくても、無効なパケットにサーバーが応答しない場合があるため、それだけでポートが閉じているとは判断できません。クライアントでの実際のハンドシェイク結果、ネットワークを切り替えたときの変化、サービス提供元の案内を合わせて判断してください。
| 症状 | まず確認する項目 | 次に行うこと |
|---|---|---|
| 接続がタイムアウトし続ける | アドレスの名前解決、実際のUDPポート、現在のネットワークからの到達性 | 同じ設定のままWi-Fiとモバイル通信で1回ずつテストし、認証情報は同時に変更しないでください。 |
| 認証失敗と表示される | Passwordの値全体、大文字・小文字、サーバー側の認証許可状態 | 元のパラメータを再確認し、コピー時に前後の空白が混入していないか確認してください。 |
| 証明書エラーと表示される | SNI、証明書名、有効期限、デバイスの時刻 | サーバー証明書の設定を確認し、検証を無効にしてエラーを隠さないでください。 |
| 接続できるがスループットが変動する | 帯域幅の単位、経路上のパケットロス、ネットワークの速度制限、サーバー負荷 | 接続先を固定し、同時接続を減らして、時間帯を変えながら結果を記録してください。 |
| 一部の接続先にアクセスできない | 現在のConfig、適用されたルールとポリシー、DNSの名前解決結果 | 短時間Proxy経由で比較します。症状が変わる場合は、認証情報を再入力する前にトラフィックの振り分けを確認してください。 |
小さなリクエストは成功する一方、長時間の転送が頻繁に止まる場合は、サービス提供元に経路のMTU、UDPデータグラムの処理、速度制限の設定を確認してください。一度止まっただけで基盤パラメータをむやみに変更しないでください。特定のWi-Fiでのみ問題が起き、モバイル通信に切り替えると解消する場合は、経路の違いが原因である可能性があります。ただし、短時間のサーバー負荷変動をネットワークの問題と誤認しないよう、繰り返し検証してください。
iPhoneのバッテリー消費と日常的なテスト方法
Hysteria2のバッテリー消費量が一定の割合で増えるとは限りません。暗号化処理、データ転送量、再送、接続の維持、モバイル通信モジュールが動作している時間などが消費電力に影響します。ダウンロードが速く終われば無線通信の時間が短くなる一方、高スループットが続く場合や電波が弱い場合、再接続を繰り返す場合は消費が増えることもあります。プロトコル名だけで省電力かどうかを判断することはできません。
- テスト条件をそろえる：同じiPhone、同じネットワーク、同じリソースを使い、画面の明るさ、充電状態、バックグラウンドタスクもできるだけ統一します。
- 負荷を分けて確認する：短時間のWebリクエストと継続的なダウンロードを別々に観察します。長時間の最大速度ダウンロード時の電池消費を、待機中の消費の目安にしないでください。
- 測定時間を記録する：たとえば1回10分間テストし、転送量、発熱、再接続回数、バッテリー残量の変化を記録します。少なくとも3回繰り返してください。これはテスト方法の提案であり、実測性能の結論ではありません。
- 接続の自動開始を確認する：Settings → On Demandで、ネットワーク条件に応じて接続が開始される設定になっているか確認します。Wi-Fiの切り替え前後で状態をそれぞれ観察し、自動接続による利用時間の違いをプロトコルの差と混同しないようにしてください。
- バッテリーの使用状況を分けて見る：iPhoneの設定でバッテリー使用状況を確認し、画面やモバイル通信の電波状況も考慮します。VPNによる通信を、特定のフォアグラウンドアプリの消費電力全体と単純に同一視することはできません。
結論：ピーク速度より安定性を優先
帯域幅の目標値を上げて一時的に速度が向上しても、発熱、操作の遅延、再接続が目立つ場合は元の値に戻して再テストしてください。一度の速度測定で最高値を追うより、実際の用途を安定してこなせる設定を維持するほうが日常利用に適しています。
Hysteria2を検討するには、サーバーが対応していること、UDP経路が使えること、必要なパラメータがそろっていることが前提です。ShadowrocketはAppleプラットフォーム向けの有料アプリで、主にiPhoneとiPadで利用できます。アプリの購入と接続サービスは別です。サブスクリプションは利用中のサービス提供元から取得してください。対応範囲とシステム要件はApp Storeの記載をご確認ください。基本設定を先に済ませる場合は、使い方ガイドでHome、Config、初回のVPN構成許可を確認してから、プロトコルをテストしてください。