Shadowrocketでドメインごとに直通とプロキシを使い分けるには、HomeのGlobal RoutingでConfigを選び、現在有効な構成にルールを設定します。この記事では、構成ファイルの確認、DOMAINとDOMAIN-SUFFIXの使い分け、ルールの優先順、設定後のテストまでを順に説明します。すでに利用するサービスとサブスクリプションを用意している方を対象とし、例に使うドメインは構文説明用です。
1. ルールを使う前にConfigを選ぶ
ルールは、通信先のドメインなどを条件にして、その接続をどのポリシーで処理するか決めます。ルールを記述しただけでは適用されません。Home → Global RoutingでConfigを選び、ルールを含む構成が現在有効になっていることを確認してください。
Proxyは通常、通信をプロキシ経由にするための切り分けに使い、Directはプロキシを経由しない直接接続の確認に使います。どちらもルールによる振り分けの確認には適しません。日常的にルールを使う場合はConfigを選びます。Configを選択していても、構成ファイルが空だったり、別の構成が有効だったりすれば、意図した結果にはなりません。
| Global Routing | 通信の扱い | ルール確認での用途 |
|---|---|---|
Config | 有効な構成のルールとポリシーに従う | ドメインごとの振り分けを確認する |
Proxy | プロキシ経由で接続する | ルールを介さない比較確認に使う |
Direct | 接続先へ直接接続する | プロキシを使わない状態を確認する |
構成ファイルのルールがどのように設定されているか分からない場合は、編集前に内容を確認してください。サブスクリプションから読み込んだ構成と、手動で編集する構成は同じものとは限りません。設定画面に編集項目が表示されない場合は、無理に別の設定を変更せず、使用中の構成の編集方法を確認してから作業します。
2. ドメインルールとポリシーを理解する
ルールは一般に、英語のカンマで区切った「ルールタイプ、対象、ポリシー」の順に記述します。次の例では、api.example.comへの接続だけをプロキシ経由にし、example.netとそのサブドメインは直接接続、それ以外はプロキシ経由にします。
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.net,DIRECT
FINAL,PROXY
DOMAINは指定したホスト名に一致します。DOMAIN,api.example.com,PROXYはapi.example.comを対象にしますが、別のホスト名であるwww.api.example.comまで含める指定ではありません。一方、DOMAIN-SUFFIX,example.net,DIRECTはドメインとそのサブドメインを対象にするため、example.net、www.example.net、a.example.netが一致します。notexample.netのように末尾の文字列が似ている別ドメインまで含めるものではありません。
FINALは、それより前のルールに一致しなかった通信を処理するためのフォールバックです。上の例では、個別のDOMAINとDOMAIN-SUFFIXに一致しない通信がPROXYになります。ポリシー名は、現在の構成で使える名前と一致させてください。PROXYを指定しても、有効なプロキシサーバーやポリシーが自動で追加されるわけではありません。
ドメイン単位の指定
- 完全一致
DOMAIN,api.example.com,PROXY- ドメインとサブドメイン
DOMAIN-SUFFIX,example.net,DIRECT- 例の対象
- ホスト名。URLのパスやクエリではない
ルールの対象には、通常、URL全体ではなくドメインを指定します。
ポリシーとフォールバック
- プロキシ経由
PROXY- 直接接続
DIRECT- 最後の判定
FINAL,PROXY
ポリシー名と利用可能な接続先は、有効な構成の内容を確認してください。
3. 上から順に判定されるルールの優先順
ルールは上から順に確認され、最初に一致したルールのポリシーが適用されます。後ろにより具体的なルールがあっても、先に一致した判定が優先されます。そのため、個別の例外を先に置き、対象範囲の広いルールを後に置き、FINALを最後にするのが基本です。
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY
この順番なら、api.example.comは最初の行でPROXYになります。www.example.comは最初の行に一致せず、2行目でDIRECTになります。もし2行目を先に置くと、api.example.comも先にDOMAIN-SUFFIXへ一致するため、個別に指定したつもりのプロキシ設定が使われません。
また、ルールの対象にはプロトコル名、ポート、URLのパスを混ぜないでください。たとえば同じホスト上の/accountと/helpを、ドメインルールだけで別々に振り分けることはできません。マッチ対象が想定どおりか判断できない場合は、まずホスト名だけに絞った少数のルールで試し、結果を確認してから対象を広げます。
結論:例外を先に、FINALを最後に置く
特定のドメインだけ経路を変えるときは、個別のDOMAINルールを広いDOMAIN-SUFFIXルールより上に置きます。ルールの順序を変更したら、同じドメインへの接続で結果が変わるかを一つずつ確認してください。
4. 構成にルールを追加して確認する
ここでは、すでにサーバー情報がHomeにあり、構成を使った接続ができる状態から、ルールを追加して動作を確かめる流れを説明します。サブスクリプションURLやサーバー情報は利用中のサービス提供元から取得してください。接続そのものがまだ確認できていない場合は、先にHomeでサーバーを選択し、接続とConnectivity Testを確認します。
-
Configを確認
Home → Global RoutingでConfigを選びます。続いてConfigを開き、編集対象が現在使っている構成であることを確認してください。同じような名前の構成が複数ある場合は、編集前に有効なものを見分けます。
-
例外を追加
構成のルール欄に、まず
DOMAIN,api.example.com,PROXYのような個別ルールを追加します。既存のルールを使っている場合は、いきなり内容を置き換えず、追加位置とポリシー名を確認してください。 -
広いルールを配置
ドメインとサブドメイン全体を同じ経路にする場合は、後ろに
DOMAIN-SUFFIX,example.net,DIRECTのような行を配置します。対象を限定したいときに、広い範囲に一致するルールを先に置かないようにします。 -
FINALを確認
末尾の
FINALが、個別の例外ルールより後にあることを確認します。すでに設定されている場合は同じ行を重ねて追加せず、既存のポリシーが意図に合っているかを確認してください。 -
接続をテスト
Home → Global RoutingでConfigを選び直し、接続状態を確認します。例にしたドメインへのアクセスを試し、ルールの対象とポリシーが想定どおりか確認してください。設定を一度に多数変更せず、確認後に必要な次のルールを追加します。
5. 期待した経路にならないときの確認
設定したルールが機能しないと感じたら、まずHome → Global RoutingがConfigか確認します。次に、編集した構成が有効か、ルールがその構成に保存されているかを確認してください。ProxyやDirectを選んでいる間は、そのモードの動作が優先されるため、Config内のドメインルールをテストしていることにはなりません。
続いて、アクセス先のホスト名がルールの対象と一致しているかを調べます。ページのURLをそのままルールへ貼り付けていないか、ホスト名に不要なパスやポートを含めていないかを確認します。個別ルールが広いルールより下にある場合は、順序を見直してください。最後に、ルール末尾のポリシーが構成で利用可能かを確認します。
ルールを入れたのに直接接続されます
Home → Global RoutingでConfigが選ばれているか確認し、編集した構成が有効か見直してください。対象ドメインに一致するルールが、別の広いルールより前にあるかも確認します。
サブドメインも同じ設定にできますか?
ドメインとそのサブドメインをまとめる場合はDOMAIN-SUFFIXを使います。1つのホスト名だけを対象にする場合はDOMAINを使い、例外が先に判定される順序にしてください。
ルールを確認するときProxyにすればよいですか?
ProxyはルールでDIRECTになるかを確かめる用途には向きません。ドメインごとの振り分けを確認するときはConfigを選び、同じ接続先で結果を確認してください。
Configを選んでも接続できない場合は、ルールだけでなくHomeで選択中のサーバー、接続状態、サービス提供元の設定も確認します。ルールは通信先を振り分けるもので、サーバーの認証情報や到達性を修正するものではありません。まず接続自体が可能かを確かめ、その後にルールの対象、順序、ポリシーを一項目ずつ確認すると原因を絞り込みやすくなります。