Shadowrocketのプロトコル解説：設定項目・速度・バッテリー消費の比較

01 / CONNECTION LAYERS

接続の階層：プロトコル・トランスポート・ルールの役割

まず4つの異なる要素を区別する

Shadowrocketでプロトコルの種類を選ぶことは、まず「クライアントがサーバーとどの形式で通信するか」を指定することです。Shadowsocks、VMess、VLESS、Trojanなどは、認証やデータのカプセル化に関する動作を定めます。TCP、UDP、WebSocketはデータの運び方に関わります。TLSは認証済みの暗号化通信路を確立し、ルールはどのリクエストをその通信路に送るかを決めます。これらの階層は組み合わせて使えますが、相互に置き換えることはできません。種類の名前だけ変更しても、接続先のサーバーが同じサービスに自動で切り替わるわけではありません。

たとえば、既存の設定にサーバーアドレス、ポート、UUID、WebSocketパス、TLSサーバー名が含まれていても、5種類の独立したプロトコルという意味ではありません。これは複数の階層にまたがる1つの接続設定です。クライアントはサーバーを見つけ、指定された方法で通信を確立し、必要な安全なハンドシェイクと認証を行ってから、宛先へのリクエストを転送します。どこか1つでも設定が一致しないと、同じ「接続失敗」として現れることがあります。トラブルシューティングでは、エラーメッセージを見て種類をむやみに切り替えるのではなく、まず設定の構成を記録してください。

速度とバッテリー消費はプロトコル名だけでは判断できない

Webページを1つ開く処理には、ドメイン名の解決、接続の確立、ハンドシェイク、データ転送、アプリ側の処理が含まれます。短いリクエストでは往復時間やハンドシェイクの影響が大きく、長時間のダウンロードでは利用可能な帯域幅、パケットロス、サーバー負荷の影響が大きくなります。ある設定でダウンロード速度が高くても、小さなページを多数開くときも速いとは限りません。1回の測定値が低かったからといって、そのプロトコルが現在のデバイスに不向きだとも限りません。同じ接続先、近い時間帯、同じネットワークで繰り返し比較し、最良の結果だけでなく失敗回数も記録しましょう。

iPhoneとiPadでは、バッテリー消費が無線ネットワークの状態にも大きく左右されます。電波が弱い場所での再送、接続が切れた後の再接続の繰り返し、バックグラウンドタスクによる頻繁な復帰は、暗号化方式そのものより顕著な影響を及ぼすことがあります。Wi-Fiとモバイル通信を切り替えた後は、既存の接続を復旧する必要が生じる場合があります。トランスポート方式によって復旧方法は異なりますが、一定の省電力率を示すことはできません。まず接続を安定させ、同じ使用時間でのバッテリー消費と発熱を観察してください。常に最も省電力なプロトコルを探すのではなく、利用状況に合わせて判断しましょう。

階層	確認する項目	代わりにならないもの
プロトコルと認証	種類、パスワードまたはUUID、暗号化方式	正しいトランスポート設定
トランスポート	TCP / UDP、WebSocketのパスとHost	TLSによる本人確認
TLS	サーバー名、証明書チェーン、ネゴシエーション要件	クライアント認証情報
ルーティング	Global Routing、ルールの順序、デフォルトサーバー	サーバーのハンドシェイクエラーの修復

利用できる条件をもとに選ぶ

実際の選択手順は、まず既存のサーバーが対応する種類を確認し、次に現在のネットワークで該当するトランスポートが使えるか確かめ、最後に使用感を比較します。サーバーが確認済みの設定を1種類だけ提供している場合は、手動で別の種類に変更するより、設定をそのままインポートする方が確実です。複数の設定がある場合は、元の項目を残したうえで区別しやすい名前を付け、テストごとに変更する条件を1つに絞ります。サーバーアドレスや認証情報が異なる設定同士を、プロトコルだけの厳密な比較実験として扱うことはできません。

以降の解説を読む際は、「プロトコルで実現できること」と「現在のサーバーで有効になっていること」も区別してください。プロトコル仕様上のオプション機能は、クライアントとサーバーの両方が対応し、設定されている場合にのみ有効になります。サブスクリプションで既定値が省略されていたり、共有用の形式で短縮表記が使われたりすることもあります。見慣れない項目があれば、設定元の説明を確認してください。不明な項目を自己判断で削除して試したり、認証情報を含む設定全体を公開ページに掲載したりしないでください。操作手順を確認する場合は使い方ガイドに戻り、エラーの分類を確認する場合はよくある質問をご覧ください。

02 / SHADOWSOCKS

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

シンプルなプロキシのカプセル化を重視した設計

Shadowsocksは、クライアントとサーバーの間でプロキシ通信を比較的シンプルな方法で転送することを目指して設計されています。一般的なネットワークトンネルのように、まずデバイスに仮想アドレスやルーティング関係を設定するのではなく、宛先への接続を中心に通信をカプセル化します。そのため、設定の中心となる項目はサーバー、ポート、暗号化方式、パスワードであり、トンネル用のネットワーク範囲ではないことが多くあります。使用感はサーバーの実装、ネットワーク品質、実際に使う方式によって変わります。設定項目が少ないからといって、速度が速いとは限りません。

