Shadowrocketはルールを上から順に確認し、最初に一致したルールで振り分けます。FINALは、それまでのルールに一致しなかったリクエストを処理します。この記事は、iPhone / iPadでShadowrocketを使い、自分で用意したサービスと設定があり、Configを編集する方を対象としています。Mac、Windows、Android、Linuxでもマッチングの仕組みは参考になりますが、編集画面は各プラットフォームの現行UIを確認してください。読み終えると、6種類の条件を見分け、例外とデフォルトを含むルールを記述し、新しい接続で結果を確認できるようになります。
1. ルールの構造とGlobal Routingの前提
ルールは接続パラメーターではなく、アプリ名から用途を自動判定する一覧でもありません。リクエストで利用できるドメイン名や接続先IPなどを参照し、適用するポリシーを選びます。設定ファイルのルールで振り分けるには、iPhone / iPadのHome → Global RoutingでConfigを選択します。Configファイルだけを編集してProxyやDirectのままでは、この記事の想定どおりにルールを確認できません。
[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.org,PROXY
FINAL,DIRECT多くの条件ルールは「タイプ、マッチする値、ポリシー」の3項目で構成され、半角カンマで区切ります。FINALにはマッチする値がないため、2項目で記述します。DIRECTは直接接続、PROXYはプロキシ経由を表します。この欄に自分が用意したサーバーのアドレスやパスワードを書くわけではありません。設定内のカスタムポリシー名を指定する場合は、実際の定義と同じ名前を使います。
要点：デフォルトの振り分けを決めてから例外を書く
まず、条件に一致しないリクエストをDIRECTとPROXYのどちらにするか決め、対応するFINALを末尾に置きます。その上に対象が明確な例外を追加してください。デフォルトのポリシーを明示する代わりに、キーワードルールを大量に並べるのは避けましょう。
- Config：現在有効な設定のルールに従って振り分けます。この記事の手順ではConfigの選択が前提です。
- Proxy：すべての通信をプロキシ経由にするモードです。特定のDIRECTルールが適用されるかの確認には使いません。
- Direct：すべての通信を直接接続するモードです。特定のPROXYルールが適用されるかの確認には使いません。
- Scene：設定した条件に応じて切り替わります。問題を調べる際は、Sceneで最終的に使用される設定とポリシーも確認してください。
2. DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDの違い
3種類のドメインルールは、マッチする範囲が異なります。DOMAINはドメイン名全体が一致した場合に適用されます。DOMAIN-SUFFIXは指定したドメインと、その配下のサブドメインに一致します。DOMAIN-KEYWORDはドメイン名に指定した文字列が含まれる場合に適用されます。いずれもURLのパスは判定しないため、同じドメイン内のページを区別する目的で/video/を追加しても機能しません。
| 記述例 | 一致する対象 | 一致しない対象 |
|---|---|---|
DOMAIN,example.com,DIRECT |
example.com |
www.example.com |
DOMAIN-SUFFIX,example.com,PROXY |
example.com、cdn.example.com |
notexample.com、example.com.other.test |
DOMAIN-KEYWORD,example,PROXY |
example.com、notexample.net |
sample.test |
たとえば、example.com全体をプロキシ経由にしつつ、ログイン用ホストだけ直接接続するには、完全一致の例外を先に書き、その後にサフィックスルールを記述します。DOMAIN-SUFFIXを*.example.comと書く必要はありません。サブドメインの範囲指定にアスタリスクは不要です。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTこの設定では、login.example.comは1行目に一致するため、2行目の判定には進みません。img.example.comは1行目には一致せず、2行目に一致します。2行を逆にすると、サフィックスルールが先に適用され、完全一致の例外が機能しなくなります。「具体的なルールを優先する」とは、編集者が順序を決めるという意味であり、システムが自動的にルールを並べ替えるわけではありません。
3. GEOIPとIP-CIDR：接続先アドレスによる条件
GEOIPは、使用する地理情報データベースに登録された接続先IPの情報をもとに判定します。GEOIP,CN,DIRECTは、データベース上でCNに分類された接続先IPにDIRECTを適用する指定です。端末の所在地やドメインの末尾による判定ではありません。ドメインが分散環境で運用されている場合、名前解決の結果が異なる地域のIPになることがあり、ルールの結果も変わる可能性があります。
[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYIP-CIDRはアドレス範囲で判定します。192.168.0.0/16は192.168.0.0から192.168.255.255まで、10.0.0.0/8は10.0.0.0から10.255.255.255までを対象とします。この2行は一部のプライベートIPv4アドレス範囲の例であり、ローカルネットワーク向けルールを網羅したものではありません。
| 条件 | 必要な情報 | 確認ポイント |
|---|---|---|
GEOIP,CN,DIRECT | 接続先IPと地理情報データベースの登録内容 | データベースの登録内容は、現在の物理的な所在地を証明するものではありません。 |
IP-CIDR,192.168.0.0/16,DIRECT | 接続先のIPv4アドレス | 実際の接続先が指定したプレフィックス範囲内か確認します。 |
no-resolve | ルール判定時に利用できる接続先IP | このIPルールのためだけにドメインの名前解決を追加で発生させないようにします。 |
no-resolveは「すべてのDNS問い合わせを禁止する」指定でも、「常に直接接続する」設定でもありません。リクエストにドメイン名しかなく、利用可能なIPがまだない場合、このオプション付きのIPルールはマッチングのためにドメインを能動的に名前解決しません。そのため、後続のルールへ進むことがあります。IPv6アドレス範囲には対応するIP-CIDR6ルールを使います。IPv6プレフィックスを上記のIPv4例にそのまま当てはめることはできません。
- 特定のプライベートネットワーク内アドレスを直接接続する場合は、実際のアドレスを確認してから適切なIP-CIDR範囲を指定します。
- 特定のドメインに指定したポリシーを適用する場合は、現在どの地域のIPに名前解決されるかに依存せず、ドメインルールを使います。
- IPルールが適用されない場合は、接続先アドレス、アドレスファミリー、名前解決のタイミング、先行ルールへの一致を確認します。
4. FINALの位置とルール全体の例
FINALは条件なしで適用されるフォールバックルールのため、ルール一覧の末尾に置く必要があります。途中に置くと、それ以降に正しい条件を記述しても、FINALが先に処理したリクエストには適用されません。FINALにDIRECTとPROXYのどちらを指定するかは、デフォルトのルーティングポリシーによって異なり、すべての設定に共通する正解はありません。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example-cdn,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY以下は、この記事で扱う6種類の構文例です。サーバーやポリシーグループの定義は含まれず、そのまま接続できる完全な設定でもありません。例示ドメインは構文の説明用です。テスト時は、用途と実際のアドレスを把握しているドメインに置き換えてください。PROXYで接続できるかどうかは、自分で用意したプロキシ設定が有効かどうかによります。
login.example.com：1行目に一致し、DIRECTが適用されます。static.example.com：2行目に一致してPROXYが適用され、GEOIPの判定には進みません。192.168.1.20：先行するドメインルールに一致しない場合、プライベートアドレス範囲のルールに進み、DIRECTが適用されます。- それ以外のリクエスト：後続の条件を順に確認し、どれにも一致しない場合はFINALによってPROXYが適用されます。
5. Configの編集と動作確認
以下では、iPhone / iPadのHomeとConfig画面を使って説明します。操作前に現在の設定のコピーを保存してください。設定全体を[Rule]だけの断片で置き換えないでください。既存の設定にこのセクションがある場合は、同じ名前のセクションを重複して追加せず、その中を編集します。リモート設定を再度更新するとローカルの変更が上書きされることがあるため、編集中のものがローカルコピーか更新元かを確認してください。
-
設定のコピーを保存
Configを開き、現在使用している設定を見つけて、まず元の内容を保存します。ファイル名を控え、後で有効化した設定と編集した設定が同じファイルであることを確認します。
-
ルールを編集
Configで対象設定の編集画面を開き、
[Rule]を探します。対象が明確なドメインルールを追加し、FINALが引き続き一覧の末尾にあることを確認してください。 -
設定を有効化
保存後、Configで編集した設定が選択されていることを確認します。次にHome → Global Routing → Configへ戻り、Proxy、Direct、または別のSceneが選ばれたままになっていないか確認してください。
-
新しいリクエストを作成
いったん切断して再接続し、テストページの既存接続を閉じてから対象ドメインにアクセスします。接続ログで接続先、適用されたルール、最終ポリシーを確認してください。ページが開けるかどうかだけで判断しないでください。
-
項目ごとに確認
完全一致ドメイン、同じドメインのサブドメイン、どのルールにも一致しないドメインをそれぞれテストします。各回で変更する条件や順序は1つだけにし、違いを記録してください。問題が起きたら保存したコピーに戻し、テスト対象を絞り込みます。
既存のTCP長時間接続や再利用接続は、ルールを変更した後も接続開始時の経路を使い続ける場合があります。また、ブラウザーに表示されたページがキャッシュ由来のこともあります。そのため、ページを一度再読み込みして変化が見られないだけでは、ルールが適用されていないとは判断できません。新しい接続のログも確認してください。
- Subscribeとルールは別々に確認：Homeで既存のSubscribe内容を更新する操作は、通常サーバー情報の更新です。それだけで現在のConfigのルールも更新されたとは判断できません。
- 自動接続と振り分けは別々に確認：Settings → On Demandでは自動接続の条件を管理します。Configの振り分けモードを選ぶ操作とは異なります。
- プロトコルとマッチングは別々に確認：Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardはそれぞれ異なる接続プロトコルです。ドメインルールによって、あるプロトコルが別のプロトコルに自動変換されることはありません。
6. ルール不一致と接続エラーの確認手順
まず、「ルールの振り分け先が違う」のか、「正しい経路を選んだが接続に失敗した」のかを切り分けます。Webページは、メインサイトのほか画像、ログイン、APIなど複数のドメインへ同時にリクエストすることがあります。メインサイトにDOMAINを設定しても、関連リソースのドメインまで同じポリシーになるとは限りません。一部のコンテンツが読み込めない場合は、キーワードマッチへ安易に範囲を広げず、失敗した接続の実際の接続先ドメインを確認します。
エラー：connection refused
原因と対処：この接続エラーは接続が拒否されたことを示します。接続先ポートで待ち受けていないか、経路上の機器が接続を拒否している可能性があります。まず失敗した接続の実際のアドレス、ポート、選択されたポリシーを確認してください。PROXYが正しく適用されている場合は、自分で用意したサーバーの接続設定を確認します。DOMAINルールだけを変更しても解決しないことがあります。
エラー：i/o timeout
原因と対処：この接続エラーは、該当するネットワーク操作が制限時間内に完了しなかったことを示します。これだけでルールの構文エラーとは判断できません。接続ログでDIRECTとPROXYのどちらが選ばれたか確認し、DNS、接続先への到達性、選択されたプロキシ経路を順に調べてください。ログの詳細な表記はプロトコルやプラットフォームによって異なる場合があります。
これらのエラーは、実際の接続ログに記録された場合に限り、該当する原因の調査に使えます。「ルール不一致」を示す専用メッセージではありません。ログにFINALと表示される場合は、先行する条件がリクエストを処理していません。実際のドメイン名がルールと一致するか、リクエストがIPアドレスを直接使っているか、IP条件が名前解決のタイミングに左右されていないか、設定が有効になっているかを確認してください。
| 確認できる現象 | 最初に確認する項目 | 具体的な対処 |
|---|---|---|
| すべてのリクエストがプロキシ経由になる | Home → Global RoutingがProxyになっていないか | Configに切り替え、新しい接続で確認します。 |
| ログイン用ドメインの例外が適用されない | DOMAIN-SUFFIXが例外ルールより前にないか | 完全一致のDOMAINをサフィックスルールより上に移動します。 |
| すべてのリクエストにFINALが表示される | 実際の接続先、有効な設定ファイル、FINALの位置 | 対象ファイルが選択されていることを確認し、途中のFINALを削除して接続先情報を調べます。 |
| ドメインルールは一致するがIPルールが適用されない | 名前解決の結果、アドレスファミリー、no-resolve | 実際の接続先IPを確認し、IPv6をIPv4のテストに使わないようにします。 |
| 変更後もしばらく古い経路が使われる | 既存接続の再利用とページキャッシュ | 接続を作り直し、新しいマッチングログを確認します。 |
ルールをさらに追加する場合は、ルールリファレンスを参照してください。まずは少数で内容を説明できるルール一覧を保ちましょう。ルールを1つ追加するごとに、マッチする対象、想定するポリシー、配置する理由を明確にすると、出所を確認できないルールを一度に大量追加するより問題を特定しやすくなります。