Shadowrocketのルール設定方法｜特定のサイトだけをPROXY経由にするConfig例

この記事の概要

iPhone/iPadのShadowrocketに自分で用意したサーバーをすでに追加していて、一部のサイトだけをPROXY経由にしたい方に向けた解説です。まずGlobal Routing（グローバルルーティング）でConfig（設定）を選び、現在のConfigにドメインルールを追加して、末尾にFINAL,DIRECTを配置します。ルールの追加例、保存と動作確認の手順に加え、ルールに一致しない場合やページの一部が読み込めない場合の確認方法も紹介します。ドメイン例は説明用です。

Configとデフォルトサーバーを確認する

Shadowrocketの接続スイッチ、サーバー選択、ルールによる振り分けはそれぞれ別の設定です。接続スイッチをオンにすると接続が有効になりますが、ドメインによる振り分けはHome（ホーム）のGlobal Routing（グローバルルーティング）の設定にも左右されます。この記事ではConfig（設定）モードを使い、選択中のConfigにあるルールで通信先を決めます。

始める前に、登録済みのサーバーに接続できることを確認してください。Home（ホーム）のサーバー一覧で対象の左側にある選択マークをタップしてデフォルトサーバーに設定し、Connectivity Test（接続テスト）を実行します。ここでは標準のポリシーPROXY（プロキシ）を使用します。元のConfigでルールの転送先に独自のポリシーグループを指定している場合、実際に使われるサーバーはそのグループの選択内容にも左右されるため、デフォルトサーバーだけでは判断できません。

Config（設定）

Proxy（プロキシ）

クライアントが処理する接続をすべてプロキシに送ります。この記事のドメインルールによる振り分けは行いません。プロキシ接続の問題とルール設定の問題を切り分ける際、一時的に利用できます。

用途：登録済みサーバーから対象サイトに接続できるかを短時間で確認する。

Direct（直接接続）

クライアントが処理する接続をすべて直接送信します。ConfigにPROXYと記述されたルールがあっても、プロキシ経由にはなりません。

用途：現在のネットワークから対象サイトへ直接接続できるか確認する。

Scene（シーン）

設定済みのシーン条件に応じてルーティングを適用します。この記事で使うConfigルールモードとは異なるため、問題の切り分けではまずConfigに戻してください。

用途：シーン条件を設定して使う場合。

モードを決めてからルールを変更する

テスト前にGlobal RoutingをConfigに設定します。シーン、サーバー、ルールを同時に切り替えると、アクセス結果が変化したときに原因を特定できません。

最小限のルール：指定ドメインはPROXY、それ以外は直接接続

ルールは半角カンマで区切ります。DOMAIN-SUFFIX（ドメインサフィックスによる照合）では、ルールタイプ、ドメインサフィックス、適用するポリシーの順に記述します。ドメイン欄にはホスト名だけを指定し、プロトコル、パス、ポート、ワイルドカードは含めません。以下はルール部分の例であり、DNSなどの設定を含むConfig全体ではありません。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

この部分を既存Configの[Rule]セクションに統合し、同じ名前のルールセクションをファイル内に複数作らないでください。既存のルールがある場合は、先にバックアップを取り、より上のルールが先に一致しないか確認します。「指定したサイトだけをPROXY経由にする」には、それ以外のドメインをPROXYに送る広範なルールを残さず、古いフォールバックルールを途中に置かないことが必要です。

2行

最小限のルールセクション：ドメインルール1つとフォールバックルール1つ

3項目

ドメインルールの項目：タイプ、照合値、ポリシー

最後の1行

FINAL,DIRECT：それまでのルールに一致しなかった接続を処理

DOMAIN-SUFFIX,example.com,PROXYは、example.com自体と、www.example.comやapi.example.comなどのサブドメインに一致します。
notexample.comやexample.com.other.testには一致しません。これらのホスト名は対象ドメインのサフィックスに該当しないためです。
FINAL,DIRECTには照合値の項目がありません。それまでのルールに一致しなかった接続をDIRECT（直接接続）に送ります。3項目の形式で記述しないでください。

ここでいう「それ以外は直接接続」とは、このルールセクションで処理され、前のルールに一致しなかった接続を指します。端末上のすべてのシステム通信がリクエスト記録に表示されるという意味ではありません。また、DNSクエリとWeb接続が必ず同じ経路を使うわけではないため、DNSは現在のConfigで別途確認してください。

DOMAIN-KEYWORDとルールの順序

DOMAIN-KEYWORD（ドメインキーワード照合）は、ドメインに指定した文字列が含まれているかを調べます。複数のドメインをキーワードでまとめて対象にする場合に便利ですが、サフィックス照合より範囲が広くなります。サイトのメインドメインがわかっている場合はDOMAIN-SUFFIXを優先し、名前にたまたま同じ文字列を含む別のドメインまでPROXY経由になるのを避けましょう。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,media-example,PROXY
FINAL,DIRECT