比較的新しい設定では、認証付き暗号化方式がよく使われます。受信側はデータを復号できるだけでなく、改ざんや鍵の不一致も検出できます。暗号化方式によって鍵の形式、データの構成、双方の実装要件は異なり、名前が似ていても互換性があるとは限りません。サーバーが指定する方式と同じものをクライアントで選んでください。名前が新しそうだからという理由で既存の設定を置き換えないでください。変更する場合は、元のパスワードが新しい方式の形式要件を満たすかも改めて確認する必要があります。

4つの主要項目を確認する順番

まずサーバーアドレスに余分な空白、プロトコルのプレフィックス、パスが含まれていないか確認します。アドレス欄には通常、ドメイン名またはアドレスだけを入力し、ポートは別に指定します。共有用の設定全体をアドレス欄に貼り付けても、インポートの代わりにはなりません。次に、そのサービスに割り当てられたポートか確認してください。同じサーバーでも、プロトコルごとに異なるポートを使う場合があります。最後に暗号化方式とパスワードを照合します。パスワードの大文字・小文字や末尾の文字を維持し、特殊に見える記号もコピー時に削除しないでください。

一部の新しい方式では鍵の形式に特別な要件があり、通常の覚えやすいパスワードとエンコード済みの鍵を同じ入力として扱うことはできません。サービス情報に複数の鍵や追加の認証情報が含まれている場合は、提供元の説明に従ってインポートしてください。既存のサブスクリプションが種類を正しく認識しているなら、項目間の対応関係を維持することを優先します。手動で設定する場合は、まず必須項目だけを記録し、接続を確認してからオプションを調べましょう。確認できていない設定を一度に複数追加するのは避けてください。

UDPの利用条件も個別に確認してください。アプリがUDPリクエストを送信しても、サーバーが処理できるか、現在のネットワーク経路がUDPを許可しているか、クライアントが転送できるか、それぞれ対応が必要です。Webページが開けても、一部のTCPリクエストが成功したことしか確認できず、音声通話、リアルタイム通信などのUDPを使う場面が正常とは限りません。反対に、リアルタイムアプリに問題があっても、パスワードの誤りとすぐに決めつけることはできません。認証エラーと特定のトラフィックのエラーを区別すれば、確認範囲を絞れます。

iOSで実際の使用感を確認する方法

iOSで継続的にデータを転送するときの暗号化処理の負荷は、プロセッサーの性能、方式の実装、通信量によって変わります。普段のページ閲覧では、接続確立や無線通信による消費電力の方が目立つことがあります。大容量ファイルの転送では、暗号化処理と継続的な無線通信の影響が表れやすくなります。テストでは、短いページの閲覧、継続的な転送、画面ロック後の復旧を分けて記録し、ダウンロードを1回試すだけで判断しないでください。デバイスが発熱した場合は、バックアップ、メディア処理、アプリのアップデートも並行していないか確認し、すべての負荷をプロキシプロトコルのせいにしないようにしましょう。

接続できない場合は、まず元の設定をすべて復元し、システム時刻とネットワークが正常か確認したうえで、別のネットワークでも同じ設定を試してください。すべてのリクエストが失敗する場合は、アドレス、ポート、方式、パスワードを重点的に確認します。一部の宛先だけ失敗する場合は、ルール、名前解決、宛先自体を調べてください。暗号化方式を何度も変えて試すのは避けましょう。テスト失敗後に作成した一時的なコピーを、正式なサブスクリプション一覧に混在させないでください。手動で追加した項目にはわかりやすいメモを付けておくと、後でデフォルトサーバーを誤って選ぶのを防げます。

Shadowsocksを選ぶ前提は、利用者が対応する設定をサーバーから入手しており、実際の用途に合うことをテストで確認できていることです。設定項目がシンプルなので個別に照合しやすい一方、項目を省略してよいわけではありません。プラグインなど追加のカプセル化が必要な設定で、現在の画面に該当機能がない場合は、対応しているかを先に確認してください。必要な設定を重要でない補足情報として扱ってはいけません。プロトコル名だけを覚えるのではなく、再現可能な有効設定を保存しておきましょう。

03 / VMESS & VLESS

VMessとVLESS：認証・暗号化・トランスポートを分けて理解する

種類を切り替えるだけでは互換性はない

VMessとVLESSは、複数のトランスポート設定を含む構成でよく使われますが、同じプロトコルの別名ではありません。VMessはプロトコル層に認証とデータ保護に関する仕組みを備えています。VLESSはよりシンプルなプロトコル層を採用し、別途設定するセキュアなトランスポートと組み合わせて使われることがよくあります。どちらもUUID形式の識別子を使うことが多いため、種類を置き換えるだけで変換できると誤解されがちです。しかし、UUIDが同じに見えても、サーバーが該当するプロトコルを実行し、同じトランスポートの組み合わせを受け入れる必要があります。

