Shadowrocketのルールでは、マッチ対象・記述順・実行ポリシーをそれぞれ確認する必要があります。利用中のサービスと設定があり、振り分けルールを変更したい方向けに、まずConfigでルールによる振り分けを有効にし、ドメインルールとIPルールを区別したうえで、最後にFINALで未一致の接続を処理する方法を説明します。例は構文の解説用で、接続に使える認証情報は含みません。
まずConfigを確認：ルール適用の前提
設定内のルールに従って振り分けるには、Home → Global RoutingでConfigを選び、Config画面で編集対象の設定が選択されていることを確認します。ファイルを保存しただけで選択していない場合や、Global RoutingがProxyまたはDirectのままでは、その設定どおりに振り分けられるか検証できません。
- Configを開いて現在使用中の設定を確認します。編集前にコピーを残し、既存の設定を直接上書きしないようにしましょう。
- 設定の編集画面を開き、
[Rule]を探します。この記事のコードはルールセクションに記述し、Homeのサーバーアドレス欄には貼り付けないでください。 - Home → Global Routingに戻ってConfigを選び、既存のプロキシ接続自体が使えることも確認します。
- 変更を保存したら、対象へのリクエストを新たに実行します。接続ログで対象・マッチしたルール・最終的なポリシーを確認し、Homeの接続スイッチだけで判断しないでください。
Proxyは対象の接続をプロキシ経由にし、Directは直接接続します。Sceneを使っている場合は、そのシーンで適用される設定も確認してください。この記事の検証手順ではConfigに統一し、シーンの切り替えとルール変更が混同しないようにしています。Settings → On Demandは条件に応じて接続を開始する機能で、ドメインがどのルールにマッチするかを決めるものではありません。
ルール構文の読み方：マッチ条件と実行ポリシーを分けて考える
一般的なルールは、ルールタイプ・マッチ条件・実行ポリシーを英語のカンマで区切って記述します。ルールタイプは「何を調べるか」、実行ポリシーは「マッチした接続をどう処理するか」を示します。同じドメイン条件でも異なるポリシーを指定できるため、DOMAIN-SUFFIXを「自動的にプロキシ接続するルール」と考えてはいけません。
[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,REJECT
GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY上記は6種類の構文を示す例で、そのまま有効にするための完全な設定ではありません。たとえば1行目では、example.comは後続のPROXYではなく、先にDIRECTにマッチします。FINALにはドメインやネットワーク範囲のパラメーターがないため、FINAL,PROXYと記述します。3つ目のフィールドを埋めるために空欄を追加してはいけません。
| ポリシー | マッチした場合の動作 | 確認すること |
|---|---|---|
PROXY | プロキシ経由で接続します。 | 現在選択中のプロキシと、その接続パラメーターが使用可能か。 |
DIRECT | 対象に直接接続します。 | 現在のネットワークから対象に直接アクセスできるか。 |
REJECT | マッチした接続を拒否します。 | マッチ範囲が広すぎないか、ページに必要なリソースまで遮断していないか。 |
ルールでカスタムポリシーグループを参照する場合は、名前が設定内の定義と一致していることを確認し、グループ内で実際に選択されている項目も確認します。PROXYは特定のプロトコルを指すものではありません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardは接続設定で選ぶプロトコルであり、ルールのマッチ条件の代わりにはなりません。
DOMAIN・DOMAIN-SUFFIX・DOMAIN-KEYWORDの違い
完全一致する1つのドメインにはDOMAIN、親ドメインとそのサブドメインにはDOMAIN-SUFFIXを使います。ドメイン内の文字列で検索する必要がある場合に限り、DOMAIN-KEYWORDを使います。よくある誤りは、ドメイン欄に完全なURLを書くことや、サフィックスマッチを末尾の数文字だけで判定することです。
| ルール | マッチする | マッチしない |
|---|---|---|
DOMAIN,example.com,DIRECT | example.com | www.example.com |
DOMAIN-SUFFIX,example.com,PROXY | example.com、img.example.com | notexample.com、example.com.test |
DOMAIN-KEYWORD,example,REJECT | example.com、myexample.com | sample.test |
DOMAIN-SUFFIXはドメイン階層の境界を考慮してマッチします。例ではフィールドにexample.comと記述すればよく、*.を付ける必要はありません。DOMAIN-KEYWORDは階層の境界を考慮しないため、exampleは異なる組織のドメインにも含まれる場合があります。REJECTと組み合わせる場合は特に、範囲を絞ってください。
- ドメイン欄には
https://を付けず、ページのパスやクエリパラメーターも記述しません。 https://example.com/docsとhttps://example.com/accountにアクセスした場合、この3種類のドメインルールから見えるドメインは同じです。パスごとに振り分けることはできません。- 通常のドメインルールでは、接続先ポートが80か443かによってマッチ範囲は変わりません。ポートはDOMAIN-SUFFIXの3つ目のフィールドではありません。
- リクエストに接続先IPだけが含まれ、利用できるドメイン情報がない場合、ドメインルールでサイト名を自動的に特定することはできません。
GEOIPとIP-CIDR：サイト名ではなく接続先IPで判定
GEOIPはIPアドレスの地理的な割り当て情報を使って接続先を判定し、IP-CIDRは指定されたアドレス範囲で判定します。どちらもページ内の文字、サイトの登録情報、ドメインの末尾を調べるものではありません。中国語でサービスを提供するサイトでも、接続先IPがGEOIPでCNと判定されるとは限りません。同じドメインでも、ネットワークによって異なるIPアドレスに解決される場合があります。
GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
IP-CIDR,198.51.100.8/32,REJECT
FINAL,PROXYここで使う192.0.2.0/24と198.51.100.8/32は説明用のアドレスであり、接続先として使えるサーバーアドレスではありません。/24は先頭24ビットがネットワークプレフィックスであることを示し、この例では192.0.2.0から192.0.2.255までが対象です。IPv4の/32は1つのアドレスだけを示します。IPv6の範囲には対応するIP-CIDR6タイプを使い、IPv4の例をそのまま流用しないでください。
IPルールの末尾にno-resolveを付ける目的は、そのIPルールのために能動的な名前解決を行わないことです。すべてのDNSを無効にする設定ではありません。ドメインしかなく、利用できる接続先IPがない場合は、このルールがスキップされ、後続のルールに判定が進むことがあります。最初の最小テストでは、このオプションを同時に追加せず、マッチ条件を混乱させないようにしてください。
FINALとルールの順序：先にマッチしたルールを実行し、具体的なルールが自動で優先されるわけではない
この記事で扱う通常ルールは、上から順に確認し、最初にマッチしたルールのポリシーを実行します。DOMAINはDOMAIN-SUFFIXより具体的だからといって、前にあるルールを自動的に飛び越えることはありません。FINALは、それ以前の条件にマッチしなかった接続を処理するフォールバックなので、ルール一覧の末尾に置きます。
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTこの最小構成の例では、account.example.comは直接接続し、example.comとそのほかのサブドメインはPROXYを使います。それ以外の未マッチの接続先はDIRECTになります。上の2行を入れ替えると、account.example.comは先にサフィックスルールにマッチするため、後ろのDOMAINの例外では接続先を決められません。
FINALは「プロキシ接続に失敗したら直接接続に切り替える」ためのフォールバックでもありません。上にあるPROXYにマッチした接続がタイムアウトしても、一覧の後ろに戻ってFINALが実行されるわけではありません。未マッチの通信のデフォルト動作を変える場合はFINALのポリシーを変更します。プロキシが使えない場合は、接続パラメーターまたは既存のポリシーグループの選択を確認してください。
- 特定のドメインに対する例外は、そのドメインを含むサフィックスルールより前に置きます。
- 広い範囲にマッチするDOMAIN-KEYWORDやGEOIPルールが、後続の個別ルールより先に適用されないか確認します。
- REJECTは配置した場所でマッチした接続を遮断する可能性があります。広すぎるキーワードを、精密なブロック条件として使わないでください。
- FINALより後ろに、適用したい通常ルールを追加しないでください。ルールを追加するときは、まずフォールバック行の位置を確認します。
保存後の確認方法：一度に変更する条件は1つ
検証では、まず「ルールにマッチしたか」、次に「マッチ後の接続に成功したか」を確認します。ブラウザーでページが開けないからといって、ルール構文の誤りとは限りません。ページが表示されても、すべてのリソースが同じポリシーで接続されたとは限りません。1つのページからメインドメイン、画像用ドメイン、API用ドメインへのリクエストが発生することがあるため、それぞれ確認してください。
- Configで上記の最小構成を保存して選択し、Home → Global RoutingでConfigになっていることを確認します。
- まず、既存の設定でプロキシに接続できることを確認します。基本接続に失敗する場合は、先にアドレス・ポート・認証情報・プロトコル関連のパラメーターを確認してください。
- 古いリクエストを終了してからテスト対象に再アクセスし、再利用中の接続を使って新しいルールを判定しないようにします。
- アプリの接続ログで、実際の接続先・マッチしたルール・ポリシーを確認します。テストするドメインには、実際にアクセスする必要があるものを使ってください。この記事に記載したドメインは構文の説明用です。
- メインページは表示されるのに画像が失敗する場合は、画像リクエストに使われたドメインを特定します。そのうえでDOMAINとDOMAIN-SUFFIXのどちらを追加するか判断し、曖昧なキーワードルールに範囲を広げるのは避けてください。
- 変更前後の結果を記録し、1回につき1つのルールだけを変更します。確認が終わったら、段階的に元の設定へ反映してください。
以下の2種類は接続レイヤーのエラーで、特定のルールに固有の構文エラーではありません。具体的な表示内容には、システムやプロトコルの情報が含まれる場合があります。まずログで実際に適用された出力ポリシーを確認し、該当する接続を調べてください。エラーを見ただけでFINALを削除しないでください。
エラー：Connection refused
原因と対処：接続先のポートで接続が拒否されています。該当するサービスが待ち受けていないか、ポートの設定が合っていない可能性があります。まずログでDIRECTとPROXYのどちらが適用されたか確認します。DIRECTなら接続先サービスのポートを、PROXYなら既存プロキシのアドレス・ポート・稼働状態を確認してください。
エラー：Connection timed out
原因と対処：待機時間内に接続が完了しませんでした。ネットワークの到達性や外向き接続が関係している可能性があります。同じ設定でほかの接続先を確認してから、該当リクエストにマッチしたルールとポリシーを調べてください。タイムアウトだけを根拠に、ドメインルールをIPルールに変更しないでください。
よくある質問：ルールが正しいのに期待どおり動かない
DOMAIN-SUFFIXを追加したのに、なぜ直接接続されるのですか？
Home → Global RoutingでConfigが選択されていることを確認し、次にConfigで編集した設定が現在選択中か確認します。その後、サフィックスルールより前にDOMAIN、DOMAIN-KEYWORDなど、先にマッチするルールがないか確認し、接続を再実行してログを調べてください。
特定のサイトだけをプロキシ経由にする場合、FINALはどう設定すればよいですか？
プロキシ経由にしたいドメインをDOMAIN-SUFFIX,example.com,PROXYと記述し、末尾にFINAL,DIRECTを指定します。実際に使うときは、例のドメインを対象のドメインに置き換え、ページの表示に必要なほかのドメインも追加してください。ページ内のすべてのリソースに対するルールが自動生成されるわけではありません。
GEOIP,CN,DIRECTを一番上に置いてもよいですか？
構文上は可能ですが、先にマッチしたGEOIPが、PROXYを必須にしたい接続にも適用される可能性があります。特定のドメインを必ずPROXY経由にする場合は、通常、そのドメインの明示的なルールを先に置き、次にGEOIP、最後にFINALを配置します。実際の接続ログで結果を確認してください。
Homeに登録済みのサブスクリプションを更新すると、振り分けルールも変更されますか？
サーバーのサブスクリプションとConfig内の設定ファイルは区別が必要です。サーバーのサブスクリプションを更新すると、主に接続先の項目が更新されます。現在の設定内のルールまで同期して変更されたとは限りません。更新後はHomeで接続先の選択を、Configでルールの内容をそれぞれ確認し、編集内容のコピーも残してください。
REJECTを追加したらページが真っ白になりました。プロキシの不具合ですか？
まず、読み込めなかったリソースがREJECTにマッチしていないか確認します。APIやスクリプトを誤って遮断している場合は、必要なドメインの例外を広範囲の拒否ルールより前に置くか、拒否範囲を絞ってください。REJECTは接続を明示的に拒否する設定です。接続失敗を根拠にプロキシの可否を判断しないでください。
ルールでできること：出力先の選択であり、サービスの補完ではない
ルールで接続方法をDIRECT、PROXY、REJECTから選べますが、利用可能なプロキシサービスを生成したり、整合していないプロトコル設定を修正したりすることはできません。PROXYにマッチした後も既存の接続設定が必要です。DIRECTにマッチした場合も、現在のネットワークや接続先サービスの状態に左右されます。「ルールが正しくマッチしたか」と「接続に成功したか」は分けて確認してください。
- マッチ条件：ドメインまたはIPが条件を満たすか、ルールの順序が正しいか確認します。
- ポリシー：ルールが参照するポリシーやポリシーグループ、および現在の選択を確認します。
- 接続：実際の外向き接続に必要なアドレス・ポート・認証情報・プロトコルパラメーターを確認します。
- 設定の管理：サブスクリプションやリモート設定の更新後は選択状態を再確認し、変更前の設定に対する検証結果をそのまま当てはめないようにします。
Shadowrocketは主にiPhoneとiPadで利用できます。入手先はApp Storeです。システム要件はApp Storeの製品ページをご確認ください。アプリの買い切り購入に回線プランは含まれません。この記事では、利用するサービスと設定をすでにお持ちであることを前提にしています。ルールの構成はルールマニュアルで確認できます。初期設定はチュートリアルに沿って進めてください。