Shadowrocket
プロトコルの選び方と設定項目

01 / プロトコル・通信方式・ルールを区別する

種類はサーバー側の設定に合わせる

Add Serverで種類を選ぶことは、クライアントとサーバー間で使う通信形式を選ぶことです。Shadowsocks、VMess、VLESS、Trojanなどは、それぞれ認証やデータの構成方法が異なります。自由に入れ替えられる速度設定ではありません。手元の情報にVLESSと記載されているなら、設定が簡単に見えるからといってTrojanを選ぶことはできません。接続には、サーバーが同じプロトコル、認証情報、通信方式の組み合わせに対応している必要があります。

設定は4つの階層に分けて考えると整理しやすくなります。最下層はデバイスからサーバーへのネットワーク到達性、その上にTCP、UDP、またはそれらを基盤とする通信方式があり、さらにプロトコル認証と任意のTLSが続きます。最後にリクエストが目的のサービスへ届きます。Configのルールはリクエストの振り分け先を決めるもので、サーバーのパスワードを修正するものではありません。階層ごとに切り分ければ、認証エラーでDNSを繰り返し変更したり、ルールの誤りでプロトコルを何度も変えたりする事態を避けられます。

アドレス・認証情報・通信方式をそれぞれ確認

サーバーアドレスは接続先を示し、ポートはその接続先で待ち受けているサービスを指定します。アドレスにはドメイン名とIPアドレスを使えますが、ドメイン名の場合は名前解決も必要です。認証項目は接続が許可されていることを示すもので、Password、UUID、鍵などが使われます。通信方式の項目は、WebSocketのPathやHTTP Hostなど、リクエストをサーバーへ届ける方法を指定します。アドレスと認証情報が正しくても、通信経路の設定が合わなければハンドシェイクが中断することがあります。

サブスクリプションをインポートすると、これらの項目がまとめてサーバー設定に反映されることがよくあります。最初のトラブル対処では、インポート直後の値を残し、手元の情報と一つずつ照合してください。意味が分からない項目を先に消したり、別の設定から項目を流用したりしないでください。画面に追加の通信項目がない場合、その組み合わせでは不要な可能性もあれば、選択中の種類に関係している可能性もあります。無関係な例をそのまま写すのではなく、現在のアプリ画面と手元の設定を基準にしてください。

速度と電池消費は同じ条件で比較する

iOSではプロトコルの処理にプロセッサーを使いますが、無線電波の状態、再送、画面の明るさ、バックグラウンド動作も同じように影響します。ハンドシェイクが短いからといって大容量ファイルの転送が速いとは限らず、帯域をすぐ使い切れるプロトコルが、低トラフィックで長時間待機する用途に適しているとも限りません。短い接続ではハンドシェイクや名前解決のコストが目立ち、継続的なダウンロードでは帯域、輻輳制御、サーバー負荷の影響が大きくなります。比較する前に、どのような用途を測定するのかを決めてください。

プロトコルを選んでも、サーバーが接続されているネットワークの条件は変わりません。同じプロトコルでも接続先によって遅延やスループットは大きく異なり、異なるプロトコルでも同じ混雑した出口を使えば、ともに遅くなる場合があります。比較時はデバイス、ネットワーク、接続先、測定時間をそろえ、大容量通信を行うほかのタスクを一時停止してください。接続の成否、最初のリクエストまでの待ち時間、継続通信の安定性を記録します。一度の測定結果を恒常的な順位として扱わないでください。

02 / Shadowsocks：暗号化方式とパスワードの組み合わせ

プロキシ転送を中心に構成された接続

Shadowsocksは、比較的シンプルな方法でプロキシ通信を扱い、クライアントとサーバー間に認証と暗号化を加える設計です。ユーザーが仮想ネットワーク全体の構成を理解しなくても、サーバーアドレス、ポート、暗号化方式、パスワードを中心に設定できます。項目が少ないため照合しやすい一方、どの組み合わせでも使えるわけではありません。暗号化方式もプロトコルの互換性を構成する要素です。

従来の設定では、アルゴリズムや動作方式、鍵長などが名称に含まれた暗号化方式がよく使われます。選択する際はサーバー側と完全に一致させ、端末の機種に合わせて速そうな方式を選ばないでください。方式によってパスワードの処理方法やパケット形式が異なる場合があります。クライアントに設定を保存できても、サーバーが受け入れるとは限りません。異なる認証情報の形式を求める派生方式では、通常のパスワードに置き換えず、手元の設定に従ってください。

基本の4項目を一つずつ確認