上記の2行目は、ドメインにmedia-exampleを含む接続に一致します。Webページのタイトルや本文、完全なURLを検索するものではありません。サイト内の特定のディレクトリに一致させるためにexample.com/videoと記述するのは避けてください。ドメインルールでは、同じホスト上にあるページをURLパスで区別できません。

リクエスト先のホスト名	最初に一致したルール	ポリシー
`api.example.com`	`DOMAIN-SUFFIX`	`PROXY`
`img.media-example.test`	`DOMAIN-KEYWORD`	`PROXY`
`unrelated.test`	`FINAL`	`DIRECT`

ルールは上から順に照合され、最初に一致したルールのポリシーが適用されます。後続のルールから「より正確そうなもの」が自動で選ばれることはありません。たとえばlocal.example.comを直接接続し、同じサフィックスの他のドメインをPROXY経由にするには、完全一致のドメインルールをサフィックスルールより前に置きます。

[Rule]
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

iPhone/iPadでConfigを保存して有効にする

ここでは、すでに使えるConfigがあることを前提にします。元のConfigを残したうえでローカルコピーを編集し、唯一使えるファイルを直接上書きしないでください。リモートConfigを再ダウンロードまたは更新すると、ローカルでの変更が上書きされる場合があります。「サーバー一覧の更新」と「ルールConfigの置き換え」は区別して管理しましょう。

Configをバックアップする

Configを開き、現在選択中のファイルを確認します。ファイルの操作メニューからコピーを保存し、問題が起きたときに戻せるよう元のファイル名を控えておきます。
ルールを編集する

Configでコピーしたファイルの操作メニューを開き、Edit Plain Text（プレーンテキストで編集）を選びます。[Rule]を探し、必要なドメインルールをFINAL,DIRECTより前に追加します。ほかの必要な設定セクションは残してください。
編集したConfigを選択する

ファイルを保存してConfigに戻り、編集したローカルConfigを選択します。選択マークがそのファイルに付いていることを確認してください。元のリモートConfigが選択されたままになっていないか注意します。
モードを切り替える

Home → Global Routing → Configの順に開きます。Homeに戻ってデフォルトサーバーを確認し、接続スイッチをオンにします。初回にシステムのVPN構成への許可を求められたら、画面の案内に従って許可してください。
接続を再確立する

テストに使ったページをいったん閉じ、対象サイトを開き直します。必要に応じてShadowrocketの接続を一度オフにしてからオンにし、新しいリクエストに保存したルールを適用します。再利用中の既存接続は、動作確認には適していません。

Settings → On Demand（設定 → オンデマンド接続）が有効な場合、手動で切断しても接続条件に一致すると再接続されることがあります。テスト中は条件を確認し、必要ならOn Demandを一時的に無効にしてください。テスト後は元に戻すことも忘れずに。On Demandは接続の開始条件を管理する機能で、ドメインルールの代わりにはなりません。

ルールの一致を確認し、ページに必要なドメインを追加する

確認は少なくとも2種類のサイトで行います。PROXY経由にする対象と、ルールに記載していない対象をそれぞれ開いてください。まずHomeでConnectivity Testを実行し、デフォルトサーバーが基本的に接続できることを確認してから、新しいWebリクエストを送信します。テストの成功が示すのは対象への接続状況であり、すべてのサイトにアクセスできることではありません。

対象ホストを確認：ブラウザの現在のアドレスとリクエスト記録で、実際のホスト名を照合します。リダイレクト後のドメインは最初に入力したアドレスと異なることがあるため、入力時のURLだけで判断しないでください。
適用されたポリシーを確認：リクエスト記録で該当する接続の詳細を開き、表示されるルールとポリシーを確認します。PROXY経由にする対象にはドメインルールが適用され、それ以外のテスト対象にはFINAL,DIRECTが適用されるはずです。
依存リクエストを確認：ページ本文は表示されるのに画像、ログイン、動画などが失敗する場合は、失敗したリクエストのホスト名を確認します。リソースが別ドメインから読み込まれている場合、メインサイトのサフィックスルールだけでは対象になりません。
必要なルールを個別に追加：PROXY経由が必要だと確認できた依存ドメインだけを追加し、再テストします。対象範囲が広がりすぎないよう、短すぎるキーワードを安易に追加しないでください。

