Shadowrocketのプロトコル解説
と設定項目ガイド

1. プロトコル選択と接続階層

プロトコルを選ぶ際に最も重要なのは名称ではなく、サーバーが実際に受け付ける接続方式です。Shadowrocketのプロトコルタイプは、既存のサブスクリプションまたはサーバー情報と一致させる必要があります。同じアドレスのタイプを別のものに変更しても、サーバーにその機能が備わるわけではありません。サーバー側が複数の接続方式を提供し、それぞれの認証・通信設定がそろっている場合に限り、比較検討できます。読み込み後は速度の印象で設定を試し変えするのではなく、まずタイプ、アドレス、ポートを確認し、追加設定の変更が必要か判断してください。

通信を4つの階層に分けて考える

第1層はローカルネットワークです。端末をWi-Fiまたはモバイル通信に接続し、サーバーに到達できる状態にします。第2層は通信方式とセキュリティのカプセル化です。TCPとUDPのどちらを使うか、TLSを確立するか、WebSocketなどの通信方式を重ねるかを決めます。第3層はプロトコルの認証とデータ形式で、パスワード、UUID、公開鍵などが該当します。第4層はクライアントのルーティングと接続先で、選択したサーバーを経由するか、直接接続するかを決めます。前の階層で問題が起きている場合、後の階層を変更しても解決しないことがほとんどです。

「応答を確認できる」ことと「Webページを利用できる」ことが同じではないのは、このためです。テストによっては、アドレスへの到達、ハンドシェイク、指定した接続先からの応答のみを確認し、すべての接続先、DNS、UDP、アプリの動作まで検証するものではありません。反対に、テスト先自体に到達できず、単発のテストが失敗することもあります。結果を読むときは、テスト方法、使用中のネットワーク、選択したサーバー、ルーティングの設定を合わせて確認し、条件の異なる数値をそのまま比較しないでください。

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

プロトコルのオーバーヘッドは速度を左右する要素の一つにすぎません。サーバーまでの距離、利用可能な帯域幅、混雑、パケットロス、接続先の制限、端末の無線電波状況のほうが、暗号方式の違いより大きく影響する場合があります。同じネットワーク・近い時間帯・同じ接続先で、初回表示、継続的なデータ転送、アイドル状態からの復帰をそれぞれ確認すると、ハンドシェイクの影響と安定時のスループットを区別できます。短時間のテスト結果を継続的な速度とみなしたり、複数のタスクを同時に実行した際の使用感を特定のプロトコルのせいにしたりしないでください。

iPhoneやiPadのバッテリー消費には、無線モジュールの起動、バックグラウンドでの再接続、電波状況、画面の明るさ、フォアグラウンドのタスクも影響します。ハンドシェイクが少なくても必ず省電力になるとは限らず、接続を積極的に維持しても必ず消費電力が増えるわけではありません。実際の影響はアクセス頻度やネットワークの切り替えによって変わります。評価するときは使用時間をそろえ、端末の発熱や接続切断の頻度を記録し、アプリの通信とシステムのバックグラウンド処理を区別してください。このマニュアルでは、プロトコル名だけで速度やバッテリー消費の順位を決めません。

設定を整理するときは、動作確認済みの設定を基準として保存し、一度に変更する項目を一つにして、変更理由を記録してください。認証情報、サブスクリプションURL、秘密鍵は機密情報です。公開するスクリーンショットや診断テキストに含めないでください。各プロトコルの項目は、現在のアプリ画面とサーバー側の説明に従ってください。項目が表示されない場合、名前の似た項目で代用してはいけません。システム要件はApp Storeの製品ページに記載された内容をご確認ください。デバイスの対応状況とプロトコルの性能は分けて考えてください。

2. Shadowsocks：共有鍵と暗号方式

Shadowsocksは、比較的軽量なプロキシ転送を目的に設計され、あらかじめ共有したパスワードと暗号方式を使って通信を処理します。証明書チェーンによってサーバーの身元を確認するTLSプロトコルではないため、接続には「パスワードが正しいこと」と「暗号方式が一致すること」が重要です。プロキシプロトコル自体を比較的シンプルに保ち、サーバーの展開、アカウント管理、通信方式の拡張は周辺の実装に委ねています。ユーザーはサーバー側から提供された設定を一式で扱い、アドレスとパスワードだけを保存するのではなく、全項目をそろえてください。

アドレス、ポート、Password、Method