サーバーアドレスには実際の接続先を入力し、共有用のURL全体をアドレス欄に貼り付けないでください。ポートにはサーバーから指定された数値を入力します。コピー時に空白、コロン、説明文が混ざらないようにしてください。Passwordは大文字・小文字や記号も含めて保持します。チャットアプリからコピーすると改行が加わることがあるため注意してください。Methodは暗号化方式です。表記を一字ずつ照合してください。共有用のURLしか手元にない場合は、まずガイドに沿ってインポートし、読み込まれた内容を確認しましょう。手作業で分解するより、エンコードされた文字の見落としを防ぎやすくなります。

環境によっては、プラグインや通信方式に関する追加設定が必要です。これらは飾りの項目ではなく接続経路の一部です。サーバー側で追加のカプセル化が必要な場合、クライアントに対応する設定がなければ同じ形式で通信できません。一方、通常の接続先に独自のカプセル化を追加する必要はありません。用途が分からない場合は、ご利用のサービス提供元に項目の意味を確認してください。インターネット上で「共通の値」を探して既存の設定を上書きしたり、互換性を確かめずにチェックを無効にしたりしないでください。

TCPが正常でも、UDPが使えるとは限らない

ShadowsocksはTCPとUDPの転送に対応する場合がありますが、実際に使えるかどうかはサーバー、ネットワーク経路、クライアント側の設定によります。Webページが開けても、その時点で使われたリクエスト経路が成功しただけで、UDPが必要なアプリも正常に動くとは限りません。Webは使えるのにリアルタイムアプリで問題が起きる場合は、まずアプリが実際に利用する通信方式を確認し、サーバーが対応しているかを調べてください。すぐに暗号化方式を変える必要はありません。

UDPパケットにはサイズ制限があり、追加のカプセル化によってデータに使える領域が狭まります。小さなパケットは正常でも、大きなパケットや継続通信で問題が起きる場合は、Path MTU、パケットロス、フラグメンテーションを確認してください。パケットサイズによって症状が安定して変わる場合、Passwordを何度も変更しても解決にはつながりません。認証エラーが特定のパケットサイズでだけ起きることは通常ありません。すべての接続先で問題が起きるのか、特定のタスクだけかを記録し、同じサーバーで簡単なリクエストを試して原因を絞り込んでください。

iOSで処理負荷を確認する

ハードウェアと実装の相性が良ければ、最新の認証・暗号化方式で大容量通信を効率よく処理できます。ただし、実際の性能はサーバーの処理能力やネットワーク帯域にも左右されます。高いスループットで通信を続けると、暗号化、送受信、無線通信によって端末の発熱が増えることがあります。待機中は、実際に通信が発生しているかどうかを確認してください。設定項目が少ないという理由だけで常に省電力とは限らず、端末の発熱を特定のアルゴリズムだけのせいにすることもできません。

トラブル対処では、まず元の設定を残し、アドレス、ポート、Method、Passwordを一つずつ確認します。その後、Connectivity Testと実際の接続先へのリクエストを別々に試してください。すべてのリクエストに失敗する場合は、接続先と認証情報を優先して確認します。特定のアプリだけで問題が起きる場合は、UDP、DNS、ルールによる経路を調べてください。関連プロトコルの全体像はプロトコルの種類と特徴も参考になります。実際の設定には、手元にあるサーバー情報を使用してください。

03 / VMessとVLESS：認証情報だけでなく通信方式も確認

見た目が似ていても同じプロトコルとは限らない

VMessとVLESSは、どちらもUUID形式の識別情報を使うことがあり、複数の通信方式と組み合わせられるため、初見では混同しやすいプロトコルです。VMessはユーザー認証とプロトコル内のデータ保護を組み合わせます。一方、VLESSはプロトコル自体の処理を簡素化し、互換性のあるセキュリティ通信方式にデータ保護を委ねる設計です。パケット形式と認証手順は異なるため、UUIDの形式が同じでも、種類だけ変更して接続できるとは限りません。

UUIDはユーザーを識別する値であり、サーバーのドメイン名や表示名ではありません。コピー時は全体を保ち、文字の欠落や見えない空白の混入に注意してください。設定によっては認証方式や互換性に関する項目も含まれます。古いガイドを見て推測で入力しないでください。VMessの過去の設定項目は、現在のすべての設定で必要とは限りません。手元の情報と画面の項目が一致しない場合は、設定元と現在対応している組み合わせを確認し、値を推測で追加しないでください。

通信方式によってサーバー側の接続方法が決まる

