Shadowrocket プロトコルガイド

01 · プロトコルの選び方と接続レイヤー

種類はサーバー側の設定と一致させる

プロトコルを選ぶ際にまず確認するのは互換性であり、速度ランキングではありません。同じサーバーアドレスでも、ポートごとに異なるプロトコルが設定されている場合があります。アドレスが同じだからといって、認証方式や通信方式を置き換えられるわけではありません。Add ServerでTypeを選ぶときは、手元にあるサーバーの説明やサブスクリプションの解析結果を確認してください。ShadowsocksをTrojanに変更しても、元のサーバーが自動的にTLSに対応するわけではありません。VMessの認証情報をVLESSに入力しても、接続できるとは限りません。サブスクリプションの内容と説明が異なる場合は、同じ接続先を指しているか確認してから項目を調整してください。

接続は4つのレイヤーに分けて考えられます。最初は、現在のWi-Fiまたはモバイル通信からサーバーに到達できるか。次に、TCP、UDP、QUICなどの通信方式。その次に、プロトコルの認証・暗号化・任意のTLS。最後に、宛先へのリクエストとルールによる処理です。タイムアウトはどのレイヤーでも起こり得るため、エラーメッセージだけでパスワードの誤りと判断できません。たとえば、ポートに到達できない段階では認証は始まっておらず、証明書が一致しない場合も、宛先へのリクエストが送信されたとは限りません。レイヤーごとに考えることで確認範囲を絞り、関係のない設定を同時に変更せずに済みます。

速度とバッテリー消費は同じ条件で比較する

接続速度には、接続確立までの待ち時間、最初の応答までの時間、継続的な転送速度という異なる指標があります。短いページの閲覧ではDNSやハンドシェイク、最初の応答の差が表れやすく、大容量ファイルの転送では回線速度や輻輳制御、サーバー負荷の影響が大きくなります。1回のConnectivity Testで、すべてのアプリの使用感が分かるわけではなく、ダウンロード速度にそのまま換算することもできません。複数の接続先を比べる場合は、同じ端末・ネットワーク・テスト先を使い、時間帯も近づけてください。接続直後と、接続が確立した後の状態も分けて記録します。

iPhoneやiPadのバッテリー消費も、プロトコル名だけでは判断できません。暗号化処理はプロセッサを使用しますが、無線通信の継続、パケットロスによる再送、頻繁なハンドシェイク、過剰なKeepaliveも大きく影響することがあります。電波が弱い環境では、データの再送が暗号アルゴリズム以上に電力を消費する場合があります。測定時は画面の明るさ、前面で使うアプリ、測定時間をそろえ、画面やバックグラウンド同期による消費をプロトコルの影響と混同しないようにしてください。低遅延と低消費電力を同時に実現できるとは限りません。まず実際の利用目的を決めましょう。

サーバー側が1種類のプロトコルしか提供していない場合、「選び直す」ために別のプロトコルを入力する必要はありません。互換性のある種類を選び、必須項目を確認するのが正しい手順です。比較に意味があるのは、ご自身のサーバーで複数の接続先が実際に設定されている場合に限られます。通信方式やセキュリティの設定は、サーバー側の具体的な構成とアプリの対応状況によって異なります。アプリに該当する項目がない場合、名前が似ている設定で代用できるとは限りません。元の説明を保管し、現在のクライアントで必要な項目をすべて設定できるか確認してください。

02 · Shadowsocksの暗号化と転送

シンプルな転送構成の特徴と注意点

Shadowsocksは、軽量な暗号化プロキシ転送を実現するために設計されました。宛先アドレスとアプリのデータをカプセル化し、リモート側へ渡します。ネットワーク層全体を扱うトンネルとは異なり、プロキシ接続を中心とするため、端末にトンネル用のアドレス一式を割り当てる必要はありません。構成が比較的シンプルなため、導入やトラブル対処がしやすい一方、「暗号化プロキシ」というだけですべてのセキュリティ特性が決まるわけではありません。暗号化方式、認証強度、UDPの動作、追加の通信要件は、サーバー側の設定ごとに確認してください。

Shadowrocketで手動追加する場合は、まずShadowsocksを選び、サーバーアドレスとポートを入力してからMethodとPasswordを確認します。Methodはプロトコルの互換性に関わる項目で、自由に選べる性能設定ではありません。双方で異なる方式を選ぶと、パスワードが同じでもデータを正しく解釈できません。Passwordをコピーする際は、前後の空白や改行、大文字・小文字を確認してください。サブスクリプションの名前をパスワードと取り違えたり、共有情報をエンコードした文字列全体をPassword欄に貼り付けたりしないでください。共有情報全体は、対応するインポート方法で処理します。