UUIDは構造化された識別子であり、サーバーアドレスでもWebサイト証明書の検証名でもありません。確認時は、値が完全か、空白が混入していないか、現在のサーバーに対応するものかを確かめてください。複数の設定からUUID、ポート、パスを取り出して組み合わせないでください。VMessの認証には時刻条件も関係するため、デバイスの時計が大きくずれていると接続に失敗することがあります。システム時刻は自動設定にしてください。時刻の問題は解消できますが、誤った識別子やトランスポート設定を補うことはできません。

トランスポート設定は組み合わせで確認する

よくある設定では、プロトコルとは別にTCPやWebSocketなどのトランスポートを指定します。WebSocketを使う場合、パスはサーバー側の受信先と一致している必要があり、スラッシュ、大文字・小文字、付加パラメーターが結果に影響することがあります。Hostは通常、アプリケーション層のリクエストやフロントエンドのルーティングに関わります。一方、TLSのサーバー名はセキュアなハンドシェイクと本人確認に使われます。両者が同じ場合もあれば、サーバーの構成によって異なる場合もあります。サーバーアドレス、Host、TLS名はそれぞれ役割が異なるため、画面上の見た目を整えるために同じ値を指定しないでください。

1つのドメインの背後に複数の転送段階がある場合、クライアントがフロントエンドのポートに接続できても、リクエストが正しいプロトコルのサービスに届いたとは限りません。パスが違うと通常のWebページが返り、Hostが違うと別のサイトに振り分けられ、TLS名が違うとさらに早い段階で拒否されることがあります。ポートに到達できた時点で確認できるのは最初の段階までです。サーバーが「オンライン」だから設定に問題はないと判断せず、アドレスとポート、TLS、トランスポートパス、プロトコル認証の順に確認してください。

VLESS自体を、あらゆる場合にペイロードを暗号化する仕組みの代替として扱ってはいけません。クライアントとサーバー間の通信内容を保護するには、実際の設定で使われるセキュリティ層とその検証方法を確認する必要があります。特別なフロー制御やハンドシェイク設定を含む場合もありますが、これらは汎用の高速化スイッチではありません。両端で同じ組み合わせが指定されている場合にのみ有効です。現在の画面に表示されない項目がある場合は、その組み合わせが対応しているかを先に確かめてください。不明な値をメモ欄や無関係な項目に入力して代用することはできません。

短い接続でのオーバーヘッドと多重化の限界

iPhoneで初回接続したときの体感速度には、ネットワークの往復時間、TLSハンドシェイク、追加のトランスポート処理が同時に影響します。VMessとVLESSを単純に速い順に並べる根拠はありません。サーバーまでの距離、トランスポート方式、接続の多重化方法が違えば結果も変わります。多重化によって、場合によっては接続を何度も確立するコストを減らせますが、複数のリクエストが1つの基盤チャネルを共有することにもなります。混雑時に共有した方が快適とは限りません。すべてのオプションを常に有効にするのではなく、同じ負荷条件でテストしてください。

バッテリー消費を比べるときも条件をそろえる必要があります。ネットワーク切り替え後に認証失敗が続く設定では、ハンドシェイクの繰り返しによってバックグラウンド処理が増えることがあります。軽量そうな別のプロトコルに変えるより、パス、時刻、認証情報を修正する方が直接的です。画面ロック後にアプリを再び開いたとき、最初のリクエストだけが遅いなら、通常の接続再確立と繰り返しの再試行を区別してください。復旧にかかった時間、手動での切り替えが必要か、エラーが再発するかを記録しましょう。1度の現象をプロトコル固有の性質と決めつける必要はありません。

完全なVMess設定がすでにあり、安定して使えているなら、別の種類の方がシンプルだからという理由だけで移行する必要はありません。VLESS設定がある場合は、セキュアなトランスポート、認証、オプションのフロー制御がどのように対応しているかを確認してください。複数の設定をテストする場合は、トランスポートと用途をメモに記し、サーバーから提供されたプロトコル項目を書き換えないでください。デフォルト項目の選び方やConnectivity Testの実行方法は、初回接続と動作確認のガイドをご覧ください。

04 / TROJAN & TLS

Trojan：TLSによる本人確認とプロトコルのパスワードを分けて確認

標準的なTLS通信路を使ってプロキシリクエストを転送

Trojanの設計上の特徴は、TLSで暗号化とサーバー認証を行い、その通信路上でプロトコル認証とリクエスト転送を行うことです。そのため、パスワード欄だけでなく、証明書、サーバー名、接続先の関係を理解する必要があります。TLSは広く利用されているセキュアなトランスポートですが、TLSを採用しているからといって、任意のTLSサーバーがTrojanリクエストを受け付けるわけではありません。クライアントは正しいポートに接続し、該当プロトコルに対応したサービスへ正しい認証情報を送る必要があります。

サーバーアドレスは接続先を決め、ポートは接続するサービスを指定します。TLSサーバー名は、ハンドシェイク時の名前通知と証明書の本人確認に使われます。証明書には検証対象の名前が含まれ、有効期限内である必要があります。また、証明書チェーンがシステムから信頼されなければなりません。アドレスを直接指定して接続し、証明書がドメイン名に対して発行されている場合は、元の設定に従って検証名を正しく指定してください。同じマシンに名前解決できるからといって、証明書が任意の名前を検証できるわけではありません。ネットワーク上の接続先が同じでも、本人確認が同じとは限りません。