同じプロトコルでも、異なる通信方式を利用できます。TCPを直接使う組み合わせでは、通常WebSocketのパスは必要ありません。WebSocketを使用する場合、PathやHostによってリクエストの転送先が決まることがあります。別の通信方式では、異なるサービス識別情報が使われる場合もあります。これらは通信を適応させるための項目であり、UUIDに代わるパスワードではありません。アドレスとUUIDだけを入力し、通信方式の項目を省略することは、不完全なインポートでよくある接続失敗の原因です。

Pathは先頭のスラッシュ、大文字・小文字、既存のクエリ部分を含めて保持してください。ユーザー向けのメモではありません。Hostとサーバーアドレスが異なる場合もあります。Hostはアプリケーション層のルーティングに使われることがあり、サーバーアドレスはネットワーク接続先を示します。TLSを併用する場合は、安全なハンドシェイクに使うServer NameまたはSNIも設定されることがあります。3つの値が同じ場合もありますが、役割はそれぞれ異なります。すべてをサーバーのIPアドレスに変更して一致させるのではなく、設定情報に従って個別に入力してください。

VLESSの簡素さは、セキュリティ層を省略できるという意味ではない

VLESSを説明する際は、「プロトコル自体が一部の暗号化を担わない」ことと「接続全体が保護されていない」ことを区別する必要があります。実際のセキュリティは、組み合わせる通信方式や認証機能によって決まります。プロトコル名だけで安全性を判断したり、画面の項目に「暗号化なし」と表示されているからといって、TLSを無効にしたりしないでください。サーバーが特定のセキュリティ設定を要求する場合は、その設定をすべて保持してください。説明がない場合は、接続前に不足している情報を確認しましょう。

設定によってはFlowなどの追加項目が表示されます。特定の動作方式に対応する項目であり、どの環境でも有効にできる性能設定ではありません。誤った値を入力すると、認証後に接続が切れたり、サーバーに受け付けられなかったりすることがあります。手元の共有情報を基準にし、Shadowrocketの現在の画面でその組み合わせを設定できるか確認してください。対応する項目が画面にない場合、メモ欄に値を入れても設定できません。サーバー側に互換性のある接続先があるか確認してください。

ハンドシェイク、時刻、モバイルネットワークの切り替え

時刻の確認を含む認証手順は、デバイスの時計がずれていると影響を受けることがあります。接続先に到達できるのに認証が繰り返し失敗する場合は、システムの日付と時刻が正しいか確認してください。ただし、あらゆる接続失敗を時刻のずれだけで説明できるわけではありません。TLSと追加の通信方式を組み合わせる場合、最初のリクエストで複数段階のハンドシェイクが行われることがあります。継続通信が始まれば、この固定コストは分散されます。そのため、Webページを最初に開く速さと大容量ファイルの転送速度では、結果の順位が異なることがあります。

iOSでWi-Fiとモバイル通信を切り替えると、既存の接続を再確立する必要が生じる場合があります。復帰後の新しいリクエストが成功するかを確認し、既存のダウンロードが一切途切れないことを期待しないでください。VMessとVLESSを比較する際は、通信方式とサーバーの条件をできるだけそろえましょう。そうしないと、測定差がWebSocket、TLS、接続先の負荷によるものかもしれません。VLESSの設定を詳しく確認する場合は、まず現在の項目を保存し、修正が必要と分かっている項目を一度に1つだけ変更してください。

04 / Trojan：TLS内のパスワード認証を理解する

TLSは安全な通信路を担い、パスワードは利用権限を確認する

Trojanは、実績のあるTLS通信路の中でプロキシ通信を行い、その内部で認証とリクエスト転送を行う設計です。理解するには、2段階の確認を分けて考えてください。まず、クライアントは信頼できるTLSサーバーに接続していることを確認します。次に、そのサーバーがクライアントから送られたパスワードを検証します。証明書が正しくても、プロキシのパスワードが受け入れられたとは限りません。両者は互いに代用できません。

一見するとどちらも「サーバーへの接続」中に起きるエラーでも、原因は異なることがあります。サーバーアドレスやポートが違うと、TCP接続さえ確立できない場合があります。Server Nameが一致しなければ証明書の検証に失敗することがあります。Passwordが誤っている場合は、TLS接続の確立後に拒否されることがあります。失敗した段階に合わせて該当項目を確認し、すべての切断をパスワードの誤りと決めつけないでください。ドメイン設定の問題を隠すために証明書の検証を無効にするのも避けてください。

接続先アドレスと証明書名が異なる場合がある

