Shadowrocketでは、Global RoutingでConfigを選ぶと、現在の設定にあるRuleセクションに沿って通信を振り分けます。この記事は、利用可能な接続先と設定をすでに用意しており、指定したサイトだけをプロキシ経由にしたい方向けです。まずドメインのルールを設定し、最後にFINAL,DIRECTを置いて、リクエストログで実際の適用状況を確認します。例示するドメインは構文の説明用であり、接続先やサービスを推奨するものではありません。
Configと接続先を確認する
ルールによる振り分けには、現在使用中のConfigに対象ルールが含まれていることと、HomeのGlobal RoutingでConfigが選択されていることの2つが必要です。Config内でファイルを編集しただけでは、すべての通信がそのファイルに従って振り分けられるわけではありません。編集したConfigが現在選択されていることも確認してください。
Global RoutingのProxyはすべての通信をプロキシ経由にし、Directはすべての通信を直接接続する設定です。どちらも、この記事で扱う「指定サイトはプロキシ経由、ほかは直接接続」の確認には使いません。Sceneはシーンを選択する機能で、現在のファイルを使うConfigモードと同じものではありません。確認時はConfigが選択されていることを確かめ、シーンの切り替えでテスト条件が変わらないようにします。
PROXYはプロキシ接続のポリシーで、通常は現在選択されている接続先を使用します。DIRECTは接続先に直接接続します。既存のファイルにカスタムポリシーグループがある場合は、グループ名とグループ内の選択内容を確認してください。グループ名、サーバーの表示名、組み込みポリシーは混同しないようにします。この記事では、追加のグループ定義を避けるためPROXYとDIRECTのみを使用します。
- Homeで利用可能な接続先を選び、Connectivity Testで基本的な接続状況を確認します。
- Configを開き、現在の設定をバックアップしてから、今回のテスト用にローカルコピーを編集します。
- 編集したコピーが選択されていることを確認し、Home → Global Routing → Configに戻ります。
- 接続を開始したら対象サイトを再読み込みします。既存の接続では以前の接続先が使われ続けることがあるため、新しいルールの検証には使えません。
DOMAIN-SUFFIXとFINALの最小構成
example.comとそのサブドメインをプロキシ経由にし、それ以外のリクエストを直接接続する場合、基本となるルールは2行だけです。以下はRuleセクションの例で、既存の設定ファイル全体を置き換えるものではありません。既存ファイルに[Rule]がある場合は、そのセクションを編集してください。同名のセクションを重複して追加しないでください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTDOMAIN-SUFFIX,example.com,PROXYはドメインの末尾で照合し、example.com自体に加えてwww.example.com、api.example.comなどのサブドメインにも適用されます。入力するのはドメインであり、https://、ポート、パスは含めません。ウェブページの完全なURLを指定する必要はなく、ドメインの前に*.を付ける必要もありません。
FINAL,DIRECTにはドメインの指定がありません。前のルールに一致しなかったリクエストに対し、最終的にDIRECTを適用します。「残りの通信を直接接続する」という意味であり、「まず直接接続し、失敗したら自動的にプロキシへ切り替える」という意味ではありません。対象サイトを追加する場合は、新しいドメインルールをFINALより前に記述します。
DOMAIN-KEYWORDを使うケース
DOMAIN-KEYWORDはドメインに含まれるキーワードを照合するため、通常はDOMAIN-SUFFIXより広い範囲に適用されます。ウェブページ本文、URLのパス、検索語句は照合対象ではありません。たとえば次のmediaは、特定のサイトだけでなく、ドメインにこの文字列を含むリクエストに一致します。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,media,PROXY
FINAL,DIRECTここでは、1行目のドメインルールが意図的な例外です。login.example.comは直接接続し、example.comのほかの一致リクエストはプロキシ経由にします。さらに、ドメインにmediaを含む残りのリクエストもプロキシ経由になります。この例は適用範囲と順序を説明するもので、すべてのユーザーにmediaキーワードの追加を勧めるものではありません。プロキシ経由にするサイトを限定したい場合は、DOMAINまたはDOMAIN-SUFFIXを優先してください。
| ルールキーワード | 照合例 | 適用範囲 |
|---|---|---|
| DOMAIN | login.example.com | 指定したドメインだけに一致し、ほかのサブドメインには自動的に適用されません。 |
| DOMAIN-SUFFIX | example.com | 指定したドメインとそのサブドメインに一致し、サイト単位の振り分けに適しています。 |
| DOMAIN-KEYWORD | media | ドメイン内の文字列に一致するため、意図していないドメインまでプロキシ経由になる場合があります。 |
| FINAL | ドメイン指定は不要 | それまでに一致しなかったリクエストを処理するため、Ruleセクションの末尾に置きます。 |
ルールの順序：最初に一致したルールを適用
Ruleセクションのルールは上から順に照合されます。有効なルールに一致すると、そのルールのポリシーが適用され、「より具体的な」ルールを探して照合を続けることはありません。範囲の広いルールより前に具体的な例外を置き、FINALを末尾に配置することが、ルール設定で最も重要です。
前のセクションの例で、DOMAIN-SUFFIX,example.com,PROXYをDOMAIN,login.example.com,DIRECTより前に置くと、login.example.comは先にPROXYに一致し、後ろにあるDIRECTの例外は適用されません。同様に、FINALを先に置くと、その後のルールは意図したとおりに機能しません。
- 具体的な例外を先に設定：ログイン用ドメインを直接接続する場合は、該当するDOMAIN-SUFFIXより前にDOMAINを置きます。
- 次にサイトの範囲を設定：DOMAIN-SUFFIXで、プロキシ経由にするメインドメインとサブドメインをまとめます。
- キーワードの追加は慎重に：DOMAIN-KEYWORDは適用範囲が広いため、追加後は一致してはいけないドメインでもテストしてください。
- 最後にフォールバックを設定：残りを直接接続する場合はFINAL,DIRECTを使い、それより前に広範囲へ適用されるルールがないか確認します。
既存の設定にRULE-SET、GEOIP、IP-CIDRがある場合は、新しく追加した2行だけでなく、それらも確認してください。これらが前にあり先に一致すると、リクエストには従来のポリシーが適用されます。新しいルールをファイルの末尾、特にFINALの後ろに追加しても、適用されるとは限りません。
IP-CIDR、GEOIPとドメイン振り分けの違い
DOMAIN-SUFFIXはドメイン、IP-CIDRは接続先IPが属するネットワーク範囲、GEOIPはIPの地理的な分類を使って照合します。3つは照合の基準が異なります。限られたサイトだけをプロキシ経由にする場合は、まずドメインルールを使うと確認しやすくなります。同じサイトでもIPが変わることがあり、複数のサイトが同じIPアドレスを共有する場合もあるためです。
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT192.0.2.0/24は文書内の例示用ネットワークであり、実際のウェブサイトのアドレスとしてそのまま使うものではありません。no-resolveは、このIPルールとの照合だけを目的としたドメイン解決を避けるための指定で、すべてのDNSを無効にするものではありません。GEOIP,CN,DIRECTは、接続先IPがCNに分類された場合に直接接続することを示します。「特定のドメインは必ずプロキシ経由にする」という明確な要件の代わりにはなりません。
- アプリがIPアドレスへ直接接続し、リクエストに利用可能なドメイン情報がない場合、ドメインルールに一致しないことがあります。
- サイトが複数のコンテンツ配信用ドメインを使っている場合、メインドメインだけではすべてのリソースをカバーできないことがあります。
- HTTPSでよく使われる宛先ポートは443ですが、この記事のドメインルールは443番ポートを条件にせず、ブラウザだけを対象とするものでもありません。
- DNSの名前解決経路と接続先への通信経路は、それぞれ確認する必要があります。PROXYに一致しても、すべての名前解決リクエストが同じ経路を使うとは限りません。
保存後にリクエストログで確認する
Connectivity Testで結果が表示されても、該当のテスト条件下で接続先が一定の接続性を備えていることを示すにとどまり、特定のサイトが指定ルールに一致した証明にはなりません。「対象サイト」「通常のサイト」「例外ドメイン」の3種類のリクエストを比較し、リクエストログで宛先、適用ルール、ポリシーを確認してください。
- 設定を保存し、Configで編集したファイルが現在選択されていることを確認します。
- Home → Global Routingが引き続きConfigになっていることを確認します。Settings → On Demandを設定している場合は、自動接続の動作によって接続状態が変わっていないかも確認してください。
- 対象ページの既存の接続を閉じ、必要に応じてShadowrocketを再接続してから、新しいページリクエストを開きます。
- 該当するリクエストログを確認します。対象ドメインはDOMAIN-SUFFIXなどの明示的なルールに一致し、ポリシーはPROXYになっているはずです。指定範囲外のドメインはFINALに一致し、DIRECTが適用されるはずです。
- リソースの読み込みに失敗した場合は、実際のリソースドメインを記録してください。ブラウザのアドレスバーに表示されたメインドメインだけで判断しないでください。
以下は、ネットワークエラーやログに表示されることのある一般的なエラーメッセージです。具体的な表示はリクエスト元やシステムによって異なります。これらのエラーは接続の失敗を示すもので、ルールの構文に誤りがあると断定できるものではありません。まず適用されたポリシーを確認し、接続先、直接接続の経路、対象サービスのどこに問題があるかを切り分けてください。
エラー：Connection refused
原因：接続先のアドレスまたはプロキシのポートが接続を拒否しています。対処法：まずリクエストに適用されたポリシーがPROXYかDIRECTかを確認し、対応するアドレスとポートが正しいか確認してください。プロキシ接続先の情報は、利用中のサービス提供元から入手した設定と一致している必要があります。
エラー：Operation timed out
原因：接続または応答が制限時間内に完了しませんでした。現在のネットワーク、接続先、対象サイトが関係している可能性があります。対処法：まずConnectivity Testを実行し、同じサイトのリクエストログと照らし合わせてください。本来はプロキシ経由にするリクエストがFINAL,DIRECTに一致している場合は、ルールの適用範囲を優先して見直します。
特定サイトの振り分けに関するよくある質問
ルールを設定したのに、なぜすべてのサイトがプロキシ経由になるのですか？
まずHome → Global RoutingでProxyではなくConfigが選択されていることを確認します。次に、現在のConfigに先に一致する範囲の広いPROXYルールがないか、FINALがPROXYになっていないかを確認してください。一度に変更する条件は1つに絞り、新しいリクエストで検証します。複数の設定を同時に変更すると、比較が難しくなります。
ページは開くのに画像やログインが失敗する場合、どのルールを追加すればよいですか？
まずリクエストログで、読み込みに失敗したリソースの実際のドメインを確認します。独立した別のドメインであれば、そのドメインにDOMAINまたはDOMAIN-SUFFIXのルールを追加し、FINALより前に配置します。ページの一部が読み込めないからといって、よくあるキーワードまで範囲を広げると、関係のないサイトも含まれるため避けてください。
既存のサブスクリプションを更新したら、カスタムルールが消えたのはなぜですか？
サーバーのサブスクリプションとリモートConfigは別のものです。サーバーリストを更新してもRuleが変更されるわけではありませんが、リモート設定を再取得すると、そのファイル内のローカル変更が上書きされることがあります。カスタムルールは管理できるローカルコピーに保存し、更新後に現在選択されているConfigとRuleセクションを確認してください。
別のプロトコルに切り替える場合、DOMAIN-SUFFIXを書き直す必要はありますか？
通常は必要ありません。ドメインルールはリクエストをどのポリシーに渡すかを決め、プロキシのプロトコルは接続先への接続方法を決めます。役割は異なります。接続先を切り替えた後は、PROXYの参照先として利用可能なものが選択されていることを確認し、同じ対象が引き続き元のルールに一致するかを確認します。接続先の不具合を隠すためにドメインルールを変更しないでください。
最終的には、内容を把握しやすい最小限のルールセットに整理します。明示したサイトにはPROXYを適用し、必要な例外を前に置き、それ以外はFINAL,DIRECTで処理します。ドメインを追加するたびに、プロキシ経由にするリクエストと直接接続するリクエストをそれぞれ確認してください。接続のオン・オフだけを見るより、設定結果を確実に検証できます。