AEAD、互換性、追加設定

AEAD方式では暗号化とデータの完全性検証を行い、受信側は改ざんや認証に失敗したデータを検出できます。単に「内容を読めなくする」こととは異なりますが、アルゴリズム名が似ている方式同士がすべて互換性を持つわけではありません。プロトコルの種類によっては、鍵やセッション、ユーザー情報に追加の要件があります。サーバーが指定する種類、アルゴリズム名、認証情報はひとまとまりとして扱ってください。サブスクリプションに追加項目が含まれている場合は、項目を削除して入力欄を通すのではなく、元の設定説明を確認しましょう。

既存の設定には、追加の通信コンポーネント、ホスト名、パスが含まれている場合があります。これらはShadowsocks共通の必須項目ではなく、サーバー側で実際に有効になっているときだけ合わせる必要があります。追加コンポーネントは外側のデータ形式を変えたり、ハンドシェイクや設定を複雑にしたりするため、通常の接続先に根拠なく設定しないでください。「インポートは成功したのに接続できない」場合は、必要な項目がすべて取り込まれているか、現在のクライアントがその組み合わせに対応しているか確認します。記録が表示されたことはデータの解析に成功したという意味であり、双方のプロトコル交渉が完了したことを示すものではありません。

TCP、UDP、iOSでの動作

TCPのリクエストは成功するのに、UDPを必要とするアプリが失敗する場合は、別の原因として切り分けます。サーバー側でUDP転送が有効になっていない、経路上でUDPが許可されていない、現在のルールが対象の通信を想定したポリシーに渡していない、といった可能性があります。この場合、Passwordを何度も変更しても解決しないことが多いです。まず通常のWebページで基本的なTCP転送を確認し、次にアプリが実際に使う通信方式とクライアントの記録を確認してください。Webページが1回表示できたからといって、すべてのネットワーク機能が使えるとは限りません。1回の失敗だけでプロトコル全体が不適切だと判断することもできません。

iPhoneやiPadでは、追加レイヤーが少ないほど設定が簡単になる傾向がありますが、実際の転送速度は選択したアルゴリズムの端末上での処理効率、サーバー性能、ネットワークのパケットロスにも左右されます。アルゴリズムによる違いは端末ごとに異なるため、別の端末での結果をそのまま当てはめることはできません。継続的な転送は安定しているのに初回アクセスだけ遅い場合は、DNSと接続確立を優先して確認します。高負荷時だけ速度が落ちる場合は、プロセッサ負荷と回線の制約を調べてください。アルゴリズムを変更するにはサーバー側の対応も必要で、クライアント側だけを変更しても解決しません。

接続できる設定を1つ保存し、コピーを作って項目を1つずつ検証する方法がおすすめです。まずAddress、Port、Method、Passwordを確認し、実際に設定されている追加項目を調べてから、UDPとルールの経路を確認します。サブスクリプション更新後に問題が起きた場合は、更新前後で種類や重要な項目が変わっていないか比較してください。認証情報を含む設定全体を公開しないようにしてください。インポートと更新の方法はSubscribeの更新方法をご覧ください。この章ではプロトコルの設定項目と確認の順序を説明します。サーバー設定の入手先を案内するものではありません。

03 · VMessとVLESSの認証・通信方式

プロトコルの認証と通信方式を分けて考える

VMessとVLESSはいずれもユーザー識別子としてUUIDを使うことが一般的ですが、Typeだけを変更して入れ替えられる形式ではありません。VMessは認証とデータ保護をプロトコルの設計に含み、一部の認証処理は時間のずれに影響されるため、端末の時刻が大幅にずれていると失敗することがあります。一方、VLESSはより簡潔な構造で、基本プロトコル自体はデータを暗号化しません。通常は構成に含まれるセキュリティレイヤーでデータを保護します。両者の違いは構造と役割分担にあり、名称だけで一方が必ず速いと考えるのは適切ではありません。

UUIDは、手元にあるサーバー設定から取得し、文字や区切り記号をそのまま保持してください。形式の合ったUUIDをランダムに生成しても、サーバー側で認められるとは限りません。サーバーアドレス、ポート、UUIDが正しくても、確認は完了ではありません。通信方式、TLS、Server Name、パスなども接続の可否を左右します。サブスクリプションに似た接続先が複数ある場合は、サーバーの説明で同じ設定に属すると明示されていない限り、ある記録のUUIDと別の記録のパスを組み合わせないでください。

