Shadowrocket プロトコル技術ガイド

プロトコルを選ぶ前に：プロトコル・トランスポート・ルーティングの階層

Shadowrocketでプロトコルを選ぶことは、速度のラベルを付け替えることではなく、サーバーと同じ通信方式を選ぶことです。サーバーが特定のプロトコルだけを受け付ける場合、クライアントでも対応する種類を選ぶ必要があります。Add Serverで種類だけを変更しても、サーバーに新しい機能が加わるわけではありません。サブスクリプションから読み込んだ項目には、通常こうした条件が含まれています。手動編集の前に元の項目を残し、複数の設定が同時に変わって原因を特定できなくなる事態を避けましょう。

1つの接続を構成する複数の役割

接続情報は4つの層に分けて確認できます。アドレスとポートは接続先を示し、プロトコルと認証は相手が接続を識別する方法を定めます。トランスポートと暗号化はデータの送信方法に関わり、ルールはどのリクエストをその項目に振り分けるかを決めます。各層は関連していますが、互いに代用はできません。パスワードが正しくても証明書が正しいとは限らず、証明書が有効でもサーバーがそのアカウントを受け付けるとは限りません。ルールでPROXYを指定しても、選択中のサーバーが使えるとは限りません。階層ごとに確認すれば、「接続済みなのにWebページが開かない」原因が複数あり得る理由が分かります。

プロトコル名だけでは、外側のトランスポートまで分からないことがあります。VMessやVLESSは複数のトランスポート設定と組み合わせられます。TrojanはTLS接続で使われることが多く、Hysteria2はQUICベースのトランスポートを使用します。WireGuardはネットワーク層のトンネルを構築します。プロトコル設定にWebSocket、Host、Path、SNIなどがある場合は、外側の条件も確認してください。名称から値を推測したり、似た別の項目から設定をそのままコピーしたりしないでください。

条件をそろえてから挙動を比較する

選択できるのは、利用中のサーバーが提供し、かつ現在のクライアントが対応している設定に限られます。有効な項目が1つなら、名称の新しさではなく、正しく設定して確認することが重要です。複数の項目を利用できる場合は、ローカルネットワーク、接続先のWebサイト、テスト方法をそろえたうえで、接続成功率、最初のコンテンツが表示されるまでの時間、継続転送、バックグラウンドでの動作を確認します。サーバーの場所や負荷、帯域幅、中継ネットワークの違いがプロトコル自体の差を上回ることもあります。サーバーが異なるテスト結果を、プロトコルだけの差として判断することはできません。

データの安全性も階層ごとに判断してください。プロトコル接続が暗号化されていても、接続先アプリが独自のセキュリティ要件を無視するわけではありません。接続先WebサイトのHTTPSは、引き続きエンドツーエンドの本人確認を担います。一方、通常のHTTPやSOCKS5で接続する場合、プロキシまでの経路が自動的に暗号化されるとは限りません。設定情報を読む際は、プロキシ経路、接続先Webサイト、ドメイン名の名前解決を区別し、それぞれがどの仕組みで保護されるかを確認してください。鍵のアイコンやプロトコル名だけで判断しないことが大切です。

Global Routingではプロトコルは変わらない

Global RoutingのConfig、Proxy、Directはトラフィックの処理方法を指定します。Configは設定ファイルのルールに従ってリクエストを処理し、Proxyはプロキシ経由で処理し、Directは直接接続します。これらを切り替えても、ShadowsocksがTrojanに変わったり、不足している認証情報が補われたりすることはありません。原因を調べる際は、必要に応じてモードを切り替えてルールの影響を切り分け、テスト後は普段の設定に戻してください。一時的な設定をそのまま使い続けないよう注意しましょう。具体的な手順はチュートリアルのルール解説をご覧ください。

本ページでは互換性と設計上の違いを説明します。特定のプロトコルを一律に順位付けするものではありません。プロトコルによって特定のネットワーク環境での通信方法が改善されることはありますが、サーバーの実際の帯域幅が増えるわけでも、無線の電波状況や無効なアカウントの問題が解消するわけでもありません。「正しく接続できるか」と「接続後に目的を達成できるか」を別々に考えましょう。そうすることで、各章の設定項目を確認する意味が明確になります。

Shadowsocks：暗号化プロキシの設定範囲

Shadowsocksは比較的シンプルなプロキシプロトコルで接続を中継し、クライアントとサーバーが共有する認証・暗号化情報を使ってデータを処理します。リモートのネットワークインターフェースではなく、サーバーが属するネットワークの全ルートをクライアントに渡す必要もありません。通常、必要な情報はサーバーアドレス、ポート、暗号化方式、パスワードです。項目が少なく見えても、すべて一致していなければなりません。アドレスとパスワードが同じだからといって、暗号化方式を任意に変更できるわけではありません。

暗号化方式は好みで変更できる項目ではない

