利用できる接続があり、指定サイトだけをプロキシ経由にしたい方向けの記事です。まずConfigモードを確認し、設定内にドメインルールを順番に追加します。最後にFINAL,DIRECTで未一致の接続を処理し、リクエストログでページが読み込むドメインを確認します。「ページが開く」だけで振り分けが正しく動作していると判断しないことが大切です。
1. 対象プラットフォームと振り分けの前提
ShadowrocketはiPhone、iPad、Mac、Windows、Android、Linuxに対応しています。入手方法は2通りです。iPhone / iPad版はApp Storeから入手でき、価格は$2.99の買い切りです。システム要件はApp Storeの掲載内容をご確認ください。Mac（Appleシリコン／Intel）、Windows、Android、Linux版は無料です。各プラットフォームの入手方法はダウンロードページをご覧ください。以下ではiPhone / iPadのHome、Config、Settingsの画面項目を使って説明します。他のプラットフォームでは、対応する設定画面とルーティング項目を操作してください。
ルールが決めるのは、接続をどのポリシーに振り分けるかです。接続情報を作成するものではありません。この記事では、ご自身で用意したサービスとサブスクリプションがあり、正常に接続できることを前提としています。当サイトではノードやサブスクリプションを提供、販売、推奨していません。アプリの購入費用に通信サービスは含まれません。
- Home：ご自身の接続情報がインポートされ、利用可能な接続が選択されていることを確認します。接続テストを単独で実行してください。
- Config：現在適用されている設定ファイルを確認します。編集前に復元用のコピーを保存してください。
- Settings：テスト中はOn Demandを確認し、自動接続の条件によって接続状態が変わり、判定に影響しないようにします。
サブスクリプションからインポートした接続リストと、Config内のルールは別の設定です。接続リストを更新しても、設定ファイルの選択は変わりません。リモート設定を更新すると手動編集が上書きされる場合もあります。作業前に、変更対象が接続パラメーター、サブスクリプション項目、ルーティング設定のどれかを確認してください。
2. Global RoutingはConfigに設定
「指定サイトをプロキシ経由にする」には、ルールによる振り分けが必要です。Home → Global RoutingでConfigを選ぶと、現在の設定に基づいて接続が処理されます。特定のサイトが一時的に開けないからといってProxyに切り替えたままにしないでください。設定内容が同じでも、実際のルーティング範囲が変わります。
Config：設定に基づいて処理
推奨現在の設定にあるルールを読み込みます。指定ドメインに一致した場合はPROXYを使い、一致しない場合はFINAL,DIRECTに振り分けます。
用途：指定サイトだけをプロキシ経由にし、ほかは直接接続する設定。
Proxy：全体をプロキシ経由
クライアントの処理対象となる接続をすべてプロキシに振り分けます。この記事のようにドメイン一覧でサイトを区別しません。
用途：プロキシ接続が利用可能か一時的に確認する場合。確認後はConfigに戻します。
Direct：全体を直接接続
クライアントの処理対象となる接続をすべて直接接続として扱います。ドメインルールでPROXYが選ばれるかどうかの検証には使えません。
用途：ローカルネットワークから直接接続できるか一時的に確認する場合。
Scene：シーン設定
設定済みのシーンに従ってルーティングします。トラブル時はシーンの内容を確認してください。Sceneという表示だけで最終的なポリシーを判断することはできません。
用途：明確なシーン設定がある場合。この記事の検証開始時の設定としては使いません。
確認の順序：先にモードを確認し、その後ルールを編集
まずGlobal RoutingをConfigに設定し、現在の設定ファイル名を確認します。Proxyのままでは、DIRECTルールを追加し続けても、この記事で目指す振り分けを検証できません。
3. 最小限のルール：ドメイン一覧とFINAL,DIRECT
まずは範囲を絞り、プロキシが必要だと確認できたドメインだけを追加します。以下の予約済みサンプルドメインは構文の説明用であり、実際の回線やサイトを推奨するものではありません。既存の設定を使う場合は、該当する項目だけを既存の[Rule]セクションに追加してください。重複するセクションを新設したり、設定ファイル全体をこのサンプルで置き換えたりしないでください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,example.net,PROXY
FINAL,DIRECTDOMAIN-SUFFIX,example.com,PROXYは、example.comとwww.example.com、api.example.comなどのサブドメインに一致します。任意の文字列を含むかどうかの判定ではないため、別のドメインに似た文字列が含まれていても一致しません。ドメイン欄にhttps://、ポート番号、パス、クエリパラメーターは入力しません。
ルールは順番に評価され、最初に一致した項目でポリシーが決まります。FINAL,DIRECTは未一致の接続に適用するフォールバックであり、「日本国内のサイトを判定する」ものではありません。先行ルールに一致しなかった接続は、すべて直接接続を試みます。サイトに直接接続できなくても、FINALが機能していないとは限りません。現在のネットワークから直接アクセスできない可能性もあります。
PROXYはプロキシポリシー、DIRECTは直接接続を示します。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardなどのプロトコル名ではありません。プロトコルは既存の接続パラメーターで決まります。このシンプルなルール一覧を使う際は、PROXYが想定したプロキシ接続を参照していることも確認してください。同名のポリシーグループがDIRECTを指している場合があります。
4. DOMAIN-KEYWORDとIPルールの使い分け
名前に含まれるキーワードで照合する場合は、DOMAIN-KEYWORDを使えます。ただし、キーワードの適用範囲はドメインの末尾一致より広くなる傾向があります。正確なドメインがわかっている場合はDOMAIN-SUFFIXを優先してください。同じ文字列を含む複数のドメインを対象にする必要が明確な場合に限り、キーワードの使用を検討します。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECTこの例では、2行目がドメイン名にexampleを含む接続に一致するため、1行目にないドメインもPROXY経由になる可能性があります。「example.comだけに一致する」書き方と同じではありません。実際の設定では、通常は目的に合う書き方を一つだけ使います。短すぎるキーワードで手間を省こうとすると、プロキシの範囲が広がるおそれがあります。
| キーワード | 照合対象 | この記事での設定方針 |
|---|---|---|
DOMAIN-SUFFIX | ドメインとそのサブドメイン | 対象サイトのドメイン一覧を明確に指定 |
DOMAIN-KEYWORD | ドメイン名に含まれる文字列 | 照合範囲が広がることを確認してから追加 |
IP-CIDR | IPv4アドレスの範囲 | 対象のアドレス範囲がわかっている場合のみ使用 |
GEOIP | アドレスデータベース上のIPアドレスの地域情報 | サイトの言語、運営組織、ドメインの地域を判定するものではない |
FINAL | それまでのルールに一致しなかった接続 | 末尾に配置し、DIRECTを指定 |
たとえばIP-CIDR,192.0.2.0/24,PROXY,no-resolveに使われているのは、ドキュメント用のサンプルアドレス範囲です。実際のルール一覧にそのまま追加しないでください。no-resolveは、このルールへの一致判定のためにドメインを積極的に解決しないという意味で、すべてのDNSを無効にするものではありません。IPアドレスを直接指定した接続では、ドメインルールと照合できるホスト名がない場合があります。また、同じIPアドレスを共有するサイトが同じサービスとは限りません。サイトの名前解決で得たIPアドレス範囲を安易にPROXYに設定しないでください。
5. 設定を保存して順に検証
検証では、プロキシ対象のサイトと直接接続の比較対象の両方を確認してください。ホームページを1つ開くだけでは不十分です。ブラウザーのキャッシュ、既存接続の再利用、ページ内のサードパーティーリソースによって、設定変更が見えにくくなることがあります。ルールを変更するたびに保存してテスト接続を確立し直し、リクエストログで実際に一致したルールを確認してください。
-
設定をバックアップ
Configを開き、現在の設定のコピーを保存します。元のファイルがリモートURLから取得されたものなら、次回の更新でローカルの変更が上書きされないか確認してください。
-
ルールを編集
Configで対象設定の編集画面を開き、
[Rule]を探します。指定ドメインの項目をFINALより前に追加し、より上位に広範囲のルールがないか確認してください。 -
設定を有効化
保存して対象の設定を選択し、Home → Global Routing → Configに戻ります。既存のプロキシ接続が利用可能なことを確認し、必要に応じて一度切断してから再接続してください。
-
接続条件を確認
Settings → On Demandを開き、自動接続や切断によってテスト中の状態が変わらないよう、接続条件を確認します。その後Homeに戻り、接続が有効になっていることを確認してください。
-
リクエストを確認
一覧にあるサイトと、一覧にないサイトをそれぞれ再読み込みします。リクエストログで対象ホスト、適用ルール、実際のポリシーを確認し、それぞれPROXYとDIRECTになっていることを確かめてください。
ホームページのテキストは表示されるのに画像やログインが失敗する場合は、失敗したリソースの実際のホスト名を確認します。1つのページから、メインサイト、静的リソース、API、認証用ドメインへ個別にリクエストが送られることがあります。そのアクセスに必要で、プロキシ経由にする必要があると確認できたドメインだけを1つずつFINALより前に追加し、再テストしてください。公開リソース基盤全体を対象にするような広範囲のキーワードは追加しないでください。
6. よくある現象と対処方法
以下の順に確認します。「モード → 現在の設定 → ルールの順序 → 実際のリクエストドメイン」。一度に変更する要素を1つに絞り、変更前後の一致結果を記録すると、ルールの問題か、プロキシ接続、DNS、接続先サイト自体の問題かを切り分けやすくなります。
FINAL,DIRECTを設定したのに、多くのサイトがプロキシ経由になるのはなぜですか？
まずHome → Global RoutingがConfigになっているか確認し、次に現在の設定でFINALより前に広範囲のDOMAIN-KEYWORD、IPルール、外部ルールセットがないか確認します。先に一致したルールでポリシーが決まるため、末尾のFINALがその結果を覆すことはありません。参照されているポリシーグループの実際の選択先も確認してください。
指定したサイトがまだ直接接続になります。ドメインルールは効かないのでしょうか？
編集したファイルがConfigで現在選択されているファイルと同じか確認し、実際のリクエストホスト名を調べます。example.comにアクセスした後で別のドメインにリダイレクトされる場合は、移動先のホストも個別に指定する必要があります。ログにIPアドレスしか表示されない場合、URL欄だけを見てDOMAIN-SUFFIXが必ず一致すると判断することはできません。
メインサイトは開くのに、ログインや動画が失敗します。何を追加すればよいですか？
失敗する操作をもう一度行い、リクエストログで認証、メディア、APIへのリクエストを探します。プロキシ経由が必要だと確認できた依存ドメインだけをルールに追加し、FINALより前に配置してください。ログにすでにPROXYと表示されている場合は、既存の接続が利用可能か確認します。ドメインの照合範囲をむやみに広げないでください。
サブスクリプションを更新したらルールが変わりました。何度も編集しないためにはどうすればよいですか？
まず、更新したのがHomeの接続サブスクリプションか、Configのリモート設定かを確認します。接続サブスクリプションの更新では主に接続リストが更新されますが、リモート設定の更新ではファイルの内容が置き換わる場合があります。自分で追加したルールのコピーを保管し、更新後は現在の設定、ルールの順序、FINALのポリシーを確認してから、一覧内と一覧外のサイトを1つずつテストしてください。
最終的には、各ルールの一致結果を説明できるシンプルな一覧を用意します。指定したドメインはPROXY、それ以外の接続はFINAL,DIRECTで処理します。新しいサイトを追加するときも、「実際のドメインを確認する、必要最小限のルールを追加する、ポリシーを確認する」の手順で進め、キーワードをむやみに増やさないでください。設定の基本をさらに知りたい場合は、プロトコルガイドと用語クイックリファレンスをご覧ください。