TCP、WebSocket、gRPCは異なるレイヤー

プロトコルは認証や宛先リクエストの表し方を決め、通信方式はそれらのデータをどう運ぶかを決めます。WebSocketを使う場合、クライアントは対応するハンドシェイクを行い、PathやHostなどをサーバーの要件に合わせる必要があります。gRPCでは対応するサービス名やTLSなどを確認してください。通常のTCP接続先に、根拠なくWebSocketのPathを入力する必要はありません。同じドメイン名を使っていても、同じ接続先を共有しているとは限りません。リバースプロキシがパス、ホスト名、サービス名に応じて異なるバックエンドへリクエストを振り分ける場合があります。

Host、Server Name、サーバーアドレスも混同しないでください。サーバーアドレスは接続先を決めます。TLSのServer Nameはハンドシェイク時の名前の通知や証明書の照合に使われます。WebSocketのHostはアプリケーション層のリクエスト情報です。設定によって同じ値になることはありますが、すべての状況で一致するというプロトコル上の要件ではありません。説明に従ってそれぞれを入力することで、「正しいサーバーに接続したがバックエンドが違う」場合と「サーバー自体に到達できない」場合を区別できます。特定レイヤーの誤りを隠すために、名前を適当に置き換えないでください。

セキュリティ設定と性能の限界

VMessのSecurityなどはプロトコル固有の設定であり、TLSの有効・無効と同じものではありません。VLESSの一部のセキュリティ設定やフロー制御の拡張も、特定の構成でのみ使えます。サーバー側が対応を明示していない場合は、名前だけを見て拡張を選ばないでください。インポート後に見慣れない項目がある場合は、現在のアプリの該当設定とサーバー側の要件を確認し、元の記録を保管します。意味の分からない項目を削除すると、完全な設定が互換性のない設定に変わることがあります。「よく使われる値」を入力するより、元の情報を保つほうが確実です。

TLSやアプリケーション層の通信方式を追加すると、通常はハンドシェイクやカプセル化の分だけ処理が増えますが、それだけで最終的な速度が遅くなるとは限りません。持続接続ならハンドシェイクのコストを分散でき、ネットワーク上の中継機器によっても各方式の実際の動作は変わります。短時間の接続を何度も行う用途では接続確立の負荷が表れやすく、長時間の転送では輻輳やサーバー負荷の影響が大きくなります。iOSでは、失敗と再接続を繰り返すほうが、接続を安定して維持するよりバッテリーを消費する場合があります。まず設定の不一致を直すことが、特定のカプセル化レイヤーを減らすことより重要です。

トラブル対処では、まず端末の日付と時刻が自動設定になっているか確認し、次にアドレスとポートへの到達性を調べます。その後、UUID、プロトコル固有のセキュリティ項目、通信方式、TLS、名前、パスの順に確認します。TLSが成功してもリクエストが失敗する場合は、証明書検証を無効にするのではなく、認証やバックエンドのルーティングを確認してください。サブスクリプション更新後だけ使えなくなった場合は、通信方式の項目が変わっていないか比較します。同じグループの記録がすべて使えなくなった場合は、現在のネットワークや共通のドメイン解決を先に調べてください。確認の手順は接続先のタイムアウトと接続失敗に関するメモも参考になります。

04 · Trojan、HTTP、SOCKS5の違い

Trojan：TLS接続内で認証

Trojanは、TLS接続内でプロキシ認証とリクエストを処理する設計で、広く使われているTLSの仕組みで通信を保護します。設定ではPasswordとTLSの項目がそれぞれ異なる役割を担います。パスワードはサーバーでユーザーを識別し、証明書と名前の検証は安全な接続先の身元を確認します。パスワードが正しくても証明書の確認を省略できるわけではなく、証明書が有効でもアカウント認証が成功するとは限りません。この2つを別々に確認すれば、「ハンドシェイクの失敗」と「認証の失敗」に応じた対処ができます。

Server Nameは、サーバー証明書と構成の要件に合う値を指定します。適当な見覚えのあるドメイン名を入力しないでください。サーバーアドレスにIPアドレスを使っていても、TLSハンドシェイクではドメイン名が必要な場合があります。接続先と検証する名前が異なる設定は正常ですが、既存のサーバー説明に基づいて指定してください。証明書エラーが出た場合は、端末の時刻、名前の入力ミス、証明書の有効期間、証明書チェーンを確認します。検証を無効にしてエラー表示を隠しても、意図したサーバーに接続できた証明にはなりません。長期的な解決策として使うべきではありません。