暗号化方式によってデータ形式や鍵の扱いが異なります。一般的な認証付き暗号方式では、本文を秘匿するだけでなく、データが改ざんされていないかも確認します。サーバーで指定された方式を使ってください。新しい方式の中には、特定の形式の鍵が必要なものもあり、一般的な短いパスワードとして扱えない場合があります。元の情報に長いエンコード文字列がある場合は、大文字・小文字、記号、末尾の文字までそのまま保持してください。覚えやすい形に書き換えたり、空白や引用符を追加したりしないでください。

リンクから読み込むと手入力のミスを減らせますが、文字列の見た目だけで設定の正しさを確認することはできません。読み込み後に、プロトコルの種類、アドレス、ポート、暗号化方式が元の情報と一致しているか確認してください。認識できないリンクは、まずリンクが完全か、別途対応が必要な拡張情報が含まれているかを確認します。ブラウザーに表示された一部だけをコピーしたり、表示名を認証情報として扱ったりしないでください。項目名は識別用のメモであり、通常はサーバーの認証には使われません。

TCPとUDPはそれぞれ確認が必要

Webページへの接続は通常、信頼性の高いトランスポートを利用しますが、リアルタイム通信や一部のアプリではUDPが使われることもあります。Shadowsocksで対象のトラフィックを処理できるかは、クライアントの設定、サーバーの対応、中継ネットワークの条件がそろうかによって決まります。Webページは開けるのにリアルタイム機能が失敗しても、すぐにパスワードの誤りと判断しないでください。まず対象機能が使うトランスポートを確認し、サーバー側で該当する転送が有効か、ローカルネットワークがその通信を許可しているかを調べます。Webページを1回開けても、そのときの経路が使えたことしか確認できません。

設定情報には、追加のトランスポートやプラグインのパラメーターが含まれることがあります。これらはサーバー構成の一部であり、すべてのShadowsocks項目に共通して必要なものではありません。アドレス、ポート、パスワードだけでは、拡張機能を使う接続を再現できない場合があります。現在の画面に対応する入力欄がない場合は、似た名前の欄に無理に入力せず、設定元に互換性を確認してください。プロトコル自体への対応と、特定の拡張機能への対応は別です。読み込みが成功しても、すべての拡張機能が実際に使われるとは限りません。

iPhoneでの効率の考え方

シンプルなプロトコル構造は余分な処理を抑えやすいものの、どの環境でも速く、バッテリー消費が少ないとは限りません。暗号化アルゴリズムを効率よく実行できるか、サーバーの処理能力、接続数、無線ネットワークでの再送などが結果に影響します。Webページの閲覧とファイルの連続転送では負荷が異なります。前者は接続確立や小さなリクエストへの応答、後者は安定したスループットが重要です。大容量ファイルの転送を1回比べるだけでは、普段のアプリで繰り返し接続する際の使い勝手を見落とすことがあります。

バッテリー消費は、安定した接続を少数維持する場合と、接続に失敗して何度も再接続する場合で大きく異なることがあります。正しく設定された2つの項目間で暗号化処理の負荷を比べるより、その差が目立つこともあります。バックグラウンドでの消費が明らかに変わった場合は、項目が繰り返しタイムアウトしていないか、On Demandが接続を継続的に起動していないか、ネットワーク切り替え後に接続が復旧するかを確認してください。「Shadowsocksは設定項目が少ないからバックグラウンドでも消費しない」とは限りません。また、システムに記録されたネットワーク活動のすべてがプロトコル自体によるものでもありません。

トラブルの確認はシンプルな順序で進められます。元の項目が有効かを確認し、暗号化方式とパスワードを照合したら、サーバーの接続先とローカルネットワークを確認し、最後にルールと名前解決の違いを調べます。1回の失敗で方式、ポート、DNSを同時に変えないでください。復旧しても原因が分からなくなります。確認済みの設定を控えておけば、次回のサブスクリプション更新後に、サーバー側の情報が変わったのか、ローカルでの編集が原因なのかを見分けやすくなります。

VMessとVLESS：認証と外側のトランスポートを分けて確認

VMessとVLESSは、複数のトランスポートを組み合わせるサーバー設定でよく使われますが、同じ種類の別名ではありません。VMessは独自の認証とデータ処理方式を定めています。VLESSは簡潔な認証情報とリクエスト記述に重点を置き、接続の保護は構成に組み合わせるセキュリティ層に委ねます。どちらもUUIDを使う場合がありますが、UUIDが同じだからといって相互に置き換えられるわけではありません。サーバーの待ち受けプロトコル、トランスポート方式、セキュリティ設定をクライアント側とすべて一致させてください。

プロトコルとトランスポートを分けて考える理由

これらのプロトコルは、複数のトランスポートやサーバー構成を組み合わせる用途で使われるため、項目には「誰が接続するか」だけでなく、「どの外側の経路で接続するか」も含まれることがあります。同じVLESSでも、外側のトランスポートはまったく異なる場合があります。WebSocketを使う場合はHostとPathも確認し、TLSを使う場合は証明書に関する設定も確認してください。どの階層でも設定が一致しなければ、認証段階に至る前に接続が終了することがあります。

