GUIの設定だけでは実現しにくいルール追加やURL Rewriteを、Shadowrocketの設定ファイル（.conf）で管理する方法を説明します。ルールの順序、外部RULE-SET、HTTPS通信を検証するMITMの設定を、構文例と画面上の確認手順に沿って解説します。設定ファイルの編集に慣れていない場合は、まず元のファイルを複製し、ユーザー自身が利用しているサーバーやサブスクリプションを前提に、変更を一つずつ確認してください。
.confの構成と編集前に確認すること
.confは、Shadowrocketが読み込む設定ファイルです。画面上のサーバー情報をまとめたものと同じではなく、DNS、ルール、URL Rewrite、MITMなど、通信の処理方法に関わる項目をセクションごとに記述します。設定の内容や利用できる項目はファイルによって異なるため、すでに使っているファイルを編集する際は、その構成を先に確認します。
編集前にConfigを開き、現在選択されている設定ファイルを確認してください。ファイルを複製できる場合は、複製した方を編集用にします。元の内容を残しておけば、読み込みエラーが出たときや通信結果が変わったときに、変更前の状態へ戻して比較できます。複数の設定をまとめて書き換えると、どの行が影響したか判断しにくくなるため、一回の確認で変更する項目は一つに絞ります。
次のコードは構文の説明用です。すべての設定を含む完成済みの設定ファイルではなく、既存ファイルへそのまま貼り付けて置き換えるものでもありません。特に[General]など同じセクションがすでにある場合、同名の見出しを重ねると、設定の読み取り方が分かりにくくなることがあります。既存の該当セクションを探し、必要な行だけ追加してください。
[General]
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTセクション名やルールキーワードは英語表記のまま記述し、カンマ区切りの各項目を正しい順序で並べます。コメントを付ける場合も、設定行とコメントを混同しないようにしてください。ファイルを保存したらConfigに戻り、編集したファイルが選択されていることを確認します。表示や更新の方法はファイルの入手元やアプリの画面構成によって異なるため、画面上の状態を見てから通信テストに進みます。
ルールの追加と優先順位
[Rule]には通信先を判定するルールを記述します。ルールは上から順に照合され、先に一致した条件が処理に使われます。したがって、範囲の広い条件を上に置くと、その下に書いた特定ドメインのルールに到達しない場合があります。適用したい接続先を決めてから、より具体的なルールを上、広い範囲のルールを下に配置し、最後にFINALで残りの通信を処理します。
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY上の例では、api.example.comは最初のルールでPROXYへ送られます。そのほかのexample.comとサブドメインは次のルールでDIRECTになります。さらに、先行するドメインルールに一致しない通信はGEOIPで判定され、それにも一致しない場合はFINAL,PROXYが適用されます。これは例示用の優先順位であり、利用者が望む経路に合わせて調整してください。
| キーワード | 判定対象 | 確認すること |
|---|---|---|
DOMAIN | 指定したドメイン名 | ホスト名が完全に一致するか確認します。 |
DOMAIN-SUFFIX | 指定ドメインとそのサブドメイン | 必要以上に広いドメインを指定していないか確認します。 |
IP-CIDR | 指定したIPv4アドレス範囲 | ネットワーク範囲と必要に応じたno-resolveの指定を確認します。 |
GEOIP | 接続先IPの地理情報 | ドメイン名や端末の言語ではなく、IPに対する判定です。 |
FINAL | 前のルールに一致しない通信 | 設定の末尾に置き、DIRECTかPROXYかを意図して選びます。 |
ルールの動作を調べるときは、対象ドメインを一つ決めて、どの行に一致する想定かを確認します。たとえば特定のAPIだけ経路を変えたい場合、Webページのホスト名だけでなく、実際の通信ログに現れるAPIのホスト名も確認してください。複数のホストを利用するサービスでは、ページ本体と画像、APIが異なるドメインを使うことがあります。
結論：目的のドメインに一致する最初の行を探す
FINALだけを変更しても、上にある広いルールが先に通信を処理していれば結果は変わりません。対象ホスト名を記録し、上から順に照合して最初に一致するルールを確認してください。
外部RULE-SETを使うときの確認手順
外部RULE-SETは、ルールをまとめたリストを設定から参照する方法です。個別のルールを一行ずつ登録する代わりに、対応する形式のルールファイルを参照し、マッチした通信にPROXYやDIRECTなどのポリシーを指定します。配信先のURLにアクセスできることだけでなく、そのファイルの形式がShadowrocketの設定に適合していることも重要です。配信元が異なると、記述形式や更新方法も同じとは限りません。
[Rule]
RULE-SET,https://rules.example.com/list.txt,PROXY
FINAL,DIRECTここにあるURLは形式を示すための例であり、実際に使えるルール配信先ではありません。利用する場合は、ユーザー自身が確認した配信元のURLを記述します。読み込みができない場合は、URLの入力ミス、ネットワークから配信元へ接続できるか、配信元が現在も利用可能か、ファイルの形式が対応しているかを分けて確認してください。必要に応じて、そのRULE-SETの提供元が示す仕様も確認します。
RULE-SETの指定位置は、ルール全体の優先順位にも影響します。例のようにFINALより前に置けば、リスト内の条件に一致する通信をFINALより先に処理できます。反対に、同じ通信が上にある別のルールに一致すれば、RULE-SETまで判定が進まない可能性があります。新しいリストを追加した後は、Configで有効な設定を確認し、実際の対象ドメインへの接続とDataのログを使って、想定したポリシーが選ばれたか確かめます。
追加するルール
- 形式
- RULE-SET,URL,ポリシー
- 配置
- 個別ルールとの順序を確認
- 例の末尾
- FINAL,DIRECT
例示URLを実際のリストとして使わず、利用する配信元と形式を確認します。
失敗時の切り分け
- URL
- 文字列と到達性を確認
- ファイル
- 対応するルール形式か確認
- 適用
- Configと通信ログを照合
一度にURL、ルール順、ポリシーをすべて変えないでください。
URL Rewriteの記述とテスト
[URL Rewrite]は、条件に一致するURLを書き換えるルールを記述するセクションです。ルールは正規表現による一致条件、書き換え先、処理方法で構成されます。次の例は、説明用のドメインに対する形式を示しています。対象のURLが意図した文字列に一致しているかを確かめ、既存のRewriteルールより上か下かも含めて配置を検討してください。
[URL Rewrite]
^https?://www\.example\.com https://example.com 302この例ではwww.example.comを含むURLをexample.comへ書き換えるパターンを示しています。^は文字列の先頭、\.はドメイン内のピリオドを表す正規表現の指定です。ドメイン部分のピリオドをそのまま書くと、正規表現では別の意味になるため、意図する範囲を確認してください。末尾の処理コードを変える場合は、その値が対象の書き換えに適していることも確認します。
変更後は、対象URLを新しい接続で開き、Dataの通信ログでアクセス先と処理結果を確認します。ページが開かない場合は、Rewrite行を一時的に外した状態と比較し、ルールの一致条件か書き換え先に問題があるかを切り分けます。HTTPS通信の内容を対象に処理する場合は、URL Rewriteだけで済むとは限りません。次のMITM設定が必要かどうかを、対象の通信と実際の動作に沿って判断してください。
MITMと証明書を安全に検証する
MITMは、指定したホスト名に対するHTTPS通信を、端末に登録した証明書を使って解析するための機能です。対象ドメインの通信内容が読める状態になるため、必要なテストに限って使用します。金融、医療、個人認証など機密性の高い通信や、所有者から許可を得ていないサービスを対象にしないでください。検証が終わったら、対象ホスト名を削除し、MITMを使わない状態に戻します。
設定ファイルには、対象にするホスト名を限定して記述します。%APPEND%を使う例では、既存のホスト名設定に追記する意図を示します。利用中のファイルに既存の[MITM]セクションがある場合は、同じセクション内へ必要な値を追加し、設定を重複させないようにしてください。
[MITM]
hostname = %APPEND% api.example.com-
バックアップする
Configで編集対象のファイルを確認し、変更前の内容を別に保存します。検証するホスト名は、自分が管理するテスト用ドメインなど、解析の許可がある対象に限定します。
-
ホスト名を指定
既存の
[MITM]セクションを探し、対象のホスト名だけを設定します。広い範囲のドメインを指定すると、意図しない通信まで対象になるため、最小限の指定で始めます。 -
証明書を導入
ShadowrocketのSettingsにあるCertificate関連の画面で証明書を生成し、画面の案内に従ってシステムへインストールします。証明書の生成と、iOSで完全に信頼する設定は別の段階です。
-
信頼状態を確認
iOSのSettings → General → About → Certificate Trust Settingsを開き、対象証明書の信頼設定を確認します。項目名や表示位置はシステムのバージョンによって異なる場合があるため、現在の画面の説明に従ってください。
-
通信結果を検証
Shadowrocketへ戻り、接続を再確立して許可されたテスト先だけにアクセスします。Dataの通信ログで対象ホストへの記録を確認し、証明書エラーが出た場合は、ホスト名、証明書の導入、システムの信頼状態を別々に確認します。
証明書を端末にインストールしただけで、通信内容を常に読めるようになるわけではありません。アプリや接続先が独自の証明書検証を行う場合など、MITMに対応しない通信もあります。証明書エラーが起きたときに、検証を回避するための設定を追加してはいけません。対象をテスト用ホストに絞り、必要な診断情報だけを記録して、不要になった証明書やMITM設定を整理してください。
設定を保存したのにルールが反映されない？
Configで編集したファイルが選択中か確認し、同じ対象に一致するルールが上にないか調べます。その後、新しい接続で対象ドメインへアクセスし、Dataのログを確認してください。
RULE-SETの追加後に読み込めない？
配信URLの入力、アクセスできるネットワークかどうか、配信元のルール形式を順に確認します。ファイル形式が不明な場合は、提供元の説明と照合してから利用してください。
証明書を入れたのにHTTPSを確認できない？
対象ホスト名がMITMの指定に含まれるか、iOSのCertificate Trust Settingsで信頼状態になっているかを確認します。証明書ピンニングなどの仕組みにより、解析できない通信もあります。
検証の最後に、変更前のファイルと現在のファイルを比較し、不要なテストルール、RULE-SET、MITMのホスト名を削除します。保存した設定をConfigで選び直し、必要な通信だけが想定どおりに処理されるか確認してください。設定ファイルの構文を変更しても、サーバー情報やユーザー自身のサブスクリプションの内容が自動で修正されるわけではありません。