Addressはネットワーク接続をどこに送るかを指定します。Server NameまたはSNIは、TLSハンドシェイクでサーバー名を伝えるために使用されます。IPアドレスで接続する場合も、サーバー証明書がドメイン名に対して発行されていることがあるため、手元の設定で別の名前が指定されている場合があります。証明書には有効期間、発行元の証明書チェーン、名前の適用範囲も関係します。ブラウザーでWebサイトを開けても、プロキシの接続先と同じポート、証明書、ルーティング設定が使われているとは限りません。

サーバーが複数のサービスを提供している場合、SNIによって選択される証明書やバックエンドが変わることがあります。よく知られたWebサイトのドメインに変更しても、通常は問題の解決にならず、無関係なサービスへリクエストが送られるおそれがあります。正しい値は手元の設定情報で確認してください。以前は接続できたのに突然証明書エラーが出た場合は、デバイスの時刻、サーバー証明書の状態、接続先の変更を確認し、エラー内容を残したうえでご利用のサービス提供元に問い合わせてください。

追加の通信方式もすべて一致させる

Trojanの設定が最小限の項目だけとは限りません。TLSを使っているように見える構成でも、サーバーによっては特定の通信方式やパスとの組み合わせが必要です。手元の情報に従い、別のTrojan設定の項目を混ぜないでください。サブスクリプションからインポートした場合は、アプリが種類と通信方式をすべて認識しているか確認します。手動で入力する場合は、アドレス、ポート、パスワード、セキュリティ層の名前、指定された追加項目をそれぞれ記録してください。

パスワードは大文字・小文字を区別する認証情報です。コピー時に空白、改行、記号の置き換えが入ると認証に失敗することがあります。サブスクリプション取得用のトークンをTrojanのパスワードとして使ったり、設定のメモをユーザー名として使ったりしないでください。サブスクリプションのURLとサーバーの認証情報は別のものです。前者は設定を取得するため、後者は実際に接続するために使います。サブスクリプションの更新が成功しても、掲載されたすべてのサーバーに現在接続できるとは限りません。

iOSでの速度と電池消費は利用方法によって変わる

TLSはモバイルOSで広く使われている成熟した機能ですが、処理コストがないわけではありません。安全な通信路を初めて確立する際にはハンドシェイクが必要で、短い接続を頻繁に作る場合はその待ち時間が目立つことがあります。継続通信では、ネットワーク、暗号化処理、サーバーの転送能力がスループットに大きく影響します。追加の通信方式を重ねる場合は、カプセル化や接続管理のコストも考慮してください。Trojanが常に別のプロトコルより速い、または遅いと単純に断定することはできません。

電池消費を確認する際は、実際の利用時間を通して観察してください。短時間のダウンロードは瞬間的な消費電力が大きくても、すぐに完了することがあります。接続失敗と再接続を繰り返すと、通信量が少ないままネットワークが起動し続ける場合があります。待機中の消費が多い場合は、バックグラウンドでリクエストするアプリがないか、再試行が続いていないか、ネットワークを頻繁に切り替えていないかを確認し、On Demandの動作条件も見直してください。プロトコル名だけではバックグラウンド動作の原因は分からず、パスワードを変更しても再試行は止まりません。

トラブル対処では、まず現在の接続先に接続し、通常ならアクセスできるWebサイトを開き、最後に実際の用途を試すと切り分けやすくなります。接続段階で失敗する場合は、アドレス、TLS、認証情報を確認してください。特定の接続先だけで失敗する場合は、DNS、ルール、接続先からの応答を調べます。「接続はオンなのにWebページが開かない」場合の手順は、接続をオンにした後の4段階チェックもご覧ください。TLSだけを何度も試すのを避けられます。

05 / HTTPとSOCKS5：プロキシのインターフェースと暗号化通信路は別

アプリケーション層プロキシの役割から違いを理解する

HTTPプロキシは、アプリケーション層でのリクエスト転送に使われます。通常のHTTPリクエストを処理するほか、CONNECTを使って接続先へのバイトストリームを確立することもできます。SOCKS5は、接続先アドレスや接続コマンドを汎用的に指定する方式で、転送するデータがすべてWebプロトコルである必要はありません。どちらもプロキシのインターフェースを表すものであり、名前だけからクライアントとプロキシサーバー間が暗号化されていると判断することはできません。セキュリティ層は別途確認してください。