UUIDは認証用の識別子であり、Webサイトのアドレスでも、自由に入力できる端末名でもありません。元の情報を一文字ずつコピーし、区切り記号を変えたり、別の項目の値に置き換えたりしないでください。VMessの認証では時刻も重要です。システム時刻が大きくずれている場合は、自動設定に戻して再確認してください。時刻のずれはTLS証明書の有効期間の判定にも影響するため、VMessだけの確認項目ではありませんが、こうした設定では早めに調べる価値があります。

VMessの互換性に関する情報の扱い方

古い設定情報には認証互換性の追加項目が含まれることがあり、新しい情報では別の認証方式が使われることもあります。過去のチュートリアルに記載された固定値を、すべてのサーバーに共通する初期値として扱わないでください。また、「最新の設定」にするために、現在使えている項目を勝手に変更しないでください。利用中のサーバーが提供する最新かつ完全な情報を優先します。サブスクリプションの内容と手動入力した設定が異なる場合は、表示名ではなく実際の項目を比べてください。意味を確認できない項目は、情報の提供元にサーバーでの用途を確認しましょう。

VMessのデータ保護と外側のTLSを混同しないでください。外側のTLSの有無、証明書の検証方法、中継の有無はそれぞれ独立した構成条件です。認証エラーとして表示される場合もあれば、ハンドシェイクや経路の不一致で止まる場合もあります。診断記録から失敗した段階が分かる場合は、その段階に対応する項目を確認してください。記録が明確でない場合も、アドレス、トランスポート、証明書、認証の順に範囲を絞り、暗号化設定を手当たり次第に変更しないでください。

VLESSのシンプルさが意味すること

VLESS自体が接続経路全体の暗号化を提供すると考えてはいけません。プロトコル層の一部の役割を減らしているため、外側のセキュリティ設定が特に重要です。設定情報でTLSなどの対応するセキュリティ方式が指定されている場合、クライアントでもその組み合わせを設定してください。UUIDとポートだけで接続全体を再現したことにはなりません。Flowなどの追加項目がある場合も、利用中のクライアントとサーバーが同じ組み合わせに対応することを確認してください。名称が似ているだけでは互換性の証明になりません。

Host、SNI、サーバーアドレスに同じドメイン名を入力する場合があっても、それぞれの役割は異なります。サーバーアドレスはネットワーク上の接続先を指定し、SNIはTLSハンドシェイクで接続先サービス名を伝えます。Hostは外側のリクエストのルーティングに使われることがあります。PathによってWebSocketリクエストの処理先が決まる場合もあります。複数段の中継を使う構成では、値が一致しなくても誤りとは限りません。すべてを「サーバーのドメイン名」に統一せず、元の設定で各項目が担う役割に従ってください。

速度は実際の設定の組み合わせで変わる

直接接続、WebSocket、追加のセキュリティハンドシェイクでは、接続確立にかかる時間が異なることがあります。ただし、接続が安定していれば、1回限りのコストはその後の通信に分散されます。そのため、小さなリクエストが多い用途と長時間のデータ転送では結果が異なる場合があります。VLESSの構造がシンプルだからといって、VMessより常に速いとは限りません。サーバー負荷、外側の中継、接続先Webサイトも主な制約になり得ます。iOSでは、プロトコル構造から一律の速度を予測するのではなく、実際に使う設定全体を比較してください。

利用中の設定で特定のトランスポートが指定されている場合は、性能を最適化する前に、その組み合わせが正しく動作するか確認してください。接続後に、初回アクセス、連続アクセス、ネットワーク切り替え後の動作をそれぞれ観察します。セキュリティ設定を変更する前に、元の項目を残してください。証明書の確認を無効にして速度を上げようとするのは避けてください。用語は用語集でも確認できますが、設定項目の値は、利用中のサーバーの説明と現在のアプリで選べる項目に従ってください。

Trojan・HTTP・SOCKS5：プロキシ接続のセキュリティ上の違い

これらはプロキシ接続の方式として使えますが、セキュリティ層と認証の仕組みが異なります。TrojanはTLS接続上でプロキシリクエストを処理する設計で、対応するパスワードで認証します。HTTPプロキシはHTTPの仕組みで接続を確立または転送し、SOCKS5はより汎用的なプロキシリクエストのネゴシエーションを行います。選択時は、まずサーバーが実際に提供している接続方式を確認し、接続区間が暗号化されているかを調べてください。どの方式もWebページを転送できるからといって、完全に同じものとして扱わないでください。

Trojan：証明書の検証は接続条件の一部

Trojanの設定では、アドレス、ポート、パスワードに加え、TLSのサービス名も重要です。サーバーアドレスはドメイン名またはIPアドレスですが、証明書は通常、特定の名前に対して発行されます。SNIはTLSハンドシェイクでサービス名を伝え、証明書検証では相手の識別情報が想定どおりかを確認します。両者は関連していますが同じものではありません。SNIを設定しただけで証明書が信頼できるとは限らず、任意のドメイン名を共通値として使うこともできません。サーバー情報で明示された名前を使用してください。