ハンドシェイクの失敗はパスワードの誤りとは限らない

通常、認証はセキュアな通信路が確立した後に行われます。証明書の期限切れ、デバイス時刻の誤り、名前の不一致、証明書チェーンの不足などがあると、パスワードの確認段階に進む前に接続が失敗することがあります。その場合、パスワードを何度入力し直してもTLSの問題は解決しません。まずシステムの日付、ドメイン名の綴り、証明書に関するメッセージを確認し、既存サーバーの管理者に証明書の設定を照会してください。TLS接続に成功した後でプロトコル認証が拒否された場合は、パスワード、サービスの種類、サーバー側のアクセス権を重点的に確認します。

パスワードは大文字・小文字、特殊文字、先頭と末尾の位置も含めてそのままコピーしてください。サブスクリプションの更新後にパスワードが変わった場合、古い手動設定では接続できないことがあります。似た名前の過去の項目ではなく、サブスクリプションに含まれる新しい項目が選択されているか確認しましょう。パスワードを保存するときは、日本語の注釈、引用符、改行をパスワードの一部として含めないでください。トラブルの記録には「パスワードを設定元と照合済み」と記載できますが、実際のパスワードを公開スクリーンショットやログに掲載しないでください。

設定によっては、ALPNなどの追加TLSネゴシエーション要件を指定することがあります。ALPNはアプリケーション層のプロトコルをネゴシエートする仕組みで、自由に選べる速度設定ではありません。入力が必要か、どの値を受け付けるかはサーバー側の要件に従ってください。入力欄を埋めるために、別の設定から値をコピーしてはいけません。サブスクリプションに関連項目が含まれている場合はその組み合わせを維持し、問題が起きたら元の説明と1項目ずつ照合します。セキュリティ設定をすべて一度に消してテストするのは避けてください。

iOSではハンドシェイクと接続復旧を確認

TLSの初回接続ではハンドシェイク情報を交換するため、ネットワークの往復時間が所要時間に影響します。接続が確立した後の実効速度は、トランスポート経路、混雑、サーバー負荷にも左右されます。ページを初めて開くまでの時間を、長時間利用時の速度と同じものとして扱わないでください。条件がそろえばセッション再開によって後続のハンドシェイク時間を短縮できることがありますが、実際に行われるかは実装とサーバーの状態によります。毎回再利用されるとは限りません。初回アクセスとその直後の再アクセスを分けて確認し、キャッシュの効果をプロトコルの違いと誤認しないようにしましょう。

Wi-Fiからモバイル通信に切り替えると、既存の基盤接続を再確立することがあります。少し待つ必要があっても、すぐに認証情報の誤りとは限りません。毎回の復旧に長時間かかる場合は、現在のネットワークからサーバーのポートに到達できるか、名前解決が正しいかを確認してください。バッテリー消費では、TLSの頻繁な再確立、連続する再試行、電波が弱い場所での再送が、安定した長時間接続よりも大きな要因になることがあります。まず誤った再試行をなくしてから通常利用時の消費を比較し、特定のハンドシェイク方式に一律の消費電力を当てはめないでください。

Trojanを選ぶのは、利用者がこの種類の設定をサーバーから入手しており、TLS名、証明書、認証情報がそろっている場合です。設定確認は、接続先の確認、安全なハンドシェイクの検証、パスワードとリクエストの確認という順に進められます。接続テストに成功してもWebページに問題がある場合は、ドメイン名の解決やルールも調べてください。TLSを使用しているからといって、後続の階層を省略することはできません。モードの選び方はGlobal Routingの3つのモードの解説もご覧ください。

05 / HTTP & SOCKS5

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

汎用プロキシ2種類の設計

HTTPプロキシはアプリケーション層でのプロキシ利用を目的とし、HTTPリクエストを処理するほか、CONNECTメソッドで他の接続先へのバイトストリームを確立することもあります。SOCKS5はより汎用的な接続ネゴシエーションを提供し、クライアントが接続先をプロキシに伝え、プロキシが後続の通信を確立します。どちらもプロキシインターフェースですが、インターフェース自体はクライアントからプロキシまでの通信が暗号化されているか、あらゆるリクエストに対応しているかを示すものではありません。選ぶ際は、通信の保護方法、認証方式、サーバーが対応する機能も確認してください。

よくある誤解の1つは、接続先のWebサイトがHTTPSなら、プロキシまでのすべての通信も同じように保護されると思い込むことです。接続先WebサイトのTLSは通信内容を保護できますが、通常のHTTPプロキシで行うCONNECTのネゴシエーションやプロキシ認証が、接続先のHTTPSによって自動的に同じ保護を受けるわけではありません。TLSでプロキシに接続する場合は、プロキシの証明書も別途検証する必要があります。「接続先WebサイトがHTTPSを使用していること」と「クライアントが暗号化してプロキシに接続していること」は別の条件であり、相互に置き換えられません。

アドレス・認証情報・名前解決の場所

