Shadowrocket
ルールと設定ガイド

Global Routingとルールの適用条件

ルールが意味を持つのは、リクエストが対応する処理経路に入った場合だけです。編集を始める前に、Shadowrocketで利用可能なサーバーが選択されていること、接続のオン・オフが想定どおりであること、Configで編集対象の設定が有効になっていることを確認してください。リストにファイルが保存されていても、使用中とは限りません。テキストエディタに新しい内容が表示されていても、接続がその内容で再確立されたとは限りません。「ファイルがある」「ファイルが選択されている」「リクエストに新しい設定が使われている」を分けて確認すれば、適用の問題を構文エラーと取り違えずに済みます。

Config、Proxy、Directの違い

Global RoutingのConfig、Proxy、Directは、それぞれ現在の設定による振り分け、プロキシ経由、直接接続を表します。このページの多くの例を確認するには、Configを使ってください。Configでは現在の設定のルールに従ってリクエストのポリシーが決まります。Proxyは通常プロキシ経由となるリクエストをプロキシ経路に、Directは直接接続経路に通します。経路を比較する際には便利ですが、カスタムRuleを一つずつ検証している状態ではありません。システムのバイパス設定、ローカルネットワークの例外、既存の接続が結果に影響する場合もあるため、モードを切り替えた後はリクエストを新たに発行してください。

サーバー情報、サブスクリプション、ルールを分けて考える

サーバー情報には接続先、プロトコル、認証パラメータが記載されます。サブスクリプションはサーバー情報をまとめて管理するための入力方法で、ルールはリクエストに適用するポリシーを決めます。サーバーのサブスクリプションを更新してもRuleが同時に変更されるわけではなく、設定ファイルを読み込んでも、そこに記載されたサーバーが自動的に追加されるわけではありません。本ページは、利用者が自分のサブスクリプションまたはサーバー情報をすでに持っていることを前提としています。アプリの買い切り購入と通信サービスの契約は別のものです。アプリを購入することと、接続に必要な環境を用意することは異なります。当サイトではノードやサブスクリプションを提供、販売、推奨していません。

ShadowrocketはAppleプラットフォーム向けの有料・クローズドソースの商用アプリです。主にiPhoneとiPadで利用でき、入手先はApp Storeのみです。入手方法はApp Storeでの正規購入とインストール方法をご覧ください。システム要件と購入対象地域はApp Storeの掲載内容をご確認ください。本ページの設定例はアプリの動作を説明するもので、App Storeの情報に代わるものではなく、利用者が用意したサーバーの接続性を保証するものでもありません。まず基本の接続を確立してから通信を振り分けると、問題の切り分けが容易になります。

再現できるテスト条件を整える

最初のテストでは、対象ドメインを一つだけ決め、現在のGlobal Routing、選択中のサーバー、設定名、ネットワークの種類を記録します。利用可能な設定で対象にアクセスし、対象自体が応答することを確かめてから、ルールを一つ変更してください。サブスクリプションの更新、ネットワークの切り替え、DNSの変更、ルールの並べ替えを同時に行わないでください。複数の条件が一度に変わると、マッチ結果が変わっても、どの変更が影響したのか判断できません。作業記録はローカルのメモに保存し、共有する際はサーバーアドレス、認証パラメータ、完全なサブスクリプションURLを削除してください。

[Rule]
DOMAIN,example.com,PROXY
FINAL,DIRECT

上記は一部のルール例です。ドメインexample.comに対してPROXYを使い、その他のマッチしないリクエストにはDIRECTを使います。あらゆる環境に適した振り分け設定ではなく、プロキシサーバーを自動で用意するものでもありません。対象ページがほかのドメインにもリクエストを送る場合、それらはFINALにマッチし、ページの一部は表示されるのに別の部分は失敗することがあります。ルールが不規則に適用されているのではなく、ページが複数の独立した接続を使っているためです。検証時は、アドレスバーのメインドメインだけで判断せず、実際のリクエスト先を一つずつ確認してください。

.conf設定ファイルの構成と編集手順

設定ファイルの内容は角括弧で囲まれたセクション名で整理されています。Generalには全般的なパラメータ、Ruleには順番に評価するマッチルール、Hostにはドメインとアドレスのローカルな対応関係、URL Rewriteには条件に合うURLの書き換えや拒否処理が記載されます。セクション名は見出しとして飾るためのものではなく、後続の行の用途を解析器に伝える目印です。同じテキストでも、誤ったセクションに置けば意図したとおりには処理されません。編集前に現在のセクションを確認し、特にドメインのマッピングをRuleに書いたり、通常の説明文をパラメータのセクションに直接入れたりしないよう注意してください。

まず全体構成を確認し、次に個別の例を見る