証明書の期限切れ、端末時刻のずれ、名前の不一致、中間証明書の不足などは、接続を妨げる原因になります。該当する場合はシステム時刻と元の設定情報を確認し、必要に応じてサーバー管理者に証明書の修正を依頼してください。「安全でない接続を許可」などの設定は、相手の本人確認に関する条件を変えるもので、通常の互換性改善や高速化のための機能ではありません。検証を無効にして接続できても、問題の箇所を特定する手がかりになるだけで、根本的に解決したことにはなりません。日常設定でその状態を使い続けないでください。

パスワードは元の情報から完全にコピーし、末尾の改行や空白にも注意してください。サーバーで追加のトランスポート方式を使っている場合は、関連するPathやリクエストパラメーターも一致させます。すべてのTrojanサーバーが同じ接続方式とは限りません。項目ごとの説明はTrojanのパスワード・SNI・TLS設定をご覧ください。記事では設定方法を解説しますが、サーバー情報の提供や、利用中の設定値の代わりにはなりません。

HTTP：プロキシ接続と接続先のHTTPSを区別する

HTTPプロキシは、管理されたネットワーク環境でよく使われます。HTTPSの接続先では、通常CONNECTで接続先アドレスへのトンネルを確立し、接続先アプリが引き続きTLS検証を行います。ただし、接続先WebサイトがHTTPSでも、クライアントからプロキシまでの制御情報が別のTLSで保護されるとは限りません。TLS付きのプロキシ接続が提供されている場合は、項目の種類やセキュリティ設定が実際の接続方式に対応しているか確認してください。一般的なポート番号に変えるだけでは不十分です。

プロキシのアカウントとパスワードは、Webサイトのログイン情報とは別です。認証に失敗した場合は、ユーザー名が必要か、パスワードが正しいか、現在の接続元がアカウントで許可されているかを確認してください。管理者から明示的な案内がない限り、ブラウザーのログイン画面に入力する認証情報をプロキシ用として使わないでください。通常のHTTPプロキシで利用できる機能は構成によって異なります。Webページを1つ開けただけで、すべてのアプリの通信に適しているとは限りません。UDPが必要な用途では、特に別途確認してください。

SOCKS5：汎用転送は暗号化を意味しない

SOCKS5はネゴシエーションによって接続先アドレスとリクエストの種類を指定します。ドメイン名を接続先として扱えるほか、認証やUDP転送の仕組みも定めています。ただし、プロトコル自体を暗号化トンネルとみなすことはできません。実際のサーバー構成によって、認証方式、接続先、UDPの利用が制限される場合があります。クライアントとサーバーの両方が対応して初めて機能します。SOCKS5という名称だけでは、特定の通信が許可されているか、接続経路がどのように保護されているかは分かりません。

ドメイン名をどこで名前解決するかも重要な違いです。プロトコルがドメイン名を扱える場合でも、アプリやローカルの名前解決処理で先にIPアドレスへ変換されることがあります。トラブルの確認では、ShadowrocketのDNSとルール設定を合わせて調べてください。プロトコルの説明だけから、すべての名前解決がリモートで行われると判断するのは適切ではありません。Webサイトの名前ではアクセスできないのに、直接入力したアドレスには応答がある場合は、プロキシアカウントの変更や認証エラーと決めつけず、名前解決の結果とルールの適用を確認してください。

日常的な用途での選択は、利用中の環境から始めてください。サーバーがTrojanを提供している場合は、証明書とパスワードを正確に確認します。管理されたネットワークでHTTPやSOCKS5が提供されている場合は、管理上の要件とセキュリティ上の条件を確認してください。設定を簡潔に見せるために必要なTLSを省いたり、種類を試すために既存の項目を一括変更したりしないでください。iPhone・iPadでは、条件に合わない方式を何度も試すより、正しく設定された安定した接続のほうが速度とバッテリー消費の面でも有利です。

WireGuard：ネットワーク層のトンネルと鍵の設定

WireGuardは、ここまでに紹介したプロキシリクエスト向けのプロトコルとは異なり、暗号化トンネルでネットワーク層のデータを運びます。比較的シンプルなプロトコルと固定された暗号方式の組み合わせを採用し、多数のネゴシエーション項目を減らしています。そのため、利用者が多くの暗号化方式から選ぶ必要はありませんが、ローカルインターフェース、相手の識別情報、ルーティング範囲を正確に設定する必要があります。項目が少なく見えても、ネットワーク設計を省略できるわけではありません。アドレス、鍵、許可範囲によってトンネルの機能が決まります。

Private KeyとPublic Keyの役割

ローカルのPrivate Keyは自分側の識別と保護に使い、Public Keyは対応する相手を識別するために使います。両者は関連していますが、相互に置き換えることはできません。設定をコピーする際、自分のPublic Keyを相手の識別情報欄に入れたり、相手のPublic Keyを自分のPrivate Keyとして入力したりしないでください。元の情報に事前共有鍵が含まれている場合は、双方で一致させる必要があります。これはメモ欄ではなく、接続が不安定だからといって任意に削除できる項目でもありません。

