Shadowrocketでカスタムルールを設定するときは、具体的な例外を先に、広範囲に一致するルールを後に記述し、最後にFINALを置きます。利用可能な設定があり、通信の振り分けを調整したい方向けに、まずGlobal Routingと現在のConfigを確認し、例を参考にルールの書式を理解したうえで、新しい接続を作成して実際の判定結果を確かめます。PROXYを使う手順は、ご自身が利用中のサービスとサブスクリプションがあることを前提としています。
1. Configが有効か確認してからルール順をチェック
ルールを保存できても、現在の接続でその設定が使われているとは限りません。まずHomeでGlobal Routingを確認します。この記事のようにルールごとに通信を振り分ける場合はConfigを選び、次にConfigで現在選択中の設定ファイルを確認してください。使用中でない別のファイルを編集しても、現在の設定による判定結果は変わりません。
Global RoutingのProxy、Direct、Config、Sceneはルーティングのモードであり、4種類のルールキーワードではありません。Proxyはすべての通信をプロキシ経由にし、Directはすべての通信を直接接続します。Configでは現在の設定に基づいて通信を振り分けます。Sceneはシーンごとにルーティング動作を設定する機能のため、問題を調べる際は実際のシーン設定も確認してください。ルーティングモードと、ルール行末に指定するポリシーを混同しないようにしましょう。
- Configで現在のファイルのコピーを保存し、使用中の設定名を控えます。
- Home → Global RoutingでConfigを選び、別のモードでルールを確認していないことを確かめます。
- Configに戻り、選択中の設定ファイルを編集して保存したら、テスト用のリクエストを新しく実行します。
- アプリ内の接続ログで接続先とポリシーを確認します。以前の接続が継続している場合は、その接続を終了してから再度テストしてください。
2. 上から順に判定：一致後に、より具体的なルールは探さない
一般的なルールはリストの上から順に確認され、最初に一致したルールのポリシーが適用されます。同じリクエストについて、後続のルールが再判定されることはありません。後ろにあるドメイン名のほうが長くても、Shadowrocketが自動的にそのルールを先頭へ移動することはありません。例外を広範囲なルールより前に置くよう、設定を作成してください。
たとえば、先にDOMAIN-SUFFIX,example.com,PROXYを記述し、その後にDOMAIN,api.example.com,DIRECTを記述すると、api.example.comは先にあるルールにマッチします。このサブドメインを直接接続するには、DOMAINの行を前に移動してください。以下のドメイン名は書式の説明用であり、利用可能なサービスを示すものではありません。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT要点：ルールを重複追加する前に、例外を前へ移動
特定のドメインが想定どおりに振り分けられない場合は、まず上位にそのドメインを含むルールがないか確認してください。リストの末尾に同じ対象のルールを追加しても、先に一致した結果は通常変わりません。
3. ルールの書式：マッチ条件とポリシーを分けて考える
一般的なルールの多くは「タイプ、マッチ値、ポリシー」をカンマで区切って記述します。FINALは例外的なフォールバック用の行で、マッチ値は不要です。半角カンマを使い、1行につきルールを1つ記述してください。設定全体を1つのマッチ値欄に貼り付けないようにしましょう。
| ルールの例 | マッチ対象 | 確認ポイント |
|---|---|---|
DOMAIN,api.example.com,DIRECT | 完全一致するドメイン | そのドメインだけに一致し、すべてのサブドメインが対象になるわけではありません。 |
DOMAIN-SUFFIX,example.com,PROXY | ドメインのサフィックス | example.comとそのサブドメインに一致します。任意の文字列を含むかどうかの判定ではありません。 |
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve | IPv4のネットワーク範囲 | 該当するアドレス範囲に一致します。no-resolveは、このルールのIPマッチングのためにドメインを自動で名前解決しません。 |
GEOIP,CN,DIRECT | IPアドレスの地理的な割り当て | 使用する地理データベースに基づいて判定します。ドメインのサフィックスはIPアドレスの所在地を示すものではありません。 |
FINAL,PROXY | 前のルールに一致しなかったリクエスト | 末尾のフォールバックとして使います。PROXYを指定する場合、利用可能なプロキシの出力先が必要です。 |
ドメインルールには、プロトコルの接頭辞、Webページのパス、ポート番号を記述しません。たとえば、接続先URLにHTTPS、パス、ポート443が含まれていても、DOMAINのマッチ値に記述するのはホスト名だけです。ポートに応じて振り分ける場合は、対応するポートルールを使い、ドメイン名の後ろに:443を付けないでください。
4. DOMAIN-SUFFIX、IP-CIDR、GEOIPの配置順
すべての設定に当てはまる固定のタイプ順はありません。重要なのは、例外をそれに一致する広範囲なルールより前に置くことです。一般的には、まず完全一致するドメインの例外を記述し、次にドメインのサフィックス、明確なネットワーク範囲、より広範囲なGEOIPを置き、最後にFINALを記述します。特定のネットワーク範囲を優先する必要がある場合は、前に置くこともできます。その際は、どのリクエストに一致する可能性があるかを把握しておきましょう。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYこの例は順序を示すものであり、設定全体を置き換えるためのものではありません。api.example.comは直接接続する例外としてサフィックスルールより前に置き、metrics.example.comも拒否する例外として前に置いています。その他のexample.comのサブドメインにはPROXYを適用します。192.168.0.0/16の行が対象とするのは指定されたプライベートネットワークの範囲だけであり、すべてのローカルネットワークアドレスを意味するものではありません。
- ドメイン条件：特定のWebサイトやサブドメインを対象にする場合に適しています。1つのサブドメインを例外にするために、サフィックス全体のポリシーを変更しないようにしましょう。
- IP-CIDR条件：既知のアドレス範囲を指定する場合に適しています。この段階でドメインアクセスからIPアドレスを取得できるかどうかは、名前解決の流れやno-resolveなどのオプションに左右されます。
- GEOIP条件：通常は広範囲に適用され、接続先IPアドレスとデータベースに基づいて判定されます。同じドメインでも名前解決先が異なると、マッチ結果が変わることがあります。
- FINAL条件：すべての具体的な条件の後に配置します。前のルールに一致しなかったリクエストに、このポリシーが適用されます。
no-resolveは、アプリ全体でDNS名前解決を停止するという意味ではありません。また、そのルールがドメインへのリクエストに絶対に一致しないことを保証するものでもありません。制限されるのは、そのIPルールへのマッチングを目的として名前解決を能動的に行う処理です。接続先がもともとIPアドレスの場合や、処理中に利用可能なアドレスが取得済みの場合は、実際のログもあわせて確認してください。
5. FINALにPROXY、DIRECT、REJECTのどれを指定するか
FINALは「まだ分類されていないリクエスト」をどう処理するかを決めるもので、接続に失敗したときの再試行設定ではありません。前のルールでPROXYに一致した場合、プロキシ接続に失敗してもFINALに進むことはありません。予備の出力先が必要な場合は、末尾のフォールバックに失敗した通信を任せるのではなく、該当するポリシーグループの動作を確認してください。
| フォールバックの設定例 | 未一致のリクエストの処理 | 使用前の確認事項 |
|---|---|---|
FINAL,PROXY | プロキシ経由で接続します。 | 利用中のプロキシが使用可能で、直接接続する対象が前のルールに明示されていること。 |
FINAL,DIRECT | 接続先へ直接接続します。 | プロキシが必要な対象は前のルールで指定済みで、それ以外は直接接続してよいこと。 |
FINAL,REJECT | それ以外のリクエストを拒否します。 | 許可する対象を網羅したルールを設定し、ログイン、画像、APIの見落としを調査できること。 |
DIRECTの場合でも、システムが確立したVPNトンネルを通じて通信が処理されることがあります。ただし、出力ポリシーとしてプロキシサーバーを使わないという意味であり、Shadowrocketを終了するわけではありません。REJECTはルールでリクエストを拒否するもので、リクエストが「有用」かどうかを自動判定するものではありません。1つのドメインが複数の機能を担っている場合、ドメイン全体を拒否すると正常な機能にも影響することがあります。
要点：未分類の通信にどう対応するかでフォールバックを選ぶ
まず例外にする対象を明確にし、そのうえで残りのリクエストの処理方法を決めましょう。エラーを一度解消するためだけに、FINALのポリシーを切り替え続けないでください。
6. 変更後の確認と元に戻す方法
接続先、マッチしたルール、出力ポリシーをあわせて確認してください。Webページが開けるかどうかだけでは、設定が正しいとは判断できません。ブラウザーのキャッシュ、既存の長時間接続、ページ内で使われる複数のドメインへのリクエストによって、見た目の動作と新しいルールの適用範囲が一致しないことがあります。
- 変更前の状態を保存：元の設定を保存し、正常にアクセスできる接続先と現在のルーティングモードを控えます。
- 変更範囲を絞る：一度に変更するのはルール1つ、または順序1か所だけにします。保存後、Configでそのファイルが引き続き選択されていることを確認します。
- 新しい接続で確認：テストページを閉じてから開き直します。必要に応じて関連アプリの古い接続を終了し、リクエストを再実行してください。
- ログを確認：アプリ内の接続ログで実際のホスト名またはIPアドレスを探し、マッチしたルールと最終的なポリシーを確認します。Webサイトのメインドメインだけで判断しないでください。
- 変更前の状態に戻す：問題が起きた場合は、直前に追加したルールを取り消すか、保存しておいた設定を再選択し、同じ接続先で再テストします。
設定の取得元がリモートの場合は、更新によってローカルの変更が上書きされていないかも確認してください。サーバーアドレス一覧の更新とConfigのルールファイルの更新は別の操作です。更新対象をそれぞれ確認しましょう。長期的に使うカスタムルールは、ご自身で管理し、必要に応じて元に戻せる設定に保存してください。
7. カスタムルールに関するよくある質問
DIRECTを設定したのに、PROXY経由になるのはなぜ？
まずHome → Global RoutingでConfigが選択されていることを確認し、次にConfigで編集中のファイルが現在使用中のものか確認します。続いて、DIRECTより上に同じ接続先を含むDOMAIN-SUFFIXなどのルールがないか調べてください。具体的な例外を前へ移動し、新しい接続で再テストします。
FINALを先頭に置くとどうなりますか？
FINALがその位置まで到達したリクエストをフォールバックとして処理するため、後に続く具体的なルールが想定どおり機能しなくなります。FINALをルール群の末尾に移動し、明確なフォールバックを1つだけ残してください。その後、上位の条件が特別な処理を必要とする接続先をカバーしているか確認します。
REJECTを追加したら、ログインと画像も一緒に失敗するのはなぜ？
拒否したドメインがログイン、画像、APIのリクエストにも使われていないか確認してください。まず追加したREJECTを取り消して元の状態に戻し、接続ログをもとにマッチ範囲を絞ります。DOMAIN-SUFFIXで拒否されるのはドメイン一式であり、特定のWebページのパスだけではありません。
GEOIPがWebサイトの運営地域に一致しない場合、ルールが機能していないのでしょうか？
必ずしもそうではありません。GEOIPは運営主体の所在地ではなく、データベースに登録されたリクエスト先IPアドレスの地理的な割り当てを判定します。まず実際の名前解決先とマッチした記録を確認してください。特定のドメインを常に同じ方法で処理する必要がある場合は、GEOIPより前に明示的なドメインルールを追加します。