[General]
bypass-system = true

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.net,DIRECT
FINAL,PROXY

[Host]
test.example.com = 192.0.2.10

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

ここにあるexample.com、example.net、test.example.comは構文説明用のドメインです。192.0.2.10も文書用の例示アドレスであり、アクセスできることを期待しないでください。URL Rewriteの例では、指定したHTTPアドレスをHTTPSにリダイレクトしますが、実際の接続先に適用できるかは、そのサイトの対応状況によります。コード全体はセクションの配置を示すもので、現在の設定全体を置き換えることを推奨するものではありません。実際に編集する際は必要な行だけをコピーし、各行がどのリクエストを変えるのかを明確にして、動作を確認済みのほかの設定は残してください。

Configで現在の設定ファイルを確認する

Configを開いたら、まず現在選択されている設定を確認し、該当ファイルを開いてください。画面の状態によって閲覧、編集などの操作が表示されます。具体的な入口はアプリ上の表示に従ってください。ファイル名が似ているだけで同じ内容だと判断しないでください。リモートから保存したファイル、ローカルのコピー、以前読み込んだ古いファイルが同時に存在する場合があります。作業用のコピーには用途が分かる名前を付け、変更後はリストに戻って選択中の項目が変わっていないことを確認してから、リクエストを検証してください。

ファイル全体の置き換えと一部の追記では、リスクが異なります。全体を置き換えるとDNS、バイパス設定、ルール、書き換えの挙動も同時に変わる可能性があるため、設定全体を理解している場合に適しています。一部の追記なら必要な項目だけを追加でき、問題の切り分けも容易です。一部だけを追加する場合も、対応する既存セクションを見つけ、同じセクション名を末尾に何度も追加しないでください。重複セクションの統合や上書きに依存した管理は避けましょう。各セクションの役割を明確にし、内容の順序を整理すると、エディタ上の設定と実行結果の食い違いを減らせます。

保存前に文字とセクションの境界を確認する

Rule内のカンマには半角の英語カンマを使い、パラメータの代入には等号を使います。角括弧は必ず対にしてください。日本語入力では、カンマ、空白、引用符が見た目の似た別の文字に置き換わることがあります。リッチテキストからのコピーで、見えない文字が混入することもあります。正しく見えるのに解釈されない行がある場合は、テキストエディタでセクション名、区切り文字、キーワードを入力し直してから保存し、テストしてください。ルールに書くドメインはホスト部分だけにし、パスやクエリパラメータ、ブラウザに表示される完全なURLは付けないでください。

長い設定は用途ごとに並べ、短いコメントを残してください。たとえば、正確な例外をサフィックスルールより前に置く理由を、独立した行の#コメントで説明できます。重要なパラメータの説明に複雑な行末コメントを使うのは避けてください。コピー時にコメントまで混ざるおそれがあります。コメントにはキーワードの意味を繰り返すのではなく、判断の理由を記録してください。後から見直す際、「ある対象の直接接続をテストする」と書かれていれば、「DIRECTルール」よりも、その行が今も必要か判断しやすくなります。

変更後は、正常に保存できることと設定が選択されていることを確認してから、接続テストを再実行してください。保存できても、すべてのルールがマッチするとは限りません。構文が正しくても、先行するルールに遮られて一度も評価されないことがあります。変更前のコピーを残し、ルールを一度に一つずつ追加して、検証が済んでから次に進むことをおすすめします。各セクションの詳しい編集方法は、General、Rule、Host、URL Rewriteのセクション解説をご覧ください。本ページの優先順位の章もあわせて確認してください。

General、DNS、システムバイパスの適用範囲

Generalのパラメータは全体の処理環境に影響し、Ruleのようにドメインごとのポリシーを個別に決めるものではありません。そのため、想定したルール記録にリクエストが表示されないからといって、Ruleにより広い条件を次々に追加するべきではありません。まず、リクエストがクライアントの処理対象になっているか、システムのバイパス設定が関係しているか、接続先の情報を取得できるか、ドメインの名前解決に成功しているかを確認してください。こうした前提を調べてからルールを追加するか決めるほうが、設定全体を置き換えるより問題を特定しやすくなります。

bypass-systemの意味と制限

[General]
bypass-system = true

bypass-systemは、システム関連の一部の通信をバイパスするかどうかを制御します。「ローカルアドレスへの通信をすべて直接接続する」という意味ではなく、特定サイトへのアクセスを成功させる万能スイッチでもありません。システム関連のリクエストは通常のルールを確認する前に処理される場合があるため、このパラメータを有効にしても、すべての通信についてRuleのマッチ記録が確認できるとは限りません。既存の設定で使われている場合は、残されている理由を確認してください。記録をすべて表示させるためだけに無効にしたり、すべてのアプリの挙動を変える保証として扱ったりしないでください。

