Shadowrocket プロトコル解説

プロトコル、伝送、ルーティングの役割

まず設定がどの階層を示しているか確認

プロトコルを選ぶ前に、接続をいくつかの独立した要素に分けて考えましょう。サーバーアドレスは接続先、ポートは待ち受け口、プロトコルはリクエストの識別方法と認証、伝送方式はデータの運び方、ルーティングはどのリクエストにその接続を使うかを決めます。これらを混同すると、「アドレスもパスワードも正しいのに使えない」という状況になりがちです。確認すべきなのはノード名に含まれるプロトコル名だけでなく、設定一式です。

たとえばVLESSを選んでも、サーバーによって必要な伝送方式、TLSの条件、追加項目は異なります。種類の名前が同じでも、双方が同じ形式のリクエストを使おうとしていることを示すだけで、接続の詳細まで一致しているとは限りません。サブスクリプションのインポートでは多くの項目を引き継げますが、取り込み後の内容も確認しましょう。アプリが認識できない項目がある場合は、まずアプリ内で選択できる項目を確認し、既存サーバーの管理者に照会してください。似た名前の項目に自己判断で置き換えるのは避けましょう。

速度やバッテリー消費に環境を問わない順位はありません

プロトコルの設計はハンドシェイク回数、データのカプセル化、再送の動作に影響しますが、実際の速度はサーバーの負荷、往復遅延、パケット損失、無線の電波状況、接続先サイトにも左右されます。短いWebページではハンドシェイクや名前解決の影響が出やすく、大容量ファイルの転送では輻輳制御や利用可能な帯域が効いてきます。1回の遅延測定でわかるのは特定条件下の応答時間であり、実際の閲覧を再現するものでも、終日の転送速度を示すものでもありません。比較する際は、デバイス、ネットワーク、接続先、測定時間帯をできるだけそろえましょう。

iPhoneやiPadのバッテリー消費は、暗号化アルゴリズムだけでは決まりません。携帯回線の電波が弱い、接続を頻繁にやり直す、バックグラウンドでデータを送り続ける、Keepaliveの間隔が短すぎる、詳細ログを長時間有効にするといった要因も消費を増やすことがあります。安定したネットワークでは正常なのに、ネットワークを切り替えると再接続を繰り返す場合は、プロトコルの消費電力を疑う前に接続状態とKeepaliveの条件を確認してください。バッテリー設定の統計には、対象期間中のほかのアプリの動作も影響します。

プロトコル解説はサーバーの説明に代わるものではありません

この記事では各項目の役割を説明しますが、その役割から有効な値を推測することはできません。アドレスはご自身が保有する情報を使い、認証情報はサーバー側と一致させ、伝送の拡張機能は接続の両側が対応している必要があります。変更前に元の設定を記録し、試す場合は見分けやすいコピーを残しておくと安心です。原因を判断できるよう、一度に変更するのは1項目だけにしましょう。プロトコル、DNS、ルールを同時に変更すると、接続が復旧しても原因を特定しにくくなります。

システムによるVPN構成の許可は、クライアントが端末上にネットワーク処理用の通路を作ることを認めるものであり、リモートサーバーの情報を代わりに入力するものではありません。システム上で接続済みでも、リモート認証、DNS、接続先へのアクセスがすべて成功したとは限りません。許可画面で止まる場合は、まずVPN構成の確認画面についてをご覧ください。接続済みなのにアクセスできない場合は、後述の手順で問題を切り分け、システムの許可に関する問題をプロトコル選択の問題と混同しないようにしましょう。

Shadowsocks：シンプルな構造と暗号化設定

暗号化して転送する設計

Shadowsocksは、比較的シンプルなプロトコル構造でアプリの通信を転送し、クライアントとサーバー間のデータを暗号化・認証する設計です。リモートネットワーク全体を端末に持ち込むネットワーク層のトンネルとは異なります。Shadowrocketで表示されるシステムのVPN接続と、リモート側で使われるShadowsocksは別の階層です。前者は端末の通信を取り込み、後者はクライアントとサーバー間のデータ交換を担います。この違いを理解すると、端末側のルーティングとリモート側のプロトコルを区別しやすくなります。