HTTP：プロキシリクエストと通信全体の暗号化は別

HTTPプロキシは、アプリケーション層のリクエストを転送する仕組みとして設計されました。HTTPSの接続先には、通常CONNECTを使って宛先までのデータ通路を確立します。ここでは「接続先のWebサイトがHTTPSを使うこと」と「端末からプロキシ接続先までの通信にTLSを使うこと」を区別してください。前者はWebサイトとのセッションを保護し、後者はプロキシまでの区間を保護します。プロキシ接続先自体が暗号化されていないHTTPの場合、宛先のURLがHTTPSで始まっていても、プロキシの認証情報や接続先情報まで同じように保護されるわけではありません。

HTTP系の接続先を設定するときは、サーバーアドレス、ポート、TLSの有無、UsernameとPasswordが必要かを確認してください。Webサイトのログイン情報をプロキシの認証情報として使ったり、URLのパス部分をそのままアドレス欄に入力したりしないでください。サーバー側が通常のHTTPプロキシだけを提供している場合、クライアントでTLSを有効にしても自動的に接続が切り替わるわけではありません。反対に、TLSが必須の接続先へ暗号化なしで接続すると、初期段階で失敗することがよくあります。最初に送られるデータの解釈が、クライアントとサーバーで一致している必要があります。

SOCKS5：柔軟な転送方式だが、データを自動で暗号化しない

SOCKS5は、宛先アドレスの指定、認証の交渉、転送リクエストなどの仕組みを定めており、ドメイン名やIPアドレスを宛先として指定できます。構成によってはUDPにも対応します。ただし、SOCKS5自体は一般的なデータ暗号化を提供せず、UsernameとPasswordによる認証も暗号化通信と同じではありません。この種類を選ぶ場合は、既存のネットワーク環境でどのような保護が提供されているか、接続先に別のセキュリティレイヤーがあるか確認してください。「パスワードがある」ことは「データが暗号化されている」証拠にはなりません。また、アプリの接続先自体のセキュリティが、すべての通信内容に及ぶとも限りません。

SOCKS5でUDPを使えるかどうかは、サーバー、通信経路、クライアントの処理がそろっている必要があります。サーバーとのTCP接続が確立しても、UDP転送が使えるとは限りません。ドメイン名を端末側とリモート側のどちらで解決するかは、実際のリクエスト形式とクライアントのDNS設定によります。ドメイン名ではアクセスできず、同じ宛先のIPアドレスなら到達できる場合は、まず名前解決の経路を調べてください。通常のWebページは表示できてもリアルタイムアプリに問題がある場合は、UDPとルールを確認します。十分な根拠がないまま、違いをすべて認証方式のせいにしないでください。

iPhoneやiPadでこの3種類を比較する場合も、実際に利用できる接続先があることを前提にします。TrojanのTLSハンドシェイク、HTTPの接続再利用、SOCKS5の転送経路は、最初の応答に影響する可能性があります。一方、継続的な速度は主に実際の通信経路によって決まります。通信の保護が必要な用途では、プロトコルの表示名だけでなく接続先のセキュリティレイヤーを確認してください。アプリでUDPが必要な場合は、端から端まで転送できるかを確認します。使える設定が1つしかないなら、互換性のない種類に切り替えるより、その設定を正しく入力することが重要です。

05 · WireGuardの鍵、アドレス、MTU

ネットワーク層のトンネルとプロキシ接続先の違い

WireGuardは、シンプルなネットワーク層トンネルを中心に設計されています。公開鍵と秘密鍵で接続相手を識別し、UDPで保護されたデータを転送します。主にアプリの接続を転送するプロキシプロトコルとは異なり、トンネル内のアドレスやルーティング範囲も関わります。そのため、設定を「サーバーとパスワード」だけで考えることはできません。端末側の鍵による識別情報が必要で、接続相手にも対応する公開鍵を登録し、トンネルを通すアドレス範囲も双方で把握する必要があります。認証の成功から宛先への到達までには、アドレスの割り当てとルートの設定も確認しなければなりません。

