Shadowrocket 設定を詳しく解説

Shadowrocketの主要設定は4つの層に分けて考えられます。第1層はGlobal Routingで、通信全体をConfig、Proxy、Directのどれで処理するかを決めます。第2層はConfig内のルールとポリシーで、Config時にリクエストを順番に判定します。第3層はユーザーが用意した購読またはサーバー情報、DNS、On Demandなどの接続条件です。第4層はData、Connectivity Test、Diagnosticsで、実際の結果を確認します。この順序で理解すると、全体の設定が適切でないままDNSやサーバーパラメータを何度も変更することを避けられます。

日常の多くの場面では、まずConfigを使い、ルールにPROXY、DIRECT、REJECTを選ばせる方法が適しています。サーバーが接続を確立できるか一時的に確認するときは、ルールの影響を減らすため短時間だけProxyに切り替えます。ローカルネットワーク自体が正常か確認するときは、Directで比較します。テスト後は目的に合う設定へ戻し、ページの表示、ルールのマッチ、DNSの名前解決を改めて確認してください。

概要：Global Routingは接続前に確認する最も重要な入口で、通信をConfigのルールで判定するか、選択中のサーバーを一律に通すか、ローカルネットワークへ直接送るかを決めます。3つのモードはConfig、Proxy、Directと表示されます。

場所：HomeでGlobal Routingを開きます。切り替え後のリクエストは、新しいモードに従って処理されます。問題を調べるときは、モードを変更した後にテストページを再読み込みし、ブラウザのキャッシュや既存の接続が判断に影響しないようにしてください。

設定方法：日常利用ではConfigを選び、使用中のConfigが想定したファイルか確認します。ページを開けない場合は、現在のモードを記録してからDirectとProxyで順に比較します。Directでもアクセスできない場合は、まずローカルネットワークまたは対象アドレスを確認します。Proxyでアクセスでき、Configで失敗する場合は、ルールの順序、ポリシーの対応付け、FINALを重点的に確認します。Proxyも失敗する場合は、現在のサーバー情報とDNSを確認してください。

注意点：Global Routingは全体の処理モードを示すだけで、特定のサーバーが利用できることや、特定のルールが必ずマッチすることを意味しません。切り替えるたびにData、ログ、Diagnosticsで結果を確認してください。確認が終わったら元の設定に戻し、テスト用のProxyやDirectのままにしないよう注意します。

概要：ルール分流は、Global RoutingでConfigを選択したとき、リクエストのドメイン、IPアドレス、その他の特徴に応じてPROXY、DIRECT、REJECT、カスタムポリシーのいずれを使うか決める仕組みです。ルールは記載順に確認され、通常は最初に適用されたルールにマッチした時点で判定が止まります。そのため「ルールの内容が正しい」だけでなく、「どこに置くか」も重要です。

場所：Configから現在の設定ファイルを開き、Rulesまたは対応するルール編集画面を確認します。Configの構成は提供元によって異なる場合がありますが、ルールキーワードと対象ポリシーは一つずつ確認してください。変更前に元のConfigを保存しておくと、結果が想定外だった場合に戻せます。

設定方法：まず範囲が明確で特殊なルールを前に置き、その後に対象範囲の広いルールを置き、最後にFINALで未マッチの通信を受けます。たとえば、特定の完全なドメインをDIRECTにし、メインドメイン全体をPROXYにする場合、完全なDOMAINをDOMAIN-SUFFIXより前に置きます。ポリシー名はConfigに存在するものと一致させてください。大文字・小文字、句読点、カンマの位置も正しく保つ必要があります。

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

注意点：上記のアドレスは構文の例にすぎません。ルールが機能していないように見える場合は、まずGlobal RoutingがConfigになっているか確認し、さらに前のルールがすでにマッチしていないか調べます。ドメインはDNS名前解決後にIP系ルールで判定されることもあります。IPv6を有効にしたネットワークではIP-CIDR6も確認してください。REJECTはマッチした通信を明示的に遮断するため、追加前に対象を確認し、必要なページリソースまで妨げないようにします。