アドレスにはドメイン名またはIPアドレスを指定できます。ドメイン名を正しく解決できることは、接続の前提条件です。ポートはサーバーの接続口を示します。同じアドレスでも、ポートによってパスワードや暗号方式が異なる場合があります。Passwordは一字一句正確に入力してください。コピー時に前後の空白、改行、全角文字が混入していないかも確認します。Methodは暗号化データの処理方法を決めるもので、自由に切り替えられる速度設定ではありません。名称が似ていても、異なる方式を相互に置き換えることはできません。

初期のストリーム暗号方式と、後から登場したAEAD方式では、完全性保護、メッセージ処理、リプレイ防止などに違いがあります。AEADは機密性と認証を同時に処理しますが、特定のアルゴリズム名が含まれていれば現在のサーバーに適しているとは限りません。方式によって鍵の形式が異なる場合もあり、通常のパスワードと同じように扱えないものもあります。読み込み後に長い文字列が表示された場合、それが所定の形式の鍵かを確認してください。自己判断で短縮、再エンコードしたり、覚えやすい文字列に置き換えたりしないでください。

インポート用リンクには通常、タイプ、暗号方式、パスワード、アドレス、ポートが含まれています。リンクが短くまとまっていても、情報を省略してよいわけではありません。まず元の設定で動作確認し、手動で照合する必要がある場合は、アプリに表示される項目を一つずつ比較してください。備考欄の名前はローカルで見分けるためのラベルであり、プロトコルやサーバーの機能を示す根拠にはなりません。サブスクリプション内の名前に通信方式の説明が含まれていても、それだけを根拠に追加の通信設定を有効にしないでください。実際の接続方式は設定項目とサーバー側の説明で確認します。

UDPと追加の通信方式は自動的に互換するわけではありません

リアルタイムの音声・動画通信などUDPを使うサービスでは、クライアントの設定、サーバーの転送機能、中間ネットワークをすべて確認する必要があります。TCPでWebページを開けても、UDP経路が使える証拠にはなりません。追加の通信方式や難読化パラメーターが設定に含まれている場合、それらも双方で合意された設定の一部です。基本プロトコルだけ一致していても、追加設定が欠けると接続後にデータを送受信できない場合があります。追加項目は現在のアプリでサポートされているものを設定し、別の接続方式に属する値を組み合わせないでください。

Shadowsocksの実際のリソース消費は、方式の実装、端末のハードウェア、データ量、接続数によって異なります。軽量なカプセル化で処理負荷を一部抑えられる場合もありますが、電波が弱い環境やパケットロスが多い環境では、無線通信や再送のコストが大きくなることがあります。プロトコルの影響を判断する際は、同じサーバーで利用できる接続方式を比較してください。回線や負荷の異なるサーバー同士の差を、暗号方式の違いと解釈しないようにします。短時間のダウンロード後に端末が熱くなった場合も、主な原因は無線通信やストレージ処理かもしれません。

トラブルシューティングの手順は、アドレスとポートの確認、MethodとPasswordの照合、追加の通信方式の確認、最後にUDPとルーティングの確認に固定できます。以前は使えていたサブスクリプションが突然失敗した場合は、更新で項目が変わっていないか、サーバー情報が現在も有効かを先に確認してください。複数の設定を次々と変更しないでください。サブスクリプションを更新する前に、手動で変更した項目を記録しましょう。更新によって設定が再度書き込まれる場合があります。追加手順を最初から確認する場合ははじめにをご覧ください。この章では設定項目を解説し、操作手順全体は繰り返しません。

3. VMessとVLESS：認証、通信方式、セキュリティのカプセル化

VMessとVLESSはいずれもユーザー識別情報としてUUIDをよく使用しますが、同じプロトコルの切り替え項目ではありません。VMessはプロトコル自体で認証とデータ保護を扱います。一方、VLESSはよりシンプルな構造を採用し、通常は別のセキュリティ通信層と組み合わせます。一方はプロトコル内で多くの役割を担い、もう一方は一部の役割を外側の層に委ねるという、設計上の違いがあります。UUIDを持っていても、両者のタイプをそのまま切り替えられるわけではありません。

UUIDが有効でも、形式が正しいことしか分かりません

UUIDの文字と区切り記号はすべて保持してください。コピー時に引用符、空白、説明文を含めないようにします。形式が正しくても、アカウントの停止、識別情報の不一致、接続先の設定違いなどを理由に、サーバーが接続を拒否することがあります。VMessでは、端末の時刻が正確かどうかも確認してください。大きな時刻のずれが認証に影響する場合があります。自動日時設定にすると、この要因を除外しやすくなります。時刻を直しても失敗する場合は、何度も時刻をリセットするのではなく、サーバー側の設定を引き続き確認してください。

