Shadowrocketのルール設定ガイド｜DOMAIN-SUFFIX・GEOIP・FINALの使い方

ルールがルーティングに適用されているか確認する

ルールは接続ごとに使用するポリシーを決めるもので、利用可能なプロキシサービスを作成するものではありません。DOMAIN-SUFFIX,example.com,PROXYと記述しても、利用可能なプロキシ設定が別途必要です。この記事では、利用するサービスとサブスクリプションをすでにお持ちであることを前提に、設定内の[Rule]セクションを確認します。

Home → Global Routingでは、Proxy、Direct、Config、Sceneはそれぞれ異なる動作モードです。ProxyとDirectは一時的な比較テストに使えます。現在の設定にあるルールを検証するときはConfigを選択してください。Sceneは状況に応じてルーティング動作を切り替える機能です。表示がSceneであることだけを根拠に、特定のルールが適用中だと判断することはできません。

1. 設定をバックアップする

   Configを開き、現在使用中の設定ファイルを確認して、まず複製を保存します。テスト後に元の状態へ戻せるよう、現在のGlobal Routingの選択内容も記録してください。

2. ルールモードを選択する

   Home → Global Routing → Configに戻ります。続いて、Configで有効になっているファイルが、編集するファイルと同じであることを確認してください。

3. ルールを1行だけ変更する

   Configで対象ファイルの編集画面を開き、[Rule]を探して、ルールを1行ずつ追加または変更します。ほかの設定セクションはそのまま残してください。

4. 保存後に動作を確認する

   設定を保存してテスト接続を新たに開始し、接続ログで宛先、適用されたルール、使用されたポリシーを確認します。以前の接続が再利用されている場合は、該当ページを閉じてから再度アクセスしてください。

ドメインルール：完全一致・末尾一致・部分一致

一般的なルールは「タイプ、マッチ値、ポリシー」の順に記述し、各項目を半角カンマで区切ります。ドメインのマッチ値にはホスト名だけを指定し、https://、パス、クエリパラメーター、ポートは含めません。https://api.example.com:443/v1にアクセスする場合、ドメインルールの対象はURL全体ではなくapi.example.comです。

DOMAIN-SUFFIXの前にドットを付けたり、*.example.comと記述したりする必要は通常ありません。末尾一致はドメイン自体とそのサブドメインを含みます。通常の末尾一致フィールドにアスタリスクを入れても、意図したワイルドカード表現にはなりません。

DOMAIN-KEYWORDは、部分一致が必要な場合に使います。完全一致のドメインルールを簡略化するためのものではありません。たとえばキーワードexampleは、example-news.testにも一致する可能性があります。1つのサイトとそのサブドメインだけを対象にする場合はDOMAIN-SUFFIX、単一のホストだけを対象にする場合はDOMAINを使います。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

上の例では、api.example.comにはPROXY、www.example.comにはDIRECTが適用され、example-news.testだけがキーワードルールに一致します。これらの予約ドメインは構文の説明用であり、対応するWebページへのアクセスを保証するものではありません。

IP-CIDRとGEOIP：URLではなくIPアドレスに一致

IP-CIDRはIPv4アドレスの範囲に一致します。192.168.0.0/16は、192.168.0.0から192.168.255.255までのアドレス範囲を表します。単一のIPv4アドレスは/32で指定できます。ここでのプレフィックス長はネットワークの範囲を表し、ポート番号ではありません。

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,203.0.113.8/32,PROXY,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

例にある203.0.113.8は文書用のサンプルアドレスであり、利用可能なサービスのアドレスではありません。no-resolveは、このIPルールに一致させる目的だけでドメイン名を積極的に名前解決しないことを示します。アプリ全体でDNSが停止するという意味でも、このルールを通るすべてのリクエストで名前解決が不要になるという意味でもありません。宛先アドレスがすでに利用可能であれば、引き続きアドレスとの照合が行われます。