接続先のWebサイトがHTTPSを使っていることとは別の問題です。接続先のHTTPSは、デバイスと接続先の間でアプリケーションデータを保護できますが、プロキシの接続先などの情報が見える可能性があります。プロキシ自体への認証と通信にも、独自のセキュリティ境界があります。TLS付きのHTTPプロキシを選ぶ場合は、証明書とサーバー名を確認してください。手元の情報が通常のプロキシを指定している場合、クライアントでTLSを有効にしても、サーバーが自動的に対応するわけではありません。

ユーザー名・パスワードとサーバー側の利用許可範囲

HTTPとSOCKS5では、ユーザー名とパスワードを使う場合もあれば、サーバー側のアクセス制御によって利用を許可する場合もあります。手元の情報どおりに入力し、項目を空欄にすれば必ず使えると思い込まないでください。特定のネットワークからの接続だけが許可されているプロキシは、モバイル通信に切り替えると受け付けられないことがあります。ネットワーク切り替え後に失敗する場合は、認証情報とサーバー側のアクセス範囲をあわせて確認してください。すぐにShadowrocketの設定が壊れたと判断する必要はありません。

画面で完全なURLを入力するよう明示されていない限り、サーバーアドレスに余分なプロトコルの接頭辞やパスを含めないでください。ポートを接続先Webサイトのアドレスから推測することもできません。職場や個人で管理しているネットワークの情報を使う場合は、プロキシの利用目的と接続先の許可範囲も確認してください。特定のアプリやネットワーク領域専用の接続先もあります。一度認証できたからといって、すべてのインターネット上の接続先へ転送できるとは限りません。

どこでドメイン名を解決するかによって結果が変わる

リクエストがプロキシに届く前に、クライアントが接続先のドメイン名をIPアドレスに解決する場合と、ドメイン名をプロキシに渡して解決させる場合があります。どちらの方法を使うかによって、名前解決の場所、エラーの現れ方、ドメイン名に基づくルールの判定が変わります。SOCKS5がドメイン名の指定に対応していても、すべてのリクエストが必ずサーバー側で名前解決されるとは限りません。ShadowrocketのDNSやルーティング設定、アプリのリクエスト方法、実際の実装も関係します。切り分ける際は、ドメイン名を使うリクエストと、既知のIPアドレスを使うリクエストをそれぞれ確認してください。

同様に、Webページが表示できてもリアルタイム通信が利用できるとは限りません。一般的なHTTP CONNECTは主にTCPを対象とします。SOCKS5にはUDP ASSOCIATEがありますが、サーバー、クライアントの設定、中間ネットワークがすべて対応している必要があります。用途でUDPを使う場合は、接続先がその機能を明示的に提供しているか確認してください。対応がない場合、接続先のポートを変更するだけでは解決しません。手元のサーバー側で互換性のある接続方式を用意する必要があります。

用途とiOSでの動作

職場のネットワークから提供されたHTTPプロキシや、個人で管理している環境のSOCKS5接続先を使う場合は、別のプロトコルに無理に変更するより、対応する種類を選ぶほうが適切です。重要なのは汎用的に聞こえるプロトコル名ではなく、既存のサービスに合っていることです。信頼できるローカルネットワーク内だけで使う接続先であれば、そのネットワーク範囲も設定条件の一部です。接続環境が変わった場合は、認証の保護、ネットワーク到達性、アクセス許可範囲を改めて確認してください。

プロトコル自体の処理が少なくても、全体の電池消費が少なくなるとは限りません。追加の暗号化を行わない接続では一部の計算を省ける場合がありますが、接続先のTLS、ネットワークの再送、アプリのリクエスト頻度は変わりません。プロキシサーバーの処理が遅いと、デバイスが無線通信をより長く続けることがあります。比較時は成功率、リクエストの待ち時間、継続タスクの完了時間も記録してください。一度の遅延測定だけで、通常のプロキシがあらゆる用途に最適な選択肢だと判断しないでください。

一部の接続先にしかアクセスできない場合は、まずプロキシのアクセス方針と接続先ポートの制限を確認し、その後ローカルルールを調べてください。認証が拒否された場合は、ユーザー名、パスワード、接続元ネットワークの範囲を確認します。ハンドシェイク後に接続先がタイムアウトする場合は、名前解決とサーバーから接続先までの経路を確認してください。このように階層ごとに切り分ければ、プロトコルの種類を何度も変えるより効率的です。ご利用のサービス提供元にも、「使えない」だけではなく、具体的な状況を伝えられます。

06 / WireGuard：鍵・Peer・アドレスルーティング

ネットワーク層のトンネルを扱うプロトコル

