この記事は、Shadowrocketに自分のConfigを読み込み済みで、一部のサイトだけをプロキシ経由にしたい方を対象としています。基本は、対象ドメインをDOMAIN-SUFFIXルールに追加し、末尾にFINAL,DIRECTを置いて、Global RoutingをConfigに設定することです。最小限のルール、編集手順、接続確認、よくあるトラブルの順に解説します。例示のドメインは構文説明用で、接続サービスを示すものではありません。
1. ホワイトリスト型ルーティングの範囲を確認する
ここでいう「ホワイトリスト」とは、プロキシ経由にする対象の一覧です。リストにあるドメインはPROXYへ、それ以外のリクエストはDIRECTで処理します。アクセス制限のリストではなく、対象外のサイトへの接続を禁止するものでもありません。DIRECTは接続先へ直接接続する指定であり、Shadowrocketをオフにするという意味ではありません。接続は引き続きローカルトンネルやルールによる処理を経る場合があります。
ルールを適用するには、まずHome → Global RoutingでConfigを選択します。ProxyやDirectを選んでも、ドメインごとに振り分けるこのConfigの検証にはなりません。Sceneはシーンに応じたルーティング選択に使うため、今回の確認基準にはしません。先にConfigに固定してからルールを編集すれば、モードの変更をルール適用と取り違えずに済みます。
ルールは上から順に確認され、一致すると該当するポリシーが適用され、後続の通常ルールは確認されません。そのため、先に対象を含むDIRECTルールがあると、追加したプロキシルールに到達しないことがあります。ホワイトリスト型ルーティングでは、ドメインが記載されているかだけでなく、ルールの内容と順序も確認してください。
2. DOMAIN-SUFFIXとFINAL,DIRECTで最小ルールを作る
以下はルール部分だけを示した最小例です。example.comとexample.netは説明用のドメインです。実際には振り分けたいサイトのドメインに置き換えてください。既存のConfigには通常ほかのセクションも含まれます。この例は[Rule]だけを示しているため、接続設定全体として元のファイルと置き換えないでください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,example.net,PROXY
FINAL,DIRECTDOMAIN-SUFFIX,example.com,PROXYは、example.comに加えて、www.example.comやassets.example.comなどのサブドメインにも一致します。任意の文字列を含むかどうかで判定するルールではないため、notexample.comやexample.com.other.testには一致しません。ルールにはドメインだけを指定し、https://、パス、クエリパラメータ、ポート番号は含めません。
FINAL,DIRECTは、それまでのルールに一致しなかったリクエストを処理するため、対象となるすべての個別ルールより後ろに置きます。先頭に置くと、後続のドメインルールが期待どおりに機能しません。PROXYはサーバーアドレスではなく、プロキシのポリシーを表します。使う前に、Homeで自分がすでに利用している有効なサーバーが選ばれていることと、Configによって実際の送信先が意図せず変わっていないことを確認してください。
まとめ：まず最小構成で確認する
最初の確認では、対象ドメインを1つと末尾のフォールバックルールだけにします。プロキシ接続と直接接続でそれぞれ再現できる結果を確認してから、対象を1つずつ追加してください。
3. Configを編集して有効にする
編集前に、Homeで選択中のサーバー、Global Routingのモード、Configで使用中のファイルを記録します。唯一のファイルを上書きするより、Configを複製して編集するほうが元に戻しやすくなります。元のファイルがリモートで管理されている場合は、ローカルコピーを残してください。リモートConfigを更新すると、ローカルでの変更が上書きされることがあります。
-
元のConfigを残す
Configを開き、現在使用中のファイルを見つけて、ファイル操作からコピーを保存するかバックアップをエクスポートします。コピーを見分けられることを確認してから編集してください。サーバーのサブスクリプション更新をルールファイルのバックアップとして扱わないでください。
-
ルールセクションを編集する
Configで編集するファイルを開き、テキスト編集画面から既存の
[Rule]を探します。対象のDOMAIN-SUFFIXルールをこのセクションに追加し、同名のセクションを重複して作らないでください。ルールの区切りには半角カンマを使います。 -
フォールバックを確認する
ルールセクション全体の順序を確認し、
FINAL,DIRECTを末尾に置きます。「指定したドメインだけをプロキシ経由にする」には、既存のGEOIP、IP-CIDR、ルールセットの参照、その他のプロキシルールも確認し、対象範囲が意図せず広がらないようにしてください。 -
ファイルを選択する
保存したらConfigに戻り、名前が似たリモートファイルではなく、編集したファイルが選択されていることを確認します。ファイルを保存したことと、そのファイルを使用するよう選択したことは別なので、両方を確認してください。
-
Configを有効にする
Home → Global Routing → Configに戻り、すでに利用しているサーバーを選択して接続します。テスト用のリクエストをもう一度実行してください。以前の接続が再利用されている場合は、いったん切断して再接続してから、テストするページを開き直します。
手動でオフにした接続が自動的に再びオンになる場合は、Settings → On Demandの現在の設定を確認してください。On Demandは条件に応じた接続動作を制御する機能であり、サイトのプロキシ対象リストを定義するものではありません。再現性のある確認を行うには、元の設定を記録したうえで、関連する自動接続条件を一時的にオフにし、確認後に元へ戻します。
4. サブドメインの例外とサイトの関連リソースを扱う
メインドメインの大部分をプロキシ経由にしつつ、特定のサブドメインだけを直接接続する場合は、より具体的な例外を先に書き、その後に範囲の広いサフィックスルールを置きます。たとえば、status.example.comだけを直接接続する場合は、以下の順序にします。DOMAINは指定した完全なホスト名だけに一致し、その配下のサブドメインには自動で適用されません。
[Rule]
DOMAIN,status.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTサイトを単一のドメインだけで構成されていると考えることはできません。メインページ、ログインAPI、画像、フォント、動画がそれぞれ異なるホストから配信される場合があります。ページのURLに対応するメインドメインだけを追加すると、テキストは表示されるのに画像が出ない、ページは開くのにログインできない、といったことがあります。その場合は失敗したリクエストの実際のホスト名を確認し、必要に応じて対象に追加してください。ルール不足を隠すために、すべての通信をプロキシへ切り替えるのは避けてください。
- 同じメインドメインのサブドメイン：
cdn.example.comはDOMAIN-SUFFIX,example.com,PROXYの対象に含まれるため、同じポリシーを重ねて指定する必要はありません。 - 別ドメインのリソース：ページが
static.example.netを必要とする場合は、まずDOMAIN,static.example.net,PROXYで個別に指定し、必要に応じてサフィックス全体に対象を広げます。 - IPアドレスへの直接アクセス：DOMAIN-SUFFIXだけでは一致を保証できません。IP-CIDRはアドレス範囲に一致し、GEOIPはアドレスの地域に基づいて判定します。いずれもドメインサフィックスの代わりにはなりません。
- URLのパス：
example.com/accountとexample.com/newsはホスト名が同じです。ここで使うドメインルールでは、片方のパスだけをプロキシ経由にすることはできません。
IP-CIDRを追加する場合は、共有アドレスにも注意してください。同じIPアドレスが複数のドメインで使われていると、アドレス単位のプロキシ指定によって、ドメイン一覧にないリクエストにも影響する場合があります。「指定したサイトだけ」を対象にするには、まず実際のホスト名を基準に設定してください。アドレス範囲と影響を把握している場合に限り、IPアドレスのルールを追加します。
5. ページが開くかではなく、ルールの一致結果を確認する
ページが開いても、PROXYが使われたとは限りません。ページが開かない場合も、ルールの記述ミスとは限りません。確認時は、Shadowrocketの接続記録またはログで、接続先ホスト、適用されたルール、最終的なポリシーを確認してください。サーバーのレイテンシテストだけで判断せず、新しく確立した接続を確認します。
- 対象リスト内から実際のサイトを1つ、リスト外から現在のネットワークで直接アクセスできるサイトを1つ選び、それぞれの完全なホスト名を記録します。例示のドメインは構文説明用であり、実際のテスト先の代わりにはなりません。
- Configモードで接続し、リスト内のサイトに再アクセスします。接続先が該当するDOMAIN-SUFFIXまたはDOMAINルールに一致し、ポリシーがPROXYになっていることを確認してください。続けて、実際に使われたプロキシの送信先も確認します。
- リスト外のサイトにアクセスし、そのリクエストがFINALに一致しているか、ポリシーがDIRECTになっているかを確認します。別のルールに一致した場合は、Configに残っているルールを見直してください。
- メインページと読み込みに失敗したリソースの記録をそれぞれ確認します。同じページでPROXYとDIRECTが混在していても、必ずしも異常ではありません。各ホストの結果が対象リストどおりかを確認してください。
- 一度に変更するのは1項目だけにし、接続を確立し直して同じテストを繰り返します。変更前後の接続先、ルール、結果を記録しておけば、どの変更が影響したかを特定しやすくなります。
ドメイン名の名前解決に失敗すると、その後の接続が確立されないことがあります。アプリ内蔵の暗号化DNSやIPアドレスを直接使うリクエストも、確認できるドメイン情報に影響する場合があります。ドメインルールの修正と同時に複数のDNS設定を変えないでください。まず現在の設定を保ったまま名前解決の結果を確認し、問題があれば別途対処します。確立済みの長時間接続については、再接続後に新しい記録を確認してください。
6. ルールの問題と接続の問題を症状から切り分ける
異常が起きたら、まず2段階で確認します。1つ目はリクエストが想定したルールに一致しているか、2つ目は選択された送信先で接続を完了できるかです。以下はネットワーク接続で発生することのあるエラー原文です。毎回同じ画面にまったく同じ形式で表示されるとは限らないため、記録にある接続先アドレスと送信方向もあわせて確認してください。
エラー：Connection timed out
原因：制限時間内に接続が完了しなかった状態です。プロキシサーバーへの接続時、または接続先サイトへの接続時に起こる場合があり、このメッセージだけでDOMAIN-SUFFIXが機能していないとは判断できません。
対処：まず適用されたポリシーを確認します。PROXYに一致している場合は、自分がすでに利用しているサーバーへの接続と同じ接続先へのアクセスをテストし、プロキシ側の送信障害か接続先サイトの到達不能かを切り分けます。
エラー：Connection refused
原因：接続先から拒否されています。接続先ポートで待ち受けていない場合や、サーバーアドレス・ポートが実際のサービス設定と異なる場合によく起こります。
対処：まずエラーがプロキシサーバーとサイトのどちらに対応しているか確認し、利用中のサービス提供元に既存Configのアドレスとポートを確認します。サイトのHTTPSポート443をそのままプロキシサーバーのポートに設定しないでください。
- すべてのサイトがプロキシ経由になる：まずGlobal RoutingがProxyのままになっていないか確認します。次に、Configに対象範囲の広いプロキシルールがないか、末尾が
FINAL,PROXYになっていないかを調べてください。 - リスト内のサイトが直接接続される：別のConfigファイルを使用していないか、上にDIRECTルールがないか、ドメイン指定にプロトコルの接頭辞やパスを誤って含めていないかを確認します。
- 一部のコンテンツだけ読み込めない：実際に失敗したリソースのドメインを確認します。すでにPROXYに正しく一致している場合はプロキシ接続を調べ、同じメインドメインのルールを繰り返し追加しないでください。
- 再読み込み後に変更が消える：更新しているのがリモートConfigなのか、サーバーのサブスクリプションなのかを確認してください。管理している内容はそれぞれ異なります。独自ルールはローカルコピーに保存し、更新後に差分を確認します。
まとめ：一致したルールの記録をもとに次の対応を決める
誤ったルールに一致した場合はルールと順序を修正し、正しいルールに一致しているのに接続できない場合は、該当する送信先を調べます。問題を切り分けて対処すれば、「リスト内はプロキシ、その他は直接接続」という設定範囲を保てます。
検証済みのローカルConfigと、リスト内・リスト外それぞれの固定テスト先を保存しておきます。サイトの追加、サブスクリプションの変更、リモートConfigの更新後も、同じ手順で確認してください。Shadowrocketのクライアント購入と接続サービスは別のものです。この記事では、自分で利用するサービス提供元とConfigをすでに用意していることを前提としています。