「構造がシンプル」だからといって、すべての設定が同じとは限りません。暗号化方式ごとにデータ形式や鍵の要件が異なり、追加の伝送拡張によって実際の接続方法も変わります。通常の設定とプラグインなどの拡張を使う設定は、サーバーアドレスとパスワードだけをコピーしても置き換えられません。手動で追加する場合は、サーバーが要求する組み合わせをアプリがサポートしているか項目ごとに確認しましょう。サブスクリプションから取り込んだ情報は、まず設定全体を保持し、見慣れない項目を整理目的で削除しないでください。

パスワードと暗号化方式はセットで確認

基本項目はサーバーアドレス、ポート、パスワード、暗号化方式です。暗号化方式は「長いほど安全」という自由選択の項目ではなく、接続する双方で一致させる必要があります。サーバーとクライアントで方式が異なると、パスワードが同じでも正常に復号できません。新しい方式の中には、鍵の長さやエンコード形式が指定されているものもあります。その場合、任意の文字列を同等のパスワードとして使うことはできません。元の大文字・小文字、記号、エンコードを保ち、手作業で空白を追加したり末尾の文字を削除したりしないでください。

サブスクリプションの更新後に突然接続できなくなった場合は、まず種類と暗号化方式が変わっていないか確認し、既存の設定が更新によって上書きされていないか調べましょう。パスワードをコピーするときに、チャットツールの改行、リッチテキストの空白、選択範囲の漏れなどで差が生じることがあります。アドレスとポートに到達できることは、ネットワーク上に接続先があることを示すだけで、パスワードが正しい証拠にはなりません。接続直後に切れる場合もあれば、待ち続ける場合もあります。画面に表示される1つのタイムアウトより、エラーが起きた段階のほうが原因の分析に役立ちます。

TCPとUDPを個別に確認

一般的なWebページの閲覧でTCP通信の一部は確認できますが、UDPが使えることの証明にはなりません。リアルタイムの音声・動画、一部のDNS問い合わせ、その他のアプリはUDPに依存する場合があります。転送できるかどうかは、サーバーの機能、クライアント設定、通信経路の条件によります。Webページは表示できるのにリアルタイムアプリが失敗する場合は、同じページを繰り返し速度測定するのではなく、その通信経路を個別に確認してください。逆に、UDPを使うアプリが1つ正常に動作しても、すべての名前解決やTCPリクエストが想定どおりとは限りません。

端末でShadowsocksの設定を比較する場合は、単発の大容量ファイルの速度だけでなく、接続を継続できるか、短いリクエストで待ち時間が頻発しないか、ネットワーク切り替え後に復旧するかを優先して確認しましょう。処理負荷には、ハードウェアの暗号化支援、実際の転送量、通信速度が関係します。安定していて設定項目が明確な、すでに検証済みの設定を基準にするほうが、方式名だけを見て未確認の設定を試すより適切です。性能の違いは繰り返し測定して確かめましょう。

「テストには応答するのにWebページを表示できない」場合は、名前解決、認証、UDP、ルールの適用、接続先サイトの順に確認します。一部のドメインだけで問題が起きる場合は、DNSのトラブルシューティングもご覧ください。名前解決の問題を暗号化方式の切り替えで解決しようとしたり、確認項目を無効にしたまま使い続けたりしないでください。設定情報の出どころ、双方の対応状況、エラーが起きる段階を確認してから変更すれば、原因と結果を把握しやすくなります。

VMessとVLESS：認証と伝送を分けて確認

似た設定項目でもプロトコルは同じとは限りません

VMessは、ユーザーの識別、リクエストの構成、データ保護に関する仕組みをプロトコルに含みます。VLESSはよりシンプルなリクエストと認証の構造を採用し、基本プロトコル自体は同じデータ暗号化機能を備えていないため、通常は適切なセキュリティ伝送と組み合わせます。どちらもUUIDを使い、TLSやWebSocketと組み合わせる場合がありますが、共通点があるからといって種類をそのまま入れ替えられるわけではありません。サーバーがVMessを提供している場合、UUIDをそのまま残してクライアント側でVLESSを選んでも、プロトコルの不一致が起きます。

それぞれの設計を理解する際は、機能の分担に注目しましょう。プロトコル自体に多くの仕組みを含むものもあれば、データ保護を外側のセキュリティ層に任せるものもあります。設定項目が少ないから速い、項目が多いから信頼性が高いとは限りません。実際の接続には、伝送の層数、ハンドシェイクの経路、サーバーの実装、ネットワーク環境も影響します。まず既存のサーバーが対応する方式を確認し、利用可能な組み合わせを比較してください。先に種類を決め、すべての項目を合わせようとするのは避けましょう。

