この記事の概要

Hysteria2はUDPベースのQUICを利用するため、高遅延やランダムなパケットロスがあっても、利用可能な帯域が残っている回線での評価に適しています。設定情報をすでにお持ちの方向けに、通信の仕組み、帯域パラメータ、Shadowrocketの設定項目、トラブル時の確認手順を順に解説し、プロトコルの特性、ネットワークの制約、ルール設定の問題を切り分けます。

1. Hysteria2とQUIC:速度を支える仕組み

Hysteria2はプロキシプロトコルであり、回線プランでも帯域を加速するスイッチでもありません。クライアントのShadowrocketは、ユーザーがすでに持っているサーバーアドレス、認証情報、通信パラメータを使って接続します。通信品質は、利用中のネットワーク、通信事業者の経路、サーバー負荷、出口帯域にも左右されます。

QUICはUDP上で暗号化、信頼性のあるデータ転送、フロー制御、輻輳制御を実現します。UDPだからといって「すべてのデータが再送されない」わけではありません。Hysteria2でTCP接続をプロキシする場合はQUIC streamが信頼性を担い、UDPデータグラムをプロキシする場合は異なる通信方式を使います。両者を混同しないようにしましょう。

UDP
外側の通信には、サーバーの該当するUDPポートへの到達性が必要
TLS 1.3
QUICに組み込まれた暗号化ハンドシェイクでも、サーバーの認証は必要
443/UDP
利用例として挙げたポートであり、固定値ではありません。手元の設定情報を確認してください。

従来の単一TCP接続では、順序どおりのデータ受信が必要なため、後続データが欠落データの再送を待つことがあります。QUICではstreamごとにデータ受信を分離できるため、あるstreamのパケットロスが、別のstreamの順序どおりの受信を必ずしも妨げるわけではありません。ただし、同じstreamでは欠落データを待つ必要があり、各streamは回線容量と輻輳状態を共有します。そのため、「QUICならヘッドオブラインブロッキングが完全になくなる」という説明は正確ではありません。

QUICのハンドシェイク設計により、接続確立にかかる時間を一部短縮できる場合があります。ただし、初回接続、セッション再開、実際のネットワーク経路では条件が異なります。理論上のハンドシェイクの利点を一定のWebページ高速化率に換算することはできず、接続時の遅延を継続的なダウンロード速度と同一視することもできません。

2. 輻輳制御と帯域設定:数値を大きくしても速くなるとは限らない

パケットロスは無線干渉でも、キューの混雑でも起こります。クライアントではどちらもデータの欠落として見えますが、適切な送信方法は異なります。Hysteria2の特徴のひとつは、目標帯域に基づくBrutal輻輳制御を利用できることです。また、帯域のネゴシエーションや別の輻輳制御方式もあり、すべての接続が常に同じ方式で送信するわけではありません。

該当する帯域設定を有効にした接続では、送信側が目標速度とパケットロスの状況に応じて送信を調整します。ランダムなパケットロスが発生する回線では、ロスのたびに輻輳とみなす方法より、利用可能な帯域を活用できる場合があります。一方、すでに回線が混雑している場合は、目標値を高くしすぎるとキューの増加や再送、ほかの通信の遅延につながります。

ポイント:アイドル時の遅延を測ってから帯域を調整

同じ既存サーバーを使って連続通信を行いながら、Webページの応答や操作時の遅延も確認します。ダウンロード中に操作への反応が明らかに遅くなった場合は、数値をさらに上げるのではなく、帯域目標を下げて再測定してください。一度に変更する項目はひとつにし、元の値も控えておきましょう。

3. 利用シーン:モバイル回線、パケットロス、バッテリー消費

モバイル回線では、電波状況や基地局の負荷、無線での再送によって、利用可能な帯域が変動します。UDPが利用でき、ランダムなパケットロスがあっても回線容量に余裕がある環境では、Hysteria2を試す価値があります。UDPが遮断または厳しく制限されている場合や、ネットワークへのログイン認証が必要な場合、プロトコル自体でこうした接続条件を回避することはできません。

Wi-Fiからモバイル回線に切り替わる際、QUICの接続IDと経路検証の仕組みが、IPアドレスの変化への対応に役立つ場合があります。ただし、セッションを維持できるかは実装、OSのネットワーク状態、サーバー側の対応状況にも左右されます。利用中に再接続が必要になることもあるため、「QUIC対応ならすべてのアプリの通信が途切れない」とは限りません。