HTTPまたはSOCKS5の設定を追加する際は、まずサーバーの種類を確認し、次にアドレス、ポート、ユーザー名、パスワードを照合します。サーバーによってはユーザー名なしで利用できますが、認証を必須とする場合もあります。項目を空欄にできるかどうかは元の設定に従ってください。ユーザー名とパスワードは別の項目です。区切り文字を含む文字列全体を片方の項目に入力してはいけません。接続元ネットワークを制限する構成もあります。その場合、認証情報が正しくてもモバイル通信に切り替えると拒否されることがあるため、既存サーバーの管理者にアクセス権を確認してください。

名前解決をどこで行うかによっても、接続結果は変わります。クライアントが先にドメイン名をアドレスに変換してからプロキシに接続する場合もあれば、プロトコルを通じてプロキシ側にドメイン名を解決させる場合もあります。実際の動作は、クライアントの設定、プロトコルの機能、サーバーの実装によって異なります。アクセス元に応じてアドレスを割り当てるサービスでは、どちらの方法でも異なるアドレスが返ることがあります。「ドメイン名では失敗するが、アドレスならつながりそう」という場合は、すぐにプロキシの種類を変えるのではなく、名前解決の経路と結果を確認してください。アドレスを直接指定してHTTPSをテストすると証明書名の問題が生じることがあるため、完全に同等のテストにはなりません。

SOCKS5の仕様にはUDPアソシエーションが定義されていますが、すべてのサーバーで利用できるわけではなく、種類の名前だけで現在の設定が使えると判断することもできません。サーバーがTCPのみを処理する場合や、関連するファイアウォールがUDPの戻り通信を遮断する場合があります。HTTP CONNECTは一般にTCPトンネルの確立に使われ、SOCKS5のUDPアソシエーションと同じ機能を持つとは限りません。リアルタイムの音声・映像通信が目的なら、必要なトラフィックを個別にテストしてください。Webページが1つ開いたことだけで、すべての要件を満たすとは判断できません。

確認項目	HTTP	SOCKS5
代表的なインターフェース	HTTPリクエストとCONNECT	接続ネゴシエーションと宛先への転送
暗号化の条件	プロキシへのTLS接続かどうかを個別に確認	プロトコル自体は通信経路の暗号化を保証しない
UDPの条件	通常のCONNECTで対応すると決めつけない	両端とネットワークがUDPアソシエーションに対応している必要がある

用途の選び方とiOSでの使用感

勤務先や実験環境のネットワーク、または自分で管理するサーバーが汎用プロキシを提供している場合、HTTPやSOCKS5を既存サービスへの接続に利用できます。選択の基準は、名称の優劣ではなくインターフェースが適合するかどうかです。追加の暗号化がないからといって、あらゆるネットワークで機密性の高い認証情報を送ってよいわけではありません。通信経路の範囲と保護方法を先に確認してください。平文で送られる認証情報を通常のトラブル情報として公開したり、アクセス権が不明な状態で認証情報を繰り返し送信したりしないでください。

iOSでの速度も、プロキシまでの距離、接続方式、接続先からの応答に左右されます。プロトコルの処理が少なくても、経路の品質が悪ければ利点が相殺されることがあり、省電力になるとも限りません。アプリごとに挙動が違う場合は、接続先、トランスポート、名前解決の経路が異なるかを先に確認してください。TCPテストは成功してもリアルタイム機能が失敗する場合は、UDPの条件を優先的に調べます。認証エラーの場合に限ってユーザー名とパスワードを重点的に確認し、無関係な設定を何度も変更しないようにしましょう。

汎用プロキシごとに、次の3点を記録してください。プロキシまでの通信経路が保護されているか、どのトランスポートに対応するか、ドメイン名をどちら側で解決するかです。3点を明確にしてから、自分の用途に合うか判断できます。サーバーのアドレスとポートしかわからず、他の情報が不足している場合は、設定元に確認してください。セキュリティ条件を推測で補わないでください。インターフェースが利用可能かどうかと、自分の用途に適しているかどうかを分けて考えることで、「接続できても期待どおりではない」という問題を減らせます。

06 / WIREGUARD

WireGuard：鍵・トンネルアドレス・ルーティング範囲をまとめて確認

個別のプロキシリクエストではなくネットワークトンネルとして考える

WireGuardは、暗号化されたネットワークトンネル向けに設計されており、ピアと公開鍵・秘密鍵、ルーティング範囲を使って通信を確立します。プロキシのように宛先を個別に指定する方式と比べると、データパケットを仮想ネットワーク経路に流す仕組みに近いものです。そのため、設定にはトンネル内アドレス、ピアの公開鍵、エンドポイント、許可するアドレス範囲が含まれることがよくあります。この違いを理解することが重要です。エンドポイントとのハンドシェイクができても、適切な通信経路が設定されているとは限りません。また、鍵が正しくても、サーバー側の転送設定や戻り経路の代わりにはなりません。

各ピアは自身の秘密鍵を持ち、相手の公開鍵を使って相手を識別します。クライアントの秘密鍵は自身の設定に保持し、サーバーの公開鍵はサーバー側の設定から取得してください。両者を入れ替えてはいけません。オプションの事前共有鍵は、既存の鍵の関係に共有情報を追加するものであり、秘密鍵の別名ではありません。サーバー側で設定されていなければ、クライアントに入力しても互換性は得られず、認証の不一致を招きます。インポート後は鍵同士の対応関係を維持し、複数の設定の鍵を任意に混ぜないでください。