UUID以外の伝送設定も確認

手動で追加する場合は、まず種類、アドレス、ポート、UUIDを確認し、続いて伝送方式とセキュリティ設定を確認します。UUIDはユーザーの識別子であり、サーバーアドレスではなく、パスワードを使うプロトコルの認証項目の代わりにもなりません。VMessの設定には、追加の認証や暗号化関連の項目が含まれる場合があります。元の設定に従い、古い解説に合わせるためだけに値を追加しないでください。端末の時刻が大きくずれていると、認証や証明書の検証に影響することもあります。システムの日付と時刻が正しいか確認しましょう。

WebSocketを使う場合、パスとリクエストヘッダーのHostは別々の項目です。パスでは先頭のスラッシュと大文字・小文字を保ち、ドメインをパス欄に入力したり、WebページのURL全体をHostとして入力したりしないでください。TLSを使う場合、SNIはサーバー名のネゴシエーションと証明書の検証に使われます。接続アドレス、Host、SNIは構成によって異なる場合がありますが、既存の設定で明確に指定されている必要があります。見た目をそろえるためだけに、3つを同じ値に変更するものではありません。

失敗した段階を特定

接続先への到達がタイムアウトする場合は、まずアドレス、ポート、パスへの到達性を確認します。TLSエラーでは、サーバー名、証明書チェーン、端末の時刻を確認しましょう。ハンドシェイク直後に切断される場合は、認証情報とプロトコル項目を引き続き調べます。サーバーの手前に中継先がある構成では、中継先とバックエンドの間で問題が起きている可能性もあります。そこでUUIDを何度も変更しても、中継先のパス不一致は解決しません。テスト時刻、ネットワークの種類、エラーの概要を記録すると、複数項目を続けて変更するより原因を特定しやすくなります。

iOSでは、伝送の層が増えると最初のリクエストに時間がかかる場合がある一方、接続を再利用して後続のハンドシェイクを減らせる場合もあります。実際の負荷を踏まえて判断しましょう。「接続の多重化」を常に速度を上げる設定と考えるのは避けてください。複数のリクエストが同じ下位接続を使うと、パケット損失や接続障害が同時に複数のリクエストに影響することがあります。関連項目が現在の設定にある場合は、まずサーバーが対応していることを確認し、同じWebページと連続転送でそれぞれ検証してください。速度測定を1回しただけで判断しないようにしましょう。

サブスクリプションを正常にインポートできる場合は、その取り込み結果を基準として設定し、項目の意味を一つずつ確認するのがおすすめです。用途がわからないストリーム項目、セキュリティ拡張、伝送方式があっても、削除して接続を続けたり、クライアントが対応していると決めつけたりしないでください。元の情報を保持し、アプリ内の選択項目を確認してから、必要に応じてサーバー管理者に問い合わせましょう。プロトコルを確認した後は、はじめにに沿ってGlobal Routingと実際のリクエストを確認してください。認証に成功しても、ルーティングが正しいとは限りません。

Trojan：TLSのサーバー認証とパスワード認証

セキュリティ接続とプロキシリクエストの役割

Trojanの基本設計では、TLS接続上にプロキシリクエストを載せます。確立されたセキュリティ接続で通信を保護し、プロトコル内の認証情報でユーザーを識別します。理解するには、まずサーバーとの信頼できるTLS接続を確立し、次にサーバーがプロキシリクエストとユーザーを認証するという2段階に分けて考えましょう。最初の段階に成功しても、次の段階が成功するとは限りません。「証明書が正常」と「パスワードが正しい」は別々に確認する必要があります。これらを1つのスイッチのように扱うと、トラブルの切り分けが難しくなります。

サーバーアドレスにはドメインを使えます。既存の構成に明確な別の接続先がある場合は、それを使用することもできます。ただし、TLSの検証に使う名前は正しく設定する必要があります。SNIは、クライアントがどの名前のサーバーに接続するかを伝え、証明書はその名前の正当性を証明します。接続アドレスと証明書の名前が異なる場合は、既存の設定に従って該当する項目を入力してください。問題を回避しようとしてSNIを削除しないでください。アドレスは接続先を見つけるため、名前は接続先の身元を検証するためのもので、互いに代用できません。

証明書は有効期限だけで判断しない