VMessの暗号化に関する設定は、サーバー側の指定どおりに入力してください。外側でTLSを使っているからといって、内側の設定を自己判断で推測してはいけません。古い設定には異なる追加項目が含まれる場合があります。読み込み後は、現在のアプリが実際に認識した内容を確認してください。古い項目がない場合やデフォルト値が表示される場合は、インターネット上で見つけた異なる時期の設定を混ぜず、元の設定とサーバー側の説明に戻って確認します。プロトコルの更新時期やサーバー側の違いは、項目名だけでは判断できません。

通信方式によってプロトコルの接続先への到達方法が変わる

同じプロトコルでも、異なる通信方式でデータを運ぶ場合があります。直接TCP接続、WebSocket、その他の対応方式では、経路、ホスト名、サーバー側の処理に異なる要件があります。WebSocketを使う場合、PathやHostなどの項目がリクエストのルーティングに使われることがあります。パスのスラッシュ、大文字・小文字、文字列を正確に合わせてください。サーバー側が中継プロキシ経由で接続先を振り分けている場合、同じアドレスとポートにつないでも正しいサービスに到達できるとは限りません。

TLSのServer Nameは、ハンドシェイク時のサーバー名表示と関連する身元確認に使われます。一方、通信層のHostは、上位のリクエストを振り分ける目的で使われる場合があります。一部の設定では同じ値になりますが、役割は異なります。一方の値が欠けているからといって、もう一方の値を機械的にコピーしないでください。接続に失敗した際、証明書の検証は優先的に無効化する項目ではありません。ドメイン名の不一致、証明書チェーンの異常、システム時刻のずれを先に確認してください。検証を無効にすると、明確なエラーが気づきにくいリスクへ変わるだけです。

VLESSのシンプルさは、外側のセキュリティを省略できるという意味ではありません

VLESS自体はVMessと同じデータ暗号化の役割を担いません。実際の保護レベルはセキュリティ設定一式によって決まります。既存の設定でTLSなどの対応するセキュリティ項目が指定されている場合は、そのまま一式を使用してください。サーバーによっては特定のFlowや関連するセキュリティ項目が必要です。これらは通信上の動作に関わる値で、単なる備考ではありません。項目の利用可否や組み合わせがサポートされているかは、現在のShadowrocketの画面と既存設定で確認してください。エラーを消すために値をむやみに空欄にしないでください。

iOSでは、初回アクセス時の待ち時間にDNS、外部接続、セキュリティハンドシェイクが含まれることがあります。継続的なデータ転送は、主に経路の品質や混雑に左右されます。カプセル化を追加すると処理が増える場合がありますが、サーバーに正しく接続するために必要なこともあります。アイドル状態の後に遅くなり、連続ダウンロードは正常な場合は、接続の再確立やネットワークの切り替えを確認してください。最初から最後まで遅い場合は、経路とサーバー負荷を比較します。VMessとVLESSのどちらが適しているかは、「シンプル」「暗号化」といった一つの説明ではなく、既存の接続設定一式が正しく一致するかで判断してください。

4. Trojan、HTTP、SOCKS5：セキュリティの境界の違い

TrojanはTLSを重要な外側の層として、自身の認証・転送形式と組み合わせます。一方、HTTPとSOCKS5は汎用プロキシとしてのニーズから生まれ、プロキシサーバーにどの接続先へつなぐかを伝えることを重視します。この3種類をまとめて確認するのは、プロキシ機能とセキュリティ通信経路を区別するためです。接続を転送できても、クライアントからプロキシサーバーまでの通信が暗号化されているとは限りません。選択時はプロキシの種類に加え、既存の接続先で適切なセキュリティ機能を利用できるか確認してください。

Trojan：まずTLS、次にPasswordを確認

Trojanの設定には通常、サーバーアドレス、ポート、Password、TLSのサーバー名に関する情報が必要です。接続アドレスは実際にサーバーへ到達するために使われ、Server NameはTLSハンドシェイクと証明書による身元確認に関係します。両者が同じ場合も、構成によって異なる場合もあります。接続先にIPアドレスを使う場合でも、証明書がそのIPと一致するとは限りません。既存の設定に従ってServer Nameを保持してください。認証が通っても、その後の転送が成功するとは限らないため、接続先への到達性も別途確認します。