ローカルの秘密鍵は機密情報です。トラブルの確認では「元の設定と一致することを確認済み」と記録するにとどめ、内容全体を公開の場に送ったり、公開されるスクリーンショットに表示したりしないでください。ローカルの秘密鍵を変更すると、通常はサーバー側でも対応する認証情報の更新が必要です。クライアントだけで新しい鍵を生成しても、同じサーバーが引き続き受け付けるとは限りません。端末を紛失した場合や設定を無効にする必要がある場合は、利用中のサーバー管理者に相手側の認証を処理してもらってください。表示名を変えるだけでは対応できません。

Endpoint、Address、Allowed IPs

Endpointは相手の接続先アドレスとポートを指定し、ローカルのAddressはトンネル内で使うアドレスを指定します。用途は異なります。外部から接続するアドレスをトンネル内のアドレス欄に入れたり、トンネル内のアドレスを外部サーバーの接続先として使ったりすると、想定した接続ができません。アドレスの種類も実際の設定に合わせてください。元の情報に一方のアドレスだけが記載されている場合、もう一方を勝手に補わないでください。DNS欄は通常、名前解決の設定を示すもので、ローカルインターフェースのアドレスやサーバーのEndpointの代わりにはなりません。

Allowed IPsは、相手が扱えるアドレス範囲に関係し、WireGuardのルーティングや送信元確認にも使われます。Shadowrocket全体の処理では、実際の接続先を判断するためにアプリのトラフィックポリシーも確認する必要があります。Allowed IPsをWebサイトのドメインルールと同じものとして扱わないでください。範囲が狭すぎると一部の接続先がトンネルを通れず、広すぎると元のネットワーク設計から外れることがあります。管理者から提供された設定に従い、「すべて使えるようにする」ために範囲を勝手に広げないでください。

モバイルネットワークでのKeepaliveと復旧

WireGuardはUDPを使用します。モバイル端末でWi-Fiとモバイル通信を切り替えると、ネットワーク上のマッピングが変化することがあります。WireGuardには相手のアドレス変更に対応する設計がありますが、実際に復旧できるかは、新しい通信が相手に届くか、サーバーが受け付けるか、ローカルネットワークが許可するかによります。必要に応じてPersistent Keepaliveを設定すると、一部のネットワークマッピングを維持できますが、定期的な通信が増えます。すべてのネットワークに共通して適切な値はありません。利用中の環境の要件に従い、バックグラウンドでの動作やネットワーク切り替え後の挙動を確認してください。

安定性を高めようとしてKeepaliveの間隔を極端に短くしないでください。無線ネットワークでは、少量の定期通信でも端末がスリープする機会に影響することがあります。ネットワークが安定しており、マッピングを維持する必要がなければ、Keepaliveを追加しても効果がない場合があります。一方、元の設定で必要とされているKeepaliveを完全に無効にすると、長時間のアイドル後に最初のリクエストが失敗することがあります。実際に起きている問題に対して設定を検証し、アイドル後の復旧が改善するか、システムのバッテリー使用量にどのような影響があるかを確認してください。

MTUと一部の通信だけ失敗する問題

トンネルのカプセル化には追加のデータが必要なため、経路で扱えるパケットサイズが重要になります。MTUが適切でない場合、小さなリクエストは成功するのに大きな転送が止まる、あるWebサイトは開けても別のサイトは読み込み続ける、といった症状が出ることがあります。ただし、ほかの原因でも同様の症状は起こるため、読み込みが遅いだけでMTUを変更しないでください。まず元の値とサーバーの推奨値を確認し、ルール、名前解決、電波状況の問題を除外してから、一度に変更するのはこの項目だけにします。元に戻すための情報も残してください。

確認はハンドシェイクの有無だけで終わらせないでください。ハンドシェイクは通信の一段階が完了したことを示すだけです。接続先のネットワーク範囲、DNS、実際のリクエストも確認してください。ハンドシェイクが成功しても通信できない場合は、鍵を何度も作り直すのではなく、トンネルアドレス、許可範囲、サーバー側の転送条件を優先して確認します。こうすれば、認証の問題とネットワーク設計の問題を分けられ、正しい設定をむやみに変更せずに済みます。

Hysteria2：QUICトランスポートと帯域幅の設定

Hysteria2は、パケットロスや遅延、通信経路の変動がある環境で、安定した通信を実現することを設計上の課題の1つとしています。QUICベースのトランスポートを使用し、下位層でUDPと対応する認証・セキュリティの仕組みを利用します。「変動に対応する」という設計方針が、どのネットワークでも有効であることを保証するわけではありません。ローカルネットワークで必要なUDP通信が許可されていない場合や、サーバーの接続先に到達できない場合、プロトコル名を変更しても基本的な到達条件は変わりません。

UDPを「常に速い」と考えてはいけない理由