バイパス設定を調べる際は、対象がインターネット上のサービス、ローカルネットワークの機器、システムコンポーネントのどれかを区別してください。インターネット上のドメインは通常、正確なDOMAINルールで確認できますが、ローカルネットワークの機器にはアドレス範囲、ネットワーク環境、システムの動作がそれぞれ影響します。アクセス先と現在のWi-Fiまたはモバイルネットワークを記録してから、変更を一つだけ試してください。ローカルネットワーク上の特定の対象にだけ問題がある場合は、その対象に絞って検証してください。システム全体のバイパス設定を変えて、アドレス、ポート、ネットワーク分離の問題を覆い隠さないようにしましょう。

名前解決の結果と接続ポリシーは別のもの

ドメインルールは接続先の名前を、IPルールは接続先のアドレスを判定します。その間には名前解決の処理が行われることがよくあります。DNSからアドレスが返ってきても、そのアドレスに到達できるとは限りません。PROXYが選択されていても、名前解決が必ずそのプロキシと同じ経路で行われるとは限りません。設定を確認する際は、DNS関連の設定、キャッシュの有無、リクエスト記録に表示された実際の接続先をそれぞれ確認してください。解決されたアドレスが変わっただけでドメインルールが無効だと判断すると、名前解決の層とルーティングの層を混同してしまいます。

同じドメインから複数のIPv4またはIPv6アドレスが返ることがあり、アドレスはネットワークや時間によって変わる場合もあります。特定のIPv4アドレスだけをルールで指定していると、次回の名前解決でIPv6が選ばれた際に別のポリシーが適用される可能性があります。その場合、名前解決のたびに表示されたアドレスを追加するのではなく、要件をドメインルールで表現できないか検討してください。安定したネットワーク範囲や特定のアドレスを制御する必要がある場合に限り、IP-CIDRまたはIP-CIDR6を使います。ルールの対象を実際の要件に合わせると、たまたま得られた名前解決結果に依存せずに管理できます。

no-resolveはルールのオプションであり、DNSの切り替えではありません

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
FINAL,PROXY

no-resolveは通常、IP系ルールのオプションとして使われ、そのルールを確認するためだけに追加のドメイン解決を行わないことを表します。クライアント全体のDNSを停止する意味でも、以後の接続で名前解決が不要になる保証でもありません。マッチに使える接続先IPがすでにあれば、ルールがマッチする場合があります。ドメイン名しかなく適用できるアドレスもない場合、このルールでは判断できず、リクエストは後続のルールへ進むことがあります。「あらゆる名前解決を禁止する」「すべてのドメインを自動でアドレス判定する」と理解すると、想定と異なる結果になります。

no-resolveを削除した場合にだけ特定の対象の挙動が変わるなら、単純にオプションの良し悪しを判断せず、新たな名前解決が影響したか確認してください。変更前後のアドレス、マッチしたルール、最終ポリシーを記録してから、どちらの挙動を残すか判断します。特にドメインルールとGEOIPルールが同時にある場合、先行するドメインルールでマッチが終了し、後続のルールにある名前解決オプションが一度も使われていない可能性があります。オプションを検証するには、実際の処理がそのルールまで到達していることを確認してください。

DNSの問題を調べるときは、まずアクセス可能だと分かっている対象と比較します。次に、問題が特定のドメインだけで起きるか、特定のネットワークでだけ起きるか、IPv6経路の変化を伴うかを確認してください。明確なパラメータを一つだけ変更し、テスト結果を記録します。インターネット上のGeneral設定を丸ごと現在のファイルに上書きしないでください。名前解決、バイパス設定、その他の全般設定が相互に影響する場合があります。基本の接続を確認するには、FAQの接続トラブル対処に戻り、名前解決と接続の2つの段階に分けて確認してください。

DOMAIN、サフィックス、キーワード、USER-AGENT

ドメインルールは、必要な範囲に合わせて選び、むやみに広い条件を使わないでください。DOMAINはホスト名の完全一致、DOMAIN-SUFFIXはドメインとそのサブドメイン、DOMAIN-KEYWORDはドメイン内の指定文字列の検索に適しています。いずれも完全なURLを対象とするルールではありません。パス、クエリパラメータ、ページタイトル、ブラウザに表示されるテキストはマッチ範囲に含まれません。まず対象ホストを特定し、最小限の範囲を選ぶことで、意図しないマッチや原因を説明しにくいアクセス変化を減らせます。

完全一致とサフィックス一致

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