WireGuardは、ネットワーク層のトンネル、簡潔な暗号方式、公開鍵による対向先の識別を中心に設計されています。プロキシのパスワードを1つ入力する種類と比べて、ローカルインターフェースのアドレス、対向端末の識別情報、接続先、トンネルに通すアドレス範囲を理解する必要があります。項目が多くても、すべてが認証を担うわけではありません。識別情報を示す項目と、ネットワークパケットを正しい宛先に送るための項目を区別してください。

Private Keyは現在のクライアントの秘密鍵、Public Keyは対応する公開鍵を示します。PeerのPublic Keyはリモート側の対向端末を示します。クライアント自身の公開鍵をリモート側の公開鍵欄に入力すると、双方の識別関係が成立しません。設定にPreshared Keyが含まれている場合は追加の共有鍵であり、公開鍵と秘密鍵の組み合わせに代わるものではありません。実際の鍵を公開画像、記事、共有ログに載せないでください。問題について他の人に説明する際も、鍵の情報はあらかじめ削除してください。

EndpointとインターフェースのAddressは用途が異なる

Endpointはリモート側へのネットワーク接続先で、通常はアドレスとポートで構成されます。インターフェースのAddressはトンネル内部でローカル側に割り当てられるアドレスで、プレフィックス長を含む場合があります。リモートサーバーの公開アドレスではありません。インポートした設定は、サービス側から割り当てられた値を保持してください。家庭内LANと同じ形式に見えるように独自変更しないでください。アドレスの競合、プレフィックスの誤り、サーバーに受け入れられないローカルアドレスによって、ハンドシェイクは成功しても通信できないことがあります。

Allowed IPsは、対向端末とアドレスプレフィックスを関連付け、どの宛先をその対向端末に渡すかにも影響します。アクセスを許可するWebサイトの一覧でも、単なるメモでもありません。すべてのアドレス範囲を指定する場合と、特定のサブネットだけを指定する場合では意味が大きく異なります。さらに、Shadowrocketの上位ポリシーがリクエストをどのサーバーに渡すかも考慮してください。トンネル内でルーティングできる範囲と、アプリのルールによる振り分けは別々の制約です。一方で他方を置き換えることはできません。

ハンドシェイク後に通信経路を確認する

ハンドシェイクが示すのは、双方が必要な鍵交換を完了したことです。アドレスの割り当て、転送、DNSが正しいことまでは確認できません。ハンドシェイクが確認できてもWebページが開かない場合は、トンネルアドレス、Allowed IPs、リモート側の転送、名前解決の設定を確認してください。ハンドシェイク自体ができない場合は、Endpoint、公開鍵の組み合わせ、UDPの到達性を優先して調べます。問題を2つに分けることで、ルーティングの誤りに対して鍵を何度も作り直し、サーバーとクライアントの設定が食い違うリスクを避けられます。

MTUはトンネル内のパケットサイズに影響します。トンネルのオーバーヘッド分を差し引いたサイズでなければ、基盤ネットワークを通過できません。設定値が大きすぎると、小さなリクエストは通るのに大きな応答が止まることがあります。再現できる症状をもとに調整し、一度に変更する項目は1つにしてください。適当な小さい数値を汎用的な最適値として使わないでください。特定のネットワーク環境だけで問題が起きる場合は、基盤となる通信経路の違いも考慮します。WireGuardの設定全体が使えなくなったと決めつけないでください。

キープアライブ、ローミング、電池消費の注意点

WireGuardはUDPを使用し、ネットワークアドレスが変わると対向端末の接続先を更新する仕組みがあります。ただし、実際の復帰はモバイルOSのスケジュール管理、NATの状態、ネットワーク環境にも左右されます。ネットワークアドレスの割り当てを維持するため、設定によってはPersistent Keepaliveが使われます。間隔を短くすればよいとは限りません。頻繁な送信は待機中の無線通信を増やすことがあり、間隔が長すぎると特定のネットワークで必要な状態を維持できないことがあります。手元の設定で指定された条件を保ち、明確な問題がある場合に調整してください。

iOSでは、長時間の継続通信と長時間の待機は異なる負荷です。前者ではスループット、発熱、パケットロスからの復帰を、後者ではバックグラウンド通信やキープアライブによる起動がないかを確認してください。ネットワーク層のトンネルがシンプルだからといって、あらゆる用途で省電力になるとは限りません。設定項目の確認にはWireGuardの設定項目を詳しく解説も参考になります。手元にプロキシのパスワードしかなく、鍵やアドレスの情報がない場合、そこから利用可能なWireGuard設定を独自に作ることはできません。

07 / Hysteria2：UDP経路と輻輳制御

QUICを基盤とする通信方式

