この記事は、iPhoneまたはiPadでShadowrocketを使い、自分のサーバー情報やサブスクリプションを持っているものの、ルールがマッチする理由や機能しない原因がわからない方を対象としています。まずGlobal Routingと現在のConfigを確認し、ドメインマッチ、IPマッチ、FINALによるフォールバックを区別しましょう。読み終えると、最小限のルール例を作成し、リクエスト記録から実際の接続先を確認できるようになります。例示用のドメインと予約済みアドレスは説明のためのものであり、接続サービスを提供するものではありません。
1. ルールが適用される前提：Global Routingと現在のConfig
Shadowrocketのルールはサーバー一覧ではありません。Homeで選択したサーバーはプロキシ接続の出口を決め、Configにはルールなどの設定が含まれます。自分のサブスクリプションを読み込んだり更新したりしても、意図したルール設定に切り替わったとは限りません。問題を調べる前に、この2つをそれぞれ確認してください。
HomeでGlobal Routingを確認します。この記事では、Configを選択し、現在の設定に基づいてリクエストを1つずつ判定する場合を扱います。ProxyとDirectは全体に適用されるルーティング方式です。その結果だけで、個別のConfigルールがマッチしたとは判断できません。Sceneは選択したシーンの設定に従って動作するため、Configと同じものとして扱わないでください。
| 設定項目 | 確認内容 | この記事でのテスト方法 |
|---|---|---|
Config | 現在のConfigに従ってルールを振り分けます。 | この項目を選び、現在のConfigが正しいか確認します。 |
Proxy | 全体にプロキシルーティングを適用します。 | 出口に関する問題の切り分けに使えますが、個別ルールの検証にはなりません。 |
Direct | 全体に直接接続のルーティングを適用します。 | 直接接続時の挙動と比較し、テスト後はConfigに戻します。 |
Scene | シーンの設定に応じて動作します。 | まずシーン設定を確認します。ルールの初回テストではConfigに切り替えてください。 |
2. ルールの構文と順序：最初にマッチしたルールを適用
一般的なルールは、英語のキーワード、マッチ対象、ポリシーで構成され、各フィールドは半角カンマで区切ります。FINALにはマッチ対象がないため、主なフィールドはキーワードとポリシーの2つです。DIRECTは直接接続を意味します。以下の例で使うPROXYはプロキシ経由の接続を意味し、使用前に現在選択中のプロキシが有効であることを確認してください。カスタムポリシーグループ名を指定する場合は、Config内にその名前が存在している必要があります。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYこれは構文を説明するための例であり、そのまま接続に使える完全なConfigではありません。Shadowrocketはルールを上から順に確認し、条件に合うルールが見つかると、そのポリシーを適用して評価を終了します。より具体的なルールを探し続けることはありません。そのため、条件が細かいルールでも、自動的に広いルールより優先されるわけではありません。
上の例で、login.example.comを含むリクエストは1行目にマッチするため、DIRECTになります。DOMAIN-SUFFIXをDOMAINより前に置くと、login.example.comは先にサフィックスルールにマッチしてPROXYに振り分けられ、後続の完全一致ルールは適用されません。
- 優先したい少数の例外（特定のログインドメインなど）を先に置きます。
- ドメイン全体とそのサブドメインを対象にする一般ルールは、例外の後に置きます。
- 範囲の広いキーワードやIPの地域判定が、後続ルールを先に拾わないか確認します。
- FINALはマッチ対象となるすべてのルールの後に置き、その下に有効な例外を追加しないでください。
3. DOMAIN・DOMAIN-SUFFIX・DOMAIN-KEYWORDの違い
この3種類のキーワードはいずれもドメインを対象としますが、マッチ範囲が異なります。ルールに指定するのはホスト名またはキーワードであり、URL全体ではありません。https://、ページのパス、クエリパラメーター、ポート番号は付けないでください。login.example.comの443番ポートにアクセスする場合も、DOMAINのマッチ対象をlogin.example.com:443とは書きません。
| ルール例 | マッチする対象 | マッチしない対象 |
|---|---|---|
DOMAIN,example.com,DIRECT | example.com | www.example.com、example.com.test |
DOMAIN-SUFFIX,example.com,PROXY | example.com、www.example.com、a.b.example.com | notexample.com、example.com.test |
DOMAIN-KEYWORD,example,PROXY | example.com、myexample.test、example.net | exampleを含まないドメイン |
DOMAIN：1つの完全なホスト名だけを対象
api.example.comとwww.example.comを別々に扱う場合は、DOMAINを使うとわかりやすくなります。サブドメインは自動的に含まれないため、DOMAIN,example.com,DIRECTでapi.example.comまで処理されることはありません。アプリのルールを作る際は、ログイン、API、画像など複数のホスト名にアクセスする可能性にも注意してください。トップページのドメインだけで、すべてのリクエストの接続先を判断することはできません。
DOMAIN-SUFFIX：ドメイン階層に沿ってまとめて指定
DOMAIN-SUFFIX,example.com,PROXYは、ルートドメインとその下のすべての階層のサブドメインにマッチします。ワイルドカードを追加する必要はありません。任意の文字列の末尾を探すルールではないため、notexample.comは末尾に同じ文字列を含んでいてもドメイン階層の境界がなく、example.comのサブドメインには該当しません。
DOMAIN-KEYWORD：文字列を含むドメインを広く対象にする
DOMAIN-KEYWORDは、キーワードが特定のドメイン階層にあることを求めません。特定の文字列を含む複数のドメインをまとめて対象にしたい場合に使えますが、意図しないマッチも起こりやすくなります。たとえばexampleはmyexample.testにもマッチします。example.comのドメイン群だけを対象にするなら、範囲の広いキーワードではなくDOMAIN-SUFFIXを優先してください。
4. GEOIPとIP-CIDR：宛先アドレスを照合
GEOIPは、IPアドレスがデータベース上でどの地域に分類されているかを判定します。GEOIP,CN,DIRECTは、宛先IPがデータベースでCNに分類された場合にDIRECTを適用するという意味です。ウェブサイトの言語、ドメインの登録地、ユーザーの所在地を調べるものではなく、特定ブランドのサービスが常に同じ地域のIPアドレスを使うことを保証するものでもありません。
IP-CIDRは、特定のIPv4ネットワーク範囲を対象にします。IP-CIDR,192.0.2.0/24,DIRECTは、192.0.2.0から192.0.2.255までにマッチします。/24はネットワークプレフィックスが先頭24ビットであることを示し、ポート番号ではありません。192.0.2.0/24は文書作成用に予約されたアドレス範囲です。ここではマッチの説明にのみ使用しており、利用可能なサーバーではありません。
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYIPルールの前にドメイン解決が必要かどうかで、確認手順が変わります。オプションのno-resolveは、このIPルールのためだけにドメイン解決を開始しないことを示します。宛先IPがすでにわかっていれば、アドレスで判定できます。これは「DNSを無効にする」という意味ではなく、以後ウェブサイトの名前解決が不要になるわけでもありません。宛先IPがわからない場合、そのルールはスキップされ、後続のルールで判定されることがあります。
- ドメインの例外を優先：ドメイン単位で処理したいサービスには、該当するDOMAINまたはDOMAIN-SUFFIXを範囲の広いGEOIPより前に置くのが一般的です。
- データベースの分類はサービスの分類ではない：CDNのアドレス、名前解決の結果、IPアドレスデータベース上の分類などがGEOIPの判定に影響することがあります。実際の宛先IPを確認してください。
- アドレスファミリーを分けて確認：IP-CIDRのIPv4範囲はIPv6をカバーしません。IPv6アドレスには、対応するIP-CIDR6ルールを別途使用してください。
- ポート番号とCIDRは別の情報：宛先ポート443とネットワーク範囲/24は異なる項目です。IP-CIDRのアドレス欄にポート番号を付けないでください。
5. FINALを必ず最後に置く理由
FINALはフォールバックルールです。前のルールに1つもマッチしなかった場合、FINALで指定したポリシーが適用されます。ドメインやネットワーク範囲による制限がないため、途中に置くと、そこまで到達したリクエストをすべて処理し、下にあるルールは判定されません。「最後」とは、現在の編集画面で最後に見える部分ではなく、有効なルール全体の末尾を指します。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYFINAL,PROXYとFINAL,DIRECTは、どちらも明示的にフォールバック先を指定する方法で、誰にでも当てはまる正解はありません。前者は未分類のリクエストをプロキシに渡し、後者は直接接続します。前者を使うなら有効なプロキシ出口が必要です。後者を使うなら、宛先が不明なリクエストも直接接続されることを理解してください。変更前に、ウェブページが開くかどうかだけで判断せず、自分の用途を確認しましょう。
「ルールを細かく書いたのに、なぜマッチしない？」
そのルールより上にDOMAIN-SUFFIX、DOMAIN-KEYWORD、FINALがないか確認してください。優先したいDOMAINの例外を広い範囲のルールより前に移動し、接続をやり直して確認します。
「FINALの後にルールを追加できますか？」
テキストとして追加することはできますが、FINALが処理したリクエストには適用されません。追加したルールをFINALより前に移動し、最後にフォールバックルールを1つ置いてください。
「FINALをDIRECTに変えれば解決しますか？」
必ずしも解決するとは限りません。利用できないプロキシ出口を避けただけの可能性があります。Homeに戻って現在のサーバーを確認し、対象のドメインをより具体的なルールで処理すべきかも確認してください。
「サブスクリプションを更新すると、ルールも更新されますか？」
サーバーのサブスクリプション更新とルール設定の更新は別の操作です。まずConfigで現在の設定を確認し、更新されたのがサーバー一覧かConfigファイルかを確認してください。一覧の更新が成功したことを、ルールも更新された証拠と見なさないでください。
6. 最小限の検証手順：一度に変更するルールは1つだけ
検証では「想定するポリシー」と「実際のリクエスト」を両方記録します。ウェブページが開いたことからわかるのは、あるリクエストが成功したということだけで、DIRECTとPROXYのどちらを通ったかは判断できません。以下の手順では、自分のサブスクリプションを変更したり、プロトコルのパラメーターを調整したりする必要はありません。Shadowsocks、VMess、VLESSなどの出口プロトコルとルールキーワードは、別のレイヤーの設定です。
-
元のConfigを保持
Configで現在の設定を確認し、編集前に復元できるコピーまたは元のテキストを保存します。元のFINALポリシーを記録し、唯一使えるConfigをそのまま上書きしないでください。
-
ルーティング方式を確認
Home → Global RoutingでConfigを選択し、Configに戻って、テストするConfigが有効になっていることを確認します。同じ名前の別ConfigやリモートConfigを選んでいないかも確認してください。
-
特定ドメインの例外を追加
現在のConfigのルール部分で、自分で確認できる実際の宛先に対するDOMAINルールを追加し、広い範囲のルールとFINALより前に置きます。この記事のexample.comは構文の説明用であり、プロキシ接続のテスト先ではありません。
-
リクエストをやり直す
保存してConfigが有効になったことを確認したら、対象アプリの既存の接続を終了し、新しいリクエストを送信します。接続の再利用や出口の変更が判定に影響しないよう、Homeで選択したサーバーは変えないでください。
-
リクエスト記録を確認
リクエスト記録またはログで、ホスト名、宛先IP、マッチしたルール、実際に適用されたポリシーを確認します。表示される項目はアプリの画面に従ってください。記録が足りない場合は必要な記録機能を有効にして、同じリクエストを再試行します。応答時間だけで接続先を推測しないでください。
7. ルールがマッチしても接続できない場合：エラーの発生箇所を切り分ける
ルールが決めるのは接続先の振り分けであり、宛先、DNS、プロキシサーバーが常に利用できることを保証するものではありません。リクエスト記録で想定どおりのルールにマッチしている場合は、その後の接続処理を確認してください。以下はネットワーク診断で見られることがあるエラーメッセージであり、ルール構文のエラーを示すものではありません。表示内容はエラーが発生したレイヤーによって異なるため、1行のメッセージだけでルールの問題と決めつけないでください。
エラー：Connection refused
原因：接続先のいずれかのエンドポイントが接続を拒否しています。宛先ポートまたはプロキシサーバーのポートでサービスが待ち受けていない可能性があります。
対処：まず記録で接続先のアドレスとポートを確認します。次にHomeで該当サーバーのポートが、自分の持つサーバー情報と一致しているか確認してください。宛先側で失敗している場合は、ドメインルールを広げるのではなく、宛先サービスを確認します。
エラー：Operation timed out
原因：処理が制限時間内に完了しませんでした。ネットワーク経路、プロキシ接続、宛先の応答などが関係している可能性があり、タイムアウトだけでは原因箇所を特定できません。
対処：エラーの前後にある接続記録から発生段階を特定します。Home → Global Routingで一時的にProxyまたはDirectに切り替えて比較し、完了後はConfigに戻してください。テスト対象は同じものを使います。
エラー：No route to host
原因：接続に使用されたネットワーク経路から宛先アドレスに到達できません。DOMAINやFINALのフィールドの記述ミスとは限りません。
対処：現在のネットワークが利用可能か、実際の宛先IPとアドレスファミリーが想定どおりか確認します。続いて、リクエストがDIRECTとプロキシ出口のどちらを通ったかを確認し、該当する経路を調べてください。
ドメイン解決の段階で失敗した場合は、まずDNSリクエストが成功しているか確認します。サーバー認証に失敗した場合は、自分のサーバーパラメーターを確認してください。すべてのリクエストをDIRECTに変更して問題を隠したり、1つのエラーを直すためにルール全体を書き換えたりしないでください。比較条件を保つことで、修正が本当に有効か判断できます。
- Configの確認：Home → Global RoutingがConfigに設定され、Configで正しいファイルが有効になっている。
- 構文の確認：半角カンマを使い、ドメイン欄にURLのパスを含めず、ポリシー名が有効である。
- 順序の確認：範囲の狭い例外を広い範囲のルールより前に置き、FINALを有効なルール列の最後に置く。
- 結果の確認：新しいリクエストのホスト名、宛先IP、実際のポリシーが想定どおりである。ウェブページが開くだけでは不十分。