PrivateKeyは現在の端末側の秘密鍵です。信頼できるローカル設定に保管してください。相手側の設定項目にあるPublicKeyは通常、リモート側の公開鍵を指し、端末側の秘密鍵をコピーする場所ではありません。端末側の秘密鍵から導出した公開鍵をリモート側で許可し、リモート側の公開鍵で接続相手を確認します。公開鍵を取り違えた場合や、サーバーに端末の識別情報が登録されていない場合は、アドレスとポートが正しくても有効なセッションは確立しません。PresharedKeyは任意の追加共有鍵です。双方で明示的に設定している場合にだけ入力し、片側だけの値を作らないでください。

Address、Endpoint、ルーティング範囲

Addressはトンネル内で端末に割り当てるアドレスで、通常はプレフィックス長を含みます。Endpointは外側のネットワーク上にあるリモート側のアドレスとポートです。役割が異なるため、インターネット上のサーバーアドレスをトンネル内のアドレスとして使うことはできません。既存の設定にIPv4とIPv6のAddressが両方ある場合は、それぞれのプレフィックスもそのまま保持してください。トンネルアドレスを任意に変更すると、他の接続先と重複したり、リモート側の許可範囲から外れたりして、ハンドシェイクはできてもデータが期待どおりに戻らないことがあります。

WireGuardのモデルでは、AllowedIPsはトンネル内で許可するアドレス範囲と、どの接続先を選ぶかに関わります。クライアントでの具体的な表示は、実際の画面に従ってください。Shadowrocketでは、接続先ごとのトンネル内ルートと、アプリ全体のルールによるポリシーを区別する必要があります。前者はトンネル内でアドレスをどう処理するかを決め、後者はどのリクエストをそのポリシーに渡すかを決めます。リモート側で広いアドレス範囲が許可されていても、端末のリクエストがすべてトンネルを通るとは限りません。まずルールが対象のリクエストを選択しているかを確認し、その後、トンネル内の戻り経路と宛先ルートを調べてください。

MTU、DNS、Keepaliveの影響

MTUは、インターフェースが処理できるパケットサイズの上限です。トンネルのカプセル化によって追加のデータが加わるため、経路が大きなパケットを正しく処理できないと、小さなリクエストは成功しても大きな応答が止まることがあります。その場合、MTUを少し下げて検証する方法がありますが、特定の値がすべてのネットワークに適するとは限りません。元の値を記録し、一度に一段階だけ変更して、同じ宛先で再テストしてください。値が低すぎるとパケット数や処理負荷が増えます。問題の原因がDNSや宛先ルートなら、MTUを変えても通常は解決しません。

DNS設定はドメイン名をどのアドレスに解決するかを決めるもので、誤ったトンネルルートを自動的に修正するものではありません。DNSサーバーがトンネル内にある場合は、先にそこへ到達できる経路が必要です。そうでないと、「ドメイン名は使えないが一部のIPアドレスには到達できる」状態になりやすくなります。Keepaliveは必要に応じてNATマッピングを維持するためのもので、帯域を増やす設定ではありません。間隔が短すぎるとモバイル端末の無線モジュールが頻繁に起動し、長すぎるとアイドル状態の後に最初のリクエストが経路の再確立を待つことがあります。ネットワーク環境とサーバー側の推奨値に従ってください。

WireGuardでは、ハンドシェイク、送受信のカウンター、実際のリクエストを分けて判断します。ハンドシェイクが成功した場合、少なくともその時点では相手の識別と外側の経路が機能したことを示しますが、トンネル内の宛先に到達できるとは限りません。送信だけ増えて受信が増えない場合は、リモート側のルート、許可されたアドレス範囲、戻り経路を確認してください。Wi-Fiからモバイル通信に切り替えた後に一時的な復旧が起きても、すぐに鍵の問題と決めつけないでください。項目の関係と調整上の注意点はWireGuardの設定項目に関するメモをご覧ください。変更前に、現在使える設定をバックアップしてください。

06 · Hysteria2のQUICと帯域設定

UDPを使った接続の仕組み

Hysteria2はQUICをベースにしたプロキシ通信方式です。QUICはUDP上で安全なハンドシェイク、接続管理、信頼性のあるデータストリームを実現するため、「外側がUDPだから内部のデータもすべて信頼性がない」というわけではありません。接続と輻輳の処理をこの通信方式の中で行うことが設計上の特徴の1つです。パケットロスや遅延の変化がある環境では、TCPを使う方式とは異なる動作をする場合がありますが、実際の結果は回線の制御、サーバーの帯域、実装や設定にも左右されます。名称だけで速度が保証されるわけではありません。