バッテリー消費は、実行するタスクと合わせて判断する必要があります。暗号化処理、ユーザー空間での通信処理、パケットロス時の再送、無線での継続的な送信は、CPUや無線モジュールの負荷を高める可能性があります。一方、処理が早く終われば、端末が動作している時間が短くなることもあります。そのため、Hysteria2が必ず電力を多く消費する、または節約できるとは一概に言えません。同じネットワーク、近い画面輝度、同じファイルサイズで、完了時間、端末の発熱、OSのバッテリー使用状況を比較してください。

4. Shadowrocketの設定項目と入力時の確認ポイント

Shadowrocketでは、Homeで接続先の選択や接続状態の確認、Configでルール設定の管理、Settingsでアプリの設定を行います。手動入力の前に、手元の設定情報がHysteria2用であることを確認してください。旧Hysteriaの設定をそのまま使えるとは限りません。項目の表示や分類はプラットフォームによって異なります。以下で確認すべきパラメータの意味を説明します。

項目・パラメータ確認する内容よくある間違い
TypeHysteria2を選択し、手元のサーバー情報に記載されたプロトコルと一致させます。種類だけを変更し、別のプロトコル用の認証項目をそのまま使う。
Serverサーバーのドメイン名またはIPアドレスを入力します。Webページのパスは含めません。サブスクリプションURL全体をサーバーアドレス欄に入力する。
Portサーバーが実際に待ち受けているUDPポートを入力します。設定情報で明示されている場合は、443などを指定します。HTTPSでよく使われるポートが443だからと、手元のポートを勝手に変更する。
Passwordサービス提供元から渡された認証情報を、省略せず大文字・小文字や必要な記号もそのまま入力します。認証情報の一部をメモと勘違いして削除する。
SNI手元の設定情報で指定された、サーバーの証明書と構成に対応する名前を使用します。任意のWebサイトのドメインを入力すれば、接続経路が自動で変わると思い込む。
Upload / Download項目の単位とサーバー側の指定に合わせ、アップロードとダウンロードの方向を区別して設定します。MbpsとMB/sを混同する、または数値を無制限に大きく設定する。
Obfsサーバー側で有効化され、対応するパラメータが提供されている場合にのみ設定します。salamanderを使う場合は、クライアントとサーバーで種類とキーを一致させてください。対応するサーバー側の設定がないのに、クライアント側だけで難読化を有効にする。

TLS検証は接続先サーバーの身元を確認するためのものです。IPアドレスで接続して証明書がドメイン名宛てに発行されている場合は、正しいSNIと証明書チェーンを確認してください。証明書検証の無効化を通常の解決策として扱わないでください。認証エラー、証明書エラー、UDPの接続不可はそれぞれ別の問題です。パスワードを変更しても、ポートの遮断は解決しません。

5. 手元の設定情報を読み込み、初回接続を確認する

用途を理解している、すでにお持ちの設定情報を優先して利用してください。本サイトでは、ノードやサブスクリプションを提供・販売・推奨していません。サブスクリプションURLは設定を更新するためのもので、サーバーアドレスではありません。たとえば https://example.com/sub?token=xxxx は形式を示す架空の例であり、接続には使用できません。URLに含まれる認証情報は大切な資格情報です。画面を公開したり、公開の場に貼り付けたりしないでください。

  1. 設定情報を確認

    プロトコルがHysteria2であることを確認し、Server、Port、認証情報、SNI、Obfsの有効・無効を控えます。帯域の単位が記載されていない場合は、利用中のサービス提供元に確認してください。

  2. 接続を追加

    手動で追加する場合は、Home → 右上の「+」からAdd Serverを開き、TypeでHysteria2を選んで各項目を入力します。すでにお持ちのサブスクリプションを使う場合は、案内に従ってSubscribeを選択してください。サブスクリプションURLをServer欄に入力しないでください。

  3. 選択して接続

    保存したらHomeに戻り、追加した項目を選んで接続を有効にします。OSからVPN構成の許可を求められたら、アプリ名を確認して許可し、接続が確立するか確認してください。

  4. ルーティングを確認

    Global Routingで、現在の設定がConfig、Proxy、Direct、Sceneのどれになっているか確認します。最初の切り分けでは、一時的にProxyでテストした後、通常の設定に戻してください。実際にはDirectで通信していたことを、プロトコルの障害と誤認するのを防げます。

  5. 再テストして設定を戻す

    Webページの表示、継続的なデータ転送、短時間の操作をそれぞれ確認します。テスト時間を手動で管理する場合は、Settings → On Demandで自動接続の条件を確認し、観察への影響を避けてください。テスト後は元の設定に戻します。

