Shadowrocketで指定したサイトだけをプロキシ接続するには、Global RoutingをConfigに設定し、使用中のConfigに対象ドメインのPROXYルールを追加したうえで、残りの通信をFINAL,DIRECTで処理する必要があります。自分で用意した接続情報がある方向けに、設定の準備、ルールの追加、接続ログでの確認方法を順に説明し、「ルールに一致していない」場合と「一致後に接続できない」場合の見分け方も解説します。
1. Configを選び、使用中の設定を確認する
ルールを正しく書いても反映されない場合は、まずHome → Global Routingを確認してください。ドメインごとに接続先を振り分けるには、Configを選択します。Configのファイルだけを編集してGlobal RoutingをProxyのままにしていると、「指定したサイトはプロキシ、その他のサイトは直接接続」という動作を確認できません。
ここでは今回の操作に関係する3つの選択肢だけを説明します。Global Routingの全項目を網羅するものではありません。Configは設定ファイルのルールを使うモードで、ルール内のPROXYは通信をプロキシのポリシーに渡す指定です。名前は似ていますが、別の設定です。
Config
おすすめ現在有効なConfigのルールに従って通信を処理します。対象ドメインはPROXY、それ以外はFINAL,DIRECTで直接接続できます。
適した用途:指定したドメインだけをプロキシ接続する。
Proxy
対象となる通信をプロキシに渡します。この記事で説明するドメイン一覧による振り分けにはなりません。一時的に使った後はConfigに戻してから振り分けをテストしてください。
適した用途:既存のプロキシ接続で対象サイトにアクセスできるか一時的に確認する。
Direct
対象となる通信を直接接続します。ConfigにPROXYのドメインルールが書かれていても、自動的にプロキシ接続へ切り替わることはありません。
適した用途:現在のネットワークで対象サイトに直接接続できるか確認する。
結論:テスト条件を固定する
変更を始める前に、現在のConfigファイル名、選択中の接続、Global Routingを記録してください。一度に変更するルールは1項目に絞ります。そうしないと、設定の切り替え、接続の変更、ルール自体のどれが原因なのか判断できません。
2. 4ステップで最小限のルール設定を作る
まずHomeで使用可能な接続が選択されていることを確認し、Configで設定を編集します。既存のサブスクリプションで接続情報を管理していても、この記事で必要なドメイン振り分けルールが有効とは限りません。接続リストの更新とConfigのルール編集は、別々に確認してください。
-
Configをバックアップする
Configを開いて選択中のファイルを確認し、利用可能な共有または書き出し操作で元の内容を保存します。既存のConfigを編集する場合は、DNS、Host、ポリシーの設定を残してください。ドメインを追加するためにファイル全体を上書きしないようにします。
-
ルールを編集する
Configで使用するファイルを開いて編集し、既存の
[Rule]セクションに以下の例を追加します。すでにセクションがある場合はその部分を編集し、同じ名前のセクションを重ねて追加しないでください。 -
ファイルを有効にする
保存後、Configに戻り、編集したファイルが選択されていることを確認します。名前が似ている別のConfigを選んでいないか注意してください。ファイルを保存しただけでは、そのファイルに切り替わったことにはなりません。
-
接続を選択する
Home → Global Routing → Configに戻り、Homeで使用する接続が選択されていることを確認してから、接続を開始するか再接続します。その後、新しい通信を発生させてルールの結果を確認してください。すでに開いているページだけで判断しないでください。
3. DOMAIN-SUFFIXでプロキシ対象のドメインを指定する
以下のドメインは構文の例であり、接続先のアドレスではありません。実際にアクセスするサイトのドメインに置き換えてください。ルールのドメインにはhttps://、ポート、パスを含めません。たとえば対象ページがhttps://www.example.com/accountの場合、照合するドメインはwww.example.comです。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,example.org,PROXY
FINAL,DIRECT
DOMAIN-SUFFIX,example.com,PROXYは、example.com自体とそのサブドメイン(www.example.comやapi.example.comなど)に一致します。「ドメイン名にexampleが含まれていれば一致する」という意味ではないため、notexample.comは対象になりません。
特定のホスト名だけをプロキシ接続し、同じドメイン内のほかのホストは対象にしない場合は、より範囲の狭いDOMAINルールを使います。たとえば以下のルールはapi.example.comだけに一致します。www.example.comへのアクセスはこの行に一致せず、後続のルールを検索します。
[Rule]
DOMAIN,api.example.com,PROXY
FINAL,DIRECT
DOMAINとDOMAIN-SUFFIXでは、同じドメイン内のページパスを区別できません。同じサイトの/videoはプロキシ接続し、/newsは直接接続したい場合でも、DOMAIN-SUFFIXの後ろにパスを追加して実現することはできません。要件がドメイン単位なのか、ページの内容単位なのかを確認してから、この記事の方法が適しているか判断してください。
4. ルールの順序とFINALの位置を確認する
ルールは上から順に照合され、一致すると通常は後続のルールを検索しません。より広い範囲のルールに対する例外は、そのルールより前に記述します。FINALは残りの通信を処理するフォールバックであり、照合対象のドメインルールより前に置いてはいけません。また、複数のConfigにあるFINALを同じルールセクションにそのまま重ねて記述しないでください。
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
この例では、account.example.comは先にDIRECTに一致し、同じexample.com内のほかのホストは後続のPROXYルールに一致できます。上の2行を入れ替えると、範囲の広いDOMAIN-SUFFIXが先に一致し、前述の直接接続の例外が意図どおりに機能しません。
- 既存のプロキシルールを確認する:ConfigにほかのPROXYルールがあると、新しい一覧に含めていないサイトもプロキシ接続される場合があります。「このドメインだけをプロキシ接続する」には、追加した2行だけでなく、有効なルールセクション全体を確認してください。
- ルールセットの参照を確認する:外部ルールセットやほかのポリシーが通信に影響することもあります。原因を切り分ける場合は、バックアップを取ったうえで最小限のConfigを使って検証し、その後ルールを1つずつ戻してください。
- ドメインとIPを区別する:GEOIPはIPの所在データベースに基づき、IP-CIDRはIPアドレスの範囲に基づいて照合します。いずれもサイトのドメイン一覧とは異なります。
- 共有アドレスに注意する:複数のサイトが同じサーバーアドレスを使っている場合があります。対象サイトへの接続記録にIPが表示されたという理由だけで、範囲の広いIP-CIDRプロキシルールを追加しないでください。
5. 接続ログで振り分け結果を確認する
ページが開けても、そのアクセスに成功したことしか分からず、想定したポリシーが使われた証明にはなりません。対象のホスト名、一致したルール、実際に適用されたポリシーをあわせて確認してください。テストでは対象サイトと一覧にないサイトにそれぞれ新しいリクエストを発生させ、既存の接続やページキャッシュによる影響を減らします。
- Home → Global Routingが引き続きConfigになっていること、Configで編集したファイルが選択されていること、接続が有効になっていることを確認します。
- 対象サイトに再度アクセスし、アプリ内の接続ログから該当するホスト名を探します。想定したDOMAINまたはDOMAIN-SUFFIXルールに一致し、PROXYに渡されているか確認してください。
- プロキシ対象の一覧に含めていないサイトにアクセスし、該当する通信がFINALで処理され、DIRECTに渡されているか確認します。比較対象として、同じサイトの別のサブドメインを使わないでください。
- リダイレクト、ログイン、画像の読み込みがある場合は、新たに発生したリクエストのホスト名もそれぞれ確認します。ページのメインドメインと依存するリソースのドメインを分けて記録し、アドレスバーだけを見て判断しないでください。
| 確認できた現象 | まず確認する項目 | 次の操作 |
|---|---|---|
| 対象の通信がFINAL,DIRECTに一致する | ドメインの範囲と有効なConfig | ログに記録された実際のホスト名を確認し、設定したドメインサフィックスに含まれるか調べます。 |
| 対象がPROXYに一致するが、リクエストがタイムアウトする | 選択中の接続とサーバーへの到達性 | ルールは変更せず、既存の接続情報と接続テストの結果を確認します。 |
| 一覧にないサイトもPROXYに接続される | Global Routingとほかのプロキシルール | Proxyになっていないことを確認し、より上位にあるルールやルールセットの参照を確認します。 |
| ページの文字は表示されるが、画像やログインに失敗する | リソースと認証に使われるドメイン | 失敗したリクエストのホスト名を調べ、必要に応じて対象を絞ったルールを追加します。 |
これは接続ログを読み取る際の目安であり、あらゆるネットワーク環境における速度測定の結果ではありません。ログで正しくPROXYに一致している場合、同じドメインを繰り返し追加しても解決しません。その場合は接続設定、サーバーの状態、接続先によるアクセス制限を確認してください。
6. リソースドメイン、DNS、自動接続の影響を確認する
Webページは、メインサイト、ログイン用API、画像のドメイン、独立したコンテンツ配信ドメインなどに同時にアクセスすることがあります。メインサイトにDOMAIN-SUFFIXを追加しても、ページが必要とするすべての通信が同じサフィックスに含まれるとは限りません。失敗したリクエストのログからドメインの用途を確認してから、ルールを追加するか決めてください。1つのリソースを読み込むために、共用ドメインを広範囲にプロキシ接続しないようにします。
- DNSとポリシーは分けて確認する:ドメインの名前解決に失敗すると、通信が想定した接続処理に進まないことがあります。まず名前解決できるか確認してください。すべての失敗をFINALの問題と決めつけず、1回のテストでDNSとルールを同時に変更しないでください。
- IPアドレスを直接使う通信は別に確認する:ログに対象IPだけが記録され、照合に使えるドメインがない場合、DOMAIN-SUFFIXに必ず一致するとは限りません。まずリクエストの発生元を確認し、IP-CIDRが本当に必要か検討してください。
- On Demandは接続状態に影響する:Settings → On Demandで自動接続の設定を確認してください。On Demandは条件に応じて接続を確立する機能であり、DOMAIN-SUFFIXやFINALの代わりにはなりません。比較のため手動で切断する場合は、自動的に再接続されていないかも確認してください。
- 古いページより新しいリクエストで確認する:確立済みの長時間接続やアプリ内キャッシュによって、以前の結果が表示され続けることがあります。ルールを保存して再接続した後、対象サイトに新しくアクセスし、該当するログを確認してください。
トラブルシューティングのためにOn Demandを一時的に変更した場合は、確認後に必要な設定へ戻してください。「接続スイッチが常にオン」であることだけでは、実際に適用されたポリシーを確認できません。接続状態から分かるのは通信の受け入れが確立しているかどうかで、個々の通信の行き先はルールのログで確認します。
7. 元に戻せるルール一覧を保管する
動作を確認できたら、正常に使えるConfigを保存し、追加した各ドメインの用途を記録します。後から機能が動かなくなった場合は、新しいリクエストドメインが増えていないかを確認し、必要な範囲だけ調整してください。ルールはプロキシの範囲を広げ続けるのではなく、実際の要件に合わせて管理します。
- 変更前に毎回バックアップを取り、一度に追加または調整するのは関連するドメインのグループ1つにします。
- 保存するたびに、Configで選択中のファイルとHome → Global Routing → Configを確認します。
- テストのたびに、PROXYに接続されるべきリクエストとDIRECTに接続されるべきリクエストを1つずつ確認します。
- 接続情報を更新した後は、選択中の接続が引き続き使用できるか確認します。ドメインルールが正しくても、接続情報が常に有効とは限りません。
Shadowrocketはクローズドソースの有料アプリです。アプリの買い切り購入と接続サービスの契約は別です。この記事は、ご自身で接続サービスと接続情報を用意していることを前提としています。主にiPhoneとiPad向けで、Mac、Apple TV、Apple Visionとの互換性もApp Storeのページで確認できます。システム要件と購入条件はApp Storeの記載に従ってください。入手先はApp Storeのみです。