DOMAIN,api.example.com,DIRECTは、このホスト名との完全一致だけを表します。www.example.comやapi.example.comのサブドメインは自動的に含まれません。DOMAIN-SUFFIX,example.com,PROXYは、example.comとそのサブドメインを対象とします。この例では、api.example.comが先に完全一致のルールにマッチしてDIRECTを使い、それ以外のexample.com配下のホストはサフィックスルールで処理されます。サフィックスルールを上に移動すると、完全一致の例外が実行されなくなります。これがルールの順序が重要な理由です。

サフィックス一致ではドメインの境界が考慮され、任意の文字列検索とは異なります。example.comを対象にする場合は、このドメインをサフィックスとして指定します。ブラウザのアドレスに表示されるプロトコルを先頭に付けたり、末尾にスラッシュを追加したりしないでください。DOMAIN-SUFFIX,example.comが「example.com」という文字列を含むあらゆる名前にマッチするわけではありません。文字列の部分一致が必要な場合はDOMAIN-KEYWORDを明示的に使い、範囲が広すぎないかも確認してください。

キーワードルールは意図しないマッチを先に確認する

[Rule]
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

DOMAIN-KEYWORD,example,PROXYは、ドメインにexampleという文字列が含まれているかを確認します。対象範囲はexample.comのサフィックスルールより広く、異なるサフィックスや別の所有者のドメインにもマッチする可能性があります。既知の複数のドメインをまとめて数行減らす目的で使うのは適切ではありません。特定サイトの機能を対象にする場合は、実際のリクエスト記録から必要なホストを抽出し、用途を一つずつ確認してから、サフィックスルールにまとめるか判断してください。条件が広すぎる場合、構文エラーにはならず、無関係なリクエストのポリシーが気付かないうちに変わることがあります。

USER-AGENTで取得できる情報の制限

[Rule]
USER-AGENT,ExampleClient*,PROXY
FINAL,DIRECT

USER-AGENTは取得可能なUser-Agentの内容をもとにマッチします。例にあるExampleClientは、ワイルドカードパターンを説明するためのサンプル値です。アプリ名を基準に通信を選ぶルールではなく、デバイス上のすべてのアプリを自動で識別するものでもありません。暗号化されたリクエストのHTTPヘッダーは、通常の接続情報だけでは読み取れないことが多いため、このルールを適用できるかはリクエストの種類や取得可能な情報に左右されます。あるアプリのWebリクエストがマッチしたからといって、そのアプリのすべての接続に同じ処理が適用されるとは限りません。マッチさせるためだけに、復号の対象範囲をむやみに広げないでください。

ドメインルールの検証では、リダイレクト後の接続先とページが依存するドメインも確認してください。ページを開くと、最初にメインドメインへアクセスし、ログイン用ドメインに移動した後、画像、API、静的リソースを読み込む場合があります。それぞれの接続は個別に判定されます。ログインだけが失敗する場合は、トップページのルールを繰り返し変えるのではなく、ログイン処理で実際に使われるホストを確認してください。リクエスト記録にIPしか表示されない場合も、ドメインルールが無効だと決めつけず、ドメイン情報を取得できているか確認してください。

まず正確なルールで検証可能な最小セットを作り、実際の結果に基づいてサフィックスルールにまとめることをおすすめします。項目を追加したら、対象へのアクセスと無関係な対象を少なくとも一つ確認し、意図したリクエストが解決し、影響範囲も広がっていないことを確かめてください。古いルールを削除する前に、元のマッチ位置を記録し、それに依存する例外まで一緒に削除しないようにします。頻繁に変わるサービスのドメインは、名前が似ているかどうかで判断せず、現在のリクエストに基づいて管理してください。名前が似ていても、同じポリシーを適用すべきとは限りません。

IP-CIDR、IP-CIDR6、GEOIP

IP系ルールは接続先アドレスを判定するもので、Webサイトの運営者やサービスの性質を判断するものではありません。また、そのアドレスに対応するサービスの内容を保証するものでもありません。IP-CIDRはIPv4の範囲、IP-CIDR6はIPv6の範囲、GEOIPはアドレスデータベースによる地域分類を扱います。明確なアドレス範囲を指定する場合や、ドメインルールに続く補助条件として使うのに適しています。「特定のドメインに特定のポリシーを適用する」という要件なら、通常はドメインルールのほうが直接的です。現在解決された1つか2つのIPをWebサイトの恒久的なアドレスと見なすと、すぐにルールの対象から外れる可能性があります。

CIDRのプレフィックス長を理解する

[Rule]
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,2001:db8::10/128,DIRECT,no-resolve
FINAL,PROXY

IPv4の/32は単一のアドレス、/16は先頭16ビットに基づくアドレス範囲を表します。IPv6の/128は単一のアドレスです。プレフィックスが短いほど、通常は対象となるアドレスが増えます。例にある192.0.2.10と2001:db8::10は文書用の例示アドレスで、実際に利用できる接続先ではありません。実際に設定する際は、アドレスとプレフィックスで指定される範囲を確認し、先頭部分が対象に似ているかだけで判断しないでください。範囲が広すぎると無関係な接続に大きな影響を与えることがありますが、範囲が広いことを知らせる警告は自動表示されません。