サブスクリプションから読み込んだ項目は、更新時に提供元によって設定内容が変わることがあります。手動で変更する前に元の値を記録し、更新後はSNI、ポート、帯域パラメータを再確認してください。リストに同じ名前の項目が残っていても、設定内容が変わっていないとは限りません。

6. Global Routingの違い:プロトコルの問題とルールの問題を切り分ける

プロトコルは「サーバーとどのように通信するか」を決め、ルーティングモードは「リクエストをどこに渡すか」を決めます。Hysteria2で接続できても、すべてのリクエストがその接続を通るとは限りません。以下はShadowrocketの設定を説明するための比較です。日常的に使うモードは、手元のルールやポリシーが正しく設定されているかによって異なります。

Config

おすすめ

現在の設定にあるルールとポリシーに従ってリクエストを処理します。DIRECTに一致したリクエストは直接接続し、プロキシポリシーに一致したものだけが該当するプロキシ経路を通ります。一致しないリクエストがすべて自動的に直接接続されるわけではありません。

適した用途:ルールを確認した後の日常的な振り分け。

Proxy

アプリが処理するリクエストをプロキシ経由で処理し、設定ルールの影響を一時的に切り分けます。ただし、OSの通信を処理する範囲や除外が必要な通信は別途存在する場合があります。端末のすべてのパケットが必ず同じサーバーを通るわけではありません。

適した用途:選択したHysteria2接続でリクエストを処理できるか、短時間で確認する。

Direct

リクエストを直接接続として処理するため、プロキシサーバーの通信速度を検証する用途には適しません。DirectでWebページを開けても、現在の直接接続経路からそのサイトにアクセスできることが分かるだけです。

適した用途:対象を明確にしたうえで、プロキシ経路と接続性を比較する。

Scene

設定済みのシーン条件に従ってルーティングを決めます。別の通信プロトコルではありません。結果を判断するときは、現在のネットワークとシーン設定の両方を確認してください。

適した用途:ネットワーク環境に応じて切り替える動作を設定し、動作確認も済ませている場合。

Configでは、DOMAIN-SUFFIXがドメインのサフィックスに一致し、IP-CIDRがIPアドレスの範囲に一致します。GEOIPはIPアドレスの地域データベースに基づいて一致し、FINALは先行ルールに一致しなかったリクエストの最終ポリシーを指定します。ルールの順序によって一致する結果が変わります。速度が想定と異なる場合は、Hysteria2の設定を変更する前に、実際に適用されたポリシーを確認してください。

7. 接続タイムアウト、認証エラー、速度変動の確認手順

トラブル時は、まず接続確立の問題を確認し、次にリクエストのルーティング、最後に速度を調整します。ポート、SNI、パスワード、帯域を同時に変更すると、比較の基準が失われます。以下に確認できる現象とチェック項目を示します。実測値ではなく、原因を切り分けるための手がかりです。ひとつの現象だけで原因を断定することはできません。

ポイント:再現できるテスト条件を保つ

サーバー、対象ファイル、Global Routingを固定し、各テストで変更する項目はひとつだけにします。接続結果、完了時間、操作時の反応を記録してください。安定して再現できる改善を、設定を維持する判断材料にしましょう。一度のピーク値だけで、あらゆるネットワーク環境で速くなるとは言えません。

Shadowrocketの入手方法と設定ガイド

iPhone / iPad版はApp Storeで$2.99の買い切りです。Mac(Appleシリコン / Intel)/ Windows / Android / Linux版は無料です。iPhone / iPadのシステム要件はApp Storeの掲載情報をご確認ください。開発者はShadow Launch Technology Limitedです。全プラットフォームのダウンロードページからお使いの端末に合ったクライアントを入手し、手元にある設定情報をガイドに沿って読み込んでください。

クライアントの買い切り購入と回線プランは別です。Shadowrocketはクローズドソースの商用アプリです。クライアントの入手費用と、利用中のサービス提供元の回線費用はそれぞれ別にかかります。