機能への進み方と設定の考え方
このページでは、実際の操作順に沿って Global Routing、ルール、Subscribe、On Demand、Data、Settings を解説します。各項目について「何か」「どこにあるか」「どう設定するか」「何に注意するか」を説明しており、App Store からのインストールを済ませ、既存の設定を整理したいユーザーに適しています。
このページのインポート手順は、ユーザー自身が用意した Subscribe またはサーバー情報を前提としています。Shadowrocket の購入で得られるのはクライアントの利用権であり、クライアントの買い切り購入 ≠ 通信回線のプランです。アプリの入手方法、システム要件、対応デバイスは、App Store の製品ページの記載に従ってください。
01 / GLOBAL ROUTING
Global Routing は、接続確立後のネットワーク要求をルールで判定するか、すべて Proxy に渡すか、直接接続するかを決めます。これは全体の処理モードであり、個別のルールやサーバー選択を置き換えるものではありません。普段使う前に、選択中のサーバーが利用可能であることを確認し、目的に合ったモードを選択してください。
| 日本語での呼び方 | 画面上の表記 | 処理方法 | 適した場面 | 主な注意点 |
|---|---|---|---|---|
| Config | Config |
現在の Config にあるルールを上から順に照合し、該当するポリシーで処理します。 | ドメイン、アドレス、地域ごとに PROXY、DIRECT、REJECT を使い分ける場合。 | 結果は、ルールの順序、内容、ポリシー名、現在の Config が有効かどうかに左右されます。 |
| Proxy | Proxy |
要求をすべて現在選択中の Proxy に渡すため、ルールの違いを切り分けて検証できます。 | 問題がルールに起因するか一時的に確認するとき、または短時間だけ要求を一律に処理したいとき。 | 細かなルールの意図を迂回するため、すべての設定問題に対する最終的な解決策には適しません。 |
| Direct | Direct |
要求を Direct で処理し、選択中の Proxy を経由しません。 | ローカルネットワークが正常か確認するとき、または接続経路の違いを一時的に検証するとき。 | Direct は正常で Config に問題がある場合は、ルール、DNS、サーバーの状態を引き続き確認してください。 |
Home で Global Routing を開くと、Config、Proxy、Direct の3つのモードを確認できます。Config はルールに従う方式、Proxy は現在の Proxy を一律に使う方式、Direct は直接接続する方式です。切り替えても現在の処理モードが変わるだけで、Config ファイルが自動編集されたり、別のサーバーが選択されたりすることはありません。
長期的にルールに従って使う場合は、通常まず Config で設定を確認し、その後 Home に戻って Config を選びます。Config で特定のサイトに問題がある場合は、Proxy と Direct に一時的に切り替えて個別に検証できます。3つの結果の違いから、問題がルール、サーバー、ローカルネットワークのどこにあるかを判断しやすくなります。
02 / RULES
ルールによる振り分けの基本は「上から順に照合し、最初に一致したルールで停止」です。ルールの左側は照合条件、末尾は処理方法を示します。通常は現在の Config の Rule セクションに記載されているため、キーワード、照合値、ポリシー名、並び順を同時に確認してください。
DOMAIN は完全なドメイン名、DOMAIN-SUFFIX はドメインのサフィックスとサブドメイン、DOMAIN-KEYWORD はドメイン内のキーワードに基づいて照合します。IP-CIDR と IP-CIDR6 はアドレス範囲を処理し、GEOIP はアドレスの帰属情報で判定し、USER-AGENT は要求内の識別情報に基づいて照合します。種類ごとに用途が異なるため、名前が似ているだけで置き換えないでください。
ドメインルールは通常、範囲の広い GEOIP や FINAL より前に配置します。具体的な条件を先に置かないと、前の広範なルールが先に一致し、後続の詳細ルールが実行されない場合があります。編集後は保存し、いま有効になっている Config が編集したものか確認してください。
PROXY、DIRECT、REJECT は代表的なポリシーです。PROXY は指定したポリシーまたは現在のプロキシ経路に要求を渡し、DIRECT は直接接続し、REJECT は要求を拒否します。ルール末尾にカスタムポリシーグループ名を指定している場合、その名前は Config 内の定義と一致していなければなりません。綴り、大文字・小文字、名称が一致しないと、想定外の結果になることがあります。
FINAL はフォールバックルールで、ルール一覧の末尾に置きます。前のルールに一致しなかったすべての要求を処理します。トラブルシューティングでは、まず対象の要求がどのルールに一致したかを確認し、そのルールのポリシーを確認してください。FINAL だけを見て判断しないことが重要です。ルールを追加した後は、少数の明確なドメインで検証し、一度に変更しすぎないようにしてください。
03 / SUBSCRIBE
Subscribe は、ユーザー自身が用意した購読情報を読み込み、サーバー一覧を更新するために使います。Add Server、Scan QR Code、Import from Cloud JSON は、異なる方法で既存の情報を追加するための機能です。インポートはデータをクライアントに書き込むだけで、実際に利用できるかどうかは情報自体、ネットワーク状態、サーバー側の設定に左右されます。
Home からサーバー一覧を開くと、Add Server で手入力できるほか、既存の情報に応じて Subscribe、Scan QR Code、Import from Cloud JSON を選べます。手動追加では、プロトコルの種類、サーバーアドレス、ポート、認証情報、追加パラメータを元の情報と一致させてください。代表的なプロトコルには Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2 があります。
Subscribe を使う場合は、まずリンクが完全か確認してから保存し、更新を実行します。更新後は一覧に想定どおりの変化があるか確認し、いずれかを選んで Connectivity Test を実行してください。テスト結果はその時点の接続性を示す参考情報であり、継続的な利用状態を単独で保証するものではありません。
購読の更新によって、サーバー名、並び順、既存の項目が変わることがあります。更新前に現在選択中の項目を記録し、更新後に Home の選択状態を確認してください。一覧に変化がない場合は、リンクが完全か、現在のネットワークからそのアドレスにアクセスできるか、購読がまだ有効か、クライアントに明確なエラーが表示されていないかを順に確認します。
複数の情報源を同時に使う場合は、判別しやすいグループ名やメモを付け、同名項目の誤選択を避けてください。古い項目を削除する前に、ポリシーグループや Config から参照されていないか確認します。サーバー情報には機密性の高い項目が含まれるため、Diagnostics、スクリーンショット、設定の一部を共有する前に、アドレス、認証情報、完全な購読リンクを削除してください。
04 / ON DEMAND
On Demand は、設定したネットワーク条件に応じて接続するかどうかを決める機能です。発動条件と例外条件を明確に把握している場合に適しています。有効にする前に手動接続を一度テストし、通常の接続でサーバー、Global Routing、ルール、DNS が正常に動作することを確認してください。
Settings から On Demand を開き、画面に表示されるネットワーク条件に従ってルールを追加します。利用できる条件は現在のアプリ画面の表示に従ってください。まずは検証しやすい単一の条件から始め、保存後に対応するネットワークへ一度切り替えてシステムの接続状態を確認し、その後ほかの条件を少しずつ追加します。これにより、発動条件に一致していないのか、接続確立後にネットワーク問題が起きているのかを切り分けられます。
On Demand は「いつ接続を試みるか」を決め、Global Routing は「接続後に要求をどう処理するか」を決めます。両者の役割は異なります。Global Routing を変更しても On Demand の条件は自動的に変わらず、On Demand が正常に発動しても、現在のルール、DNS、サーバーが利用可能だとは限りません。
05 / DATA
Data は、Shadowrocket が記録した通信情報を確認するために使います。どの接続でデータが発生したか、現在のセッションで通信が続いているか、統計期間ごとにどう変化しているかを確認する際に役立ちます。これはクライアント側の確認機能であり、サービスの請求や通信事業者の課金情報として直接扱うものではありません。
アプリの Data から統計画面を開いたら、まず表示されている集計範囲と時間帯を確認し、アップロードとダウンロードを比較します。接続を確立したのに通信量が変わらない場合は、対象アプリが要求を発生させているか、システム接続が維持されているか、ルールが想定したポリシーに要求を渡しているかも確認してください。通信量が増えたことだけで、対象コンテンツが完全に読み込まれたとは判断できません。
特定の異常を調べる場合は、まず開始時刻を記録し、問題を一度再現してから Data と Diagnostics を照合します。累計値を眺めるよりも原因を特定しやすくなります。消去やリセットを行う場合は、先に残すべき情報を記録してください。具体的な消去場所と集計方法は、現在の画面に表示される文言に従います。
06 / SETTINGS
Settings には、DNS、Test Method、Today Widget、iCloud、Diagnostics などの項目がまとめられています。これらは名前解決、テスト、システム上の入口、同期、トラブルシューティングの方法に影響します。変更前に元の状態を記録し、一度に1種類だけ変更して、同じネットワーク条件で再テストしてください。
何をする設定か：DNS はドメイン名をネットワークアドレスに変換します。解決結果はその後のドメインルール、アドレスルール、接続先に影響するため、DNS の異常はドメインを開けない、一部の要求がタイムアウトする、同じアドレスでもネットワークによって結果が異なるといった形で現れます。
場所と設定方法：Settings から DNS 関連の項目を開き、現在の Config の General セクションに別の DNS 設定がないかも確認します。出所が明確で説明可能な設定を1系統に保ち、矛盾する複数の名前解決設定を同時に重ねないでください。変更後は、ドメインへのアクセスと直接アドレスへの接続を分けてテストします。
注意点：Direct ではアクセスできるのに Config で異常がある場合、またはサーバーテストには成功するのにドメインへアクセスできない場合は、DNS とルールの関係を重点的に確認します。Wi-Fi とモバイル通信で結果が異なる場合も、それぞれの名前解決の結果を記録してから判断してください。
何をする設定か：Test Method は、Connectivity Test で接続性を判定する方法を決めます。テスト値は特定のテスト対象と方法における応答を示すもので、アプリの読み込み、動画通信、長時間接続の完全な利用感を表すものではありません。
場所と設定方法：Settings で Test Method を開き、現在の画面に表示される方法を選択します。複数のサーバーを比較する場合は、同じ Test Method、同じネットワーク、近い時間帯で実施し、テスト条件の違いをサーバーの差と取り違えないようにします。
注意点：1回のタイムアウトだけで結論を出さないでください。再テストし、実際のアクセス、Data、Diagnostics と併せて判断します。すべてのサーバーで同時に異常が起きている場合は、サーバーパラメータを個別に変更する前に、ローカルネットワーク、DNS、購読情報を確認してください。
何をする設定か：Today Widget はシステムウィジェットに関する入口で、システムが許可する場所から Shadowrocket が提供する簡易情報や操作を確認するために使います。利用できる内容は、システムとアプリの画面表示に従ってください。
場所と設定方法：まず Settings で Today Widget 関連の項目を確認し、次にシステムのウィジェット編集画面で Shadowrocket を追加します。追加後、ウィジェットが現在の状態を読み取れるか、タップしたときに想定した画面が開くかを確認してください。
注意点：ウィジェットの表示はシステムの更新タイミングに左右されるため、短時間更新されないだけで接続失敗と判断しないでください。リアルタイムの状態を確認するときは、Shadowrocket の Home、Data、またはシステムの接続状態に戻って確認します。
何をする設定か：iCloud 関連機能は、条件を満たす Apple デバイス間でアプリデータを保存または同期するために使います。移行や復元に適していますが、同期結果はデバイスのサインイン状態、iCloud の利用状況、アプリが現在提供している同期範囲に左右されます。
場所と設定方法：Settings で iCloud の項目を確認し、デバイスが想定した Apple アカウントを使っていることを確認します。有効にする前に重複サーバーと古い設定を整理し、別のデバイスで同期が完了したら、Config、サーバー名、現在の選択項目を確認してください。両方が完全に一致すると決めつけないことが重要です。
注意点：同期の競合が起きた場合は、出所が明確で新しいデータを先に残し、項目ごとに照合します。設定にはサーバーアドレスや認証情報が含まれる場合があるため、機密データとして管理し、同期内容全体を公開ページにそのまま掲載しないでください。
何をする設定か：Diagnostics は、接続、名前解決、要求処理の過程で診断情報を収集します。失敗がどの層で発生しているかを特定するための機能であり、設定を自動的に修正するものではありません。
場所と設定方法：Settings から Diagnostics を開き、問題を再現する前に時刻、ネットワークの種類、Global Routing のモード、現在のサーバーを記録します。その後、対象の問題を一度だけ再現し、前後の時間帯にあるエラー、DNS の結果、ルール処理の情報を確認します。
注意点：診断内容を共有する前に、完全な購読アドレス、サーバーアドレス、認証情報、デバイス識別子、問題と無関係なアクセス履歴を削除してください。診断中の変更は最小限にし、1項目を変更するたびに再現することで、設定と結果の対応関係を確認できます。
07 / WORKFLOW
推奨する順序は、まずローカルネットワークを確認し、次にサーバー情報を確認してから Global Routing を検証し、その後ルールと DNS を確認し、最後に On Demand、Today Widget、iCloud などの補助機能を有効にすることです。各段階を終えるたびに、明確なテストを1回行ってください。
Subscribe リンクまたはサーバー項目が完全で、プロトコルの種類が元の情報と一致していることを確認します。
対象サーバーを選び、同じ Test Method で Connectivity Test を実行します。
まず Config でテストし、Proxy と Direct を使ってルールとローカルネットワークの問題を切り分けます。
最初に一致したルールを探し、ポリシー、FINAL の位置、DNS 設定の出所を確認します。
手動接続が安定してから On Demand を設定し、単一の発動条件から検証を始めます。
Data と Diagnostics を使い、時刻、ネットワーク、モード、実際の結果を記録します。