ローカルネットワークのルールを書く場合も、実際に利用しているネットワーク範囲を先に確認してください。192.168.0.0/16はよく使われるプライベートアドレス範囲の一部であり、すべてのローカルネットワークを表すものではありません。IPv6のローカルアドレス範囲にも用途の違いがあります。機器にアクセスできない場合は、クライアントのポリシーだけでなく、Wi-Fiで機器間通信が許可されているか、接続先のポートが開いているか、対象サービスが特定のインターフェースだけで待ち受けていないかも確認してください。DIRECTは直接接続経路を選ぶだけで、ローカルネットワークへのアクセス許可を代替したり、存在しないサービスを応答させたりするものではありません。

GEOIPはアドレスの分類であり、ドメインのラベルではありません

[Rule]
DOMAIN,api.example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

GEOIP,CN,DIRECTは、データベースでCNに分類された接続先アドレスをDIRECTに渡すことを表します。ドメインのサフィックスやページの言語で判定するものではありません。ドメインが複数の地域に分散したサーバーを使うことがあり、データベースの更新にも遅れが生じる場合があります。そのため、組織の所在地だけから、各接続が同じGEOIP条件にマッチすると推測することはできません。特定のサービスに常に決まったポリシーを適用する必要がある場合は、GEOIPより前に明示的なドメインルールを書き、アドレス分類の間接的な結果に依存しないようにしてください。

GEOIPと名前解決の関係は、現在のリクエスト情報に基づいて判断してください。接続先がドメイン名だけの場合、アドレスの判定には利用可能な名前解決結果が必要になることがあります。アプリがIPに直接接続する場合は、すでにマッチ対象となるアドレスが得られていることがあります。IP系ルールにno-resolveを加えると、そのルールの判定のために追加の名前解決を行わなくなり、挙動が変わる可能性があります。接続先の名前、アドレス、マッチしたルールを記録し、最終ポリシーだけを見てGEOIPデータベースの正しさを判断しないでください。先行するドメインルールにマッチしていれば、GEOIPは評価されません。

IPv4とIPv6を分けて検証する

同じサービスがIPv4とIPv6の両方のアドレスを公開し、アプリやシステムがネットワーク状況に応じてどちらかを選ぶ場合があります。IP-CIDRだけでは対応するIPv6接続は対象になりません。一度接続に成功しただけで、もう一方のアドレスファミリーでも同じ結果になるとは限りません。「ネットワークを変えたらポリシーが変わった」という場合は、実際の接続で使われたアドレスファミリーを確認し、対応するIP-CIDR6ルールがあるか調べてください。アドレスファミリーを無効にすることを常に解決策とせず、ルールの適用範囲とネットワーク経路のどちらに問題があるかを先に確認してください。

共有アドレスと動的な名前解決にも注意してください。複数のドメインが同じアドレスを共有している場合、そのアドレスを対象にしたルールはすべてに影響します。一つのドメインが頻繁にアドレスを変更すれば、以前のルールはマッチしなくなります。特定のサイトだけを制御するなら、ドメイン条件のほうが範囲を明確にしやすいのが一般的です。共有アドレスの影響を許容できる場合、または接続先が実際にIPで指定される場合に限って、アドレスルールを主な条件にしてください。管理時にはネットワーク範囲の出典と用途を記録し、根拠を説明できなくなったルールを長期間残さないようにします。

推奨する確認順序は、実際の接続先アドレスを確認し、ルールの対象範囲を計算し、no-resolveと先行ルールを確認してから、接続結果を見ることです。正しくマッチしているのにアクセスできない場合は、範囲をむやみに広げず、接続先への到達性、ポート、選択中の経路を調べてください。IPルールが解決するのは分類の問題であり、接続性そのものではありません。安定した状態に戻すには、最近追加したアドレスルールを取り消し、既存のドメインルールと比較するほうが、設定全体を一度に消去するより原因を特定しやすくなります。

PROXY、DIRECT、REJECTと評価の優先順位

Ruleは通常、上から順に評価されます。マッチしてポリシーが決まると、それ以降の通常ルールは評価されません。キーワードの「具体性」によって優先順位が自動的に上がることはありません。後ろに書いたDOMAINは、DOMAIN-SUFFIXより条件が正確でも、すでにマッチした前の行を飛び越えません。設定を整理する際は、まず明確な例外を置き、次に広い範囲のルールを置き、最後にFINALを置いてください。優先順位を決めるのは、まずファイル内の並び順です。ドメインの長さ、キーワード名、追加した時期ではありません。