エンドポイント・アドレス・AllowedIPsの役割の違い

エンドポイントは、外部ネットワーク上でピアに接続するための場所で、通常はドメイン名またはアドレスとポートで構成されます。トンネル内アドレスは、暗号化ネットワーク内で使うローカルの識別情報とアドレス指定であり、エンドポイントのパブリックアドレスを入力する場所ではありません。AllowedIPsは、ピアのアドレス範囲とルーティング先の選択の両方に関係します。ただし、実際にどの範囲に適用されるかは、アプリとの統合方法も踏まえて理解する必要があります。範囲を広げても他のリクエストに影響しない、単純な許可リストではありません。

ルーティング範囲を広げすぎると、本来トンネルを通す必要がない通信まで送られる可能性があります。狭すぎると、宛先のネットワーク範囲への経路がなくなることがあります。サーバー側でもクライアントへの応答経路を把握する必要があり、転送設定、内部ネットワーク、アクセス制御を一致させてください。ハンドシェイクは成功しているのに宛先へアクセスできない場合は、特定の内部ネットワークだけが失敗するのか、すべての通信が失敗するのかを切り分け、アドレス範囲と戻り経路を確認します。鍵を再生成するのは適切な解決方法ではありません。

DNSも個別に確認する必要があります。トンネル内のアドレスにアクセスできても、内部ドメイン名が必ず解決されるとは限りません。設定で内部DNSサーバーを指定している場合は、そのサーバーへの経路も必要です。逆にドメイン名が解決できても、得られたアドレスのサービス用ポートに到達できるとは限りません。トラブルシューティングでは、名前解決の結果と宛先への接続結果を分けて記録し、2つの段階をまとめて「ネットワークは正常」としないでください。IPv6を利用する場合は、アドレスファミリーとルートが適切に設定されているかも確認します。

UDP・キープアライブ・MTUの調整

WireGuardはUDPでトンネル通信を行うため、現在のネットワークがクライアントとエンドポイント間のデータ通信を許可している必要があります。一定の条件ではエンドポイントの変化に対応できますが、接続の復旧はネットワーク上のアドレス変換やサーバーへの到達性にも左右されます。環境によっては、NATマッピングを維持するために定期的なキープアライブが必要です。キープアライブは一定間隔でパケットを送るため、「安定させる」目的で間隔をむやみに短くしないでください。iPhoneの画面ロック中やモバイル通信時は、余分な復帰処理がバッテリー消費に影響することがあります。サーバー設定で必要な範囲にとどめてください。

MTUは、トンネル内で処理できるパケットの最大サイズを決めます。カプセル化には追加のデータが必要です。経路上で大きなパケットを正常に処理できないと、小さなリクエストは動くのに大きなデータの転送が止まることがあります。ただし、同じ症状が別の原因で起きることもあるため、ダウンロードが遅いからといってすぐにMTUを変更しないでください。元の値を維持し、パケットサイズと関連するか確認してから、サーバーと経路の条件に応じて調整を試します。複数のデバイスで同じ設定を使う場合も、1台で有効だった値をすべてのネットワークの標準とみなさないでください。

iOSでWireGuardを評価する際は、継続的なデータ転送、長時間の待機、ネットワーク切り替え後の復旧をそれぞれ観察してください。暗号化とハンドシェイクは効率的に設計されていますが、電波状態やキープアライブの方法がバッテリー消費の大きな要因になることがあります。定期的なバックグラウンド通信がないテストと、継続的なデータ転送のテストを直接比較することはできません。既存の内部ネットワークへのアクセスが目的なら、まずアドレス範囲と名前解決を確認してください。一般的なリクエストの転送が目的の場合は、現在のShadowrocketのルール設定とどのように連携するかも理解する必要があります。

WireGuardを選ぶ基準は、利用者が明確なトンネル設定とアクセス先を持っているかどうかです。1回の通信速度だけで選ぶものではありません。トラブル記録には、エンドポイントに到達できたか、ハンドシェイクが完了したか、どのアドレス範囲で失敗したかを記載します。秘密鍵を公開資料に含めてはいけません。設定を別の端末へ移す場合は、同じIDの同時使用がサーバーで許可されているか確認してください。2台のデバイスで同じ設定を同時に使うと、原因を再現しにくい接続の変化が生じることがあります。

07 / HYSTERIA2

Hysteria2：速度を比較する前にUDP経路を確認

QUICと不安定なネットワークを想定した設計

Hysteria2はQUICをベースにしたトランスポートを使用します。QUICはUDP上で動作し、現代的なセキュアハンドシェイクを組み合わせます。一定のパケットロスや遅延、帯域幅の条件下で転送効率を維持しながら、プロキシリクエストを運ぶことを重視した設計です。ただし、すべてのネットワークで速くなるわけではありません。UDPに到達できるか、経路でUDPの速度が制限されていないか、サーバー負荷や輻輳制御の方式などによって実際の結果は変わります。プロトコルを比較する前に、まずネットワークが基本的な通信条件を満たしているか確認してください。

