カスタムルールは、リクエストに適用する接続方法を決める設定です。Shadowrocketで利用するサービスを設定済みで、通信の振り分けを調整したい方向けに、Global Routingの状態、ルールの書式、例外の順序、FINALの位置を解説します。最後に保存と動作確認の手順を紹介します。既定の動作は現在のConfigに従うため、例をあらゆるネットワークに共通する設定として扱わないでください。
Global Routing：ルールが適用される状態か確認する
Global RoutingはHomeで全体のルーティング方式を設定する項目で、個々のルールに指定するアクションとは異なります。Shadowrocketのカスタムルールは、主にConfigを選択した状態で振り分けに使われます。編集前にHome → Global Routingを開いて現在の設定を確認し、Configで使用中の設定ファイルも確認してください。既定の選択肢はアプリの表示に従ってください。この記事ではルールの動作確認にConfigを使用します。
Config
おすすめ現在の設定ファイルにあるルールに従って、リクエストの接続先を決めます。Configを選択しても、すべてのリクエストがPROXYになるわけではありません。最終的な動作は実際に一致したルールで決まります。
用途：カスタムルールの作成、ドメイン例外や最終アクションの確認。
Proxy
全体のルーティングをプロキシに設定し、この記事で扱う通常のルール一覧による振り分けは行いません。同じ接続先へのアクセス結果を比較する場合、一時的に利用できます。確認後は元の設定に戻してください。
用途：ルールの影響を切り分け、設定済みのプロキシ接続が利用できるか確認する。
Direct
全体のルーティングを直接接続に設定します。この状態では、通常の振り分けルールを変更しても、ルールが正しく適用されたかどうかの判断材料にはなりません。
用途：現在のネットワークから接続先へ直接アクセスできるか確認する。
Scene
設定済みのシーンに応じてルーティングを切り替えます。トラブルシューティングでは、設定ファイルのルールだけでなく、シーンの条件と対応する動作も確認してください。
用途：シーンの条件を設定済みで、利用環境に応じて切り替えたい場合。
On Demandは接続を開始する条件を設定する機能で、DOMAIN-SUFFIXなどのルールを置き換えるものではありません。切断後に接続が自動で再開する場合は、Settings → On Demandの現在の条件を確認してください。接続済みなのにリクエストの振り分けが想定と異なる場合は、Global Routing、現在のConfig、適用されたルールを優先して確認します。2種類の問題は分けて対処してください。
ルールの書式：マッチ条件とアクションを分けて記述
ルール行は、ルールタイプ、マッチ値、アクションで構成されます。基本形はタイプ,マッチ値,アクションです。FINALにはマッチ値がなく、最終アクションだけを指定します。テキストで編集する場合は半角カンマを使い、URLのプロトコル、パス、クエリパラメーターをドメインのマッチ値に含めないでください。以下は設定ファイルの[Rule]セクションに記述する内容で、Homeのサーバーアドレス欄に入力するものではありません。
| キーワード | 記述例 | マッチする内容 |
|---|---|---|
DOMAIN-SUFFIX | DOMAIN-SUFFIX,example.com,PROXY | example.com自体とそのサブドメインに一致します。notexample.comには一致しません。 |
IP-CIDR | IP-CIDR,192.168.1.0/24,DIRECT,no-resolve | 指定したIPv4アドレス範囲に一致します。no-resolveを付けると、このルールのためだけにドメイン名を能動的に解決することを避けられます。 |
GEOIP | GEOIP,CN,DIRECT | IPアドレスの地理情報データベースに基づいて判定します。ウェブページの言語やドメインの末尾では判定しません。 |
FINAL | FINAL,PROXY | 前のルールに一致しなかったリクエストを受け取り、指定したアクションを適用します。 |
IP-CIDRの/24はネットワークプレフィックス長です。上の例は192.168.1.0から192.168.1.255までを対象にします。IPv4アドレスを1つだけ指定する場合は/32を使用できます。これらの数値はサーバーポートではありません。ドメインルールにもexample.com:443のようにポート番号を含めないでください。ポートごとにリクエストを振り分ける場合は別のマッチ条件が必要で、DOMAIN-SUFFIXのマッチ値を変更しても実現できません。
評価順序：具体的な例外を先に、広い条件を後に記述
ルールの順序は、上から順に判定する優先順位です。システムが「最も精密なルール」を自動で選ぶわけではありません。通常のルール振り分けでは、リクエストが先にある有効なルールに一致すると、そのアクションが適用され、後続の通常ルールでは上書きされません。そのため、特定ドメインの例外は広いドメイン範囲より前に置き、ネットワーク範囲や地域のルールは適切な位置に記述し、FINALは末尾に置きます。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.1.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY順序を理解するための例です。api.example.comは1行目に一致してDIRECT、www.example.comは2行目に一致してPROXYになります。192.168.1.20へ直接アクセスする場合は、ネットワーク範囲のルールが適用されます。ほかのリクエストがGEOIPに一致するかは、接続先のアドレスとデータベースの結果によります。前のルールに一致しなかった場合にのみ、FINALが適用されます。example.comは説明用のドメインで、利用可能なサービスを示すものではありません。
DOMAIN-SUFFIX,example.com,PROXYを特定ドメインのルールより前に置くと、api.example.comが先に一致するため、後にあるDIRECTの例外が適用されません。GEOIP,CN,DIRECTを一部のドメイン例外より前に置くと、接続先のIP情報が取得できる場合、地域条件が先に一致することがあります。接続先を明確に指定したいドメインは、先に記述してください。FINAL,PROXYを途中に置くと、その後にある通常ルールが想定どおりに機能しなくなります。新しいルールはFINALより前に追加してください。- 同じドメインが異なるアクションで重複している場合、先に一致したルールで結果が決まります。確認時は追加した1行だけでなく、ルールセクション全体を検索してください。
PROXY・DIRECT・REJECT：接続先に応じたアクション
アクションはルールに一致した後の処理を示すもので、ルールがマッチする範囲を示すものではありません。PROXYはリクエストをプロキシ経由で接続し、DIRECTは現在のネットワークから直接接続し、REJECTはリクエストを拒否します。最終的なアクションは現在のConfigに従います。未分類の通信をどう処理したいかを決めてからFINALを選び、動作を確認せず一律に置き換えないでください。
| アクション | 適用する条件 | 確認するポイント |
|---|---|---|
PROXY | 対象へのアクセスに、利用者が設定済みのプロキシサービスが必要な場合。 | 現在選択しているサービスまたはポリシーグループと接続状態を確認します。ルールに一致しても、接続先への通信が成功したとは限りません。 |
DIRECT | LAN内の機器、または現在のネットワークから直接アクセスできることを確認済みの接続先。 | ローカルルート、ネットワーク権限、接続先のサービスを確認します。DIRECTでも、正常なDNSとネットワーク接続が必要です。 |
REJECT | 接続を確立したくないことが明確で、拒否による影響を確認済みの接続先。 | まず対象を限定したDOMAINルールでテストし、ログイン、決済、ページの表示に必要な共通ドメインを誤って拒否しないようにします。 |
FINAL,PROXYは未分類のリクエストもプロキシ経由にする設定で、この動作を維持したい構成に適しています。FINAL,DIRECTは未分類のリクエストを直接接続する設定で、プロキシ経由にする接続先を十分に指定した構成に適しています。利用目的を考慮せず、どちらか一方が常に優れているとは言えません。FINALをREJECTにすると、ルールに記載されていないすべてのリクエストが拒否され、新たに追加したドメインもすぐに利用できなくなる可能性があります。初めてルールを作る場合の出発点にはしないでください。
DOMAIN,blocked.example.com,REJECT
DOMAIN,printer.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT上の例は、同じドメイン範囲内でアクションを例外設定する方法を示したもので、そのまま利用できる接続設定ではありません。PROXYの実際の接続先は、現在選択中のサービスと、設定ファイルで参照されるポリシー名を確認してください。カスタムポリシーグループを参照する場合は、設定内の定義名と一致している必要があります。Global RoutingのProxy設定と、ルール行のPROXYを同じ階層の設定として扱わないでください。
保存と動作確認：変更は一度に1項目ずつ
動作確認では、編集内容、現在有効な設定ファイル、実際のリクエスト結果を照合します。始める前にConfigで元のファイルのコピーを保存し、Global Routingの元の設定も記録してください。この記事は、利用者が自分のサービスとサブスクリプションをすでに用意し、ルールだけを調整することを前提としています。HomeのSubscribeによる更新とConfigファイルの更新は別の操作です。サーバーのサブスクリプションを更新しても、使用中のルールが置き換わったとは限りません。
-
設定状態を確認
Home → Global Routing → Configの順に開きます。Homeで現在選択中のサービスを記録してください。ルールの変更とサービスの切り替えを同時に行うと、結果を比較できなくなることがあります。
-
設定ファイルを開く
Configを開いて、現在選択されている設定ファイルを確認します。そのファイルの編集画面を開き、Ruleリストまたはテキスト内の
[Rule]セクションを確認してください。編集画面の項目名は、現在のアプリ表示に従ってください。 -
例外ルールを追加
広い条件のルールとFINALの前に、対象を明確に指定したルールを挿入します。テキストエディターで編集する場合は、既存の
[Rule]セクションだけを変更し、例全体を貼り付けてルールセクションを重複させないでください。 -
保存して適用
保存後にConfigへ戻り、変更したファイルが選択されたままであることを確認してからHomeへ戻ります。必要に応じて接続を切断して再接続し、新しいリクエストで確認してください。既存の長時間接続は、変更がすぐに反映されたか判断するのに適していません。
-
記録を確認
接続先へ再度アクセスし、アプリのリクエスト記録で対象のドメインまたはIPアドレス、適用されたアクション、確認できるルール情報を照合します。追加の診断情報はSettings → Logで確認できます。記録される項目は現在の画面表示に従ってください。
適切な動作確認の記録には、対象、想定するアクション、実際のアクションの3項目が必要です。たとえば、テスト対象について「特定ドメインのルールではDIRECTを想定し、記録にもDIRECTと表示」と記録します。結果がPROXYの場合は、DNSをすぐに変更せず、まず現在の設定ファイルと上位の広いルールを確認してください。この記事の例は説明上の検証であり、実ネットワークでのテスト結果ではありません。また、直接アクセスできるテストサービスも提供していません。
DNSとIPアドレスのルール：名前解決の問題と評価順序を区別する
DNSはドメイン名をIPアドレスに変換します。IP-CIDRとGEOIPの判定には、参照可能なIPアドレス情報が必要です。DOMAIN-SUFFIXは主にドメイン名を基準に照合し、IP-CIDRはアドレス範囲を基準に判定します。リクエストにドメイン名が含まれるか、すでに名前解決済みか、設定の名前解決オプションやキャッシュの状態などによって、確認できる情報は異なります。ウェブページが開くかどうかだけで、一致したルールを判断しないでください。
- no-resolveの適用範囲：
IP-CIDR,192.168.1.0/24,DIRECT,no-resolveは、このルールに一致させるためだけにドメイン名を能動的に解決しません。ただし、DNSを全体で無効にする設定ではなく、ほかのルールによる名前解決まで防ぐものでもありません。 - GEOIPの適用範囲：地域の判定結果は接続先のIPアドレスとデータベースに基づきます。同じ言語のサイトでも異なる地域と判定されることがあり、同じドメインでもIPアドレスによって地域判定が異なる場合があります。
- IPv6の適用範囲：
IP-CIDRの例はIPv4ネットワーク向けで、IPv6も対象に含むことを意味しません。実際の接続でIPv6を使用する場合は、対応するアドレスルールと設定のサポート状況を別途確認してください。 - キャッシュの影響：ブラウザーのキャッシュや既存の接続によって、リクエストが想定どおりに再送信されない場合があります。ルールを変更した後は新しいリクエストで確認し、必要に応じて再接続してください。
まずGlobal Routingの状態と設定ファイルを確認し、次に一致したルールを調べ、最後に名前解決されたアドレスとサービスへの接続性を確認します。実際の記録で想定したアクションが表示されているのに接続先を利用できない場合は、DNS、接続先のサービス、TLS、現在のネットワーク経路などに問題がある可能性があります。その場合、FINALの位置を調整し続けても接続障害は解決しないことがあります。
よくある質問：ルールが反映されない・更新で上書きされる
ルールを追加したのに、すべての通信がプロキシ経由になるのはなぜですか？
まずHome → Global Routingを開き、ProxyではなくConfigが選択されていることを確認します。次にConfigで使用中のファイルを確認してください。どちらも問題がなければ、対象が上位のDOMAIN-SUFFIXなど広いルールに先に一致していないか調べます。明確な例外はそのルールより前に移動し、保存後に新しいリクエストで確認してください。
FINALより後のルールも適用されますか？
この記事で扱う通常のルール一覧では、FINALより後のルールが適用されることを前提にしないでください。すべてのマッチ条件をFINALより前に移し、明確な最終アクションを1行だけ残します。FINALの重複を確認する場合は、ファイル末尾の数行だけでなく、ルールセクション全体を検索してください。
サブスクリプションを更新した後、カスタムルールが消えたのはなぜですか？
まず更新対象を区別してください。HomeのSubscribeは通常サーバー情報を更新しますが、リモートのConfigを更新すると設定内容が置き換わることがあります。Configを開いて、使用中のファイルが更新または切り替えられていないか確認してください。ローカルの変更を維持するには、別のコピーを保存し、更新のたびにルールセクションを比較してください。
ウェブサイトのトップページは開くのにログインできません。FINALを変更すべきですか？
ログイン時に新たに発生したドメインと、実際に適用されたアクションを確認してください。ログインでは別のドメインが使われる場合や、REJECTされたり異なる接続先経路が割り当てられたりする場合があります。関連性が確認できたドメインに限って必要な例外を追加し、広いルールより前に置いてください。ルール全体をそのままDIRECTやPROXYに変更しないでください。
ルールのメンテナンスが完了したと判断できるのは、結果を説明でき、変更を元に戻せる状態です。各例外の対象が明確で、動作確認のたびに一致したルールを特定でき、FINALの動作が想定と一致していることを確認してください。それでも結果を説明できない場合は、バックアップを復元してルールを1つずつ追加します。異なる設定元のルールを複数まとめて追加しないでください。各画面の詳細は設定項目マニュアルをご覧ください。