証明書の問題は、名前の不一致、証明書チェーンの不備、端末の時刻のずれ、サーバー側の設定ミスでも起きることがあります。有効期限だけを見ても、検証プロセス全体の状態はわかりません。関連するエラーが出た場合は、まず端末の時刻を確認し、入力したサーバー名が設定の要件と一致しているか確かめてから、サーバー管理者に証明書の設定を確認してもらいましょう。証明書検証を無効にすると信頼の範囲が変わり、サーバーの身元を証明できません。パスワード、ルーティング、名前解決の問題を直す方法として使わないでください。

パスワードは元の文字列をそのまま保ち、コピー時に改行や空白が入っていないか特に確認してください。表示名は変更できますが、名前を変えたからといってパスワード、ポート、プロトコルの種類を推測で変更する必要はありません。TLS接続が確立してから認証に失敗する場合は、パスワードとサーバーが実際に提供するプロトコルの種類を確認しましょう。基本のTrojanと追加の伝送拡張を使う設定は、注記が1つ異なるだけではありません。拡張を使う場合は双方の対応が必要で、指定されたパスやその他の項目も入力します。

ハンドシェイクの負荷は接続の再利用も含めて確認

初回接続では通常、ネットワーク接続とTLSハンドシェイクが行われます。遠距離通信、パケット損失、ネットワーク切り替えがあると、待ち時間が大きくなることがあります。後続のリクエストで下位接続を再利用できるかどうかは、実装や設定によるため、プロトコル名だけでは判断できません。比較する際は、ページを初めて開くとき、続けてアクセスするとき、長時間転送するときのそれぞれを確認しましょう。最初だけ遅く、その後は正常なら名前解決やハンドシェイクを調べます。連続転送でも何度も止まる場合は、通信経路の品質やサーバー負荷を確認してください。

iPhoneのバッテリー消費を考えるうえで、TLS暗号化は唯一の要因ではありません。短い接続を繰り返したり、接続失敗後に再試行を続けたりすると、無線モジュールやシステムのネットワーク処理が動作する時間も増える可能性があります。同じネットワークと同程度のデータ量で比較し、画面点灯中、バックグラウンド待機中、実際の転送中を区別しましょう。動画を長時間再生した後のバッテリー消費を、数分の静的なWebページ閲覧と直接比較しないでください。負荷条件が異なるため有効な結論にはなりません。

Webページに証明書の警告が出た場合は、どの層からの警告かを確認します。クライアントからサーバーへの接続でTLSエラーが出たのか、ブラウザーで接続先サイトを開いた際に証明書の問題が出たのかを見分けましょう。前者では現在の接続設定を確認します。後者は接続先サイト、端末の時刻、ほかのネットワーク設定が関係する場合もあります。「証明書」という言葉だけを見てTrojanのパスワードを変更しないでください。エラーの表示場所と発生時刻を記録すると、2種類の問題をすばやく切り分けられます。

既存のサーバーで検証可能なTLS設定が提供され、認証項目が明確で、実際の通信も安定しているなら、Trojanを使い続ける選択肢があります。TLSを使うからといって他の方式より自動的に優れているわけでも、すべての通信経路で正常に動作する保証があるわけでもありません。これまで正常だった設定で最近になって名前や証明書のエラーが起きた場合は、すぐにプロトコルを変えるのではなく、まずサーバー側の変更を確認しましょう。購入やアプリの更新については、別途トラブルシューティングをご覧ください。

HTTPとSOCKS5：汎用プロキシの適用範囲

2種類の汎用インターフェースが扱うもの

HTTPプロキシは、HTTPリクエストの転送を中心に発展しました。一般的なCONNECTメソッドでは、指定した接続先との間にバイトストリームの通信路を確立できます。SOCKS5はより汎用的なプロキシネゴシエーションプロトコルで、接続先アドレス、接続コマンド、任意の認証手順を定義します。上位層のデータがWeb通信である必要はありません。どちらも既存のネットワーク環境で標準的なインターフェースとして使われますが、「汎用」とはインターフェースの用途を指します。すべての実装が全コマンド、全認証方式、全アプリの通信に対応するという意味ではありません。

