Shadowrocket Hysteria2とは?QUICの通信特性と使いどころ

Hysteria2のQUIC/UDP設計、高パケットロス環境で安定しやすい理由、UDPが制限されるネットワークで適さないケースを解説します。

この記事の概要

Hysteria2はQUICベースのプロキシプロトコルで、あらゆるネットワークを高速化する機能ではありません。iPhone、iPadなどでShadowrocketを使い、利用中のサービスとサブスクリプションがある方向けに、UDPの到達性、接続パラメータ、パケットロス・帯域幅・ルールの影響を順に確認します。

Hysteria2、QUIC、UDPの関係

Hysteria2はQUICを使ってクライアントとサーバー間の通信接続を確立し、QUICはUDP上で動作します。ここでいうUDPは両端間の外側の通信方式であり、Webリクエスト自体が信頼性のないデータ送信になるわけではありません。QUICはストリームに確認応答、再送、フロー制御、暗号化などの仕組みを提供し、その上でHysteria2がプロキシリクエストを転送します。

通常のWebアクセスではTCPが使われることがよくあります。Hysteria2経由では、こうしたアプリの接続をQUICストリーム上で転送できます。アプリが生成したUDPデータも、プロトコルの機能に応じて転送できます。そのため、「サーバーへのTCP接続が可能」であることと「Hysteria2で接続できる」ことは別です。外側のUDP経路が使えることを個別に確認する必要があります。

UDP
Hysteria2の外側の通信は、TCP接続だけでは確認できない
TLS 1.3
QUICの安全なハンドシェイクでは、証明書の正しい検証が必要
443/UDP
サーバーのポート設定例であり、プロトコルの固定ポートではありません

利用中のサーバーの待ち受けポートが443の場合、ファイアウォールで対応する443/UDPを許可する必要があります。443/TCPだけを開放しても不十分です。実際の接続にはサービス提供元が指定したポートを使用してください。Webでよく使われるポートだからといって、サブスクリプションに記載された別のポートをすべて443に変更してはいけません。

パケットロスが多い環境で安定することがある理由

パケットが失われると、再送するデータが増え、復旧までの待ち時間も長くなり、ダウンロードが途切れやすくなります。従来のTCPでは、ネットワークからのフィードバックに応じて輻輳制御が送信速度を調整します。パケットロスは実際の輻輳だけでなく、無線干渉などの回線要因でも発生します。どちらの場合も送信速度が下がるため、利用可能な帯域幅を十分に活用できるとは限りません。

Hysteria2の通信設計は、輻輳によらないパケットロスがあり、往復遅延の大きい経路で、比較的積極的な送信ペースを保てる場合があります。またQUICの独立したストリームにより、信頼性のある順序制御によるストリーム間のブロッキングも抑えられます。ただし、複数のストリームは同じ経路と接続リソースを共有します。パケットロス後の再送、サーバー負荷、出口帯域幅の制約も残るため、「パケットロスが多いほど速い」という意味ではありません。

  • 無線干渉による一時的なパケットロス:UDPが到達可能で回線に余裕があれば、従来の通信方式より安定したスループットが得られることがあります。
  • 地域をまたぐ高遅延の経路:帯域幅の利用効率が向上する可能性はありますが、光ファイバーの距離や経路の迂回による基本的な遅延は解消されません。
  • アクセス回線がすでに混雑している:送信量を増やすと待ち行列やパケットロスが増え、Webの応答や通話品質がかえって低下することがあります。
  • ローカルの電波状況が継続的に悪化している:再送にも無線リソースが必要です。プロトコルを切り替えても、Wi-Fiの電波が届きにくい問題は解決できません。

まとめ:パケットロスと輻輳を見分ける

ダウンロード中に直接接続したWebページも明らかに遅くなる場合は、まず同時接続数を減らし、ローカル回線と帯域幅の設定を確認してください。送信帯域幅をさらに増やすことを、標準的な対処法と考えないでください。

Hysteria2が適さないネットワーク

適性を判断する際、最初に確認すべきなのは速度測定の結果ではなく、UDPで安定した双方向通信ができるかどうかです。ゲスト用ネットワーク、職場のネットワーク、公衆Wi-FiなどではUDPが制限されることがあります。一部のUDP通信だけが許可されるネットワークや、大容量のUDP通信を長時間続けると速度制限されるネットワークもあります。ドメイン名を解決できる、HTTPSのWebページを開ける、ping値が低いといったことだけでは、接続先ポートでUDPが使える証明にはなりません。