証明書に関するエラーは、システム時刻、名前の一致、証明書チェーン、サーバー側の設定を順に確認してください。証明書の検証を無効にするとサーバーの身元確認が弱くなるため、恒久的な対処として残すべきではありません。ローカルネットワークでWebページにログインする必要がある場合は、まずネットワーク側の手続きを済ませてからプロキシをテストしてください。TLSエラー、認証エラー、接続先へのアクセスエラーは発生段階が異なります。実際の違いが日本語の要約で曖昧にならないよう、エラーの原文を記録しておくと役立ちます。

HTTP：CONNECTでトンネルを確立しても、TLSの代わりにはなりません

HTTPプロキシはプロキシリクエストを処理し、CONNECTを使って接続先へのバイトストリームのトンネルを確立することもできます。接続先のWebサイトがHTTPSを使用している場合、通常、アプリと接続先の間でそのサイト自身のTLSが確立されます。ただし、プロキシとのハンドシェイク、認証情報、接続先のメタデータまで、クライアントからプロキシまでの通信で自動的に保護されるわけではありません。暗号化されたプロキシ接続を使えるかは、サーバー側の提供方式とアプリの対応設定で確認してください。接続先URLがHTTPSで始まるかだけでは判断できません。

HTTPプロキシのユーザー名とパスワードは、サーバーへのログイン情報とはまったく異なる場合があります。サーバー側が明示したプロキシ認証情報を使ってください。認証に失敗した場合は、ユーザー名が必要か、特殊文字が含まれているか、インポート時に正しく復元されたかを確認します。プロキシによっては、接続先のポート、リクエスト方式、アカウントの利用範囲に制限があります。その結果、接続は成功しても一部の接続先が拒否されることがあります。この場合、DNSやルールを変更し続けても解決しない可能性があります。まずプロキシのアクセス範囲を確認してください。

SOCKS5：接続先と認証をネゴシエート。UDPには別途条件があります

SOCKS5は接続先とのネゴシエーションを行い、複数の認証方式をサポートできます。プロトコル上はUDP転送の仕組みも定義されていますが、それ自体がデータを暗号化するわけではありません。クライアントが機能に対応していても、現在のサーバーでその機能が有効とは限りません。接続先にドメイン名を指定した場合、名前解決がどこで行われるかは、プロキシへのリクエスト形式とクライアントの処理方法によって異なります。SOCKS5という名称だけで、名前解決がすべてリモート側で行われると判断せず、DNS設定も合わせて確認してください。

SOCKS5のUDP転送には追加の関連付け処理が必要になることが多く、双方の設定と中間ネットワークが該当する通信を許可している必要があります。Webページにはアクセスできてもリアルタイム通信が失敗する場合は、ユーザー名を何度も変更するのではなく、TCPとUDPを分けて確認してください。既存の接続先がローカルネットワークや管理下のネットワーク内で使う通常のプロキシである場合は、そのネットワークの外からもアドレスに到達できるかを確認します。アドレスの到達範囲はサーバーの構成によって決まり、クライアントに設定を保存しただけで広がるものではありません。

これらの接続方式を比較する際は、まず設定の違いを除外してから、ハンドシェイク、接続の再利用、経路の品質を検討します。TrojanのTLSハンドシェイクは短時間の接続で初回の待ち時間に影響する場合があります。通常のプロキシはカプセル化が少なくても、全体として速く、適しているとは限りません。iOSで断続的にアクセスする場合は、接続が安定して復帰することも重要です。特定の接続先だけ失敗する場合は、接続先自体とサーバー側のアクセス制限を確認してください。すべての接続先で失敗する場合は、アドレス、認証、セキュリティ層をあらためて確認します。

5. WireGuard：鍵による識別と第3層トンネル

WireGuardはネットワーク層のトンネルとして設計されており、リクエストごとに接続先をネゴシエートするプロキシプロトコルとは異なります。公開鍵で接続相手を識別し、IPパケットをUDPで転送します。この設計では、識別情報、トンネルアドレス、送信可能なネットワーク範囲が一つの設定として関連します。サーバーアドレスとパスワードだけを使って設定することはできません。サーバーから提供された情報一式が必要です。また、各項目のうちどれがローカル側で、どれがリモート側に属するかを把握してください。

PrivateKeyとPublicKeyの向き