概要：Shadowrocketでは、ユーザーが保有する購読情報や個別のサーバー情報を保存できます。Subscribeは同じ提供元が管理する複数のサーバー記録に適しており、Add Serverは明確な設定を1件手入力する場合に使います。Scan QR CodeとImport from Cloud JSONは、既存の情報を取り込むための入口です。対応する設定にはShadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2などが含まれる場合がありますが、実際に接続できるかはプロトコルパラメータとサーバー側の設定が一致するかに左右されます。

場所：Homeのサーバー一覧から追加メニューを開くと、Add Server、Subscribe、Scan QR Code、Import from Cloud JSONなどの入口が表示されます。既存の項目は通常開いて編集できるため、SERVER、ポート、パスワード、プロトコルの追加パラメータ、メモを確認します。使用するのは、ユーザー自身が保有し、利用する権限を持つ情報に限ってください。

設定方法：取り込む前に情報の種類を確認します。購読URLはSubscribeに入力し、個別のSERVERアドレスとして扱わないでください。単一サーバーの場合は対応するプロトコルを選び、SERVER、ポート、認証項目を順に入力します。取り込み後は複数のパラメータをすぐに同時変更せず、まず1件を選んでConnectivity Testを実行し、その後接続を試します。失敗した場合は元の情報と一文字ずつ照合し、特にプロトコル、ポート、通信方式、TLS関連の名称、認証情報を確認します。

注意点：購読の更新では通常、提供元の内容に従って項目が更新されます。購読管理中の項目を手動で変更しても、次回更新で上書きされる場合があります。古い項目を削除する前に、Configやポリシーグループがその名前を参照していないか確認してください。Connectivity Testは接続確認の一部にすぎません。到達できても、すべての対象が想定どおり分流されるとは限らないため、Global Routing、Rules、DNSと併せて検証します。

概要：On Demandはネットワーク条件をトリガーとして接続動作を実行し、Wi-Fiやモバイル通信の変化に応じて、あらかじめ設定したルールで自動処理する場合に適しています。On Demandが解決するのは「いつ接続するか」であり、Global RoutingとConfigが決めるのは「接続後に通信をどう処理するか」です。両者は異なる層の機能です。

場所：SettingsでOn Demandを開き、有効化の状態とネットワーク条件を設定します。初めて使う前に、手動モードで現在のサーバー、Global Routing、Configが正常に動作することを確認してください。その後に自動条件を追加すると、「基本設定の問題」と「トリガー条件の問題」を分けて調べられます。

設定方法：最初は、モバイル通信と既知のWi-Fiを区別するだけなど、単純な条件から始めます。保存後にネットワークを切り替え、システムの状態とShadowrocketの接続状態が想定どおり変化するか確認します。条件が多い場合は一度に1つだけ追加し、すぐに検証してください。互いに重なる条件を複数設定する場合は、優先関係によって想定と反対の結果にならないか確認します。

注意点：On Demandのトリガーはシステムのネットワーク状態の変化で動作するため、一時的な切り替え中の状態をサーバー障害と誤認しないでください。Wi-Fi名の変化、認証未完了、モバイル通信とWi-Fiの素早い切り替えにより、接続状態が一時的に変わることがあります。調査時はまずOn Demandを無効にして手動接続に切り替えます。手動接続が正常になったら、トリガー条件を1つずつ戻します。

概要：Dataでは、Shadowrocketが処理した通信記録と使用量の概要を確認できます。一定時間に継続的な送受信があったか、どの接続が多くの通信を消費したか、ルールやサーバーの切り替え後に通信の挙動が変化したかを判断する補助になります。これはローカルで確認するための機能であり、サーバー品質やサービスの請求結果を単独で推定するものではありません。

場所：アプリ下部または対応する入口からDataを開きます。統計を見る前に、現在の接続モードとテスト時間帯を記録します。続いて、指定したページを開く、1回ダウンロードを実行するなど、明確な操作を行ってからDataに戻って変化を比較します。バックグラウンド動作が大量に混在した累計データより、結果を判断しやすくなります。