Hysteria2を使うには、手元にあるサーバーが実際にこのプロトコルを提供している必要があります。他の種類の接続先アドレスやパスワードをそのまま流用したり、名前の似た世代のプロトコルを互換性のあるものとして扱ったりしないでください。まずType、サーバーアドレス、UDPポートを確認し、次に認証情報とTLSの設定を照合します。サーバー構成によっては追加の難読化設定が必要ですが、サーバー側で実際に有効な場合にだけ設定してください。必要な項目が抜けていると、通常のハンドシェイクに入る前にデータが破棄され、認証エラーが出ないままタイムアウトが続くことがあります。

Webページが開けるかより、UDP経路の確認が重要

現在のWi-Fiで通常のWebページを開けても、接続先ポートへのUDP通信が許可されているとは限りません。ネットワークによってはUDPへの制限がTCPと異なり、継続的なUDP通信を別の方法で処理することもあります。あるネットワークではHysteria2がタイムアウトするのに、同じ設定が別のネットワークで使える場合は、まず外側のUDP通信が到達できるか比べてください。すぐにパスワードを変更する必要はありません。パラメーターの違いとネットワークの違いを混同しないよう、同じ設定を使ってテストしてください。

ここでもTLSでは、正しい名前の指定と証明書検証が必要です。Addressはデータの送信先を決め、Server Nameはハンドシェイクでの名前通知と接続先の確認に関わります。サーバー証明書がドメイン名のみを対象としている場合、IPアドレスで接続するときにも該当する名前を指定する必要があります。具体的な値は既存の設定で確認してください。端末の日付が大きくずれている、ドメイン名が誤った接続先を指している、証明書チェーンが不完全といった状況もハンドシェイクの原因になります。QUICがこれらのセキュリティ要件を自動で回避することはありません。検証を無効にしても、ほかの項目が正しい証拠にはなりません。

帯域の入力は速度を上げるスイッチではない

帯域に関する項目は、現在の実装、サーバー設定、実際の回線に照らして理解してください。輻輳制御の方式によっては、帯域情報を使ってデータの送信方法を決めます。利用可能な回線を大幅に超える値を入力すると、キューやパケットロス、再送が増え、応答性がかえって低下することがあります。サブスクリプションの説明にある宣伝上の速度を正確な設定値と見なさないでください。自宅回線の公称速度だけを基準に、モバイル通信の値を決めるのも適切ではありません。単位にも注意が必要です。bit/sとbyte/sを混同せず、アップロードとダウンロードの方向も項目の説明に沿って確認してください。

ダウンロードは速いのにWebページの表示が遅い場合、DNSではなく、輻輳時のキューが長すぎる可能性があります。大容量の転送を止めて短いリクエストを再テストし、差が解消するか確認してください。その後、サーバー側の推奨に従って帯域や輻輳の設定を確認します。バッテリーについては、転送量が増えると無線モジュールやプロセッサの動作も増えます。通信経路が不安定な環境では、再送も消費電力を押し上げます。瞬間的なバッテリー残量や最高速度だけでなく、同じ作業を完了するまでの時間と総消費量を比較してください。

モバイル通信に切り替えた後、QUICの接続IDや経路の仕組みがあるからといって、すべてのアプリのセッションが維持されるとは限りません。接続が復旧するかどうかは、クライアントの処理、リモート側の状態、NATマッピング、アプリ自体のタイムアウトにも左右されます。確認時は切り替え前後の接続結果を記録し、接続中のアイコンが表示され続けているかだけで判断しないでください。特定のネットワークでこの種類だけ失敗し、ほかの既存の接続先は使える場合は、その比較結果を記録しておきます。すべての種類が失敗する場合は、QUICの設定に絞らず、基本ネットワーク、名前解決、全体のルーティングを先に確認してください。

07 · 設定項目と段階的なトラブル対処

元の情報を保管してから、インポート結果を確認する

サブスクリプションや共有情報をインポートした後は、「解析に成功したこと」と「接続できること」を分けて確認してください。前者はクライアントがデータ形式を認識したことを示します。後者にはネットワーク、認証、セキュリティレイヤー、転送がすべて正常に動作する必要があります。まずTypeが元の情報と一致しているかを確認し、アドレス、ポート、重要な認証情報、通信方式の拡張を順番に調べてください。項目が不足している場合は、一般的な値をすぐ入力するのではなく、手元にある設定と照合します。対応していない組み合わせの場合、表示名の変更や再インポートを繰り返しても互換性は生まれません。