PrivateKeyはローカルの識別に使う秘密情報です。公開したり、見知らぬ診断ページに送信したり、共有するスクリーンショットに含めたりしないでください。接続相手の設定にあるPublicKeyはリモート側を識別します。また、サーバー側にも通常、ローカルのPrivateKeyに対応するPublicKeyを登録する必要があります。ローカルのPrivateKeyを変更しても、サーバー側で認められた識別情報を更新しなければ、設定がそろっているように見えても通信できません。鍵をコピーするときは完全な文字列を保ち、備考や改行を一緒に貼り付けないようにしてください。

設定にPresharedKeyが含まれる場合、双方で共有する追加の情報です。公開鍵と秘密鍵の関係に代わるものではなく、任意の文字列を入力して使うこともできません。見た目が似た文字列でも、鍵項目ごとに用途は異なります。アプリが入力を受け付けたからといって、その情報が正しいとは限りません。形式チェックで分かるのは表記形式であり、リモート側にも対応する設定が存在するかどうかは判断できません。トラブルシューティングでは鍵の対応関係を確認できますが、PrivateKeyの全文を問い合わせ内容に含めないでください。

Address、Endpoint、AllowedIPs

Addressは通常、トンネル内でローカルインターフェースが使うアドレスです。Endpointは、リモート側に接続するためのアドレスとポートを表します。この二つは互換ではありません。トンネルアドレスはサーバーへの接続先ではなく、リモート側の公開アドレスもローカルのトンネルアドレスではありません。サーバーから特定のアドレスが割り当てられている場合は、プレフィックス長も含めて指定どおりに入力してください。空いているように見える別のアドレスに変更すると、サーバー側のルーティングやアクセス制御に影響する場合があります。

WireGuardのAllowedIPsは、対向側とIPアドレス範囲の対応付けに使われ、送信先の選択と受信元の検証にも関係します。Webサイトのドメイン一覧ではなく、Shadowrocketのドメイン別ルールとも異なります。実際にどの通信がこの設定に流れるかは、クライアント側のルーティング処理にもよります。他の環境での全体ルーティングの設定をそのまま適用せず、トンネルで許可する範囲、サーバーの転送機能、現在のGlobal Routingを合わせて確認してください。

MTUと接続維持は根拠をもとに調整する

MTUはトンネル内の1パケットのサイズに影響します。外側のカプセル化には追加の領域が必要で、経路が扱えるパケットサイズも異なる場合があります。値が適切でないと、小さなリクエストは成功しても大きな転送が停止することがあります。ただし、MTUを小さくすることは、あらゆる接続問題に使える解決策ではありません。まずアドレス、鍵、ルーティングの誤りを除外し、再現可能な同じタスクで変更前後を比較してください。複数の設定を同時に変えると、原因を特定しにくくなります。

接続維持は、特定のネットワーク環境でマッピングを保ったり、到達性を確保したりするために使われます。間隔を短くしすぎると、アイドル時の通信や無線の稼働が増える場合があります。設定が必要か、どの値を使うかは、サーバー側の指定と実際のネットワーク状況を参考にしてください。固定値をそのまま使うのは避けましょう。iOSでは、アプリを前面で使用しているとき、画面ロック中、無線ネットワークの切り替え時で動作が異なります。ハンドシェイクが確認できても、トンネル内の接続先に到達できるとは限りません。サーバー側の転送、戻りのルート、DNSも確認してください。各項目を読む順序についてはWireGuardの設定項目ガイドをご覧ください。

6. Hysteria2：QUIC、UDP、輻輳の条件

Hysteria2はQUICとUDPを利用してプロキシ通信を行い、複雑な通信環境でのデータ転送に重点を置いています。QUICはUDP上で安全な接続、信頼性のある転送、多重化などの機能を実現します。そのため「UDPベース」だからといって、すべての通信が信頼性のないデータになるわけではありません。TCPベースの接続方式とは通信の挙動が異なりますが、実際の性能はネットワークがUDPを許可しているか、経路がどの程度混雑しているか、サーバーのリソース、設定値の妥当性にも左右されます。プロトコル名だけで速度を保証することはできません。

性能を比較する前に、UDP経路を確認する

ローカルネットワークでWebページを閲覧できても、指定したサーバーのUDPポートが使えるとは限りません。接続環境によってはUDPが制限されたり、長時間の通信や大量のUDP通信で挙動が変わったりすることがあります。接続先を確立できない場合は、まずアドレス、ポート、ネットワークの状態を確認してください。必要に応じて、信頼できる別のネットワークでも比較します。ネットワークを切り替えて結果が大きく変わる場合は、経路を引き続き調査します。認証文字列や証明書名の変更を優先する必要はありません。