確認できる現象考えられる原因次に行う確認
Wi-Fiでは接続がタイムアウトするが、モバイル通信では使えるWi-Fiの出口でUDPが制限されている、または2つの経路でルーティングが異なる設定はそのままにして、ネットワークだけ切り替えて接続を再試行する
短いリクエストは通るが、ダウンロードを続けると速度が低下するUDPの速度制限、サーバーの輻輳、端末の温度や電波状況の変化速度が低下した時刻を記録し、同じ時間帯の直接接続時の状態も確認する
小さなリクエストは通るが、大きなリクエストは頻繁に止まる経路MTU、フラグメント処理、パケットロスの問題まずサービス提供元の案内にあるパラメータを確認し、その後に経路とログを調べる
TCPポートのテストは成功するが、Hysteria2はタイムアウトするテスト対象に接続先のUDPポートが含まれていないサーバーのUDP待ち受け設定とファイアウォールルールを確認する

MTUの問題は、一度途切れただけで断定しないでください。経路の一部で大きなデータグラムを正常に処理できず、特定のリクエストが止まることはありますが、証明書エラー、認証失敗、DNSの問題も「開けない」とひとまとめにされがちです。まずログを見てハンドシェイクの失敗と通信途中の切断を区別し、そのうえでサービス提供元に経路の確認を依頼する必要があるか判断してください。

Shadowrocketで設定を確認してテストする

以下はiPhone / iPadのHome、Config、Settings画面を例に説明します。Mac、Windows、Android、Linuxでも同じ方法でパラメータを確認し、ネットワークを比較できます。具体的な操作場所は各プラットフォームの現在の画面で確認してください。作業前に利用できている設定を保存し、テストには自身が利用中で、使用権限のあるサーバー情報だけを使ってください。

  1. 既存のサブスクリプションを更新する

    Homeで既存のサブスクリプションを見つけて更新します。追加する場合はHome →「+」→ Type → Subscribeの順に進み、自分のサブスクリプションURLを入力して保存します。サブスクリプションの内容やアクセス認証情報を、公開スクリーンショットや掲示板に載せないでください。

  2. プロトコルのパラメータを確認する

    Homeで対象項目の編集画面を開き、TypeがHysteria2になっていることを確認して、サーバーアドレス、ポート、認証情報、TLS関連の設定を一つずつ確認します。HysteriaとHysteria2は、任意に置き換えて使える種類ではありません。

  3. 証明書のドメイン名を確認する

    接続先がIPアドレスで、証明書がドメイン名に対して発行されている場合は、サービス提供元が案内するSNIを確認してください。偽装を使う場合、両端で種類とパスワードを一致させる必要があります。証明書検証を安易に無効にして、パラメータの修正に代えることはできません。

  4. ルールの影響を切り分ける

    対象の接続を選び、短時間だけHome → Global RoutingをProxyに切り替えてから接続し、決めたテスト用リソースにアクセスします。これによりルールによる影響を減らせますが、設定内で動作を上書きする項目がないかも確認してください。

  5. 普段の設定に戻す

    テスト後、Global Routingを普段使っているConfigに戻し、Configで元の設定が有効になっていることを確認します。トラブル切り分けのためにSettings → On Demandで自動接続の動作を変更した場合は、そちらも元に戻してください。

サブスクリプションの更新に成功したという表示は、クライアントが内容を取得して解析できたことを示すだけで、記載されたすべてのサーバーに接続できることを意味しません。サービス提供元が認証情報や証明書を変更した場合、手動で複製した古い項目には変更が反映されないことがあります。認証に失敗したら、項目の取得元と更新結果を先に比べ、関係のないルールをむやみに変更しないでください。

Global Routingの選び方:プロトコルを誤判定しないために

Hysteria2は接続の通信方式を担い、Global Routingはリクエストのルーティング方法を決めます。両者は異なる階層のものです。Global RoutingのProxy、Direct、Config、Sceneも、4種類のプロキシプロトコルではありません。プロトコルをテストしていても、リクエストが実際にはDirect経由なら、Webページが速く表示されてもHysteria2の速度測定にはなりません。

Config:設定に従ってルーティング

おすすめ

現在の設定にあるルールとポリシーに基づいて接続先を決定します。DIRECTに一致したリクエストは直接接続し、プロキシポリシーに一致したリクエストは該当する接続を使います。一致しないリクエストの処理はFINALなどの設定で決まり、必ず直接接続されるとは限りません。

適した用途:ルール設定があり、普段から通信を振り分けて使う場合。

Proxy:ルールの影響を切り分ける

プロキシを主なルーティング方法として使い、選択した接続が使えるか短時間で確認します。テスト時は実際のリクエストがどこへ向かっているかも確認し、ポリシー選択やほかの設定による上書きで判断を誤らないようにしてください。

適した用途:接続テスト、「ルールが想定どおりに適用されない」原因の特定。

Direct:直接接続の基準を確認する