設定方法：2つの設定を比較する場合は、まずバックグラウンド動作が安定するまで待ち、似たネットワーク条件でそれぞれテストします。1回のテストでは、Global Routingだけ、Configだけ、サーバーだけを変更するなど、変数を1つに絞ってください。アップロード・ダウンロードの方向、開始時刻、操作内容を記録すると、システム同期、メディアの先読み、アプリのバックグラウンド通信を対象の通信と取り違えにくくなります。

注意点：Dataの通信にはシステムや他のアプリのバックグラウンドリクエストが含まれる場合があり、数値もサーバー側の集計方法と異なることがあります。短時間に大きな変化がなくても、ルールが機能していないとは限りません。一部の接続は既存のセッションを再利用します。特定のルールを判断するときは、Dataをログ、Diagnostics、実際のアクセス結果と併用してください。

Settingsの項目は、名前解決、テスト方法、ショートカット、設定同期に影響します。変更前に元の値を記録し、完了後は同じ対象で再テストしてください。複数項目を一度に変更すると手順は減りますが、異常発生時に原因を特定しにくくなります。

概要：Diagnosticsは、現在のネットワーク、DNS、接続、リクエスト処理の過程にある手がかりを確認するための機能です。Connectivity Testは、サーバーや対象への到達性を簡易確認することに重点があります。どちらも障害範囲を絞るのに役立ちますが、最終的には実際のアクセス結果で確認してください。

場所：Diagnosticsは通常Settingsまたはツールエリアにあり、Connectivity Testはサーバー管理関連の入口から実行できます。開始前にネットワーク種別、Global Routing、Config名、選択中のサーバーを記録し、テスト中に複数の条件を切り替えないようにします。

設定方法：まずDirectでローカルネットワークを確認し、次にProxyで現在のサーバーを確認し、最後にConfigへ戻ってルールを検証します。問題がドメイン名前解決に集中している場合はDNS関連の結果を確認します。接続タイムアウトの場合はSERVER、ポート、プロトコル、認証パラメータを照合します。特定のサイトだけが異常な場合は、対応するDOMAIN、DOMAIN-SUFFIX、GEOIP、IP-CIDR、FINALのマッチ関係を調べます。

注意点：診断情報にはサーバーアドレス、ドメイン、ネットワーク環境の詳細が含まれる場合があります。保存または共有する前に内容を確認し、問題解決に必要な部分だけを残してください。調査中にネットワーク、サーバー、ルールを頻繁に切り替えないでください。毎回1つの変数だけを変更すると、結果と具体的な設定を対応付けられます。

1. 現在の環境を記録する。

   使用中のWi-Fiまたはモバイル通信、Global Routingのモード、Config名、現在のサーバーを書き留めます。初期状態を記録していないと、どの変更が影響したのか判断しにくくなります。

2. ローカルネットワークを確認する。

   一時的にDirectを選び、正常にアクセスできることが分かっているページを開きます。Directでも失敗する場合は、まずネットワーク認証、電波状況、DNSなどの基本的な問題に対処します。

3. サーバー接続を確認する。

   Proxyに切り替え、現在の項目でConnectivity Testを実行し、実際にアクセスします。失敗した場合はSERVER、ポート、プロトコル、認証情報を順に照合します。

4. Configに戻してルールを確認する。

   対象ドメインにマッチする可能性がある最初のルールを確認し、ポリシー名が存在することとFINALを確認します。ルールファイルに対象ドメインがあるかだけでなく、その前にあるルールも調べてください。

5. DNSとIPv6を確認する。

   他の接続は正常でドメインだけに異常がある場合は、DNS設定とキャッシュを再確認します。ネットワークでIPv6を有効にしている場合は、IP-CIDR6と対象が返すアドレス種別も確認してください。

6. 最後に自動機能を戻す。

   基本接続が安定してから、On Demand、Today Widget、iCloud同期を有効にします。1つずつ戻して検証すると、自動トリガーや同期の変化が主要な接続調査を妨げるのを防げます。