QUICの接続・再送の仕組みは、一部のパケットロスや経路変更に対応できますが、回線の物理的な帯域幅、接続先の混雑、継続的なパケットロスをなくすことはできません。パケットロスが多いと、再送によって無線通信と端末の処理負荷が増える場合があります。フォアグラウンドのタスクが短時間で終わっても、バッテリーへの影響は転送時間とアイドル時の通信を合わせて評価してください。短いメッセージのようなアクセスでは、初回のハンドシェイクと無線の起動が大きく影響する場合があります。長時間の転送では、開始直後のピークではなく、安定時の挙動を確認してください。

認証、TLSのサーバー名、追加設定

Hysteria2の認証情報はサーバー側の設定と一致させてください。パスワードまたは特定形式の認証情報が使われる場合があります。通常のパスワードのように見えるからといって、区切り文字を削除しないでください。TLSに関連するサーバー名も正確に確認し、接続先アドレスと証明書名の役割を区別します。元の設定に特定のセキュリティ項目や追加項目が含まれる場合は、現在のアプリで対応しているかを確認し、完全な状態で読み込んでください。世代の異なるプロトコル設定を名前だけ変えて変換することはできません。

一部のサーバー設定では、追加の難読化パラメーターなどが必要です。これらは速度を上げるための共通設定ではなく、自由に省略できる装飾項目でもありません。サーバー側で必要な設定がクライアントにないと、認証前に正常な通信を確立できない場合があります。読み込み後は元の情報とアプリに表示された値を一つずつ比較し、特殊文字、文字コード、項目名に注意してください。手動入力とサブスクリプションからの読み込みで違いがある場合は、どこで差が生じたのかを確認してから、どちらを使うか決めましょう。

帯域幅の設定値は速度を保証するものではありません

現在の設定で上り、下り、輻輳に関する項目を指定できる場合、その値は送信動作や帯域幅のネゴシエーションに使われることがあります。アカウントに固定の通信能力が割り当てられるわけではありません。上りと下りの方向、単位、サーバー側の制限を確認してください。値を何度も大きくしても、ローカルの無線通信が持つ物理的な容量は増えません。むしろ輻輳、パケットロス、遅延が悪化する場合があります。信頼できる根拠がない場合は、一時的な速度テストのピーク値を入力せず、現在動作している設定を維持してください。

iPhoneのバッテリー消費を評価するときは、一定時間の実際のタスクを確認した後、同じ時間だけ接続をアイドル状態にし、電波状況やネットワーク切り替えの有無を記録してください。バックグラウンドでの接続維持、頻繁な再試行、高負荷のデータ転送はいずれも結果に影響します。サーバーを変えて比較すると、経路の違いも影響します。端末が熱くなった場合は、テストを繰り返さず、条件がそろうまで時間を置いてください。端末の温度やシステムの処理制御が、その後の結果に影響する可能性があります。

利用できるかどうかは、既存の接続環境に基づいて判断してください。サーバーがHysteria2を明示的に提供し、UDP経路が利用でき、認証とTLSの設定がそろっていることがテストの前提です。同じサーバーが別のプロトコルも提供している場合は、動作確認済みの接続設定を比較用に残せます。一度の失敗から、プロトコルが常に使えないと結論付けないでください。一部の接続先だけに問題がある場合は、DNS、ルール、接続先自体を確認します。接続先の確立に成功しても、その後の階層まで確認できたことにはなりません。

7. Global Routing、ルール、DNSの関係

プロトコルの設定はサーバーへの接続方法を定義し、Global Routingはその接続設定をリクエストに適用するかを決めます。両者は異なる階層です。設定・プロキシ・直接接続は、画面上ではConfig / Proxy / Directに対応します。Configは現在の設定ルールに従って通信を処理し、Proxyは選択したプロキシを通常のリクエストに使用し、Directは直接接続します。実際の接続には設定内容、システムの処理、アプリの動作も影響するため、確認時はHomeの状態だけでなく実際のリクエスト記録を見てください。

3つの接続モードで問題の範囲を絞る

Directでは接続先を利用でき、Proxyでは失敗する場合は、選択中のサーバー、プロトコル認証、サーバーから接続先までの経路を優先して確認します。Proxyでは利用でき、Configでは失敗する場合は、現在有効な設定とルールの適用を確認してください。特に、別のポリシーに振り分けられていないか、REJECTされていないかを確認します。3つすべてで失敗する場合は、ローカルネットワーク、接続先サービス、DNSを先に確認してください。この比較は問題を特定するための方法です。すべての用途で特定のモードを使い続けることを意味するものではありません。