QUICは1つの接続内に複数のストリームを設け、トランスポート層のヘッドオブラインブロッキングの影響を一部軽減できます。ただし、すべてのストリームは実際のネットワーク経路と輻輳時の帯域を共有します。無線ネットワークで大きなパケットロスが発生すると、信頼性のあるトランスポートではいずれも失われたデータを復旧する必要があります。プロトコルが利用可能な帯域を新たに生み出すことはできません。継続的な転送が快適でも、短いリクエストの初回応答がすべて速くなるとは限りません。「特定の条件で改善する可能性があること」と「あらゆる条件で優れていること」を区別し、プロトコル名だけで結論を出さないでください。

認証・TLS・オプションの難読化を分けて確認

設定時は、サーバーアドレスとポートで接続先を指定し、認証情報で利用権限を確認します。TLSサーバー名と証明書は接続先の本人確認に使います。元の設定で難読化の種類とパスワードも指定されている場合は、両端で一致させる必要があります。難読化用のパスワードは認証パスワードの別名ではなく、証明書名の欄に入力するものでもありません。必須情報が不足している場合は、既存のサブスクリプションまたはサーバーの説明に戻って確認してください。他のプロトコルの設定方法を参考に、推測で項目を組み合わせないでください。

証明書の検証原則は他のTLS設定と同じです。名前が一致し、証明書が有効で、デバイスの時刻が正確である必要があります。UDPに到達できても、安全なハンドシェイクや認証の成功は確認できません。ネットワーク切り替え後に接続が復旧する場合は、現在の経路で同じポートのデータを送受信できるか確認してください。どのネットワークでも失敗する場合は、サーバーの状態と設定項目を調べます。QUICを使用しているからといって証明書の確認を省略したり、ハンドシェイクのエラーを単なる遅延として扱ったりしないでください。

構成によっては、アップロードまたはダウンロードの帯域幅を指定する必要があります。これらの項目は輻輳制御や送信動作に関わる可能性があり、画面を飾る数字でも、値を大きくすれば制限が解除されて高速化する項目でもありません。実際の回線性能とサーバーの説明に基づいて、単位にも注意して入力してください。モバイル通信の利用可能な帯域幅は場所や電波状態によって変わります。実際より大きく見積もると、キューイングやパケットロス、他のアプリとの競合が増えることがあります。低く見積もると転送速度が制限される可能性もあるため、安定した条件で慎重にテストしてください。

iPhoneで速度・発熱・ネットワーク切り替え後の復旧を個別にテスト

継続的なダウンロードを評価する場合は、サイズと配信元が近いデータを選び、完了までの時間と途中の切断の有無を記録します。開始直後の瞬間速度だけでは、キャッシュ、バースト送信、無線ネットワークの制御に左右されます。バックグラウンドで別のデータ転送が動いている場合も、結果はその設定単独の性能を示しません。テスト後は普段使うページ、メッセージ、メディアのリクエストも確認しましょう。大容量転送の速度を優先しすぎて、日常利用の安定性を損なわないようにしてください。1回の成功を長期的に使える保証とみなすこともできません。

バッテリー消費では、転送速度が高いほど所要時間が短くなる場合がありますが、高負荷が続けばプロセッサーや無線モジュールの動作が増えることもあります。最終的な結果は負荷の内容によって変わります。ネットワーク状態が悪いと、再送やハンドシェイクのやり直しも消費電力に影響します。単位時間あたりに送信したデータ量だけで比較せず、同じ作業を完了するまでの時間、発熱、バッテリー残量の変化を比較してください。短時間のバッテリー残量の変化は大まかな値であり、プロトコルごとの消費電力を正確に結論づけることはできません。測定器ではなく傾向を見る指標として扱いましょう。

QUICには接続移行に関する設計がありますが、実際の復旧結果は両端の実装、ネットワーク上のアドレス変換、経路の変化に左右されます。Wi-Fiからモバイル通信に切り替えても絶対に中断しない、という意味ではありません。条件を管理できる環境で1度切り替え、現在の通信が復旧するか、新しいリクエストが成功するか観察してください。既存の通信だけが中断する場合は、アプリ側の復旧方法も切り分ける必要があります。ネットワークを短時間に何度も切り替えると、どの切り替えで失敗したのか判断しにくくなります。

Hysteria2を試す前提は、利用者が対応する設定をサーバーから入手し、現在のUDP経路が利用でき、用途上そのトランスポートの性能を比較する必要があることです。軽いページ閲覧が中心なら、ピーク速度より安定性や復旧時間が重要な場合もあります。有効性が確認できている設定を基準として残し、1項目ずつテストしてから普段使う設定を決めてください。性能に関係しそうな項目だからといって、測定根拠がない状態で複数の値を同時に変更しないでください。

08 / VERIFICATION & DIAGNOSIS

設定選びを実践：プロトコル確認からルール検証まで

まず元に戻せる基準を用意する