確認済みのリソースドメインを2つ目のルールとして追加できます。ここでのstatic.example.netは説明用の例です。リクエスト記録で実際に確認したホスト名に置き換えてください。このホストだけが対象ならDOMAIN（完全なドメイン名との照合）を使えばよく、上位ドメイン全体をPROXY経由にする必要はありません。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,static.example.net,PROXY
FINAL,DIRECT

ドメインルールの照合には、接続から取得できるドメイン情報も必要です。アプリがIPアドレスに直接接続する場合、ドメインルールの照合対象がないことがあります。その場合も、すぐに広いアドレス範囲を追加せず、リクエスト先、DNSの名前解決状況、その接続が本当にPROXY経由にしたいサイトのものかを先に確認してください。

GEOIP、IP-CIDR、サブスクリプション更新の注意点

GEOIP（IPアドレスの地域情報による照合）とIP-CIDR（IPv4アドレス範囲による照合）は、アドレス条件を扱うルールであり、Webサイトのリストではありません。「指定したドメインだけをPROXY経由にする」場合、最小限のルールにはどちらも不要です。広いアドレス範囲を上位に追加すると、後続のドメインルールやフォールバックルールが適用される範囲も変わります。

ルールタイプ	構文例	確認ポイント
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,PROXY`	メインドメインとサブドメインをまとめて対象にします。
`DOMAIN-KEYWORD`	`DOMAIN-KEYWORD,media-example,PROXY`	ドメインに含まれる文字列で照合するため、意図しない一致に注意してください。
`GEOIP`	`GEOIP,CN,DIRECT`	IPアドレスの地域情報を基準にします。Webサイトの所在地を示すものではありません。
`IP-CIDR`	`IP-CIDR,192.0.2.0/24,DIRECT,no-resolve`	例に使っているのはドキュメント用のアドレス範囲です。no-resolveは、このルールのためにドメインを積極的に名前解決しないことを示します。

この表はルールの種類を見分けるためのものです。すべての行をConfigに追加する必要はありません。特に共有サーバーのアドレスでは複数のWebサイトが同居することがあるため、IP範囲でPROXY経由にすると「指定したサイトだけ」という目的から外れやすくなります。ドメインが特定できている場合は、まずドメインルールを使い、アドレスでの照合が必要だと確認できたときだけアドレスルールを追加してください。

HomeのSubscribe（サブスクリプション）項目を更新すると、通常は登録済みのサーバー一覧が更新されます。ローカルConfigの[Rule]の内容まで変更されるわけではありません。
リモートConfigを更新すると、ルールが変わる場合があります。更新後は、選択中のファイル、ドメインルール、最後のFINALを改めて確認してください。サーバーの数だけを確認して終わらせないようにしましょう。
サーバー一覧が変わったら、デフォルトサーバーやポリシーグループが引き続き利用可能な項目を指しているか確認します。ルールがPROXYに一致していても、その先のサーバーが使えなければWebページは開けません。

よくある質問：ルールを書いたのに意図どおりに振り分けられない

すべてのサイトがPROXY経由になるのはなぜですか？

まずHome → Global RoutingでConfigが選ばれていることを確認します。Proxyが選択されていないか確認してください。次に、選択中のConfigを開き、FINAL,PROXYや対象範囲が広すぎるPROXYルールが残っていないか調べます。対象ルール以外の通信先も確認したうえで、末尾のフォールバックをFINAL,DIRECTにします。

指定したサイトが直接接続されるのはなぜですか？

Configを開き、編集したファイルが現在使われていることを確認します。ドメインにプロトコルやパスを誤って含めていないか、FINALが先頭に置かれていないか、先に一致するDIRECTルールがないかを調べます。その後、開いていたページを閉じ、新しいリクエストを送信して実際のホスト名を確認してください。

メインページは開くのに、ログインや画像が読み込めないのはなぜですか？

リクエスト記録から失敗したリソースのホスト名を確認し、メインサイトのドメイン外にあるか判断します。PROXY経由が必要だと確認できた別ドメインをFINALより前に追加し、ページを開き直してください。ページの読み込みに失敗しただけで、サーバー全体が使えないと判断しないでください。

Proxyでは接続できるのに、Configでは接続できないのはなぜですか？

まずHome → Global Routing → Configに戻し、対象リクエストに適用されたルールを確認します。DIRECTに一致している場合は、ドメインの範囲やルールの順序を見直します。PROXYに一致している場合は、そのポリシーで実際に選ばれているサーバーが一時的なProxyテストと同じか確認し、DNSとリソースのドメインも調べてください。

設定ができたら、動作するコピーを保存し、追加したドメインを記録しておきます。変更は一度に1つだけにしてください。モード、ルール、サーバーの順に確認すれば、「Configが有効になっていない」「ルールに一致しない」「プロキシ接続に失敗している」を切り分けられます。Config全体を何度も置き換える必要はありません。