UDP自体には信頼性の高い順序付き転送の仕組みはありませんが、上位のプロトコルで信頼性の高いデータストリーム、再送、輻輳制御を実装できます。Hysteria2の通信性能は、こうした転送全体の設計によるものであり、信頼性をすべて省いているわけではありません。パケットロスへの対応は必要で、サーバーの帯域幅や処理能力にも上限があります。スループットが向上する一方で、実際の送信量が増える場合もあります。比較する際は、タスクの完了時間に加え、同じネットワーク上のほかの通信に大きな影響が出ないかも確認してください。

QUICは複数のストリームを扱い、ストリーム間のブロッキングが一部の状況で起こりにくくなります。しかし、無線の電波が弱い場合や、上り回線が混雑している場合、経路が絶えず変わる場合は、各ストリームが限られたネットワーク資源を共有します。「複数ストリーム対応」だからといって、1つのリクエストがほかのリクエストの影響をまったく受けないわけではありません。日常的なブラウジングと長時間のダウンロードでは、注目すべき指標も異なります。前者では名前解決やハンドシェイク、後者では安定した帯域幅が重要になることがあります。連続ダウンロードの速度だけで、すべての用途に適した設定かどうかは判断できません。

認証、SNI、証明書をそれぞれ確認

アドレス、ポート、認証情報は基本的な接続の成立に関わり、TLSの設定は相手の本人確認が想定どおりかを左右します。設定情報でSNIが指定されている場合は元の値を使い、証明書に問題がある場合は名前、有効期間、信頼チェーンを順に確認してください。下位層でQUICを使っているからといって、証明書の確認を省略しないでください。同じサーバーアドレスで別のプロトコルが使えても、別の接続先が到達可能だと分かるだけです。現在のUDP接続先や認証が正しいことの証明にはなりません。

サーバーによっては追加の難読化パラメーターが必要です。これらはサーバー側と一致させる必要があり、項目を多く有効にすればよいわけではありません。「接続に失敗した」というだけでは、不足している項目を特定できません。まず利用中の情報を読み、明確な指定があるかを確認してください。現在のクライアント画面に拡張設定がない場合は、対応範囲を確認するか、元の情報で互換性が明示された設定を使います。拡張用のパスワードを通常の認証欄に入れたり、似た設定の組み合わせを手当たり次第に試したりしないでください。

帯域幅の設定は目標値ではなく、通信条件を示す

アップロードとダウンロードの帯域幅設定は、転送速度や輻輳制御の動作に影響することがあります。具体的な効果は、双方の設定と実際のネゴシエーションによって異なります。入力する際は、単位と方向を確認してください。通常、アップロードはクライアントからネットワークへ送信する方向、ダウンロードはその逆です。ビットとバイトも別の単位です。サーバーの説明と実際の接続環境に合わせて設定し、数値をできるだけ大きくしないでください。実際より高い値を想定すると、キューの滞留やパケットロスが増え、ほかの対話的なリクエストまで遅くなることがあります。

モバイル通信で利用できる帯域幅は、電波状況、場所、ネットワーク負荷によって変化します。Wi-Fiも、外部ネットワークへの接続能力がルーターに表示された無線リンク速度と同じとは限りません。そのため、1回のピーク値を長期的な設定の根拠にしないでください。利用中の設定情報で手動設定が求められていない場合は、適切な初期設定を維持し、現在のネゴシエーション方式をまず確認します。変更後は連続処理と対話的な処理の両方を試し、瞬間的な速度だけで判断しないでください。似た条件で改善を繰り返し確認できて初めて、参考になる結果といえます。

iOSでのバッテリー消費と利用場面

タスクをより早く完了できれば、端末が早く低活動状態に戻ることがあります。一方で、大量のデータを継続して転送したり、再送や接続維持を行ったりすると、処理や無線通信のコストが増えます。両方の影響があるため、Hysteria2を常に省電力、または常に電力消費が大きいと決めつけることはできません。長時間の転送では完了までの合計時間と端末の温度を、バックグラウンドでの待機中は通信や再接続が続いていないかを確認してください。場面ごとに分けてテストすれば、異なる結果を混同せずに済みます。

利用中のサーバーがこのプロトコルを提供し、現在のネットワークで必要なUDP通信が許可されている場合は、実際の用途で比較対象にできます。特定のネットワークだけで失敗する場合は、まずそのネットワークの条件を確認してください。すべてのネットワークで失敗する場合は、認証、証明書、サーバーの接続先に戻って確認します。速度の詳しい調べ方は速度低下を階層別に調べる方法をご覧ください。正しい接続が確立する前に、帯域幅の設定を最適化しないでください。

速度とバッテリー：再現性のある比較方法

プロトコルの構造から想定される処理負荷は分かっても、特定のiPhoneでの使い勝手を順位付けすることはできません。アクセスは少なくとも、ローカルの無線ネットワーク、名前解決、プロキシの接続先、サーバーの転送、接続先サービスを経由します。どの段階がボトルネックになることもあり、接続テストの数値も特定の測定手順だけを反映します。速度の問題は、接続確立、最初の応答、継続的なスループット、失敗後の復旧に分けて考え、現在の用途に合った項目を確認してください。1つの結果で経路全体を評価しないことが大切です。