Hysteria2はQUICを基盤とするプロキシ通信方式です。QUICはUDP上で動作し、TLSと組み合わせてセキュリティハンドシェイクを行います。高遅延やパケットロスなどがある環境での通信を考慮した設計ですが、すべてのネットワークで速くなるとは限りません。利用するネットワークでUDPが制限されていたり、UDP経路の品質が大きく低下していたりすると、設計上の利点があっても基盤ネットワークの到達性を補うことはできません。接続を確立できない場合もあります。

QUICを理解する際は、通信方式内の多重化されたストリームと、基盤となる回線のリソースを区別してください。独立したストリームによって、ストリーム間で発生する一部のブロッキングを減らせる場合がありますが、各ストリームは無線回線、経路容量、輻輳状態を共有します。パケットロスが起きれば、該当ストリームのデータを復旧する必要があります。「多重化」されているから帯域が自動的に2倍になるわけではなく、すべてのリクエストが互いに影響しなくなるわけでもありません。サーバーの処理、接続先からの応答、ネットワークの待ち行列も最終的な使い勝手を左右します。

認証項目と証明書の設定はそれぞれ保持する

Hysteria2の設定では、サーバー側のアドレス、ポート、認証情報を一致させる必要があります。有効なセキュリティ層の名前と証明書の検証方法も、手元の設定に従ってください。Passwordなどの認証項目はTLS証明書の代わりにはなりません。サーバーがドメイン名を使う場合も、Server Nameが設定どおりか確認してください。IPアドレスで接続し、証明書がドメイン名に対して発行されている場合は、名前の項目が特に重要です。すべての項目を同じ値にそろえるために消去しないでください。

環境によっては、難読化に関する追加項目が指定される場合もあります。これらは双方で合意された設定の一部です。サーバー側から明確に要求されている場合に限って有効にし、種類と認証情報を一致させてください。無作為に難読化用のパスワードを入力しても互換性は高まりません。認証段階に進む前に、パケットを正しく解釈できなくなるおそれがあります。サブスクリプションからインポートした後は、追加項目がすべて反映されているか確認してから、ネットワーク品質を調べてください。

帯域幅の設定は速度を何倍にもするものではない

上り・下りの帯域幅を指定する項目は、通信方式の設定に使う情報であり、回線容量を入力した数値まで増やすものではありません。実際の能力を大幅に上回る数値を入力すると、送信動作と回線の処理能力が合わず、待ち行列やパケットロスが生じたり、同じネットワーク上の別のタスクに影響したりすることがあります。低すぎる値は利用可能なスループットを制限する場合があります。単位にも注意し、1秒あたりのバイト数とビット数を取り違えて大きな誤差を生まないようにしてください。

クライアントで指定した帯域幅の情報がサーバー側でどのように使われるかは、設定によって異なります。具体的な輻輳制御の動作は、双方が対応している設定とあわせて確認してください。まずは手元の設定とサーバー側の説明を基準にし、ほかの端末で使われているという「最適値」をそのまま流用しないことが重要です。調整する場合は、安定したネットワークで基準値を測り、ダウンロード、アップロード、Web閲覧を個別に確認します。一度のピーク値だけを追いかけ、ほかのリクエストの待ち時間を無視しないでください。

モバイル通信に適しているかを判断する方法

モバイル通信で利用できる帯域と遅延は、電波状態や基地局の混雑状況によって変化します。ある時点で測定した帯域が、その後の利用時間を通じて適切とは限りません。エレベーターや乗り物の中、電波の弱い場所で何度もテストすると、電波状況の変化がプロトコルの比較に混ざります。まずは位置を固定し、電波が安定した状態で基本接続を確認してください。その後、実際に移動しながら接続がどう復帰するかを観察し、固定設定の誤りとネットワークの変動による一時的な失敗を区別します。

高スループット、暗号化処理、再送、無線通信は、いずれも消費電力を増やすことがあります。経路によってはHysteria2でタスクの完了時間が短くなる一方、別の経路では継続的なパケットロスによって処理負荷が増すこともあります。そのため、省電力または電池を消耗すると一律に評価することはできません。互換性のある接続先を複数利用できる場合は、同じタスクにかかった時間、安定性、実際の電池残量の変化を記録してください。接続先が1つだけなら、まず設定項目を正しく照合します。プロトコル名だけを理由に設定全体を切り替える必要はありません。

08 / 用途に合わせて選び、ルールと実測で確認する

手元の条件を確認してから、設計上の違いを比べる