よくある混同は、異なる役割の「名前」を同じ項目として扱うことです。メモは端末上で接続先を見分けるためのものです。Addressは実際の接続先、Server NameはTLS、Hostはアプリケーション層の接続先、Pathやサービス名は通信先のバックエンドに関わります。これらの値が同じ場合も異なる場合もあります。トラブル対処の記録には「ドメイン名は正しい」とだけ書かず、それぞれの役割を分けて記載してください。サーバーが複数のバックエンドを使っている場合、同じアドレスへのTCP接続ができても、名前やパスの誤りで別のサービスに接続されることがあります。

失敗範囲から問題を切り分ける

1件の記録だけが失敗する場合は、その記録に固有のアドレス、認証情報、通信方式を優先して確認します。同じグループの記録が一斉に失敗する場合は、共通のドメイン、認証情報の入手元、サーバーの状態を調べます。1つのネットワークですべて失敗する場合は、既知の別ネットワークで比較してください。どのネットワークでも失敗する場合は、現在のConfig、端末の時刻、システムの接続状態も確認します。このように条件ごとに分けるほうが、テストを繰り返すだけより効率的です。問題が特定の接続先、共通の設定、端末の環境のどこにあるかを、各手順で判断できます。

タイムアウトは、制限時間内に必要な結果を得られなかったことを示し、パスワードの誤りを直接意味するものではありません。接続拒否は、接続先ポートで待ち受けていない場合や、通信経路上の機器が処理した場合に起こることがあります。証明書エラーはTLSの身元確認、認証エラーはプロトコルの認証情報を示します。具体的なメッセージは前後の状況と合わせて読み、英語のエラーをすべて同じ意味として扱わないでください。記録を確認するときは、エラーが発生する前の段階も保管します。他者に状況を伝える際は、種類、ネットワーク条件、認証情報を伏せたエラーだけを共有し、認証情報全体を公開しないでください。

テストの成功と実際の利用成功を区別する

Connectivity Testの結果はテスト方法と宛先によって異なり、すべてのWebサイト、UDPアプリ、ルールが正常だと証明するものではありません。テストに成功しても閲覧できない場合は、対象ドメインのDNS、適用されるポリシー、宛先からの応答を確認してください。特定のアプリだけ失敗する場合は、異なるドメインにアクセスしていないか、別の通信方式を使っていないか調べます。「接続スイッチがオン」の状態はシステムのトンネル状態を示すだけで、宛先へのリクエストを確認したことにはなりません。設定が使えるか判断する前に、少なくとも既知の宛先へ実際にリクエストを送ってください。

DNSのトラブル対処では、依存関係に注意してください。サーバーアドレス自体がドメイン名の場合、接続を確立する前に通常は名前解決が必要です。Webサイトの名前解決は、現在のConfigの影響を受ける場合があります。トンネル内からしかアクセスできないDNSサーバーを設定しているのに、トンネル接続を始めるための名前解決手段がないと、循環依存が起こることがあります。まずサーバーのドメイン名を正しく解決できるか確認し、その後、宛先ドメインとリクエストのポリシーを調べてください。DNS設定を一度にすべて変更しないでください。具体的な手順はDNS設定ガイドをご覧ください。

最後に、現在のネットワーク、プロトコルの種類、実際にテストした宛先、エラーが起きた段階、今回変更した項目を1つだけ記録して、最小限の再テストを行います。変更のたびに同じ宛先でテストし、結果を確認してから設定を維持するか元に戻すか決めてください。サブスクリプション全体を取得できない問題と、1つの接続先で認証に失敗する問題は別の手順で確認します。前者はサブスクリプションURLの有効性と取得結果を確認してください。詳しくはサブスクリプション取得失敗の確認方法をご覧ください。設定項目を確認しても特定のリクエストだけ異常が残る場合は、次の章でルールと接続のトリガーを確認します。

08 · Global Routing、ルール、On Demand

プロトコルが使えることを確認してから、ポリシーを検証する

プロトコルはリモート側への接続方法を決め、Global Routingはリクエストの処理方法を決めます。両者は互いに代用できません。Configは現在の設定にあるルールに従ってポリシーを選択します。Proxyは意味を確認したうえで一時的にルールの影響を絞り込む場合に使え、Directは直接接続する場合に使います。トラブル対処では、まず現在の設定状態を記録し、リクエストが実際にどの経路を通ったか確認してください。Directの状態でリモート側プロトコルを試し、誤った結論を出さないようにします。テスト後は元のConfigに戻してください。一時的な変更が後の比較に影響し、ローカルネットワークへのアクセスも変わる可能性があります。

