この記事は、Shadowrocketに利用可能なサービスを追加済みで、指定したサイトだけをプロキシ接続にしたい方を対象としています。ポイントは、Global RoutingをConfigに設定し、使用中のConfigの[Rule]に対象サイトのルールを記述してから、残りの接続をFINAL,DIRECTで処理することです。ルール例や編集手順、確認方法に加え、ドメイン・IP・DNSの違いも解説します。
1. Global RoutingがConfigになっているか確認
接続のオン・オフと通信の振り分けモードは別の設定です。接続をオンにすると通信がシステムのVPNトンネルを通りますが、すべての接続がプロキシを使うわけではありません。「通常はDIRECT、一部のサイトだけPROXY」にするには、Home → Global RoutingでConfigを選び、編集するConfigが有効になっていることを確認します。
この記事では、利用可能なプロキシサービスがすでにあることを前提としています。ルール内のPROXYは接続先を決めるポリシーであり、サーバーアドレスではありません。また、利用可能なサービスが自動で追加されるわけでもありません。まずHomeで利用可能なサーバーを選び、選択に影響するポリシーグループが既存のConfigに含まれていないか確認してください。
| 設定項目 | 動作 | この記事での設定 |
|---|---|---|
Proxy | すべての接続をグローバルプロキシモードで処理します。この記事のドメイン許可リストに基づく振り分けにはなりません。 | この記事のルール確認には使用しません。 |
Direct | すべての接続をグローバルDIRECTモードで処理します。 | 対象ドメインのルールを追加しても、自動的にプロキシ接続にはなりません。 |
Config | 現在有効なConfigのルールに従って接続の処理方法を選びます。 | この記事ではこの設定を使用します。 |
Scene | 設定済みのシーンに応じて動作します。 | シーンの切り替えとルール編集を混同しないよう、まずConfigに固定します。 |
Settings → On Demandでは、オンデマンド接続の条件を設定します。特定のサイトをDIRECTまたはPROXYにする設定ではありません。トラブルシューティングでは、「トンネルが接続されているか」と「接続がどのルールに一致したか」を分けて確認してください。ドメインルールを直すためにOn Demandを何度も切り替える必要はありません。
2. ルールは上から順に判定し、FINALは最後に置く
この記事の基本的なルール設定では、接続が上位のルールに一致すると、そのルールで指定されたポリシーが適用されます。後続のルールで結果が上書きされることはありません。そのため、具体的な例外を広範囲に一致するルールより前に記述し、残りの接続を処理するFINALは最後に置きます。
DOMAIN,api.example.com,DIRECT:この完全一致するドメインだけを対象にします。サイト全体をプロキシ接続にしつつ、特定のホストだけDIRECTにする場合に適しています。DOMAIN-SUFFIX,example.com,PROXY:example.comとそのサブドメイン(例:www.example.com)に一致します。notexample.comには一致しません。DOMAIN-KEYWORD,example-media,PROXY:ドメイン名に指定した文字列を含む接続に一致します。ドメインサフィックスより対象範囲が広いため、慎重に使用してください。IP-CIDR,203.0.113.0/24,PROXY,no-resolve:接続先のIPv4ネットワーク範囲に一致します。no-resolveは、このルールに一致させる目的でドメインを積極的に名前解決しないことを示します。FINAL,DIRECT:それまでのルールに一致しなかった接続にDIRECTを適用します。ドメインやネットワーク範囲を指定する必要はありません。
DOMAIN-SUFFIXが判定するのはドメインであり、URL全体ではありません。https://example.com/videoではなく、example.comを指定します。同じドメイン内のパスごとに振り分けることはできません。/video、クエリパラメーター、ページタイトルも判定対象外です。
3. 編集して使えるConfigのルール例
以下は[Rule]セクションのみの例で、サービス設定全体ではありません。ドメインとネットワーク範囲は書式説明用です。203.0.113.0/24は文書用の例示ネットワークであり、実際のサービスの確認には使えません。使用時は、振り分けたい実際のドメインまたは確認済みの接続先ネットワーク範囲に置き換え、不要な行を削除してください。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,example.net,PROXY
DOMAIN-KEYWORD,example-media,PROXY
IP-CIDR,203.0.113.0/24,PROXY,no-resolve
FINAL,DIRECT
先頭のルールはapi.example.comをDIRECTにする例外です。続く2つのサフィックスルールでは、指定した2つのサイトとそのサブドメインにPROXYを適用します。キーワードルールは書式例です。完全なドメインがわかっている場合は、誤一致を減らすため、通常はDOMAINまたはDOMAIN-SUFFIXを優先します。最後のIPルールで既知のネットワーク範囲を追加し、FINALでそれ以外の接続をDIRECTにします。
-
Configをバックアップする
Configを開き、現在有効なConfigを選択して、元ファイルのコピーを保存するかバックアップをエクスポートします。リモートConfigは編集可能なローカルコピーとして保存し、後の更新でローカルの変更が上書きされないようにしてください。
-
ルールを編集する
Configでローカルファイルの編集機能を開き、既存の[Rule]セクションを探します。必要なルールをそのセクションに追加し、[Rule]を重複して追加しないでください。既存のFINALの位置も確認します。
-
ポリシーを確認する
DIRECTとPROXYの綴りが正しいことを確認します。元ファイルのカスタムポリシーグループを残す場合は、該当するグループが引き続き存在することを確認してください。この記事の例は汎用のPROXYポリシーを使うため、同名のサーバーを新たに作成する必要はありません。
-
Configを有効にする
保存後、Configで編集したファイルを選択し、Home → Global RoutingでConfigを選びます。ファイルを保存しただけで有効化していない場合、現在の接続に適用されるルールは変わりません。
-
接続を再確立する
Homeの接続スイッチをいったんオフにしてから再びオンにし、ウェブページへアクセスし直します。既存の長時間接続では以前の接続先が維持されることがあります。該当するページやアプリを閉じてから再度試してください。
元のConfigにGEOIP,CN,DIRECTが含まれている場合、接続先IPの地域情報に基づいてDIRECTを選ぶルールです。ウェブサイトの言語やドメインサフィックスを判定するものではありません。通常はDIRECTにするこの記事の設定では、このルールは一般に不要です。残す場合は、特定サイトのPROXYルールより後、FINALより前に置き、先に一致しないようにしてください。
4. 接続ログで確認する。ページが開くかどうかだけで判断しない
ページが開いても、そのリクエストに応答があったことしかわかりません。どのポリシーが適用されたかを確認するには、接続ログの接続先ドメイン、接続先IP、一致したルール、適用されたポリシーを確認してください。ログへのアクセス方法や表示項目は画面によって異なる場合があります。新しく開始した同じ接続の実際の結果を確認することが重要です。
| テスト対象 | 一致するルール | 適用されるポリシー |
|---|---|---|
api.example.com | 先頭のDOMAIN例外ルール | DIRECT |
www.example.com | DOMAIN-SUFFIX | PROXY |
static.example.net | DOMAIN-SUFFIX | PROXY |
| 前のどのルールにも一致しなかった実際のサイト | FINAL | DIRECT |
表はルールから導かれる予想結果であり、例示ドメインへの接続テストではありません。実際の確認には、Configに設定した実際のサイトを使用してください。一度に変更するルールは1つにし、接続を新しく開始してから結果を記録します。ルールの順序、Configが有効になっていないこと、サービス自体に接続できないことを切り分けやすくなります。
- トップページは開くが画像が表示されない:画像、ログイン、APIのリクエストが別のドメインを使っていないか確認します。ログでプロキシが必要だと確認できたドメインだけを追加してください。範囲の広すぎるキーワードルールに置き換える必要はありません。
- 接続先IPしか表示されない:アプリがIPアドレスに直接接続しているか、その接続にドメイン情報が関連付けられていない可能性があります。この場合、ドメインルールはウェブサイト名だけでは一致させられません。
- IPルールに一致しない:実際の接続でIPv6が使われていないか確認します。IPv4用のIP-CIDRはIPv6には一致しません。IPv6にはIP-CIDR6ルールを別途検討する必要があります。
- ポート番号が異なる:一般的なHTTPSの接続先ポートは443ですが、この記事のドメインルールではポートを限定していません。DOMAIN-SUFFIXのドメイン末尾に
:443を付けないでください。
5. タイムアウトと名前解決エラーを分けて調べる
ルールでPROXYが選択されても、DNS、サーバーへの接続、接続先サービスの状態によって通信に失敗することがあります。以下はシステムのネットワークエラーでよく使われる表示です。実際のログに該当する内容がある場合に、その方向を調べてください。これらはルールの記述ミスに限ったエラーではなく、エラーコードだけでどちら側に問題があるかを判断することもできません。
NSURLErrorDomain Code=-1001
原因と対処:リクエストがタイムアウトした場合、接続時または応答待ちの段階で問題が起きている可能性があります。まず、その接続にDIRECTとPROXYのどちらが適用されたかを確認します。次に同じプロキシで、利用可能とわかっている別の接続先にアクセスし、特定サイトの問題かプロキシ経路の問題かを切り分けます。
NSURLErrorDomain Code=-1003
原因と対処:ホストが見つからない場合は、ドメインと名前解決結果を確認します。実際にアクセスしているドメインの綴りを確かめ、現在のConfigの[General]にあるdns-server設定を確認してください。変更前に元の値を保存し、DNSの調査をFINALルールの追加で代用しないでください。
ドメインルールは「このドメインを識別した後、どのポリシーを適用するか」を指定するもので、すべてのDNS問い合わせが同じプロキシ経由になることを保証するものではありません。DNSの参照元、名前解決経路、外向きの接続は関連していますが、それぞれ異なる設定です。no-resolveを付けたIP-CIDRルールについても、すべてのドメインリクエストが先に名前解決され、そのネットワーク範囲と照合されるとは限りません。
6. 一部のサイトだけを振り分ける際によくある質問
DOMAIN-SUFFIXを1つ追加するだけで十分ですか?
Global RoutingがConfigになっていることと、現在のConfigの末尾にあるFINALがDIRECTであることも確認してください。元ファイルにFINAL,PROXYが残っていると、どのルールにも一致しない接続には引き続きPROXYが適用され、通常はDIRECTにするという目的を達成できません。
*.example.comでサブドメインに一致させられますか?
DOMAIN-SUFFIXにはexample.comと入力し、アスタリスクやプロトコル、パスは付けません。この書式でルートドメインとそのサブドメインの両方に一致します。特定のホストだけを対象にする場合はDOMAINを使います。
更新後にルールが元に戻るのはなぜですか?
更新したのがHomeのサービスサブスクリプションか、Configのリモート設定かを確認してください。リモートConfigを再取得すると、ファイルの内容が上書きされる場合があります。カスタムの振り分けルールは独立したローカルConfigに保存し、更新後は現在有効なファイルを確認してください。
Hysteria2やWireGuardに変えると、ドメインルールを書き直す必要がありますか?
プロトコルはプロキシ接続の方式を決め、DOMAIN-SUFFIXは接続先の判定に使います。設定する階層が異なります。サービスを変更したら、新しいサービスが利用可能で、ルールが参照するポリシーが有効かを確認してから、同じサイトで再テストしてください。プロトコル名が変わっただけでドメインを書き換える必要はありません。
特定のサイトをプロキシ接続にすると、ほかのアプリにも影響しますか?
この記事のルールはアプリ名ではなく、接続先に基づいて振り分けます。ほかのアプリでも同じドメインへの接続はPROXYになる可能性があります。同じアプリでも一致しないドメインへの接続はFINAL,DIRECTになります。実際の接続ログで確認してください。