3つのポリシーの役割

PROXYはマッチしたリクエストをプロキシ経路に送ります。通常、利用可能なサーバーを選択しているか、設定で対応するポリシーを明示的に参照している必要があります。DIRECTは直接接続経路を使いますが、ローカルネットワークと接続先への到達性に左右されます。REJECTはマッチしたリクエストを拒否します。別の予備経路に送ったり、Webページを別のコンテンツに置き換えたりするものではありません。3つは処理結果を表し、サービス品質の段階ではありません。接続に失敗したリクエストをPROXYまたはDIRECTに変更しても経路が変わるだけで、認証、接続先サービス、プロトコルパラメータの問題が自動的に解決するわけではありません。

例外を使って順序を確認する

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

上記の例では、ログイン用ホストとmetrics用ホストを先に処理し、次にexample.com配下の残りを処理します。その後にGEOIPを確認し、最後にFINALでフォールバックします。DOMAIN-SUFFIXを一番上に移動すると、2つのホストが先にサフィックスルールにマッチし、DIRECTとREJECTが適用されなくなります。長い設定を読むときは、追加したばかりの行だけを探すのではなく、対象リクエストを条件として、その前にあるすべてのルールを確認してください。ルールが記載されていることから分かるのは、テキストにその行が存在するということだけです。実際の処理がその行まで到達するとは限りません。

FINALの位置でフォールバックの範囲が決まる

FINALにはドメインやアドレス条件がなく、FINAL,ポリシーの形式で記述します。それ以前のルールにマッチしなかったリクエストを処理するため、通常はRuleの末尾に置きます。途中にFINALを置くと、それ以降の通常ルールが実行されない場合があります。FINALを複数記述しても、後続のフォールバックが想定どおりに機能するとは限りません。FINAL,PROXYとFINAL,DIRECTのどちらを選ぶかは、利用状況と使える経路に応じて決めてください。どちらか一方が常に正解というわけではありません。例の選択は構成を示すためのもので、実際の要件に対する判断に代わるものではありません。

REJECTでは、対象範囲を特に慎重に確認してください。統計用に見えるドメインでも、設定、ログイン状態、その他の必須リクエストに使われている場合があります。名前だけで判断して拒否すると、ページの一部が読み込めなくなったり、アプリが不安定になったりすることがあります。拒否ルールを追加する前に、マッチ対象と影響範囲を確認し、元に戻す方法を用意してください。検証時は、対象リクエストが拒否されたことだけでなく、通常の機能に影響がないことも確認します。機能に異常があれば、まず追加したREJECTルールを取り消して様子を見てください。最初の誤判断を、さらに多くの例外で覆い隠さないようにしましょう。

ポリシー名と実際の接続先を区別する

本ページでは動作を分かりやすく説明するため、基本的なポリシーキーワードのPROXY、DIRECT、REJECTを使っています。既存の設定でカスタムポリシー名を使っている場合は、対応する定義が存在することと、最終的にどのサーバーや選択方法を参照するかを確認してください。名前が地域や用途を表しているように見えても、実際の接続先を示すとは限りません。サーバーが削除された、サブスクリプションの更新で項目が変わった、選択中の項目が想定と異なるといった状況では、同じルールでも接続結果が変わることがあります。表示名だけで判断せず、ポリシーの参照先を確認してからサーバーを調べてください。

順序を調整する際は、「正確な例外、サフィックスの範囲、アドレスによる補足、最後のフォールバック」の順に並べ、少なくとも3つの対象で検証してください。例外にマッチする対象、広い範囲のルールにマッチする対象、FINALに進む対象をそれぞれ用意します。例外が遮られていないか、FINALが早すぎないかをまとめて確認できます。2つの設定を比較するとき、最初から行数を比べる必要はありません。同じ対象がそれぞれのファイルで最初にマッチする有効なルールを比較してください。ルールが長くても正確とは限りません。一つひとつに明確な目的を持たせると、長期的な管理や元に戻す作業が容易になります。

HostとURL Rewriteの役割分担

Hostは名前解決に使うアドレスの対応関係を変更し、Ruleはリクエストに適用するポリシーを決め、URL Rewriteは条件に合うURLを処理します。これらは異なる層の機能であり、互いに置き換えるものではありません。ドメインを特定のアドレスに割り当ててもDIRECTになるわけではなく、HTTPアドレスをHTTPSへリダイレクトしてもPROXY経由になるわけではありません。問題を切り分ける際は、「接続先の名前、解決されたアドレス、ルールのポリシー、リクエストの処理」の順に確認してください。一つの層の変化を別の層の設定変更で解決しようとしないことが大切です。

Hostマッピングが扱うのは名前とアドレスの対応