HTTPプロキシを使った接続先サイトのHTTPSと、クライアントからプロキシサーバーまでの通信が暗号化されているかどうかは別の問題です。CONNECTでHTTPSサイトにアクセスすると、サイトとの通信はHTTPSで保護できますが、プロキシ接続自体は実際の種類に応じて確認する必要があります。SOCKS5の基本プロトコルも自動でデータを暗号化するものではなく、ユーザー名とパスワードによる認証も暗号化通信路と同じではありません。Webページに安全を示す表示があるからといって、プロキシ接続上のすべてのメタデータも同等に保護されているとは限りません。

認証方式と接続先の名前解決を分けて確認

既存のHTTPまたはSOCKS5の情報を追加する場合は、サーバーアドレス、ポート、認証の有無、アプリで選択できる認証方式を確認します。アカウントとパスワードを使わない接続先もあれば、両方の入力が必要な接続先もあります。空欄で試して長期的に使おうとしないでください。既存の説明にTLSで保護されたプロキシ接続が指定されている場合は、選択した種類とセキュリティ項目が一致しているか確認しましょう。通常のHTTP項目を、すべてのセキュアなプロキシ接続の総称として扱わないでください。

ドメインをどちら側で名前解決するかによって、アクセス結果やエラーの切り分けが変わります。SOCKS5はドメインを接続先として指定できますが、実際のリクエストでドメインをリモート側に渡すかどうかは、クライアントの名前解決やルーティング処理にも左右されます。HTTP CONNECTの接続先も、ホスト名またはアドレスで指定する場合があります。リモート側では名前解決できるのに端末側では失敗する場合は、名前解決の場所を切り替えることで状況が変わることがあります。まず現在の設定を理解してから検証してください。プロトコルがドメインに対応しているというだけで、すべてのリクエストが必ずリモート側で名前解決されるとは限りません。

Webページが使えても、すべての用途で使えるとは限らない

通常のHTTP CONNECTはTCPを対象とするため、UDPを使うアプリも利用できるとは限りません。SOCKS5はUDP関連の仕組みを定義していますが、TCPだけを許可する環境や、UDPの戻り経路がネットワーク条件の影響を受ける環境もあります。チャットのテキストは使えるのに通話が失敗する場合は、その用途で使われる通信方式を調べてください。Webページの接続先を何度変えても、利用できないUDP機能が補われるわけではなく、すべてのアプリのリクエストが同じ経路を通る証明にもなりません。

これら2種類のプロトコルは処理構造が比較的シンプルな場合がありますが、省電力か、速いかは暗号化層、接続時間、ネットワーク品質、サーバーの実装によります。プロトコルの項目が少なくても、携帯回線の通信量や動作時間が自動的に減るわけではありません。認証の失敗や頻繁な切断が続くと、かえって使い勝手が悪くなることがあります。iOSでは「標準プロトコル」というだけで性能を判断せず、接続の再試行、接続先へのアクセス、バックグラウンドでの動作を確認しましょう。

利用中のオフィスやテスト環境でこれらの接続先が明示的に提供されている場合は、機能の範囲を理解したうえで使用できます。機密データを送信する場合は、接続先アプリ自体の暗号化と、プロキシ経路の保護も確認してください。認証が拒否されたらアカウント項目を確認し、接続後に接続先へ到達できない場合は名前解決とリモート側のアクセス権限を調べます。権限の問題を解決するためにプロトコルを手当たり次第に変更したり、問い合わせ記録にアカウント情報やパスワードを公開したりしないでください。操作手順は初回の追加と接続手順をご覧ください。

WireGuard：ネットワーク層トンネルと鍵の関係

リクエスト転送からアドレスとピアへ

WireGuardは、暗号化されたネットワーク層トンネルを構成するプロトコルです。固定された最新の暗号スイートと公開鍵によるIDモデルを採用し、プロトコルの選択肢やハンドシェイクの複雑さをできるだけ抑えるよう設計されています。特定の接続先へのリクエストを主に扱うプロキシプロトコルに比べ、ローカルのトンネルアドレス、ピアのID、エンドポイント、到達可能なネットワーク範囲の関係を重視します。Shadowrocketで使う場合も、アプリが端末の通信と接続先の関係をどのように構成するかを確認してください。他の環境でのルーティング動作がそのまま当てはまるとは限りません。

