Shadowrocketで利用可能な接続を設定済みで、一部のサイトだけをプロキシ経由にしたい方向けです。使用中のConfigにドメインルールを追加し、FINAL,DIRECTを末尾に置いてから、Home → Global RoutingをConfigに設定します。ウェブサイトが開くかどうかだけで判断せず、リクエストログでドメイン、適用ルール、実際のポリシーを確認してください。
1. ルールによる振り分けと全体のルーティング設定を区別する
「一部のサイトだけをプロキシ経由にする」には、対象ドメインがPROXYに一致し、それ以外のリクエストがDIRECTになるという2つの条件があります。前者はドメインルール、後者は最後のFINALルールで決まります。どちらも接続が設定済みのルールに従って動作していることが前提です。Global RoutingでProxyまたはDirectを選んでいる場合、ルールファイルだけを変更しても、ここで説明する振り分けにはなりません。
| Global Routingの選択肢 | 動作 | この記事での設定 |
|---|---|---|
| Config | 現在のConfigのルールに従ってポリシーを決定します。 | ドメインルールの確認にはこちらを選択します。 |
| Proxy | トラフィックをプロキシ経由にし、この記事のドメイン許可リストによる振り分けは行いません。 | FINAL,DIRECTの確認には使用しないでください。 |
| Direct | トラフィックを直接接続で処理します。 | 直接接続になった結果を、ドメインルールが機能していないと誤認しないでください。 |
| Scene | 設定したシーンの条件に従って動作します。 | 最初のトラブルシューティングではConfigに切り替え、シーン切り替えの影響を抑えます。 |
ここではPROXYはプロキシ経由、DIRECTは接続先への直接接続を表します。始める前に、Homeで選択中のプロキシ接続が利用可能であることを確認してください。既存のConfigでカスタムポリシーグループを使っている場合は、ルール末尾で参照するポリシー名が実際に存在するか確認します。別のConfigにあるグループ名をそのまま貼り付けないでください。
2. DOMAIN-SUFFIXとFINAL,DIRECTを使ったルール例
以下は構文を説明するための完全な[Rule]セクションです。接続パラメーターやDNSなどを含む完全なConfigファイルではありません。example.comとexample.netは説明用のドメインです。プロキシ経由にしたい実際のサイトのドメインに置き換えてください。これらの例示ドメインを利用可能なサービスと誤解しないでください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,example.net,PROXY
FINAL,DIRECT
DOMAIN-SUFFIX,example.com,PROXYは、example.com自体とそのサブドメイン(www.example.comやapi.example.comなど)に一致します。notexample.comやexample.com.other.netは同じドメインの末尾として扱われません。照合対象はドメインであり、ウェブアドレス内の任意の文字列ではありません。
- ドメイン欄には
https://、ポート、パス、クエリパラメーターを含めません。 https://www.example.com:443/accountにアクセスする場合、ルールに記入するのはドメイン部分です。/accountは記入しません。- ルールは1行に1つずつ記述し、各フィールドを半角カンマで区切ります。
PROXYやDIRECTなどのキーワードは原文のまま使ってください。 FINAL,DIRECTにはドメイン欄がありません。前のルールに一致しなかったリクエストを、最後に直接接続へ振り分けます。
3. ルールを適用するには、テキストの保存だけでなく順番に設定する
以下ではHome、Config、Settingsの画面構成に沿って説明します。編集画面へのアクセス方法はプラットフォームによって異なる場合がありますが、「ファイルを編集する」「保存する」「使用中のConfigに設定する」「Configに従って実行する」の4つが必要です。接続情報を提供するサブスクリプションと、ルール設定が有効かどうかは、それぞれ別に確認してください。
-
Configをバックアップする
Configを開き、まず現在のファイルを複製するか、バックアップをエクスポートします。現在使用中のConfigを控えておき、別のファイルを編集したまま古いConfigで接続しないようにしてください。
-
ルールを整理する
使用するファイルの編集画面を開き、
[Rule]を探します。必要なDOMAIN-SUFFIXルールを追加し、既存のルールを確認して、FINAL,DIRECTを末尾に置きます。 -
ファイルを有効にする
変更を保存し、Configでそのファイルが現在使用中の設定になっていることを確認します。リモート更新されるファイルの場合、今後の更新でローカル編集が上書きされないかも確認してください。
-
ルーティングを切り替える
Home → Global Routingに戻ってConfigを選択し、Homeで選択中のプロキシ接続が利用可能であることを確認してから接続を有効にします。
-
新しいリクエストを発生させる
接続を切っても問題ない状況で再接続します。開いているウェブページを閉じて開き直し、新しいネットワークリクエストを発生させてから、リクエストログで一致結果を確認します。
既存のサブスクリプションURLは、利用中のサービス提供元から取得してください。ルールの振り分けを変更するためにサブスクリプションを何度も削除しないでください。また、サブスクリプションURLをDOMAIN-SUFFIXのドメイン欄に貼り付けないでください。Settings → On Demandは自動接続の条件を設定するもので、特定のドメインをPROXYまたはDIRECTにする設定ではありません。確認中は自動接続が再実行されていないか注意し、その動作をルール変更と混同しないようにしてください。
4. DOMAINとDOMAIN-SUFFIXの使い分け、例外ルールの配置
ルールは上から順に照合され、最初に一致したルールでそのリクエストのポリシーが決まります。そのため、「サイト全体はプロキシ経由、特定のサブドメインは直接接続」にするには、より具体的な例外を先に配置します。以下の例では、status.example.comを直接接続にし、それ以外のexample.com配下のドメインをプロキシ経由にします。
[Rule]
DOMAIN,status.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
| ルールキーワード | 適用範囲 | このケースでの注意点 |
|---|---|---|
| DOMAIN | ドメインを1つだけ完全一致で照合します。 | 特定のホストだけをプロキシ経由にする場合や、サブドメインに例外を設定する場合に使います。 |
| DOMAIN-SUFFIX | ドメイン自体とそのサブドメインに一致します。 | サイトのメインドメインと同じサフィックスのサービスをまとめて振り分けるのに適しています。 |
| IP-CIDR | IPv4アドレスの範囲に一致します。 | 明確なアドレス範囲に使います。ウェブサイトのパスは指定できません。 |
| GEOIP | 接続先IPアドレスの地理的な割り当てに基づいて照合します。 | ページの内容、ドメインの末尾、ユーザーの所在地では判定しません。 |
| FINAL | 前のルールに一致しなかったリクエストを処理します。 | この記事ではDIRECTを使い、この後にルールを追加しません。 |
たとえばIP-CIDR,192.168.0.0/16,DIRECT,no-resolveは、このプライベートアドレス範囲に一致する通信を直接接続にします。no-resolveは、このIPルールに一致させるためだけのドメイン名前解決を避ける指定です。すべてのルールに付ける必要があるパラメーターではなく、サイトに不足している別のリソースドメインの問題を解決するものでもありません。
ポイント:ドメイン許可リストに地理情報による振り分けは不要
「リストに記載したドメインだけをプロキシ経由にする」ことが目的なら、具体的な例外、ドメインのプロキシルール、FINAL,DIRECTを設定すれば十分です。GEOIPや広範囲のIPプロキシルールを追加する場合は、どのリクエストを変更するのか先に確認してください。そうしないと、先に一致したルールによって「それ以外はすべて直接接続」の範囲が変わることがあります。
5. ルールの動作確認:ドメイン、適用ルール、ポリシーを照合する
ウェブページが開いても、プロキシ経由で接続した証明にはなりません。開けなくても、ルールが一致していないとは限りません。ルール選択が正しくても、プロキシ接続、接続先サービス、DNS、TLSのいずれかで失敗することがあります。確認時はアプリのリクエストログや接続詳細を開き、新しいリクエストの接続先ドメイン、適用ルール、最終的なポリシーをまとめて確認してください。ログの場所や表示項目は、現在のプラットフォームの画面に従ってください。
| 確認するドメイン | 一致するルール(予想) | 適用されるポリシー(予想) |
|---|---|---|
| www.example.com | DOMAIN-SUFFIX,example.com | PROXY |
| status.example.com | DOMAIN,status.example.com | DIRECT |
| www.example.org | FINAL | DIRECT |
上の表はルールの動作例であり、例示サイトへの実際の接続テストではありません。確認時は、アクセス権のある実際のドメインに置き換え、新しい接続を1つずつ作成してください。ブラウザーが既存の接続を再利用したり、キャッシュを表示したりする場合があります。設定を変更した後、元のページを見るだけでは、新しいルールを確認できるリクエストが発生しないことがあります。
- まずルーティング設定を確認:Home → Global RoutingがConfigになっており、現在のファイルが保存したばかりのConfigであることを確認してください。
- 次に一致結果を確認:対象ドメインがFINALに一致する場合は、スペル、サブドメインの関係、ドメイン情報を確認してください。
- 次にポリシーを確認:指定したルールに一致しているのに接続先が想定と異なる場合は、ポリシーの参照先と現在選択中の接続を確認してください。
- 最後に応答を確認:ポリシーが正しいことを確認してから、プロキシサーバーのポート、接続先からの応答、証明書エラーを調べてください。
6. ページの一部しか読み込めない・接続エラーが出る場合
ウェブページはメインサイト、ログイン用ドメイン、静的リソース用ドメイン、動画用ドメインなどに同時にリクエストを送ることがあります。メインドメインをプロキシ経由にしても、すべてのリソースが同じサフィックスに属するとは限りません。たとえばページがassets.example.netにもアクセスする場合、DOMAIN-SUFFIX,example.com,PROXYだけでは対象になりません。失敗したリクエストから実際のドメインを確認してから、ルールを追加するか判断してください。推測でプロキシ対象を広げないようにしましょう。
エラー:connection refused
原因:接続先のポートが拒否されています。プロキシサーバー側または直接接続先で発生している可能性があります。対処:まずログに記録されたポリシーとリモートアドレスを確認してください。PROXY経由の場合は、利用中のサービス情報でサーバーアドレスとポートを確認します。エラーを消すためだけにすべてのドメインをプロキシ経由に変更しないでください。
エラー:i/o timeout
原因:ネットワーク処理が制限時間内に完了しませんでした。このメッセージだけでは、ルール、回線、接続先のどれに問題があるか判断できません。対処:まずルールが一致しているか確認し、現在のプロキシ接続と同じ接続先への新しいリクエストを個別にテストします。一度に変更する条件は1つにしてください。
エラー:no such host
原因:ドメイン名の名前解決で有効な結果を取得できませんでした。スペルミスやDNSクエリの失敗が考えられます。対処:実際のリクエスト先ドメインと現在のDNS設定を確認します。まず名前解決の問題を解決し、その後DOMAIN-SUFFIXとFINALのどちらに一致するかを確認してください。
上記はネットワークログでよく見られるエラーテキストの一部です。完全なメッセージにはアドレス、ポート、その他の情報が含まれることがあり、表示内容はプラットフォームによって異なります。ログを共有して確認を依頼する場合は、日時、接続先ドメイン、ルール、ポリシーを残してください。共有前にサブスクリプションのトークン、パスワード、その他の接続認証情報を削除してください。
7. よくある質問:パスによる振り分け、更新時の上書き、DIRECTの範囲
特定のサイトの/videoだけをプロキシ経由にできますか?
DOMAIN-SUFFIXではURLのパスによる振り分けはできません。照合するのはドメインであり、/videoは照合フィールドとして読み取られません。HTTPSのパスも、通常のドメインルールから直接利用できる情報ではありません。まず、対象の機能が専用のサブドメインを使っているか確認してください。専用サブドメインがある場合は、DOMAINでそのサブドメインを完全一致させられます。
FINAL,DIRECTを設定したのに、ほかのサイトがプロキシ経由になるのはなぜですか?
まずHome → Global RoutingがConfigになっていることを確認し、次にFINALより前にあるルールを調べてください。先に一致したDOMAIN-SUFFIX、IP-CIDR、GEOIP、ルールセットによってポリシーが決まることがあります。FINALが処理するのは残りのリクエストだけで、先に一致した結果を上書きしません。
昨日は動作していたのに、Configの更新後にルールが消えたのはなぜですか?
Configで現在のファイルを開き、追加したドメイン行を探してください。リモートConfigの更新でローカルのテキストが置き換えられることがあります。ローカルConfigのコピーを別途保管し、更新の前後でルールを確認してください。接続用サブスクリプションの更新とリモートルールファイルの更新は、別の操作です。
それ以外がDIRECTということは、ほかのアプリもすべてプロキシを経由しないという意味ですか?
これは、現在のルール処理に入り、前のルールに一致しなかったリクエストがDIRECTになることを表します。デバイス上のすべての通信について保証するものではありません。実際にアプリが発生させたリクエストログを確認し、テスト環境に影響するほかのシステムプロキシ、VPN、アプリ内プロキシ設定も調べてください。
作業後は、再現可能な最小限のルールを保存してください。内容は、プロキシ経由にするドメイン、必要な完全一致の例外、末尾のFINAL,DIRECTです。サイトを追加するたびに「新しいリクエストを発生させる」「一致結果を確認する」「ポリシーを確認する」の手順を繰り返してください。ほかのルールタイプに広げる場合はルールリファレンスを参照してください。用語の意味は用語集で確認できます。