複数の設定ファイルを使っている場合は、まず現在有効なファイルを確認してください。無効なファイルを編集しても、使用中のルールは自動的に変わりません。サブスクリプションでサーバー情報を更新しても、ルールファイルが更新されるわけではありません。トラブルシューティングを始める前に、選択中のサーバー、Global Routing、設定名を記録しておくと、独立した3つの変更を混同せずに済みます。確認後は、テスト用に一時変更したモードを、普段必要な状態に戻してください。

ルールの順序と最終ルール

ルールは通常、上から順に照合されます。先に適用されたルールによって、同じリクエストを後続のルールが処理できるかどうかが変わります。DOMAINは完全一致するドメイン、DOMAIN-SUFFIXはドメインとサブドメインの範囲に適しています。IP-CIDRとIP-CIDR6はIPアドレスの範囲、GEOIPはIPアドレスデータベースに基づく判定、FINALは最後に適用するルールです。キーワードを選ぶ前に、照合する対象がドメインかIPアドレスかを確認してください。対象範囲をむやみに広げないようにします。

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

この例はルールの構造と順序を示すもので、既存設定をそのまま置き換えられる完全なファイルではありません。example.comは説明用のドメインです。PROXYとDIRECTは通信の振り分け先を示し、日本語の文字列に置き換えることはできません。GEOIPの判定結果はIPアドレスデータベースと実際の接続先アドレスに依存し、Webサイトの運営主体が所在する地域と一致するとは限りません。FINALは用途に合わせて決め、最後のフォールバック位置に置いてください。変更すると、特定のテスト先だけでなく、それ以前のルールに一致しなかったリクエストにも影響します。

DNSは単独の「速度向上スイッチ」ではありません

DNSはドメイン名をIPアドレスに変換します。リゾルバーの選択、DNSリクエストの経路、返されるアドレスはいずれも、その後の接続に影響します。システムDNS、カスタムリゾルバー、DNS over HTTPSにはそれぞれ異なる利用条件があります。DoHはHTTPSでDNS通信を保護しますが、プロキシ経由かどうか、リゾルバー自体に到達できるか、接続前の通信に依存関係が生じないかは、設定を確認する必要があります。DNSの方式を変更する際は、新しい経路を確立できるか確認し、一度にすべてのDNS項目を変更しないでください。

ドメインルールとIPルールでは、利用する情報の段階が異なる場合があります。ドメイン名でのアクセスだけが失敗する場合、IPアドレスを直接使うテストで確認できるのは経路の一部だけです。証明書名、上位レイヤーのホスト名、接続先サービスには、引き続きドメイン名が必要な場合があります。IPv4とIPv6で結果が異なると、同じ接続先でもネットワークによって動作が変わることがあります。DNSから一度IPアドレスが返されたからといって問題が解決したと判断せず、失敗したリクエストが実際に使ったアドレスの種類とルール処理を確認してください。

DNSを変更しても、既存の接続やキャッシュに以前の結果が一時的に残る場合があります。条件をそろえてアクセスをやり直し、記録を比較してください。サブスクリプションの更新、リゾルバーの切り替え、ルールの変更を同時に行わないでください。どの変更が結果に影響したのか分からなくなります。名前解決経路の選択についてはシステムDNS、カスタムDNS、DoHの解説をご覧ください。用語の意味は用語クイックガイドで確認できます。

8. 用途別の選び方と段階的なトラブルシューティング

プロトコルの選択は、利用可能な設定と実際の用途に基づいて判断してください。サーバー情報が一組だけの場合は、プロトコルタイプを変更するのではなく、まずその設定を正しく使います。利用できる接続方式が複数ある場合は、同じ条件で短いリクエスト、継続的なデータ転送、アイドル状態からの復帰、ネットワーク切り替えを比較し、安定している設定を基準として残してください。用途によって適切な方式は異なります。大きなファイルを転送する場合は安定時のスループット、断続的に閲覧する場合は初回の待ち時間、リアルタイム通信ではUDP、ジッター、継続的な到達性を確認します。

利用シーンを判断するときは、まず制約を確認する