設定項目は少なく見えても、それぞれに明確な役割があります。エンドポイントアドレスは実際のネットワーク上でピアを見つけるためのもの、トンネルアドレスはトンネル内でのローカルIDを示すものです。公開鍵はピアを識別し、秘密鍵は自分のIDを証明します。エンドポイントアドレスとトンネルアドレスは通常、異なる種類のアドレスなので入れ替えて使えません。サーバーの公開アドレスをローカルトンネルアドレス欄に入力すると、ポートが正しくてもアドレスとルーティングの関係が不適切になります。

鍵がどちら側のものか確認

自分側の秘密鍵は厳重に保管し、ピアの公開鍵は接続先の識別に使います。どちらも任意に入れ替えられる同種の項目ではありません。設定に事前共有鍵が含まれる場合は、追加の鍵情報として双方で一致させます。ピアの公開鍵で代用することはできません。インポート後にハンドシェイクが失敗する場合は、まず鍵の所属とエンドポイントを確認し、次にネットワークへの到達性を調べましょう。自分側の鍵を再生成するとIDが変わります。サーバーが以前の公開鍵しか受け付けない場合、クライアント側だけを変更しても接続は復旧しません。

WireGuardの文脈でAllowed IPsは、ピアのアドレス範囲と暗号化ルーティングの関係に関わる項目です。単なるメモでも、端末で最終的に適用されるすべてのルーティングルールでもありません。Shadowrocketでは、Global RoutingやConfigも、通信がどの接続に流れるかに影響します。トンネルのハンドシェイクは正常なのに一部のアドレスへ到達できない場合は、トンネルのアドレス範囲、リモート側の転送条件、クライアントのルーティングをあわせて確認してください。最後のルールだけを見て、リモート側に必ず到達できると判断しないようにしましょう。

ハンドシェイク、MTU、Keepaliveを個別に確認

WireGuardはUDPを使用するため、通常のWebページにアクセスできても、エンドポイントが必要とするUDP経路が使えるとは限りません。ハンドシェイクを確立できない場合は、エンドポイントのドメイン、ポート、鍵、通信経路の条件を確認しましょう。ハンドシェイク後に少量のデータは通るのに、大きなページやアップロードが止まる場合は、続いてMTUを調べます。トンネルのカプセル化には追加の領域が必要です。通信経路のパケットサイズ制限に適切に対応できないと、一部のリクエストは成功するのに、大きなデータの転送が止まることがあります。

MTUは、他の人の端末で使われている数値をそのまま設定しないでください。まず現在の値を記録し、条件を管理できる状態で少しずつ検証して、Webページ、アップロード、連続転送が同時に改善するか観察しましょう。MTUを小さくするとフラグメントの問題を避けられることがありますが、同じ量のデータを送るのに必要なパケット数は増えます。小さいほど良いわけではありません。症状がパケットサイズに関係し、変更後に繰り返し改善が確認できた場合に限り、変更を維持する理由があります。認証の問題はMTUでは解決できません。

Persistent Keepaliveなどの設定は、一部のネットワーク機器でマッピングを維持するために使いますが、送信間隔はバックグラウンドのネットワーク動作に影響します。既存の環境で必要な場合にだけ設定し、「安定させる」ために一律で短い間隔にしないでください。携帯回線とWi-Fiを切り替えた後、新しいネットワーク上の位置をピアが適切に認識できるかも、実際に確認する必要があります。iPhoneでは、通信の維持、弱い電波、頻繁なネットワーク切り替えが、プロトコル処理そのものよりバッテリーに大きく影響する場合があります。

このプロトコルを使うには、利用者が必要なピアの設定をすべて持ち、内容が一致していること、アクセスするアドレス範囲を把握していることが前提です。ハンドシェイク、トンネル内のアドレス、ドメイン、実際のアプリの順に確認し、ハンドシェイクの成功だけを完了とみなさないでください。ドメイン名では失敗するのにアドレス指定では接続できる場合はDNSを調べます。特定のネットワーク範囲だけ失敗する場合は、ルーティングとリモート側の転送を確認しましょう。スリープ後に復帰しにくい場合は、マッピングとKeepaliveを確認してください。鍵とルーティングを同時に変更するより、この順番で切り分けるほうが原因を特定しやすくなります。

Hysteria2：QUIC、帯域の指定、通信経路の条件

UDPベースの伝送方式を選ぶ際の考慮点