[Host]
test.example.com = 192.0.2.10

[Rule]
DOMAIN,test.example.com,DIRECT
FINAL,PROXY

この例ではtest.example.comを文書用アドレスに割り当て、別のDOMAINルールでDIRECTを選択しています。2行は異なる役割を担うため、どちらかを省略して同じ動作を期待することはできません。実際に使う場合は、アドレスを自分が管理している、または正確に把握している有効な接続先に置き換え、そのサービスが該当ドメインを受け付けることを確認してください。Hostは、任意のドメインを任意のアドレスに割り当てれば必ずアクセスできるようにする機能ではありません。サーバーの待ち受け状態、サービスがドメイン名を識別する方法、証明書の一致は、接続先のサービス側で決まります。

HTTPSでは特に、証明書とホスト名の関係に注意してください。名前解決のアドレスが想定どおりに変わっても、クライアントはリクエストに含まれるドメイン名に基づいて検証を行います。マッピングによって証明書が自動的に一致するわけではありません。証明書エラーが発生した場合は、検証を無効にして問題を隠すのではなく、接続先のアドレスが正しいか、そのサービスが該当ドメインに対応しているか、ネットワーク認証ページなどが干渉していないかを確認してください。IPに直接アクセスして内容が返ってきても、元のドメインを使ったHTTPSリクエストが成功するとは限りません。

URL Rewriteでは確認可能な対象を先に特定する

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

上記の例では、http://example.com/で始まるURLを正規表現でマッチさせ、302でHTTPSにリダイレクトします。先頭のキャレットは文字列の開始位置を指定し、ドメイン名のピリオドにはバックスラッシュでエスケープを付け、正規表現の任意文字として解釈されないようにしています。接続先のサイトがHTTPSに対応していなければ、リダイレクトしても利用できない別のアドレスへ移動するだけです。この例は構文を示すものであり、すべてのサイトに同じ書き換えが必要という意味ではありません。また、暗号化された通信の内部経路が常に確認できることを示すものでもありません。

URL Rewriteへの入力は、クライアントが取得できるリクエスト情報に左右されます。通常の暗号化された接続では、完全なパスやリクエストヘッダーがすべてのルールから自動的に見えるわけではありません。HTTPの例を任意のHTTPSリクエストにそのまま適用し、設定が無効だと判断しないでください。より詳細なリクエスト処理には追加の条件やセキュリティ上の影響を理解する必要があります。基本的な通信振り分けにこれらの機能を有効にする必要はありません。特定のドメインの接続経路を変えたいだけなら、通常はRuleのドメイン条件が適しています。

正規表現の範囲とリダイレクトループ

正規表現はドメインのサフィックス一致より柔軟ですが、範囲が広くなりやすい点に注意が必要です。開始位置を指定しない、ピリオドをエスケープしない、ドメイン境界をまたぐワイルドカードを使うと、無関係なURLも処理される可能性があります。まずプロトコルとホストを明確に限定し、その後でパスの範囲を検討してください。条件を広げるたびに、マッチするリクエストとマッチしないリクエストを一つずつ使って比較します。正規表現の意味が分からない場合は、正確な例にとどめてください。内容が分からない長い式を既存設定に追加したり、入手元の説明だけから実際の対象範囲を推測したりしないでください。

リダイレクト後にサイト側でもう一度リダイレクトされる場合があります。ローカルルールでアドレスを接続先へ変更し、サイトが元のアドレスへ戻すと、ループが発生します。ページが繰り返し移動したり、ブラウザにリダイレクトが多すぎると表示されたりします。その場合は関連する書き換えを一時的に削除し、サイト本来の挙動を確認してから、ルールの範囲を狭めるか無効にするか判断してください。古いループを抑え込むために新しいリダイレクトを追加し続けないでください。各ステップの接続元と接続先を整理すると、どの段階で問題が起きたか特定できます。

HostとURL Rewriteを管理する際は、分けてテストするのがおすすめです。まず通常の名前解決と書き換えなしの状態に戻して基本接続を確認し、次にマッピングを一つだけ有効にし、最後に書き換えを一つ検証します。Hostを削除した後は、リクエストを新たに発行し、既存のキャッシュも考慮してください。書き換えを無効にした後も、ブラウザが以前のリダイレクト結果を再利用しないようにします。実際の接続先と最初にマッチしたルールを毎回記録すれば、どの層の変更が影響したか確認できます。ルールによる振り分けに不要なマッピングや書き換えは増やさず、隠れた依存関係と今後の調査コストを減らしましょう。

設定の検証、よくある誤認、元に戻す手順