最優先の判断基準は、サーバー側で実際に提供されている接続先です。手元のサブスクリプションに1種類のプロトコルしか含まれていない場合は、インポートが完全か、認証が正しいか、接続先に到達できるかをまず確認してください。プロトコルのランキングを見て、設定の種類を独自に変更する必要はありません。複数の利用可能な接続先を実際に持っている場合に限り、用途に応じて比較します。Webページへの頻繁なアクセスでは名前解決と最初の応答、継続的なダウンロードではスループットと安定性、リアルタイムアプリではUDP対応と遅延の変動、個人用の内部ネットワークへのアクセスでは正確なアドレスルーティングを確認してください。

TLSと通信方式を明示的に設定する接続先では、設定情報が完全で、保守時にも確認しやすいかを優先してください。ネットワーク層のトンネルでは、鍵、アドレス、ルーティング範囲がすべて提供されている必要があります。UDPを基盤とする通信方式では、現在のネットワークがUDPを安定して通せるかを確認してください。項目が少ないか新しい名称かだけでプロトコルを選ばないでください。手元のサービス設定を正確に反映でき、問題時に階層ごとに調べられることも、実用上の重要な要素です。

Global Routingを変えてもプロトコルの種類は変わらない

Global RoutingのConfig、Proxy、Directは、それぞれ画面上の項目です。Configでは現在の設定にあるルールに基づいてポリシーを決定し、Proxyでは対象の通信をプロキシポリシーに渡し、Directでは直接接続します。これらの切り替えで変わるのはルーティングの判断であり、サーバーのプロトコルではありません。リクエストが選択したサーバーを通っていないなら、そのリクエストでプロトコルの速度を比較しても意味はありません。まず通信経路を確認してください。

次の例はルールの順序を説明するものです。Shadowrocketの設定内にある該当ルール欄に配置し、プロキシポリシーが有効なサーバーを参照していることを確認してください。完全な設定ではなく、サーバーの認証情報も含まれていません。DOMAIN-SUFFIXは指定したドメインのサフィックスを先に照合し、GEOIPは地域別のIPデータベース条件に一致する接続先を処理し、FINALは残りのリクエストに適用するポリシーを指定します。地域ルールが必要かどうかは、ご自身の利用目的に応じて判断してください。そのまま機械的にコピーしないでください。

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

ルールは通常、記述順に照合されるため、より具体的な条件を適切な位置に置いてください。FINALは残りの接続を処理します。IPルールとドメインルールは対象とする入力が異なり、DNSの名前解決結果が判定に影響する場合もあります。接続先がDIRECTになったからといって、選択中のプロキシプロトコルが使えないとは限りません。PROXYに振り分けられた接続先で失敗しても、ルールの構文エラーとは断定できません。設定方法は設定ガイド、初回接続の手順はクイックスタートガイドをご覧ください。

再現可能な検証記録を作る

検証するときは、まずHomeで対象のサーバーを選び、Global Routingの設定を確認します。接続を有効にしたらConnectivity Testを実行し、実際の接続先にもアクセスしてください。テストツールの結果で確認できるのは、実行した種類のテストだけです。すべてのプロトコル機能、接続先、ルールによる経路を検証したことにはなりません。ネットワークの種類、選択した項目、接続先、失敗した段階を記録します。サブスクリプションのURL、パスワード、鍵は公開しないでください。ご利用のサービス提供元に問い合わせる場合も、機密情報を削除してから伝えてください。

まったく接続できない場合は、アドレスの名前解決、ポートと通信方式、TLS、プロトコル認証の順に確認してください。接続はできても一部の接続先で失敗する場合は、DNS、ルールの適用、UDP、接続先のサービスを確認します。性能を測る場合は、変更する条件を一度に1つにしてください。サーバー、通信方式、ルーティングを同時に変えないでください。電池消費を比較する際は、測定時間と画面の使用状況もそろえます。デバイスの温度やバックグラウンドの動作が落ち着いてから測定を始め、負荷の異なる2回の結果を単純に比較しないでください。

最後に、プロトコルの選択とクライアントの入手方法は分けて考えてください。iPhone / iPad版はApp Storeで2.99米ドルの買い切り、Mac（Appleシリコン・Intel）、Windows、Android、Linux版は無料です。入手方法やインストールの問題は、ダウンロードガイドとよくある質問をご確認ください。このサイトはShadowrocketの公式サイト・公式マニュアルです。サーバーやサブスクリプションの提供、販売、推奨は行っていません。設定項目の意味を確認する場合は英語の画面用語一覧、接続手順を確認する場合は初回接続の手順を読み、該当するプロトコルの技術的な条件をこのページで確認してください。