Hysteria2はQUICをベースに伝送を行い、安全なハンドシェイクとマルチストリーム機能を利用します。また、高遅延やパケット損失などのネットワーク条件を考慮した伝送方式を備えています。すべてのネットワークで同じ速度を実現するものではなく、従来のTCPベースの伝送とは異なる制御方式を特定の通信経路で利用する設計です。QUICはUDPを使うため、接続先や中継経路がUDPをどのように扱うかが、接続の可否に直接影響します。通常のWebページにアクセスできても、この経路が使える証拠にはなりません。

マルチストリームを理解するには、ストリーム間の伝送の独立性と、リソースを共有することの両方を考慮します。あるストリームのデータ待ちが、単一の順序付きバイトストリームのように他のすべてのデータを必ず止めるとは限りません。しかし、各ストリームは同じ通信経路、輻輳制御、利用可能な帯域を共有します。電波状況が悪化したり接続先の処理能力に制限があったりすると、マルチストリームでも容量は増えません。複数のリクエストが同時に遅くなった場合は、接続先サイトが一斉に障害を起こしたと考える前に、通信経路全体を確認しましょう。

認証、TLS、追加項目を個別に確認

基本の確認順は、プロトコルの種類、サーバーアドレス、ポート、認証情報、TLSの名前です。Hysteria2は、名前の似た別のプロトコル形式とそのまま置き換えられません。クライアントの種類は既存サーバーと一致させてください。認証項目は元の形式を保ち、SNIと証明書の要件も別々に確認します。既存の設定に追加の処理項目が含まれる場合は、現在のアプリが該当機能を提供し、サーバー側も同じ設定を使用していると確認できた場合にだけ入力してください。項目名から値を推測しないようにしましょう。

帯域に関する項目を速度測定の結果と誤解しないよう注意してください。対応する輻輳制御方式では、送信時の動作の目安や制限として使われることがありますが、入力値の速度が出ることをクライアントが保証するものではありません。アップロードとダウンロードで単位や入力方法が異なる場合があるため、現在の項目の説明と既存の設定を確認してください。数値を高く設定しても、契約回線や通信経路の容量を超えることはできません。むしろ、キューの増加、パケット損失、ほかの通信への影響を招くことがあります。

速度測定では応答性とスループットの両方を確認

ダウンロード速度が高くても、Web閲覧、音声通話、バックグラウンド同期がすべて快適とは限りません。転送中にほかのリクエストの応答も観察し、キュー待ちが目立つか確認しましょう。一度だけの最高値で判断したり、接続先やネットワークが異なる結果をプロトコル間で比較したりしないでください。まず控えめで再現可能な基準を作り、帯域関連の項目を調整した後に、スループットと応答性が両方改善したのか、どちらか一方だけ変化したのかを調べます。

iOS端末では、QUICの処理、大量のデータ転送、無線通信の継続が消費電力を増やす可能性があります。ただし、UDPを使うという理由だけで消費電力を一律に判断することはできません。同じ時間でより多くのデータをダウンロードすれば、端末の発熱が大きくなることがあります。比較するデータ量が異なる場合、その結果だけではプロトコルの効率が低いとはいえません。同じデータ量の転送にかかる時間と、同じ使用時間内のバックグラウンド動作を分けて比較し、電波状況や画面の状態も考慮しましょう。

Wi-Fiでは正常なのに携帯回線では接続に失敗し続ける場合は、認証情報を変更する前に、両方のネットワークでUDPが実際に使えるか確認してください。ネットワーク切り替え後に一時的な問題が起きるだけなら、再接続後に復旧するか観察しましょう。失敗が続く場合は、ログに記録された段階を確認します。通信経路のパケットサイズ、サーバーのリソース、接続先の制限が原因となる場合もあるため、既存サーバーの管理者に確認が必要です。クライアント画面のタイムアウト表示だけでは、どの階層でリクエストが拒否されたか判断できません。

既存のサーバーがHysteria2に明確に対応し、現在のアプリで必要な項目をすべて設定でき、利用するネットワークでの反復テストでも安定した効果が確認できる場合に、使い続ける選択肢があります。既存の設定をすべて置き換える必要はありません。TCPベースの設定ですでに用途を満たせていて、利用中のネットワークでUDPが不安定なら、検証済みの設定を維持するほうが使いやすいこともあります。選択は利用場面に応じて判断し、プロトコル名の新旧だけで決めないようにしましょう。

用途に合わせた選択と段階的な検証

まず設定要件を満たし、その後に使い勝手を比較