条件をそろえて初めて比較できる

同じ端末、同じネットワーク、同じ接続先を使い、近い条件で動作を確認済みの項目を比較してください。テスト前に、写真の同期、システムアップデート、ほかのアプリの大容量通信など、測定に関係しない転送を一時停止します。2つの項目でサーバーが異なる場合は、その違いを記録してください。この場合に比較できるのは2つの接続構成であり、プロトコルだけの差ではありません。接続先のコンテンツがキャッシュされている場合も記録します。そうしないと、2回目のアクセスが別の場所にあるキャッシュを読み込んだだけかもしれません。

数値をそろえるために、すべての診断を高頻度で連続実行しないでください。測定自体が通信量を消費し、サーバー負荷を高め、端末の動作状態を変えることがあります。まず実際の用途を再現し、原因を絞るために必要なテストを少数行うほうが、テスト一覧を何度も更新するより効果的です。最初の結果が異常なら同じ条件で再確認できますが、最も良かった結果だけを残さないでください。成功と失敗、ネットワーク切り替え時の条件を記録すると、ピーク値だけを記録するより問題の特定に役立つことがあります。

Connectivity Testで分かること

Connectivity Testの結果が示す内容は、テスト方法と接続先によって異なります。正常なら、その時点で対応するテスト経路が所定の手順を完了したことは分かりますが、すべてのWebサイトに接続できることや、継続的な帯域幅が十分なことまでは保証しません。タイムアウトしても、サーバーが完全に停止しているとは限りません。テスト先、名前解決、認証、ローカルネットワークが影響することがあります。テスト結果だけでプロトコルの優劣を決めず、実際のWebページや業務リクエストと合わせて確認してください。

ページの表示が始まるまで時間がかかる場合は、まず名前解決とハンドシェイクを確認します。表示開始は速いのに転送が遅い場合は、帯域幅、輻輳、サーバー負荷を調べます。特定の接続先だけ失敗する場合は、ルールの適用、接続先の状態、名前解決の違いを確認してください。項目ごとの詳しい確認手順は接続タイムアウトと接続失敗のチェックリストをご覧ください。同じ症状でも原因となる階層は異なります。テストは原因の範囲を絞るために行ってください。

バッテリー使用量は端末の動作と合わせて確認する

iOSのバッテリー使用状況には、一定期間のアプリに関連する動作が記録されます。表示割合はほかのアプリの使用量にも左右されるため、プロトコル単独の消費電力を測るものではありません。大量のダウンロード、接続テスト、バックグラウンド転送を行った後に、クライアントの使用量が増えても不思議ではありません。比較する際はタスク、時間、画面の状態、ネットワーク条件をできるだけそろえ、端末が発熱していないか、失敗を繰り返していないか、消費が前面操作中かバックグラウンドの待機中かも確認してください。

無線の電波が弱いと、通信にかかるコストが大きく変わることがあります。安定したWi-Fiの結果と、不安定なモバイル通信の結果をそのまま比べないでください。暗号化処理にもコストはかかりますが、多くのモバイル用途では無線通信、継続的な転送、端末の繰り返しの起動も重要です。意味のない再接続を減らすほうが、すでに一致している暗号化方式の設定項目を変更するより実用的な場合があります。プロトコルの設定項目数だけでバッテリーへの影響を推測したり、バッテリー持続時間の改善幅を一律に保証したりすることはできません。

On DemandとKeepaliveは別の機能

On Demandは条件に応じて接続を開始する方法を決め、プロトコルのKeepaliveは通常、既存の通信関係やネットワークマッピングを維持します。前者でサーバーの認証エラーを解決することはできず、後者で正しいオンデマンドルールを代用することもできません。無効な項目が条件によって繰り返し起動されると、接続を何度も試みる場合があります。Keepaliveの間隔が短すぎると、アイドル中も通信が発生することがあります。原因を調べる際は、起動条件と接続後の動作を分けて確認し、2種類の設定を同時に変更しないでください。

バックグラウンドでの問題はOn Demandとバックグラウンドのバッテリー消費を確認する方法もご覧ください。最終的な選択では、普段の用途を満たせるかを重視します。安定して開けること、ネットワーク切り替え後に復旧すること、アイドル時の動作が適切であることを確認してから、継続的な速度を比べてください。たまに行う大容量ファイル転送で優れていても、日常のブラウジングに最適とは限りません。1つの順位にまとめるより、用途ごとに確認済みの項目を残すほうが実用的です。

設定と確認：元の情報から日常使いのConfigまで

ここまでの内容を実際の設定に適用するには、「元の情報を保存」「種類を確認」「項目を照合」「接続を検証」「ルールを元に戻す」の5段階で進めます。初回起動時の画面操作はここでは繰り返しません。タップする順序はクイックスタートガイドをご覧ください。本章では、項目を追加できても読み込みが完全か分からない場合や、特定の項目を空欄にできるか、プロキシ接続は正常なのに普段のルールが機能しない理由が分からない場合を扱います。

読み込み後に確認し、すぐ一括変更しない