トラブルシューティングを始める前に、元のサブスクリプション項目または手動設定のコピーを保存し、現在のネットワーク、デフォルトサーバー、Global Routingのモードを記録してください。サブスクリプションが正常に更新されているか確認し、サブスクリプションの元の項目と過去に作成した手動項目を区別します。名前が同じでも設定が同じとは限りません。次にHomeでテストするサーバーを選び、システムの案内に従って必要な許可を行ってから接続テストを実施します。対象を1つに絞れば、設定を変更したのに実際には別のサーバーをテストしていた、といった混乱を避けられます。

Global Routingには、Config、Proxy、Directの3つのモードがあります。Configは現在の設定ルールに従ってリクエストを処理します。Proxyは対象となる通信を選択したプロキシ経路に通します。Directは直接接続します。これらはリクエストの処理方法を変えるものであり、サーバーのプロトコルを変換するものではありません。トラブルシューティング中に一時的に異なるモードを比較してもかまいませんが、テスト後は必要な元のモードに戻してください。Directでも失敗する場合は、プロキシのパスワードを変え続けるのではなく、まずデバイスのネットワークと接続先を確認してください。

最初に失敗する階層を特定する

まずサーバーアドレスを正しく解決できるか、現在のネットワークから該当ポートに到達できるかを確認します。次にTLSなどのセキュリティハンドシェイクを確認し、プロトコル認証、最後に宛先へのリクエストとルールを調べます。最初に失敗した階層を優先的に対処してください。後続の階層については、まだ信頼できる判断ができません。たとえば証明書のハンドシェイクに成功していない段階では、プロキシ認証が有効かどうか判断できません。プロキシ認証が成功しても、内部ネットワークの戻り経路が正しいとは限りません。

Connectivity Testは選択した項目の接続結果を確認するのに役立ちますが、すべての宛先、アドレスファミリー、アプリの動作をテストするものではありません。テストに成功してもWebページに問題がある場合は、名前解決、接続先の証明書、ルーティングを引き続き確認してください。テストに失敗した場合も、実際のアプリで同じ問題が起きるか確認し、テスト対象1つの問題をプロトコル全体の障害と決めつけないでください。結果にはテストの範囲を明記し、1つの成功をすべての機能が正常である証拠として扱わないようにしましょう。

症状	優先して確認する項目	次に行うこと
すべてのリクエストが失敗する	アドレス、ポート、認証、セキュリティハンドシェイク	元の設定に戻し、別のネットワークでも再テスト
テストは成功するが、一部のドメインに接続できない	名前解決の結果、ルール、接続先の状態	同じ接続先を異なるモードで比較
小さなリクエストは動くが、大きなデータの転送が止まる	経路上のパケットロス、パケットサイズ、サーバー負荷	条件をそろえ、元のMTUを維持して再テスト
Webページは開くが、リアルタイム機能が失敗する	UDP対応と戻り経路	種類の名前だけで判断せず、両端の対応状況を確認
画面ロック後またはネットワーク切り替え後に失敗する	接続の再確立、マッピング、キープアライブ、現在のネットワーク	新しいリクエストと既存の通信の復旧を区別

ルールの検証とプロトコルの検証を分ける

以下の例は、Shadowrocketの設定ファイルにおけるルールの構造を説明するものです。サーバー情報や認証情報、すぐに使用できるサブスクリプションは含まれていません。ドメイン名には例示用の値を使っています。実際に設定する前に、各ルールが用途に合うか確認してください。ルールは上から順に照合され、先に一致したルールが後続の処理に影響します。末尾のFINALは、それまでに一致しなかったリクエストを処理します。ここで使うPROXYとDIRECTは処理方法を示すもので、サーバーのプロトコル名でも、接続を別のプロトコルに変換する命令でもありません。

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

Proxyモードでは接続できるのにConfigモードで失敗する場合は、対象がどのルールで処理されているか、期待どおりの名前解決結果か、設定でどのプロキシ経路が選ばれているかを確認してください。すぐにプロトコルを入れ替えてはいけません。2回のテストで異なる経路を使っている可能性があるためです。GEOIPはIPアドレスの地域データベースに基づく判定で、特定ドメインへの意図をそのまま代替するものではありません。ドメインルールとアドレスルールが併用されている場合は、キーワードの有無だけでなく、ルールの順序と名前解決の条件を確認してください。

最後に、用途に合わせて選びます。一般的なWeb閲覧では初回応答と安定性、継続的なデータ転送では完了時間と再送、リアルタイム通信ではUDPの条件と遅延の変動、内部ネットワークへのアクセスではルーティング範囲と名前解決を確認します。プロトコルを比較する意味があるのは、既存のサーバーから複数の利用可能な設定が提供されている場合です。あらゆるネットワークと用途に共通する決まった順位はなく、短期間のテスト結果から特定のプロトコルの恒久的な優劣を判断することもできません。

サポートを求める際は、プロトコルの種類、トランスポート方式、問題が発生したネットワーク、失敗した段階、実施済みの個別テストをまとめてください。パスワード、UUID、秘密鍵、サブスクリプションに含まれる個人識別情報は隠し、問題解決に必要な設定の構成だけを共有します。よくある症状はよくある質問をご覧ください。インポートから接続までの手順を確認し直す場合は、使い方ガイドに戻ってください。あらゆる種類を手当たり次第に試すより、元に戻せて再現可能な有効設定を用意する方が役立ちます。