Shadowrocketで特定のサイトだけプロキシ接続するには、Global RoutingをConfigに設定し、現在有効な設定の[Rule]に対象ドメインのPROXYルールを記述して、最後をFINAL,DIRECTで締めます。利用中のサービス情報を読み込み、正常に接続できる方を対象に、ルールの範囲、保存と有効化、新しいリクエストでの確認、誤一致の調べ方を解説します。
1. まずConfigモードとプロキシの出口を確認
まず動作モードを確認してからルールを編集します。Home → Global Routingで通信の処理方法を指定します。Configファイルだけを変更しても、HomeがProxyまたはDirectのままでは、この記事で説明するドメイン別の振り分けにはなりません。サーバー情報とルール設定は別のものです。サーバーに接続できても、現在の設定に正しいドメインルールが含まれているとは限りません。
| 画面上の選択肢 | 動作 | この記事での扱い |
|---|---|---|
| Proxy | プロキシ経由で通信します。この記事のようなドメインの許可リストによる振り分けにはなりません。 | Configに切り替えてからルールをテストします。 |
| Direct | 直接接続で通信します。 | このモードではPROXYルールを検証できません。 |
| Config | 選択中の設定ファイルに従って通信します。 | この記事ではこのモードを使います。 |
| Scene | Sceneの設定に従って動作します。 | 原因を切り分ける際は、Sceneの切り替えによる変数を減らすため、まずConfigを使います。 |
この記事の例でPROXYはプロキシのポリシーを指し、サーバーのアドレスではありません。サーバーのAddress欄にこの文字列を入力するものでもありません。既定のプロキシポリシーを使う場合は、Homeで選択中のサーバーが利用可能か確認してください。設定にカスタムのポリシーグループを使っている場合は、そのグループで実際に何が選択されているかも確認します。DIRECTは、対象への接続をプロキシサーバー経由にせず、直接接続することを意味します。
2. DOMAIN-SUFFIXとFINAL,DIRECTの基本形
example.comとそのサブドメインをプロキシ経由にし、それ以外は直接接続する場合は、以下の断片をルール部分のたたき台として使えます。ドメインは説明用の例なので、対象のドメインに置き換えてください。この断片に含まれるのは[Rule]だけで、設定ファイル全体ではありません。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
DOMAIN-SUFFIXは、ドメインの末尾を境界にして照合します。上記のルールはexample.com、www.example.com、api.example.comに適用されますが、文字列が似ているだけのnotexample.comには適用されません。ルールのパラメーターにはドメインだけを記述し、https://、ポート、パス、クエリパラメーターは含めません。
DOMAIN-SUFFIX,example.com,PROXY:ドメインがこのサフィックスに一致した場合、PROXYを使用します。FINAL,DIRECT:それ以前のルールに一致しなかった場合、DIRECTを使用します。この行にドメインのパラメーターはありません。- ルールの区切りには半角カンマを使い、1行につき1つ記述します。2つのルールを同じ行につなげないでください。
login.example.comというホストだけをプロキシ経由にする場合は、DOMAIN,login.example.com,PROXYを使います。サイト全体のドメインに対象を広げずに済みます。
Shadowrocketはルールを上から順に照合し、最初に一致したルールのポリシーを該当する接続に適用します。FINAL,DIRECTを対象ドメインのルールより前に置くと、その時点でフォールバックが適用され、後続のルールが機能しません。既存の設定を編集する場合は、前の方に広範囲に一致するルールがないかも確認してください。ファイルの末尾に数行追加するだけで完了と判断しないようにしましょう。
3. 複数サイトとDOMAIN-KEYWORDの適用範囲
複数の独立したサイトは、1行ずつ列挙すると管理しやすくなります。ページによってはログイン用、静的ファイル用、API用のドメインにアクセスしますが、これらが同じサフィックスを持つとは限りません。実際のリクエストを確認して必要なルールを追加し、ページが正しく表示されないからといって、すべての通信をプロキシ経由に切り替えるのは避けてください。
[Rule]
DOMAIN,login.example.com,PROXY
DOMAIN-SUFFIX,example.org,PROXY
DOMAIN-SUFFIX,example.net,PROXY
FINAL,DIRECT
| 記述方法 | 照合範囲 | 使い分け |
|---|---|---|
DOMAIN,login.example.com,PROXY | login.example.comと完全一致するドメイン。 | 特定のホストだけを対象にする場合に使用。 |
DOMAIN-SUFFIX,example.com,PROXY | example.comとそのサブドメイン。 | 同じドメイン階層をまとめて対象にする場合に使用。 |
DOMAIN-KEYWORD,example,PROXY | ドメインにexampleという文字列を含むもの。 | 範囲が広いため、意図しない一致がないか確認が必要。 |
DOMAIN-KEYWORDは、サイトの運営元を判定せず、キーワードがドメインのどの階層にあるかも問いません。たとえばDOMAIN-KEYWORD,example,PROXYは、example.comとnotexample.netの両方に一致する可能性があります。照合対象はドメインであり、ページタイトル、本文、URLのパスではありません。同じドメイン内の特定のページだけをプロキシ経由にする用途には使えません。
要点:まずドメインを列挙し、必要に応じて範囲を広げる
少数のサイトだけを対象にする場合は、DOMAINまたはDOMAIN-SUFFIXを優先してください。複数の対象ドメインに同じキーワード条件を適用する必要があると確認できた場合に限りDOMAIN-KEYWORDを使い、同じキーワードを含む対象外のドメインでも一致範囲を確認します。
4. 保存・有効化・確認の5ステップ
ルールを変更したら、ファイルが保存されていること、対象の設定が選択されていること、動作モードが正しいこと、新しいリクエストが発生していることを確認します。既存の接続では以前のセッションが続いている可能性があります。ブラウザーですでに開いているページを見るだけでは、新しいルールが有効かどうかは判断できません。
-
出口を確認
Homeで利用中のサーバーを選び、Connectivity Testで接続可能か確認します。テスト結果が示すのは、そのテスト先への接続状況です。特定サイトに対するルールの検証にはなりません。
-
ルールを編集
Configを開き、使用する設定のメニューからEdit Configを選んで[Rule]を確認します。既存のルールセクション内を編集し、[Rule]を重複して追加しないでください。対象ドメインのルールはFINAL,DIRECTより前に置きます。
-
設定を選択
保存したらConfigの一覧に戻り、編集したファイルを選択します。次にHome → Global RoutingでConfigを選び、別の設定ファイルや他の動作モードが使われていないことを確認してください。
-
新しいリクエストを発生させる
再接続してから対象のサイトにアクセスし、続けてリストにないサイトにもアクセスします。必要に応じて古いページを閉じて開き直し、ブラウザーのキャッシュや長時間の接続が判断に与える影響を抑えます。
-
記録を確認
アプリ内のリクエスト記録で、今回の接続先ドメイン、一致したルール、実際に使われたポリシーを確認します。対象のリクエストはドメインルールに一致してPROXYを使用し、対象外のリクエストはFINALに一致してDIRECTを使用するのが想定される結果です。
確認時は一度に1項目だけ変更します。たとえば対象サイトのトップページは開くのに画像が表示されない場合は、まず画像リクエストのドメインとポリシーを確認し、必要であればそのリソースのドメインを追加します。サーバー、DNS、ルール全体を同時に変更すると、どの変更が結果に影響したのか特定しにくくなります。
5. 既存のGEOIP、IP-CIDR、DNS設定の扱い
「それ以外はすべてDIRECT」とするには、他の通信が先行するプロキシルールに一致しないことが前提です。既存の設定にあるGEOIP、IP-CIDRやリモートルールセットも照合に使われることがあります。最終行にFINAL,DIRECTを書いても、それより前のプロキシルールが無視されるわけではありません。
- 広範囲に一致するプロキシルールを確認:前の方に多数のアドレスを対象とするPROXYルールがあると、ドメイン一覧にない接続もプロキシ経由になる場合があります。まず複製した設定から対象と関係のないルールを取り除き、必要性を確認できたものだけを一つずつ戻してください。
- ドメインとIPを分けて考える:IPアドレスを直接指定する接続には、DOMAIN-SUFFIXで照合できるドメインがない場合があります。固定アドレスを指定する必要がある場合に限りIP-CIDRを検討し、共有アドレス全体を安易にプロキシ経由にしないでください。
- no-resolveの意味:
IP-CIDR,192.0.2.0/24,DIRECT,no-resolveは構文例です。no-resolveは、このIPルールの照合のためにドメイン名の解決を積極的に行わないことを意味し、設定全体でDNSを無効にするという意味ではありません。 - アドレスルールの適用範囲に注意:GEOIPはIPアドレスの地理的な帰属に基づいて照合し、個々のドメイン名を照合するものではありません。対象ドメインの正確な一覧の代わりにはなりません。
192.0.2.0/24はドキュメント用の例示ネットワークで、実際の対象としてそのまま使うものではありません。動的なアドレス、共有ホスティング、CDNを利用するサイトでは、ドメインルールを優先して管理してください。名前解決で得たIPを固定ルールにすると、アドレスが変わった際に機能しなくなったり、同じアドレスを使う別のドメインにも影響したりするおそれがあります。
6. ルールの問題と接続エラーを症状から切り分ける
まずリクエストが想定どおりのルールに一致しているかを確認し、次に一致後の接続が完了するかを調べます。接続の診断では、以下のような英語のエラーが表示されることがあります。実際の表示はアプリ内の記録で確認してください。エラーが出たからといって、特定のドメインルールの記述が誤っているとは限りません。
Connection refused
原因:接続先または途中の機器によって接続が明示的に拒否されています。アドレスに対応するポートで、接続を受け付けるサービスが稼働していない場合によく発生します。対処:記録上PROXY経由なら、Homeで選択中のサーバーのAddressとPortが、登録済みの情報と一致するか確認してください。DIRECTなら、接続先サイトとポートを確認し、まずFINALは変更しないでください。
Connection timed out
原因:制限時間内に接続が完了しませんでした。タイムアウトだけでは、出口、接続先、ネットワーク経路のどこに問題があるか判断できません。対処:まず今回のリクエストが一致したポリシーを確認し、Connectivity Testで選択中のサーバーを調べます。次に対象ドメインと対象外のドメインをそれぞれテストしてください。
接続エラーがないのにすべてのサイトがプロキシ経由になる場合は、Home → Global RoutingがProxyのままになっていないか、または[Rule]の前半に広範囲なPROXYルールが残っていないかを確認してください。1つのサイトだけ想定どおりに振り分けられない場合は、実際のリクエスト先ドメインを確認します。ブラウザーのアドレスバーだけを見て判断しないでください。
- 対象がFINALに一致:ドメインの綴り、選択中の設定、アクセス時にIPアドレスを直接使っていないかを確認します。
- 対象がPROXYに一致しても接続できない:選択中の出口に接続できるか、またサイトに必要な別ドメインが異なる経路になっていないか確認します。
- 対象外もPROXYに一致:DOMAIN-KEYWORDの範囲が広すぎないか、前に別のプロキシルールがないかを確認します。
- 保存後も動作が変わらない:現在使用中の設定を編集したか確認し、再接続してから新しいリクエストを確認します。
7. 特定サイトだけを振り分ける際によくある質問
サブドメイン1つだけをプロキシ経由にするには?
DOMAIN,api.example.com,PROXYを使い、FINAL,DIRECTより前に配置します。api.example.comとその下位サブドメインもプロキシ経由にする場合は、DOMAIN-SUFFIX,api.example.com,PROXYに変更します。example.com全体をサフィックスとして指定するのは避けてください。
サイトは開くのに、ログインや動画が使えないのはなぜ?
操作したときの新しいリクエストを確認し、ログインAPIやメディアリソースが実際に使用しているドメインを特定します。対象のアクセスに必要なドメインだと確認できたものだけ、ルールに1行ずつ追加してください。ブラウザーのアドレスバーに表示されるメインのドメインが、ページ内のすべてのリクエスト先とは限りません。
サーバーのサブスクリプションを更新するとルールも変わりますか?
サーバーのサブスクリプションはサーバー情報を更新し、Config内のルールファイルとは別に管理されます。サーバーのサブスクリプションとリモート設定ファイルのどちらを更新したか、まず確認してください。後者はローカルで編集した内容を置き換える可能性があります。編集前に複製を保存し、更新後に[Rule]を確認してください。
On Demandを有効にしていても、これらのルールは必要ですか?
必要です。Settings → On Demandはオンデマンド接続の条件を管理する機能であり、[Rule]による対象の照合に代わるものではありません。トラブルの確認中に接続状態が自動で変わる場合は、まずOn Demandの設定を記録します。接続状態を制御できる状態でConfigのルールを検証してから、必要な自動接続条件に戻してください。
URLのパスに応じて通信を振り分けられますか?
DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDはいずれもパスを照合するルールではありません。example.com/videoをドメイン欄に入力しないでください。この記事の方法ではドメインまたはホストを境界にするため、同じホスト内の異なるページパスをこれら3つのルールで振り分けることはできません。