GEOIPの結果は、IP地理情報データベースに依存します。CDN、DNSの応答、ネットワーク環境の変化によって、同じドメインでも異なるIPアドレスに解決されることがあります。そのため、同じドメインのGEOIP判定が変わる場合があります。宛先に常に特定のポリシーを適用したい場合は、IPの地域情報だけに頼らず、通常はGEOIPより前にドメインルールを明示してください。

上から順に照合し、FINALは最後に配置する

この記事で扱う一般的なルールでは、各接続は記述順に照合され、最初に一致したルールのポリシーが適用されます。「より細かく見える」次のルールを探し続けることはありません。ルールの種類自体に自動的な優先順位はありません。広い範囲を対象とするDOMAIN-SUFFIXの後ろに完全一致のDOMAINを置くと、そのルールが適用される機会を失うことがあります。

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

• 例外を先に記述：api.example.comはexample.com配下で個別に扱うホストなので、末尾一致ルールより前に配置します。
• 次に対象範囲を記述：残りのexample.comとそのサブドメインにはDIRECTを適用します。以降のIP判定には進みません。
• 最後にフォールバックを記述：FINAL,PROXYで、どのルールにも一致しなかった接続を処理します。これを先頭に移動すると、後続の一般ルールが一致する機会を失います。

DIRECTは宛先に直接接続することを示しますが、システムのネットワーク条件をすべて回避するという意味ではありません。PROXYはプロキシ経由の接続を指定しますが、接続の成功を保証するものではありません。ポリシー欄にカスタムポリシーグループ名を指定する場合、その名前は設定内に定義されたものと完全に一致する必要があります。この記事では、未定義のグループ名を持ち込まないようDIRECTとPROXYのみを使用します。

ルールが適用されないときは、マッチ判定と接続を分けて確認する

「Webページが開かない」だけでは、ルールの記述ミスとは断定できません。まずリクエストが想定したルールに一致しているかを確認し、次にそのポリシーで接続を確立できるかを確認します。適用ログにPROXYと表示されているのにリクエストが失敗する場合は、すでに設定しているプロキシサービスと接続パラメーターを確認してください。同じ種類のドメインルールを追加しても、通常は通信上の問題は解決しません。

1. Home → Global Routing → Configになっていることと、編集中のファイルがConfigで現在有効なファイルと一致することを確認します。
2. 同じ完全なURLで新しいリクエストを行い、実際のホスト名を記録します。ページ遷移、画像、APIでは異なるドメインが使われることがあるため、個別に確認してください。
3. 適用対象の行より前にあるDOMAIN-SUFFIX、DOMAIN-KEYWORD、FINALによって処理が決まっていないか確認します。
4. 正しいルールに一致している場合は、ProxyとDirectでのアクセス結果を一時的に比較し、テスト後にConfigへ戻します。一度に変更する条件は1つだけにしてください。

以下のエラー識別子はAppleのネットワークエラー体系に基づくもので、診断情報に該当する原文が実際に表示された場合にのみ参照してください。ネットワークリクエストが失敗した種類を示すものであり、Shadowrocketのルールパーサーの構文エラーではありません。エラーコードだけで問題の発生箇所を特定することもできません。

よくある記述ミスには、全角カンマの使用、FINAL,PROXYを3フィールド形式で記述すること、https://example.comをDOMAIN-SUFFIXに指定すること、未定義のポリシーグループ名の使用などもあります。保存前に各行のフィールドを照合し、設定ファイル全体を一括置換しないでください。リモートの配信元が設定を管理している場合は、次回の更新でローカルの変更が上書きされないかを確認し、復元できるコピーを保管してください。

よくある質問：ルールを1行変更したあとに結果を確認する方法

最終確認では、リクエスト先の実際のホスト名、適用されたルール行、使用されたポリシーの3点が正しいことを確認します。その後、ページやAPIへのリクエストが完了するか検証してください。これにより、「ルールの選択ミス」と「選択した経路が利用できない状態」を分けて対処でき、手当たり次第に切り替えて試す必要がなくなります。