ご自身が利用中のSubscribe情報を使う場合は、元の情報を保存し、更新後の項目が想定したグループに属しているか確認してください。表示名だけでプロトコルやサーバーが同じだとは判断できません。サブスクリプションから生成された項目を手動で変更すると、次回の更新時に上書きされることがあります。管理方法を確認してから編集してください。設定項目を試す場合は、元の項目を残し、見分けられるテスト用の記録を作ります。サブスクリプション内のすべての項目で、アドレス、ポート、セキュリティ設定を同時に置き換えないでください。

サブスクリプションのURLにアクセス用の認証情報が含まれる場合があります。通常のリンクのように見えても、機密情報として扱ってください。完全なURLを公開スクリーンショットやエラー報告に載せないでください。構造を説明する場合は、明らかなサンプル値だけを使います。本ページで実際の設定を送信していただく必要はありません。情報を確認する際は、種類、認証、外側のトランスポート、セキュリティ設定がそろっているかを項目ごとに確認し、コピー時に改行や空白が混入していないか、内容が途中で切れていないかも調べてください。

失敗した段階に応じて確認する

サーバーの接続先に到達できない場合は、アドレス、ポート、現在のネットワークを確認します。TLSや証明書のエラーが出る場合は、端末の時刻、名前、信頼チェーンを調べます。認証段階で失敗する場合は、パスワード、UUID、鍵を確認してください。接続できても接続先を開けない場合は、DNS、ルール、サーバー側の転送、接続先自体の状態を確認します。すべての記録に失敗段階が明確に表示されるとは限りませんが、明らかな証明書エラーが出ているのにパスワードを繰り返し変更するような事態を防ぐための順序です。

特定のネットワークだけで失敗する場合は、同じ項目を使って2つのネットワークでそれぞれ確認してください。特定の接続先だけ失敗する場合は、同じネットワークで異なる接続先を試します。条件を一度に1つだけ変えれば、結果を再確認できます。システムの通知とアプリの記録が一致しない場合は、テスト時刻と実際に選択されている項目を確認してください。何度も編集すると、表示名が似た複製項目を取り違えやすくなります。リストの位置で判断せず、設定項目とグループから対象を確認してください。

設定を増やすのではなく、短いルールでポリシーを確認する

プロトコル接続が正常であることを確認したら、Global Routingを普段の用途に合わせてConfigに戻します。以下はShadowrocketの設定で参照できる短いルール例です。順序とポリシーを説明するためのもので、完全な設定ではありません。例に含まれるドメインはサービスの推奨先ではありません。PROXYやDIRECTの動作は、実際に選択した項目と現在の設定を合わせて確認してください。出所の分からない場所に例を追加しただけで有効になったとは判断せず、Configで想定したファイルが使われているか確認しましょう。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

1行目はドメインのサフィックスに基づいて一致させ、2行目は地理IPの条件で一致させます。最後の行は、それまでに一致しなかったリクエストの処理方法を指定します。ルールは通常、記載順に処理されるため、より具体的な条件を正しく適用できる位置に置いてください。ここでは構文例としてFINAL,PROXYを使っていますが、すべてのユーザーが残りの通信をプロキシ経由にするべきという意味ではありません。指定したWebサイトだけを処理する場合は、最終ポリシーを改めて決めてください。詳しくは指定したWebサイト向けのDOMAIN-SUFFIX設定をご覧ください。

終了条件と元に戻す方法を確認する

一通りの確認では、実際の用途、ルールの適用、アイドル後の復旧、普段発生するネットワーク切り替えを確認してください。設定が正しいことを証明するために、関係のない接続先を大量に開いたり、テストを長時間続けたりする必要はありません。普段のタスクが安定して完了したら、試験的な変更をやめ、必要な日常設定に戻して、残した設定を記録してください。テストに失敗した場合は、直前に変更した項目を元に戻してから次の確認へ進みます。一時的な変更を重ね続けないようにしましょう。

利用中のサービス提供元やサーバー管理者に問い合わせる場合は、プロトコルの種類、失敗した段階、ネットワークの状態、個人情報を除いたエラーの概要を伝えれば十分です。実際のパスワード、秘密鍵、サブスクリプションの完全なURL、個人的なアクセス内容は含めないでください。購入、購入済みの復元、App Storeでの互換性に関する問題は、購入済みアプリの復元方法と同ページのよくある質問をご確認ください。アカウントの購入に関する問題とプロトコル認証を混同しないでください。システム要件と購入の可否は、App Storeのページに記載された内容をご確認ください。

プロトコルガイドの目的は、問題を適切な階層で特定することであり、名称を何度も変えることではありません。アドレスと認証は接続先への接続を担い、セキュリティ層は相手を確認し、トランスポートはデータの届け方に関わり、Configはリクエストの転送先を決めます。この流れに沿って順番に確認すれば、見た目では区別しにくい接続失敗も、確認可能な小さな問題に分けられます。サブスクリプションの更新後や端末を変更した後も、分かりやすく元に戻せる状態を保てます。