設定は「ファイル、マッチ、接続、サービス」の4段階で検証します。ファイル段階では選択中の設定と構文、マッチ段階ではリクエストが想定したルールに一致するか、接続段階では選択した経路で通信を確立できるか、サービス段階ではログイン、API、ページ内容が正常かを確認します。前の段階が成功しても、次の段階の成功が保証されるわけではありません。たとえばDOMAINが想定どおりPROXYにマッチしても、サーバー認証に失敗するなら問題は接続段階にあります。ページ本体が表示されてもAPIが失敗する場合は、ほかのリクエストも確認してください。ブラウザでページが開くかどうかだけで判断しないようにしましょう。

最小限のテストセットでルールを確認する

完全一致の例外にマッチするドメイン、サフィックスの範囲にマッチするドメイン、FINALに進む比較用ドメインを一つずつ用意します。設定を保存したらGlobal RoutingがConfigであることを確認し、対象へのリクエストを新たに発行して、アプリに表示される接続記録やリクエスト記録を確認してください。画面に表示される項目は実際の状態によって異なります。取得可能な接続先、ポリシー、サーバー、エラー情報を記録します。記録にすべての詳細が表示されない場合は、確認できる範囲に限界があることを認め、項目が表示されないことをルール未実行の証拠と見なさないでください。

テストではできるだけ新しい接続を使ってください。確立済みの長時間接続、ページキャッシュ、アプリのバックグラウンドセッションが以前の状態を引き継ぎ、変更したルールが反映されていないように見えることがあります。必要に応じて関連アプリの実行中リクエストを停止してから、新たに接続し、ほかの設定は変えないでください。一度のテストで結果が変わらないからといって、すぐにルール全体を並べ替えないでください。新しいリクエストが発行されたか、リダイレクトが発生したかを先に確認します。スイッチを頻繁に切り替えるより、再現可能なテスト条件を保つほうが原因を判断しやすくなります。

症状に応じて確認範囲を絞る

すべての接続先で失敗する場合は、個別ドメインのルールを調べる前に、接続のオン・オフ、システムのVPN設定状態、現在のサーバー、基本的なネットワークを確認してください。Connectivity Testはテスト対象の接続状況を把握するのに役立ちますが、一度成功しても、すべてのサービス、プロトコル、接続先で成功するとは限りません。初回接続の手順は、デフォルトサーバーの選択とConnectivity Testによる検証をご覧ください。特定のサイトだけで問題がある場合は、そのサイトの実際のリクエストとマッチしたルールを確認してください。

特定のルールだけが機能していないように見える場合は、まず上に広い条件のDOMAIN-SUFFIX、DOMAIN-KEYWORD、アドレスルール、または早い位置のFINALがないか確認してください。次にキーワード、半角カンマ、接続先名、ポリシーの参照先を調べます。ルールには正しくマッチしているのに結果が異なる場合は、「ルールの選択」と「接続の成功」を分けて対処してください。接続失敗を直そうとして同じ意味のルールを追加し続けないでください。同じ失敗経路を指すルールを増やしても、設定が複雑になるだけで、根本原因は変わりません。

元に戻した後の状態を明確にする

変更を始める前に、現在正常に動作しているファイルのコピーを保管し、選択中のサーバーとGlobal Routingを記録してください。異常が見つかったら、まず最後に加えた変更を一つ取り消します。変更範囲が広すぎる場合は、動作確認済みの設定に切り替えて、同じ対象でテストしてください。元に戻しても失敗するなら、ルール以外の原因も考えられます。ネットワーク環境が変わった、サーバー情報が無効になった、接続先のサービス自体に問題がある、といった可能性があります。その場合は接続段階の調査を続け、バックアップファイルまで変更されたと思い込まないようにしてください。

リモートの設定を更新する前に、ローカルの変更が上書きされないか確認してください。独自の完全一致例外と変更理由は別に記録し、更新後は以前の内容が残っていると思い込まず、一つずつ照合します。サブスクリプションの更新と設定の更新も分けて行い、サーバー一覧とルールの結果をそれぞれ検証してください。読み込み方法は、Subscribe、Add Server、QRコード、クリップボードからの読み込み方法をご覧ください。接続情報の読み込みの問題を、Ruleの解析エラーと取り違えないようにしましょう。

最後に共有する場合は、最小限の情報で問題を説明できるように整理します。デバイスで利用中のネットワークの種類、Global Routingのモード、問題が起きる公開の接続先、想定するポリシー、実際に確認した結果、関連する少数のルールを記載してください。パスワード、完全なサブスクリプションURL、認証項目、個人のアクセス記録は削除します。ルールの順序を説明するために設定全体を公開する必要はありません。まだ疑問があればFAQで項目ごとに確認し、基本手順が終わっていない場合はガイドに戻ってください。信頼できる設定とは、各ルールの目的が明確で、結果を検証でき、問題が起きても正確に元に戻せる設定です。