Shadowrocketのルールは、接続先をPROXY、DIRECT、REJECTのどれで処理するかを決めます。自分で用意したサービスやサブスクリプションを利用し、Configを調整したい方に向けて、ドメインやIPのマッチ条件から、最初に一致したルールの適用、FINALによるフォールバック、変更後の確認方法まで解説します。例示するドメインとアドレスは書式の説明用で、接続先ではありません。読み終えると、ルールが適用される理由や例外ルールを置く位置を判断できます。
1. マッチ条件と接続アクションを区別する
ルールは通常、「タイプ、マッチ値、アクション」で構成され、各項目は半角カンマで区切ります。たとえば DOMAIN,example.com,DIRECT は、マッチに使える接続先ドメインが example.com と完全一致した場合に、DIRECTを選択するという意味です。ルール自体が利用可能なプロキシ接続を作成するわけではありません。PROXYを選んだ場合も、既存の接続項目に設定されたアドレス、ポート、プロトコルパラメータが正しい必要があります。
PROXYはプロキシ経由、DIRECTは接続先へ直接接続、REJECTは接続拒否を意味します。これらはShadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardなどのプロトコル名ではありません。プロトコルはプロキシ接続の確立方法を定め、ルールは接続先ごとに使用する出力ポリシーを決めます。両者は異なる階層の設定です。
以下では、iPhone / iPad版のHome、Config、Global Routingの画面上の名称を使って説明します。ルールをテストする前に、Home → Global RoutingでConfigを選択してください。ProxyまたはDirectはグローバルルーティングの設定であり、同じConfig内のルールが想定どおりに順番に適用されるかを確認する用途ではありません。Sceneはシーン設定に関する項目で、Configと同じ意味ではありません。
2. DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD
この3種類はいずれもドメインをマッチ対象としますが、対象範囲が異なります。DOMAINはドメイン全体との完全一致、DOMAIN-SUFFIXは指定ドメインとそのサブドメイン、DOMAIN-KEYWORDはドメインに指定した文字列が含まれるかを判定します。ルールのドメインには https://、パス、クエリパラメータ、ポートを含めません。
| 書式 | マッチする例 | マッチしない例 |
|---|---|---|
DOMAIN,example.com,DIRECT |
example.com |
api.example.com |
DOMAIN-SUFFIX,example.com,PROXY |
example.com、api.example.com |
notexample.com |
DOMAIN-KEYWORD,example,REJECT |
example.com、myexample.net |
sample.net |
DOMAIN-SUFFIXの境界はドメイン階層であり、任意の文字列の末尾ではありません。そのため、notexample.com は example.com のサブドメインではありません。一方、DOMAIN-KEYWORDにはこの階層の境界がありません。ads のような短い文字列を指定すると、意図しないドメインまで対象になる可能性があります。「名前に特定の語が含まれること」と「接続の用途が確定していること」は同じではありません。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,telemetry,REJECT
FINAL,DIRECT
上の例では、api.example.com は最初のDOMAINに一致するためDIRECTになります。www.example.com は1行目に一致せず、2行目でPROXYが選択されます。ここでの telemetry は文字列マッチの例にすぎず、実際の接続内容や用途を示すものではありません。特定のドメインを拒否する場合は、対象範囲が明確なDOMAINまたはDOMAIN-SUFFIXを優先してください。
3. GEOIPとIP-CIDR:接続先IPで判定
GEOIPは、IPデータベースに登録された地域情報をもとに接続先アドレスを判定します。一般的な書式は GEOIP,CN,DIRECT です。CNはデータベースで使われる地域コードであり、Webサイトの言語やドメインの末尾を表すものではありません。中国語のページでもCNに一致するとは限りません。また、DNSの応答によって同じドメインが異なるアドレスに解決され、IPの判定結果が変わることがあります。
IP-CIDRは、アドレス範囲をネットワークアドレスで指定します。/24 は先頭24ビットが固定されることを表し、/32 は単一のIPv4アドレスを表します。以下ではドキュメント用の例示ネットワークを使って書式を説明します。接続可能なサーバーを示すものではなく、日常的な設定への追加を求めるものでもありません。
[Rule]
IP-CIDR,192.0.2.8/32,DIRECT,no-resolve
IP-CIDR,198.51.100.0/24,PROXY,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
192.0.2.8/32はこのIPv4アドレスだけに一致し、192.0.2.9は含みません。198.51.100.0/24は198.51.100.0から198.51.100.255までのアドレス範囲を表します。この範囲のすべてのアドレスがホストとして使用できるわけではありません。no-resolveは、このIPルールとのマッチだけを目的としたドメイン解決を行わない指定です。アプリ全体のDNSを無効にする設定ではありません。- 接続先のドメインしか分からず、利用可能なIPアドレスがまだない場合、
no-resolve付きのIPルールは一致しないことがあります。トラブルシューティングでは、接続時にどの情報を利用できたか確認してください。
IP-CIDRではポートを判定しません。同じ接続先IPなら、TCP 443とTCP 8443のどちらも同じネットワークルールに一致することがあります。443では接続できても8443で失敗する場合、ネットマスクの変更だけでは解決できません。IPv6アドレスには対応するIPv6ルールタイプを使い、この記事のIPv4の例をそのまま適用しないでください。
4. 上から順にマッチさせ、FINALは最後に置く
ルールはキーワードの「具体性」に応じて自動的に並べ替えられるわけではありません。DOMAINがDOMAIN-SUFFIXより常に優先されることもありません。範囲の広いサフィックスルールが先に一致すると、後続の完全一致ルールは適用されません。優先して処理する例外を先に置き、範囲の広いルールは後に配置してください。
[Rule]
DOMAIN,download.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY
- 接続先が
download.example.comの場合:1行目に一致してDIRECTが選択され、2行目は確認されません。 - 接続先が
docs.example.comの場合:1行目は一致せず、2行目でPROXYが選択されます。GEOIPは確認されません。 - 接続先が上記のドメインに該当せず、IPデータベースでCNに分類される場合:GEOIPでDIRECTが選択されます。
- それ以前のルールに一致しない場合は、
FINAL,PROXYを使い、残りの接続をプロキシ経由にします。
FINALにはドメインやネットワーク範囲のフィールドがなく、書式は FINAL,アクション です。FINAL,example.com,PROXY ではありません。それ以前のルールで処理されなかった接続に適用されるため、通常はルールの末尾に置きます。FINALを先頭に置くと、後続の通常ルールが一致しなくなります。
5. Configでルールを編集して動作を確認する
ルールを試すには、自分で用意したサービスやサブスクリプションが必要です。HomeのSubscribeにある接続項目とConfigのルーティング設定は別の内容です。接続サブスクリプションを更新しても、新しいルールが読み込まれた証明にはなりません。また、Configの変更では誤ったプロトコルパスワードやサーバーポートは修正できません。編集前に元の設定を保存し、接続パラメータとルールを同時に変更しないようにしてください。
-
設定をバックアップする
Configを開き、現在使用中の設定を探します。その項目の操作メニューからバックアップをエクスポートしてください。元の設定を選択した状態を記録し、テストには複製を使って、復元できる元データを残します。
-
ルールを編集する
Configでテスト用設定の編集画面を開き、
[Rule]を探します。このセクションがすでにある場合は重複して追加せず、明確なDOMAINルールを1行FINALの前に挿入して保存してください。 -
設定を選択する
Configに戻り、編集した設定が選択されていることを確認します。次にHome → Global RoutingでConfigを選び、Homeで現在使用中の接続項目を確認してください。
-
新しい接続で試す
対象のページを閉じてから再度アクセスし、必要に応じて接続を切断して再接続してください。既存の長時間接続では以前の接続状態が維持されることがあります。ルール保存前から続いているセッションを、新しいルールの検証結果と見なさないでください。
-
記録を確認する
接続記録またはログで、接続先ドメイン、接続先IP、実際に適用されたポリシーを確認します。一度に変更するのは1か所だけにしてください。結果に問題があればバックアップを復元し、変更前後のルール順を比較します。
検証では、まず制御しやすい完全なドメインを使ってDOMAINを試し、その後DOMAIN-SUFFIXに対象を広げてください。最初から短いDOMAIN-KEYWORDを追加すると、どの接続先に影響したのか判断しにくくなります。アプリのリクエストがIPとしてしか表示されない場合も、ドメインルールのマッチに十分な情報があるとは限りません。
6. 接続エラーとルールエラーを分けて確認する
「Webページが開かない」というだけでは、ルールの書式エラーとは判断できません。まず、実際の出力先が想定どおりかを確認し、その後、接続レイヤーを順に調べます。以下は接続診断や低レイヤーのログに表示される可能性があるエラー文です。プラットフォームやシステムによって詳細な表示は異なり、いずれもルール解析エラーの定型文ではありません。
エラー:Connection refused
原因と対処:接続先のポートが接続を受け付けていないか、明示的に拒否しています。まずログで、プロキシサーバーと接続先サイトのどちらで失敗したのか確認してください。そのうえで、利用中のサービス提供元に既存接続のアドレスとポートを確認します。PROXYに一致したことは、プロキシのポートが利用可能であることを意味しません。
エラー:Operation timed out
原因と対処:制限時間内に接続が完了しなかった状態です。ネットワーク経路、サーバー、ファイアウォールなどが関係する場合があります。まず、同じ接続先の実際の出力先が現在のルールで想定したものと一致するか確認し、その後、ネットワークと既存の接続パラメータを調べてください。タイムアウトだけでは、特定のルールキーワードが原因とは判断できません。
- ルールに一致しない:Global RoutingがConfigになっているか、正しい設定が選択されているか、上位ルールに先に一致していないかを確認し、接続先がドメインかIPかを調べてください。
- 一致後に接続失敗:正しいルールはそのままにして、現在の接続のプロトコル、ポート、認証パラメータを確認してください。TLS接続では、システム時刻とサーバー名の設定も確認します。
- 保存後に問題が発生:半角カンマ、フィールド数、
[Rule]セクションの位置、アクション名を確認してください。まず、正常に動作することが分かっているルール1行に戻し、新しい項目を1行ずつ追加します。 - 結果が一定しない:DNSが返したアドレスを記録してください。GEOIPとIP-CIDRは実際の接続先IPに依存します。CDNから異なるアドレスが返される場合、ブラウザーのアドレスバーだけで結果を判断できません。
7. ルール設定でよくある質問
DOMAINを設定したのに、なぜサブドメインがプロキシ経由になる?
DOMAINはドメイン全体との完全一致だけを対象にします。example.comとそのサブドメインをすべてDIRECTにするには、DOMAIN-SUFFIX,example.com,DIRECTを使い、このルールを上位の広範なルールより前に置いてください。変更後はHome → Global RoutingでConfigが選ばれていることを確認し、新しい接続を確立します。
完全一致のルールを後ろに置くのではなく、先に適用すべきでは?
自動的に優先されることはありません。DOMAIN,api.example.com,DIRECTをDOMAIN-SUFFIX,example.com,PROXYより前に移動すると、このサブドメインは例外ルールに先に一致します。保存後、編集した複製ではなく、実際に選択されている設定を使っているか確認してください。
サブスクリプションを更新すると、手動で追加したルールは消える?
まず、更新対象を区別してください。Homeの接続サブスクリプションとConfigのリモート設定は別のものです。リモート設定を更新すると、その設定内のローカル変更が上書きされる場合があります。ルールを試す前にバックアップを取り、独立した複製として保存してください。更新後は[Rule]の内容を確認し、手動で追加した項目がすべて残ると決めつけないでください。
FINALはDIRECTとPROXYのどちらにすべき?
前のルールに一致しなかった接続をどう処理するかによって異なります。FINAL,DIRECTは残りの接続を直接接続し、FINAL,PROXYは残りの接続をプロキシ経由にします。まずフォールバックの方針を決め、必要な例外がFINALより前にあることを確認してください。どちらを選んでも、利用可能なネットワークや正しい接続パラメータの代わりにはなりません。