すでに利用中のサービスとサブスクリプションがあり、Shadowrocketのルールを編集したい方向けの記事です。まずHomeでGlobal RoutingがConfigになっていることを確認し、Configで現在の設定を確認します。「個別の例外、広い範囲、FINAL」の順にRuleセクションを整理し、新しいリクエストで一致したルールを確認します。例では照合の仕組みのみを扱い、接続情報は含みません。
最初に確認すること：設定を選び、Configで振り分ける
ShadowrocketのHome画面でGlobal Routingを開き、Configを選択します。次にConfigを開き、編集する設定が選択されていることを確認します。その設定の編集画面を開き、Ruleセクションを探してください。テキスト形式の設定では、セクション見出しは[Rule]と記述し、ルールは1行に1つずつ記載します。編集前に復元用のコピーを保存し、現在使える設定をそのまま上書きしないようにしてください。
Global RoutingのProxy、Direct、Config、Sceneは、それぞれ異なる動作モードです。ProxyとDirectは全体の通信経路を選ぶもので、個別のカスタムルールの確認には使いません。この記事ではConfigを選び、選択中の設定に従ってリクエストを振り分けます。Sceneは状況に応じて設定を切り替える機能です。検証時はSceneの変更によって結果が変わらないよう、動作条件を固定してください。
- Home → Global RoutingでConfigを選択し、現在使用中のプロキシ選択を記録します。
- Configを開いて現在の設定名を確認し、コピー側でRuleセクションを編集します。
- 設定を保存し、引き続き選択中であることを確認してから、テスト接続を新しく確立します。
- 対象が明確なテスト先にアクセスし、Dataの接続ログで宛先、一致したルール、送信先の情報を確認します。表示される項目は現在の画面に従ってください。
サブスクリプションに含まれるサーバー一覧と、Config内の振り分けルールは用途が異なります。既存のサブスクリプションを更新しても、通常は接続情報が更新されるだけで、Ruleセクションが変わったとは限りません。一方、リモート設定の更新では設定内容が置き換わることがあります。トラブルの確認前に、どちらを更新したのか記録し、接続情報の変化をルール順序の変化と混同しないようにしてください。
照合順序：最初に一致したルールで今回の動作が決まる
Ruleセクションは上から順に確認されます。ルールに一致して動作が決まると、より「具体的な」条件を探すために後続のルールを照合することはありません。そのため、具体的なルールが範囲指定のルールより自動的に優先されるわけではありません。範囲指定のルールより前に置いて初めて、先に一致する可能性が生まれます。
たとえば、api.example.comにはPROXYを使い、example.comのほかのサブドメインにはDIRECTを使う場合は、次の順序にします。例のドメインは構文の説明用です。ネットワーク接続を検証する際は、利用権限があり、アクセスできると確認済みの宛先に置き換えてください。
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY宛先がapi.example.comの場合は、1行目のDOMAINに一致します。www.example.comの場合は1行目に一致せず、2行目のDOMAIN-SUFFIXに一致します。DOMAIN-SUFFIXはそのドメイン自体とサブドメインを対象とし、その文字列を含むすべてのドメインに一致するわけではありません。
確認ポイント：例外ルールは範囲指定ルールより前に置く
同じ宛先がDOMAINとDOMAIN-SUFFIXの両方に該当する場合は、まず2つのルールの順序を入れ替えてから、新しいリクエストで確認します。後ろに追加した個別ルールでは、先に一致した範囲指定ルールを上書きできません。
動作の指定：PROXY・DIRECT・REJECTは処理方法を決める
ルールは通常、ルールタイプ、照合値、動作の3つで構成され、半角カンマで区切ります。たとえばDOMAIN,api.example.com,PROXYでは、DOMAINが照合タイプ、ドメインが照合値、PROXYが一致後の動作です。ドメインだけを指定する欄には、URL全体やパス、全角カンマを入力しないでください。
| 動作 | 一致した場合の処理 | 確認する条件 |
|---|---|---|
PROXY | 選択中の設定にあるプロキシへ接続を振り分ける | プロキシが利用可能で、接続情報がサーバー側と一致している |
DIRECT | プロキシサーバーを経由せず、宛先に直接接続する | 現在のネットワークから宛先に直接アクセスできる |
REJECT | 一致したリクエストを拒否する | 宛先を実際にブロックする必要があり、必要な接続先まで誤って遮断しない |
PROXYに一致しても、リモート接続の成功が保証されるわけではありません。ルールの判定が正しくても、プロキシ接続先のアドレス、ポート、認証情報に誤りがあれば接続に失敗します。DIRECTも、システムのネットワーク設定を一切介さないという意味ではありません。プロキシサーバーを経由しないことを示します。REJECTは明示的な拒否なので、それによるアクセス失敗を回線のタイムアウトと混同しないでください。
[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXYこの設定では、blocked.example.comはexample.comに属していますが、1行目で拒否されます。REJECTの行をDOMAIN-SUFFIXより後ろに移動すると、この宛先をブロックできません。ウェブサイトがログイン、画像、APIなど別のドメインにもリクエストを送る場合があります。確認時はトップページが開くかだけで判断せず、接続ログを1件ずつ確認してください。
FINALのフォールバック：末尾に置き、ドメインを指定しない
FINALは、それ以前のルールに一致しなかったリクエストを処理するためのもので、ドメインやアドレスの条件は指定しません。基本的な書き方はFINAL,PROXYまたはFINAL,DIRECTであり、FINAL,example.com,PROXYではありません。FINALは明示的に1つだけ設定し、Ruleセクションの末尾に置いてください。途中に置くと、それより後ろのルールは照合されません。
ほかのリクエストはPROXYを使用
- DOMAIN
- blocked.example.com,REJECT
- DOMAIN-SUFFIX
- example.com,DIRECT
- FINAL
- PROXY
拒否する例外と直接接続する範囲を先に処理し、それ以外のリクエストをPROXYに振り分けます。
指定した宛先だけPROXYを使用
- DOMAIN
- blocked.example.com,REJECT
- DOMAIN-SUFFIX
- example.com,PROXY
- FINAL
- DIRECT
拒否する例外とプロキシ経由の範囲を先に処理し、それ以外のリクエストにはDIRECTを使用します。
以上は異なる振り分け方針です。2つのカードに示したFINALを、同じRuleセクションに両方追加しないでください。どちらをフォールバックにするかは、現在のネットワークで宛先にアクセスできるか、どのような接続を必要とするかに応じて決めます。ドメインのルールがないリクエストはFINALに進みます。そのため、ルールの不足による動作の変化は、まずフォールバックの動作として現れることがあります。
IP-CIDRとGEOIPを追加する：明確なアドレス範囲を先に処理
ドメインルールはドメイン条件を、IP-CIDRはIPアドレスの範囲を対象にします。ローカルデバイスへ接続する場合は、既知のLANサブネットを、より広いアドレス分類のルールより前に記述できます。192.168.0.0/16は192.168.0.0から192.168.255.255までを対象としますが、すべての家庭用ネットワークがこの範囲を使うわけではありません。実際のルーターのアドレス設定に合わせてください。
[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYIP-CIDRはIPv4のアドレス範囲に一致します。この例は既知のLANアドレスを対象としており、「すべてのローカルリソースを網羅している」とは限りません。no-resolveは、このIPルールへの照合のためにドメイン名の名前解決を積極的に行わないことを示します。リクエスト処理全体でDNSを使わないという意味ではありません。GEOIP,CN,DIRECTは宛先IPの地理情報に基づいて一致を判定します。ウェブサイトの言語、ドメインのサフィックス、ユーザーの所在地による判定ではありません。- ドメインの名前解決結果は複数のアドレスに分かれることがあり、アドレスの地理情報も想定と異なる場合があります。特定の経路に固定したいドメインには、前方に明示的なドメインルールを設定してください。
リクエストにドメイン名しかなく、アドレスルールで使える宛先IPもない場合、no-resolve付きのLANルールだけで名前解決が始まることはありません。一方、IPに関する判定では、すでに取得した名前解決結果やその処理が関係する場合があります。同じドメインの経路が変わる場合は、まず実際の宛先IPと一致ログを確認し、その後にDNSやアドレスの地理情報を調べてください。ルール順序がランダムに変わったと決めつけないようにしましょう。
保存後の検証：3種類のリクエストでルールの問題と接続の問題を切り分ける
一度に変更するルールは1組に絞り、保存後にリクエストを新しく確立してください。ブラウザーやアプリが既存の接続を再利用すると、設定ファイルを保存しても新しい照合テストにはなりません。必要に応じてテストアプリの既存接続を終了するか、適切なタイミングでShadowrocketを切断して再接続し、宛先へ再度アクセスしてください。
- 個別の例外を検証。個別条件と範囲条件の両方に該当する宛先を選び、後ろのDOMAIN-SUFFIXではなく、前方のDOMAINに一致することを確認します。
- 範囲ルールを検証。同じサフィックスを持つ別の宛先で、例外に指定されていないものを選び、DOMAIN-SUFFIXで処理されることを確認します。
- FINALを検証。アクセス可能と分かっており、それ以前の条件には一致しない宛先を選び、想定したフォールバック動作が使われることを確認します。
- REJECTを検証。一時的に制御可能なテスト先を使い、拒否ルールが機能することを確認します。テスト後は一時ルールを削除し、通常のアクセスに影響しないようにしてください。
テスト記録には、少なくとも宛先ドメイン、実際のIP、Global Routingのモード、一致したルール、結果を記載します。「開かない」とだけ記録しないでください。想定どおりのルールに一致しているのに接続できない場合は、送信先への接続を確認します。別のルールに一致している場合は、まずルールの順序と照合条件を見直し、プロトコルの設定を同時に変更しないでください。
確認ポイント：一致したルールを確かめてから、送信先を確認
一致したルールが想定と異なる場合は、設定の選択、照合範囲、順序を見直します。正しいルールに一致しているのにアクセスできない場合は、DIRECTでのネットワーク到達性、またはPROXYの接続情報を確認してください。1回に変更する要因は1つだけにし、復元用のコピーを残します。
ルールのメンテナンス：更新後に例外とフォールバックを確認
リモート設定を更新した後は、Ruleセクションの先頭にある例外ルールと末尾のFINALを再確認し、カスタム内容が置き換わっていないか確認してください。サブスクリプションを更新した場合は、以前使っていたプロキシ選択が引き続き有効か確認します。どちらも別々のメンテナンス作業です。設定内容と接続情報を分けて記録することで、更新前後の動作の違いを把握できます。
- 現在使える設定のコピーを保存し、カスタムルールの用途と想定する動作を記録します。
- DOMAIN-SUFFIXを追加する前に、より広い範囲を対象とするルールがすでにないか検索します。残しておく個別の例外は、そのルールより前に配置してください。
- 重複するルールや到達できないルールを削除し、FINALより後ろに有効にしたいルールが残っていないことを確認します。
- 各フィールドの詳細は設定フィールドの説明を、初回接続の手順を改めて確認する場合は使い方ガイドをご覧ください。
ルールはリクエストの振り分けを決めるもので、接続サービスを提供するものではありません。アプリの買い切り購入と回線プランは別です。この記事は、利用者がすでにサービスとサブスクリプションを用意していることを前提としています。Shadowrocketはクローズドソースの商用アプリで、主にiPhoneとiPad向けです。入手先はApp Storeのみで、システム要件はApp Storeのページをご確認ください。