実際の選択は、利用者がすでに持っている情報から始めます。サーバーが対応するプロトコル、必須項目、利用したいアプリを確認し、現在のネットワークで必要なTCPまたはUDPが使えるか調べましょう。通常のWeb閲覧、長時間の転送、リアルタイム通信、リモートネットワークへの接続では、ハンドシェイク、スループット、ジッター、ルーティングのどこを重視するかが異なります。すべての用途をカバーする単一の指標はありません。項目が不足している組み合わせや、通信経路の条件を満たさない組み合わせを除いてから、残った設定を比較するほうが、すべての種類を順番に試すより効率的です。

普段のWeb閲覧では、安定していて設定項目が明確で、最初のページ表示までの応答に問題がない既存の設定を優先できます。リアルタイム通信ではUDP、ジッター、連続性を個別に検証しましょう。リモートネットワークにアクセスする場合は、アドレス範囲と戻り経路を確認してください。複数の設定を使える場合は、DNS、ルール、伝送方式を同時に変えず、同じ端末、ネットワーク、接続先で繰り返し観察します。テスト結果が示すのは該当する用途での結果であり、すべての端末に共通するプロトコルの結論に広げないようにしましょう。

リクエストの経路はGlobal Routingで決まる

プロトコルが正しくても、ルールによって意図しない経路が選ばれることがあります。Configは現在のルールに従って処理方法を決定し、Proxyはルールの影響を一時的に小さくして確認する際に使えます。Directでは通常のネットワーク経由のアクセスを確認できます。モードの切り替えは診断のための手段であり、自動で問題を解決するものではありません。Proxyでは正常でConfigでは失敗する場合は、パスワードを再入力するのではなく、ルール、ポリシー名、DNSを確認しましょう。比較が終わったら元のモードに戻し、一時的なテスト設定がほかの通信に影響しないようにしてください。

以下は、ドメイン、アドレス、最終ルールの順序を示すShadowrocket設定の短いルール例です。設定全体ではありません。ルールは通常上から順に照合され、FINALは前のルールの後に置きます。ここでのPROXYとDIRECTはポリシーを示します。ポリシー欄にサーバーのパスワードを入力しないでください。名前付きポリシーを使う場合は、現在の設定で該当する名前が定義されていることも確認します。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはアドレス範囲、GEOIPはアドレスの所属地域データを基に照合し、FINALは前のルールに一致しなかったリクエストを処理します。これらはプロトコルの設定項目ではなく、リモート認証の内容を変更するものでもありません。ドメインルールの適用には、リクエストの処理過程で該当するドメイン情報が保持されている必要があります。接続先のアドレスしかわからない場合は、照合の条件が異なることがあります。ルールの順序、名前解決の結果、リクエストの種類をあわせて確認してください。詳しくはルールの書き方と照合の仕組みをご覧ください。

決まった順序で確認して原因を絞り込む

まず、アプリにシステムの許可が与えられ、想定した接続が選択されていることを確認します。次に接続先アドレスの名前解決と到達性、プロトコル認証とTLSの完了状況、DNS、ルールとポリシー、最後に接続先アプリを順に確認してください。前の段階で失敗している場合は、その問題を解決してから次に進みます。後続の項目を一度に大量に変更しないでください。Connectivity Testの結果は、実際のWeb閲覧、アップロード、必要なアプリの動作とあわせて判断しましょう。1つのテストが成功しても、すべての経路が使えるとは限りません。

記録にはネットワークの種類、Global Routing、選択中の接続、失敗した段階、再現性を残し、認証情報そのものは記載しないでください。長時間の転送が止まる場合はMTU、パケット損失、サーバーの状態も確認します。遅延は正常なのにドメイン名で失敗する場合はDNSのトラブルシューティングを、システムの接続スイッチに問題がある場合はトラブルシューティングをご覧ください。一度に変更するのは1項目だけにし、失敗したら基準の設定に戻します。根拠のない変更を重ねないようにしましょう。

最終的に残すべきなのは、偶然つながった状態ではなく、設定の根拠を説明できる構成です。有効な項目と適用できる用途を分けて記録し、サブスクリプションの更新後は重要項目を確認しましょう。ネットワーク条件が変わったときは、同じ順序で再確認してください。日常的な操作ははじめにをご覧ください。App Storeでの購入、購入済みアプリの復元、デバイスの互換性については入手と正規版の確認をご覧ください。プロトコルのトラブル対応と購入の問題を同時に扱う必要はありません。