この記事は、Shadowrocketで利用する接続をすでに設定済みで、一部のサイトだけをプロキシ経由にしたい方を対象としています。設定を元に戻せるように保存し、ドメインの許可リストを作成して、FINAL,DIRECTをルールの末尾に追加したうえで、Global Routing → Configを選びます。設定後は、対象サイトとリスト外サイトについて新しい接続記録をそれぞれ確認し、マッチしたルールと実際のポリシーを確かめてください。ページが開くかどうかだけでは、ルーティングが正しいか判断できません。
1. デフォルトで直接接続する範囲を決める
「指定したサイトだけをプロキシ経由にする」とは、デフォルトを直接接続にする設定です。リストにあるドメインはプロキシルールにマッチし、それ以外の接続はFINAL,DIRECTに従います。設定したルールに従うものであり、ページの内容やユーザーの所在地を基準に自動分類するものではありません。リストにないログイン用、画像用、API用のドメインも、それぞれマッチしたルールに従って処理されます。
この記事では、利用者がすでに自身で契約したサービスとサブスクリプションを持っていることを前提とします。アプリの買い切りと接続サービスの契約は別です。ルールが選択するのは接続経路であり、サーバーアドレスや認証情報、接続経路を自動で用意するものではありません。作業前にHomeに利用可能な接続があり、選択中の接続がどのプロキシポリシーで使われるか確認してください。
2. Global RoutingではConfigを選ぶ
Home → Global Routingでは、現在の接続に設定をどう適用するかを選びます。ドメインルールを編集してもProxyまたはDirectのままでは、想定どおりにルーティングされないことがあります。この使い方ではConfigを選び、現在有効な設定のルールに従って接続を処理します。
Config
おすすめ現在の設定にあるルールでポリシーを決定します。ドメインのプロキシルールを先に、FINAL,DIRECTを最後に記述すると、デフォルトを直接接続にできます。
適した用途：リスト内のサイトだけをプロキシ経由にする。
Proxy
対象となる接続をプロキシ経由にします。この記事のドメインリストに沿って個別に振り分ける設定ではありません。プロキシ経路の一時的な確認には使えますが、ルールによる振り分けが有効になった証拠にはなりません。
適した用途：対象サイトにプロキシ経由で一時的にアクセスできるか確認する。
Direct
対象となる接続を直接接続にします。Configにドメインのプロキシルールがあっても、このモードではそのルールによる振り分けを期待できません。
適した用途：現在のネットワークで直接接続できるか比較して確認する。
Scene
設定済みのシーン条件に基づいてルーティングを決めます。サイトごとの振り分けと同じ意味ではありません。使用する場合は、シーンの定義と実際の選択結果を別途確認してください。
適した用途：明確なシーン切り替えの要件がある設定。
Settings → On Demandは、オンデマンド接続の条件を設定する項目であり、特定のサイトに適用するポリシーを決めるものではありません。トラブル対処時に複数の要因が同時に変わらないよう、まず現在のOn Demand設定を維持し、接続を有効にした状態でConfigのルールを確認してください。その後、オンデマンド接続が普段の使い方に合っているか個別に確認します。
3. 最小限のドメインルールを書く
以下では、構文を説明するために予約済みのサンプルドメインを使います。プロキシ接続の検証先としてそのまま使えるドメインではありません。実際にプロキシ経由にしたいドメインに置き換えてから、現在の設定にある[Rule]セクションへ記述してください。すでにセクションがある場合はその中のルールだけを編集し、同じ名前のセクションを重複して追加しないでください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,login.example.net,PROXY
FINAL,DIRECTPROXYはプロキシポリシーを表します。使用前に、現在の設定でこのポリシーがどのように解釈されるか、またHomeでどの接続が選ばれているかを確認してください。設定に独自のポリシーグループがある場合は、実在し、プロキシ経路を選択しているグループ名を指定します。任意の名前を書いても自動作成されるわけではありません。グループでDIRECTが選択されていると、そのグループにマッチしたドメインも直接接続される場合があります。
| ルール | マッチ範囲 | 確認ポイント |
|---|---|---|
DOMAIN-SUFFIX,example.com,PROXY | example.comとそのサブドメイン | www.example.comを含むが、otherexample.comは含まない |
DOMAIN,login.example.net,PROXY | login.example.netのみ | example.netやその他のサブドメインは対象外 |
FINAL,DIRECT | それまでのルールにマッチしなかった接続 | 末尾に置き、デフォルトの直接接続を維持 |
ドメイン欄にはhttps://、パス、クエリパラメータ、ポート番号を記述しません。たとえば、ウェブサイトのURLにある/accountはDOMAIN-SUFFIXのマッチ対象ではありません。接続がTCP 443を使っていても、ドメインルールがHTTPSだけにマッチするわけではありません。この種のルールはホスト名を基準に経路を選択するため、同一ドメイン内の特定のページだけをプロキシ経由にすることはできません。
- ルールは通常、上から順に確認され、先にマッチしたルールが優先されます。対象ドメインが前方にあるDIRECTルールにマッチすると、後続のプロキシルールは適用されません。
- FINALをドメインルールより前に置かないでください。FINALはフォールバックルールであり、設定セクションの冒頭に置く宣言ではありません。
- 既存のGEOIP、IP-CIDR、ルールセットによって、リスト外の通信先が変わることもあります。デフォルトで確実に直接接続させるには、ファイル末尾に3行追加するだけでなく、既存ルールも確認してください。
4. 設定を保存して接続に適用する
Configで編集したファイルと、現在有効なファイルが同じである必要があります。まず元の設定をバックアップし、用途を明確にしたローカル設定でテストすることをおすすめします。元の設定がリモートで管理されている場合は、次回の更新でローカルの変更が上書きされないか確認してください。検証時には正しくても、次の更新で以前のルールに戻ることがあります。
-
元の設定を記録する
Configを開き、現在有効な設定を確認して元ファイルをバックアップします。テスト後に戻せるよう、元のGlobal Routingの選択内容も記録してください。
-
ルールを編集する
Configで使用するローカル設定を開き、[Rule]セクションに実際のドメインルールを記述します。前方に競合するルールがないか確認し、確認対象となるすべてのルールの後ろにFINAL,DIRECTを置いてください。
-
保存して選択する
ファイルを保存し、Configに戻って、編集した設定が選択されていることを確認します。同名のリモートファイルや別のバックアップを選んでいないか注意してください。解析エラーが表示された場合は、まずルールの項目とポリシー名を修正します。
-
ルーティングを設定する
Home → Global Routing → Configに戻り、現在のプロキシ接続またはポリシーグループで実際に選択されている出口を確認してから、接続を開始します。システムからVPN構成の追加を求められた場合は、画面の案内に従って許可してください。
-
新しい接続を作成する
保存後に対象へのリクエストをもう一度実行します。以前の接続が再利用されないよう、接続を停止してから再開し、対象ページを開き直す方法もあります。その後、新しい接続記録を確認して、マッチしたルールを調べてください。
HomeのSubscribe更新は、主に既存サービスの接続情報を更新するもので、Configでルールファイルを切り替える操作ではありません。サーバーアドレスが更新された場合は、プロキシポリシーから利用可能な接続を選べるかも確認してください。ルールの振り分けが変わった場合は、有効な設定ファイルとルールの順序を優先して確認します。原因の異なる2つの問題として切り分けてください。
5. 接続記録でルールを確認する
検証には、リスト内のドメインとリスト外のドメインが少なくとも1つずつ必要です。実際にアクセスでき、用途が明確なサイトを選んでください。本文中のexample.comは構文例にすぎません。テストのたびに新しい接続記録を確認し、ドメイン、マッチしたルール、最終ポリシー、必要に応じてポリシーグループの出口を照合します。
| テスト対象 | 想定されるマッチ | 確認できたと判断する基準 |
|---|---|---|
| リスト内のメインドメイン | 該当するDOMAIN-SUFFIXまたはDOMAIN | 記録にプロキシポリシーが表示され、有効なプロキシ出口が選ばれている |
| リスト内のサブドメイン | 該当するDOMAIN-SUFFIX | FINALではなく、サフィックスルールが適用されていることを確認 |
| リスト外のドメイン | FINAL | 最終ポリシーがDIRECT |
| ログイン先または静的リソースのドメイン | そのドメインに設定されたルールに従う | 必要に応じてルールを追加し、再度確認する |
ページが開くのは、利用可能な経路でリクエストが完了したことを示すだけで、プロキシが使われた証拠にはなりません。逆にページが開かない場合も、DNS、サーバーへの到達性、ログイン状態、接続先の制限などが原因の可能性があり、DOMAIN-SUFFIXの記述ミスとは限りません。まず想定したルールにマッチしたかを確認し、次にポリシーの出口が利用可能かを調べ、最後にページが依存するドメインを確認すると、不要な設定変更を減らせます。
6. よくある状況と修正の順序
トラブル対処では一度に変更する項目を1つに絞り、変更前後の記録を残します。「ルーティングモード → 有効な設定 → ルールの順序 → ポリシーの出口 → サイトの依存先」の順に確認してください。ログインリクエスト1件を解決するためにデフォルトのポリシー全体をプロキシに変更すると、リストで振り分ける設定ではなくなってしまいます。
ルールを書いたのに、すべてのサイトがプロキシ経由になるのはなぜ？
まずHome → Global RoutingがConfigになっているか確認し、次に現在有効なファイルの末尾がFINAL,DIRECTになっているか調べます。この2点に問題がなければ、それより前に範囲の広いプロキシルールやルールセットがないか確認し、リスト外のドメインへの新しい接続で実際にマッチしたルールを調べてください。
メインサイトは開くのに、ログインや画像の読み込みに失敗するのはなぜ？
失敗した操作をもう一度実行し、新しく作成された接続記録からログイン先、API、リソースのドメインを確認します。それらがリスト内のサフィックスに含まれない場合は、必要に応じてDOMAINまたはDOMAIN-SUFFIXを追加してください。名前が似ているという理由だけで、関係のないサフィックス全体に範囲を広げないでください。
プロキシルールにマッチしたのに、記録では直接接続になっているのはなぜ？
ルールが参照するポリシーグループと現在の選択内容を確認してください。グループでDIRECTが選択されている場合や、確認した記録が変更前から残っている接続の場合があります。出口を確認したうえで接続を作り直し、ルール、ポリシーグループ、最終的な出口が一致しているか調べてください。
特定のApp内のサイトだけをプロキシ経由にできますか？
この記事のルールは宛先ドメインを対象とし、リクエストを送信したAppでは振り分けません。同じドメインへのリクエストは、別のAppからでも同じルールにマッチする場合があります。特定のApp内にあるページだけが対象なら、そのページが独立したドメインを使っているか確認してください。URLのパスをドメインルールの代わりに使うことはできません。
更新後にルールによる振り分けが動かなくなりました。サブスクリプションを再インポートすればよいですか？
まずConfigで有効なファイルを確認し、[Rule]セクションが置き換わっていないか調べてから、Global Routingを確認してください。Subscribeを更新するのは、Homeの接続情報が実際に期限切れまたは無効になっている場合に限ります。ルールの上書きと接続認証情報の変更は別の問題です。
最終確認では、次の3点を満たしていることを確認してください。対象ドメインが指定したプロキシルールにマッチすること、リスト外のドメインがFINAL,DIRECTにマッチすること、プロキシポリシーで想定した出口が実際に使われていることです。サイトを追加するときは必要なドメイン範囲だけを追加し、この両方向の確認を繰り返します。デフォルトで直接接続する範囲を保ち、対象が不明瞭な混在設定になるのを防げます。