ローカルネットワークでUDPに到達できるか不明な場合は、Hysteria2やWireGuardの性能を評価する前に経路を確認してください。テストが失敗しても、帯域幅の値を上げたり接続維持間隔を短くしたりして、ネットワークの確認を代替しないでください。既存の設定が特定のドメイン名、パス、TLSのサーバー名に依存する場合は、VMess、VLESS、Trojanの設定一式を一致させることを優先します。既存のHTTPまたはSOCKS5接続を利用する場合は、到達可能な範囲、セキュリティのカプセル化、アクセス制限も明確にしてください。

Wi-Fiとモバイル通信を頻繁に切り替える端末では、それぞれのネットワークで個別にテストし、切り替え後に接続が復帰するか確認してください。切り替え時に一時的な切断が起きても、認証情報が無効になったとは限りません。アドレスの名前解決、ネットワーク上のマッピング、既存の接続を再確立する必要がある場合があります。画面ロック後に失敗し、前面では正常な場合は、ロック時間、復帰方法、On Demandの条件が関係しているかを記録してください。オンデマンド接続ルールの動作を、特定のプロトコルがバックグラウンドで利用できない証拠と混同しないでください。

接続できない場合：接続入口から接続先へ順に確認

手順1：ローカルネットワークに正常に接続できることを確認します。必要であれば、ネットワーク側で要求されるWebログインを先に完了してください。手順2：サーバーのアドレス、ポート、プロトコルタイプを確認し、サブスクリプションが更新済みか、設定が現在も有効かを確認します。手順3：認証、セキュリティ層、通信方式の各項目を確認します。Password、UUID、公開鍵の対応、Server Name、Host、Path、追加パラメーターを照合してください。確認できる問題を一つずつ解消し、状態を変えるためだけに複数の設定を同時に切り替えないでください。

手順4：ハンドシェイク、認証、接続先へのアクセスを切り分けます。アプリに表示されたエラーの原文を残し、利用可能なログまたは診断機能で、どの段階で失敗したか確認してください。手順5：Global Routing、ルール、DNSを確認し、複数の接続先で比較します。特定の接続先だけ失敗する場合は、サーバーから接続先までの経路、接続先の制限、名前解決の結果も確認が必要です。すべての接続先で失敗する場合は、共通する前の階層に戻って確認し、Webサイトごとのルールを一つずつ変更する必要はありません。

速度が遅い場合：再現可能なテストを行う

テスト前に、同時に実行している大容量の通信を停止します。同じ接続先と近い長さのタスクを選び、使用ネットワークとサーバーを記録してください。まず直接接続と必要なプロキシ接続を比較し、次に同じサーバーで利用できる接続方式を比較します。Connectivity Testの結果は、そのテスト方法と実施時の条件を示すものです。ダウンロード速度にそのまま換算しないでください。限界まで何度もテストすると、端末の発熱、ネットワークの混雑、バックグラウンド処理の差が生じます。間隔を空けると、結果を判断しやすくなります。

初回の表示だけが遅い場合は、DNS、ハンドシェイク、接続の復帰を重点的に確認します。開始直後は正常で、継続後に遅くなる場合は、輻輳、負荷、端末の温度、経路の変化を調べます。小さなリクエストは成功するのに大容量の転送が停止する場合は、MTUやフラグメントの問題も確認してください。いずれも同じタスクを再実行して確かめます。階層ごとの確認方法とテスト結果の見方は速度低下の段階的な切り分けをご覧ください。一度の数値だけを根拠に、設定をすべて削除しないでください。

基準設定の復元と問い合わせ内容の整理

変更項目が増えた場合は、まず動作確認済みの設定コピーに戻し、必要な変更を一つずつ追加してください。サブスクリプションを更新する前に、手動で変更した項目が上書きされるか確認しましょう。更新後の設定変更を、クライアントがランダムに動作しなくなったと誤解しないようにします。問題を問い合わせる際は、プロトコルの種類、ネットワーク環境、失敗した段階、エラーの原文、再現手順を伝えれば十分です。サブスクリプションの完全なURL、Password、UUID、PrivateKey、アカウントを特定できる情報は削除してください。再現しやすくするために認証情報を公開してはいけません。

このマニュアルはサーバー側の設定説明に代わるものではなく、プロトコル名によって品質を保証するものでもありません。アプリの入手、購入済みアイテムの復元、正規品の確認は正規品の確認をご覧ください。初回起動時のシステム権限については初回起動とVPN構成の許可を、既知の症状についてはよくある質問をご覧ください。問題を解決した後は、「別のプロトコルに変えたら直った」という結論だけでなく、実際に有効だった設定の関係を記録してください。次回の更新やネットワーク切り替え後も、階層ごとに確認できます。