ルールは通常、上から順に照合されます。より具体的な条件は適切な位置に置き、先行ルールに一致しなかった場合の処理にはFINALを使います。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレスの範囲、GEOIPは該当する地域データに基づいてアドレスを判定します。対象が異なるため、Webサイト名が似ているだけでルールを置き換えることはできません。PROXY、DIRECT、REJECTはそれぞれ異なる処理を示します。また、ルールに指定するポリシー名が現在の設定内で正しく解決できる必要があります。ルール一覧の位置だけで推測せず、リクエストの記録で実際の結果を確認してください。

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

この.confの例はルールの構文と順序を示すもので、完成した設定ではありません。example.comは説明用のドメインです。プライベートアドレス範囲へのDIRECTは直接接続を示し、GEOIPの結果は該当するデータに依存します。最後に一致しなかった通信はFINALで処理します。自分のConfigに適用する前に、既存のポリシー、DNS、ローカルネットワークの範囲を確認してください。この例で設定全体を上書きしないでください。特定の地域を対象にしたルールを誰にでも推奨される設定と考えたり、ルールの変更で誤ったPasswordやTLSの名前を直せると思ったりしないようにしてください。

On Demandが制御するのは接続を開始するタイミング

On Demandは、ネットワークなどの設定済み条件に応じてシステムの接続動作を開始します。各リクエストで使うプロトコルを決める機能ではありません。Wi-Fi、Cellular、ドメインの条件は、現在の画面とルールの機能に合わせて設定してください。接続の確立に影響する条件もあれば、名前解決の環境に関係する条件もあります。設定を始める前に、手動接続が安定していることを確認してください。手動接続自体が失敗している場合、自動接続を設定しても同じ問題が繰り返され、原因を見分けにくくなることがあります。

Wi-Fiの条件を設定するときは、SSIDの実際の文字列を確認してください。名前が似ていても別のネットワークである場合があります。モバイル通信の条件を設定する場合は、Wi-Fiから切り替えたときと、Wi-Fiに戻したときの動作をそれぞれ確認します。条件が複数ある場合は、優先順位と最後に適用される動作を調べてください。広い条件が先に一致すると、後に設定した特定の条件が実行されないことがあります。手動で接続を切った後に自動で再接続する場合、スイッチの不具合ではなく条件が再び満たされた可能性があります。システムの接続状態を確認する前に、On Demandのルールを確認してください。

名称の順位ではなく、利用場面に合わせて検証する

日常的な閲覧では、最初の応答、名前解決の安定性、アイドル状態からの復帰を確認します。継続的な転送では、実効速度、キュー、再送を確認してください。UDPが必要なアプリでは、端から端まで転送できることを先に確かめます。トンネル内のリソースへアクセスする場合は、WireGuardのアドレスとルートを重点的に確認してください。互換性のある接続先が複数ある場合は、こうした目的ごとに比較するほうが、特定のプロトコルを「どんな場合も速い」と評価するより参考になります。同じプロトコルでもサーバーによる差が、プロトコル名の違いより大きいことがあります。比較時は、統制できない条件も明確にしてください。

バッテリーの検証も実際の使い方に合わせます。既存の2つの設定で、近いデータ量と利用時間のタスクを行い、画面を点灯して使う状態とアイドル状態を分けて観察してください。バックグラウンド同期、電波強度、画面の点灯時間も結果に影響するため、合わせて記録します。アイドル時の消費が明らかに増えた場合は、接続失敗と再接続の繰り返し、Keepaliveの間隔、On Demand条件の頻繁な切り替えを確認します。継続転送時だけ消費が増える場合は、転送量と処理負荷を合わせて判断してください。1回のシステムバッテリー表示だけで、プロトコルごとの消費電力の順位を決めないでください。

最後に、次の3点を確認できる状態にします。記録のTypeがサーバー側と一致していること、実際のリクエストが想定したポリシーに一致すること、ネットワーク切り替え後の接続動作がOn Demandの設定どおりであること。確認が済んだら使える設定を保存し、自動接続の条件を1つずつ追加してください。条件に応じた接続の例はWi-FiとCellularのトリガールールに関するメモをご覧ください。追加、接続、動作確認の手順を最初から確認する場合は、使い方ガイドに戻ってください。このプロトコルガイドでは違いと確認範囲を説明します。設定値は常に、ご自身が用意したサーバー情報を基準にしてください。