直接接続時の状態から、ローカルネットワークがすでに混雑しているか確認します。もともと直接アクセスできる同じリソースだけを比較し、直接接続できない接続先を使ってローカルネットワーク全体の障害と判断しないでください。

適した用途:Wi-Fiの状態との比較、プロキシ経路の問題かどうかの確認。

Sceneは、設定済みのシーンに応じてルーティングを適用する機能です。初回のトラブルシューティングでは、不確定要素として加えないでください。ルールでは、DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレスの範囲、GEOIPはIP地理データベースに基づく判定に使われ、FINALは最終的な処理を決めます。これらのルールの順序と適用先のポリシーを確認するほうが、プロトコルを替えるだけよりも「一部のサイトは使えるのに、別のサイトは使えない」理由を把握しやすくなります。

速度を比べるときは、一度の最高値ではなく安定性を見る

Hysteria2の動作は、輻輳制御の方式、利用可能な帯域幅、サーバー側の制限に左右されます。接続設定に上り・下りの帯域幅がある場合は、現在のアクセス回線とサービス提供元の指定に基づいて入力してください。上りは端末からサーバーへ送信する方向、下りはサーバーから端末へ返す方向です。MbpsとMB/sも区別してください。基本的な単位換算では、MB/sの値を8倍するとMbpsに相当します。

家庭用ブロードバンドの公称ダウンロード速度を、あらゆるネットワーク環境での送信目標としてそのまま設定しないでください。モバイル通信に切り替えると、利用できる上り帯域幅が異なる場合があります。目標を高くしすぎると、確認パケットやほかのアプリの通信帯域を圧迫することがあります。低くしすぎるとスループットが制限される可能性があります。入力が必要か、パラメータがどう反映されるかは、現在の接続設定とサーバー側の指定を確認してください。

  • 条件を固定:同じ端末、同じネットワーク、同じテスト用リソースを使います。サーバーの場所や出口が異なる接続を、プロトコル名だけで比較しないでください。
  • 繰り返し測定:各条件で連続3回テストし、1回あたり60秒間測定します。最高瞬間速度だけでなく、安定時のスループットと中断回数を記録してください。
  • 応答も同時に確認:ダウンロード中に、もともと直接接続できるWebページを開き、明らかな待ち時間が発生しないか確認します。速度が上がっても、ほかのリクエストが止まり続けるなら、全体的な改善とはいえません。
  • ネットワークごとに記録:Wi-Fiとモバイル通信を分けて記録し、ネットワークを切り替えたら接続を確立し直します。既存接続の移行中の動作が測定結果に混ざるのを防ぎます。
  • エラーの種類を記録:タイムアウト、認証失敗、証明書検証失敗など、実際に表示された内容を記録します。記録を共有する際は、サーバーの認証情報とサブスクリプションURLを隠してください。

まとめ:最高速度より接続できるかを優先

同じ設定でUDPハンドシェイクが繰り返しタイムアウトし、ネットワークを切り替えると安定して使える場合は、まずネットワークの制限に対処するか、利用中のサービスにそのネットワークで使える別の接続方式があればそちらを使ってください。帯域幅の数値を何度も増やして解決しようとしないでください。

よくある質問と対処の範囲

Hysteria2を使えばゲームの遅延は必ず下がりますか?

いいえ。ゲームの遅延は、ゲームサーバーとプロキシ出口の場所、迂回経路、通信の待ち行列にも左右されます。ダウンロードが安定しても、小さなデータパケットの往復が速くなるとは限りません。ダウンロード速度ではなく、ゲームを実際にプレイしながら遅延の変動やパケットロスを確認してください。

接続に失敗したらTLS検証を無効にすべきですか?

検証の無効化を通常の対処法にしないでください。まず端末の時刻、サーバーアドレス、SNI、証明書に記載されたドメイン名を確認し、サーバー証明書が有効か確認します。証明書検証はサーバーの本人確認に使われます。問題を無視すると設定ミスが隠れ、接続の安全性も低下します。

On Demandを有効にすればUDPの制限を解消できますか?

いいえ。Settings → On Demandで管理するのは、接続をオンデマンドで開始する条件です。通信事業者によるUDPの許可ルールは変わりません。自動再接続で接続を再試行することはできますが、遮断された通信経路を使えるようにはできません。

プロトコルを選ぶ際は、現在の経路で接続できるか、安定しているか、リソース使用量が許容範囲かを基準にしてください。Shadowrocketはクライアントアプリで、接続パラメータは利用者がすでに使っているサービスから提供されます。当サイトは利用者がすでに所有するサブスクリプションの設定方法のみを説明し、接続サービスは提供していません。必要なパラメータが揃っていない場合は、元のサービス提供元に確認してください。パスワード、サブスクリプショントークン、認証情報を推測で設定しないでください。

Shadowrocketをダウンロード