Shadowrocketのルールガイド
設定セクション、マッチ順、振り分けポリシー。
このページでは、Shadowrocket公式マニュアルのシステム的な確認方法を説明します。サブスクリプションまたはサーバー情報があり、接続できる状態で、ルールがリクエストに与える影響を確認したい場合に適しています。初回の読み込みと接続については、先に使い方ガイドをご覧ください。基本操作を確認したら、各章で設定をチェックできます。
- 設定例を項目ごとに解説
- ルールは上から順にマッチ
- 例示用アドレスについて
設定ファイルの構成と読み込み範囲
Shadowrocketの設定ファイルには、角括弧で示す複数のセクションを含められます。セクション名によって後続のテキストの解釈方法が決まり、ファイル上の見た目のまとまりで決まるわけではありません。[Rule]のドメインルールと[Host]のアドレスマッピングは、同じドメインが記載されていても役割が異なります。編集を始める前に、現在有効な設定ファイルを確認してから該当セクションを編集してください。ファイルをConfigリストに保存しただけでは、そのファイルが選択されたことにはなりません。
サーバー情報・サブスクリプション・設定を区別する
サーバー情報には接続先、使用するプロトコル、認証方法が記載されます。サブスクリプションはサーバー情報をまとめて取得・更新するためのものです。ルール設定では、リクエストごとの処理方法を指定します。これらは同じ利用手順に登場することがありますが、互いに置き換えられるものではありません。サーバーに接続できても、ルールファイルが有効とは限りません。ルールファイルを読み込めても、参照先のプロキシ出口が使えるとは限りません。読み込み後に期待した結果にならない場合は、サーバー情報と振り分け設定のどちらが不足しているか確認してください。
Configでファイルを確認するときは、ファイル名、現在の選択状態、入手元を記録してください。リモートファイルの更新でローカルの変更が上書きされることがあるため、最初の検証前に元のファイルを複製しておきましょう。元の設定を理解しないまま、オンライン上の断片で全体を置き換えないでください。このページの例は構文の解説用で、認証情報を含まず、そのまま接続できる完全な設定でもありません。
4つのセクションの役割
| セクション | 主な役割 | 確認するポイント |
|---|---|---|
[General] | 一般的なネットワークと名前解決の設定。 | DNSやバイパス範囲が変わっていないか。 |
[Rule] | 条件に応じて接続ポリシーを選択。 | ルールの順序と末尾のフォールバック。 |
[Host] | 指定したドメインのアドレスマッピング。 | アドレスが正しく、現在も有効か。 |
[URL Rewrite] | 式に一致するURLを処理。 | マッチ範囲とリダイレクト先。 |
[General]
dns-server = system
[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY
[Host]
fixed.example.com = 192.0.2.10上記の192.0.2.10はドキュメント用の例示アドレスで、利用可能なサーバーではありません。このテキストを読むときは、まずセクション名を確認し、次に各行の区切り方を見てください。GeneralとHostでは等号でキーと値を指定し、Ruleでは通常、ルールの種類、条件、ポリシーを半角カンマで区切ります。全角カンマ、見えない空白、リッチテキストからコピーした記号が混ざると、見た目が同じでも入力内容が異なることがあります。
編集前に最低限確認する項目
まずGlobal Routingの現在の状態を記録し、次にSERVERで選択されているサーバー、最後にConfigで使用中のファイルを確認してください。3つの状態を記録しておけば、出口の切り替えをルール変更と取り違えずに済みます。変更前後を比較する場合は、条件を1つだけ変更して保存し、接続テストをやり直してください。サーバーの変更、DNSの調整、ルールの並べ替えを同時に行うと、結果が変わっても原因を特定できません。
設定ファイルの評価では、「構文を読み込めること」と「目的に合っていること」を分けて考えてください。前者は構文が受け入れられたというだけで、後者は実際のリクエストで検証する必要があります。たとえばFINALの後ろに記載したドメインルールは、構文が正しくても、先にマッチしたフォールバックルールがリクエストを処理するため適用されないことがあります。コメントに用途が明記されていても、コメント自体はマッチ動作を変えません。有効なルールを基準に確認してください。
General、DNS、ルールの入力情報
Generalはルールが動作する環境に影響します。ドメインの名前解決方法や、システム側の経路で処理される対象によって、後続の処理で確認できるリクエスト情報が変わります。そのため、ルールを調べるときにRuleセクションだけを見るのは不十分です。同じルールでも名前解決の条件によって結果が異なることがあり、特にGEOIP、IP-CIDR、IP-CIDR6のように接続先アドレスに依存するルールで顕著です。名前解決とルーティングは別の段階だと理解してから、変更箇所を判断してください。
DNSによる名前解決とポリシー選択は別
DNSはドメインをアドレスに変換し、振り分けポリシーは接続の処理方法を決めます。ドメインの名前解決に成功しても、リクエストがPROXYとDIRECTのどちらを通るかは判断できません。ドメインルールは、必ずしもアドレス取得後にしかマッチできないわけではありません。クライアントが接続先ドメインを把握していれば、DOMAINやDOMAIN-SUFFIXで判定できます。一方、アドレスルールには接続先アドレスが必要で、必要な入力情報が異なります。
[General]
dns-server = system
[Rule]
DOMAIN,portal.example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXYdns-server = systemは、ここでシステムが提供するDNSを使う設定です。理解しやすい出発点として示したもので、あらゆるネットワークに適した固定の設定ではありません。既存の設定で別の名前解決方法を指定している場合は、用途を記録してから検討してください。例に合わせるためだけに、その設定を上書きしないでください。ネットワークの切り替え、システムのDNS状態、アクセス先サービスの構成によって、最終的に返されるアドレスは変わることがあります。
no-resolveの適用範囲
アドレスルール末尾のno-resolveは、そのルールを試すためだけにドメイン名を解決しないことを示します。DNSを無効にする設定でも、その後の接続で名前解決を一切行わないという意味でもありません。リクエストに利用可能な接続先アドレスがすでにあれば、そのアドレスで判定できます。ドメイン名しかなく、対応するアドレスもない場合、このルールがアドレスを生成してマッチすることはありません。後続のルールで処理される可能性があります。
この違いはトラブル対処で重要です。no-resolveを追加した後にドメインがアドレスルールにマッチしなくても、アドレス部分の記述が誤っているとは限りません。マッチ時に利用できるアドレスがなかった可能性があります。無理にマッチさせるために、すべてのno-resolveを削除しないでください。まず対象がドメイン名によるリクエストか、アドレスへの直接リクエストかを確認し、名前解決の要否と、名前解決の負荷・振り分けの目的を検討してください。
キャッシュ、ネットワーク切り替え、確認のタイミング
ブラウザ、アプリ、システム、クライアントは、名前解決や接続の状態をそれぞれ異なる場所に保持することがあります。DNSを変更してすぐにページを再読み込みしても、既存の接続が再利用され、新しい設定の効果が見えない場合があります。テストではリクエストを再実行し、必要に応じて対象アプリの既存セッションを終了してから、アプリで可能な方法で関連キャッシュを消去してください。一度再読み込みして変化がないからといって、設定が読み込まれていないとは限りません。同様に、偶然一度成功しただけでは問題の解決を確認できません。
Wi-Fiとモバイル通信を切り替えた後は、基本的なネットワーク接続が使えるか再確認してください。システム自体が通常アクセスできる宛先に接続できない場合、Ruleの調整を続けても根本的な接続問題は解決しにくいでしょう。まずDirectの状態で範囲を絞って比較し、その後Configに戻してルールを検証できます。比較後は元の状態に戻し、グローバルな直接接続をルールによる振り分けの結果と取り違えないようにしてください。
バイパス範囲を通常のRuleと混同しない
Generalの一部設定は、どの通信が後続の処理経路に入るかに影響します。Rule内のDIRECTとは異なるレイヤーの設定です。バイパス範囲を広げると、リクエストが想定したルールを通らなくなることがあります。そのため「末尾にFINALがあるから、すべての通信がフォールバックされる」とは限りません。こうした設定を変更する前に、既存ファイルの説明とアプリ内の項目を確認してください。用途が分からない場合は、一括削除するより元の値を維持するほうが、再現性を保ちやすくなります。
IPv6に関する問題では、ドメインが異なるアドレスファミリーのアドレスを同時に返していないかも確認してください。IPv4用のアドレスルールを書いても、IPv6のリクエストまで対象になるわけではありません。まず業務上の範囲を正確に表現できるドメインルールを使い、必要性を確認したうえでアドレス範囲を追加してください。アドレスファミリーの無効化を最初に試すのではなく、実際の接続先アドレスを記録して、問題が名前解決、マッチ、接続経路のどこにあるかを確認します。
DOMAIN系ルールのマッチ範囲
サイトの振り分けを表現する場合、変化し続ける接続先アドレスよりドメインルールのほうが適していることが多いものの、マッチ時にクライアントが接続先ドメインを取得できることが前提です。DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDの違いは主に対象範囲で、どれかが一律に「強い」わけではありません。ルールを選ぶ前に対象としたい範囲を明確にし、必要十分な中で最も狭い条件を使いましょう。行数を減らすために範囲を広げると、気づきにくい誤マッチにつながります。
DOMAIN：完全一致するドメインを指定
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN,api.example.com,PROXY
FINAL,PROXYDOMAINは、完全一致するドメインに使います。1行目の条件が対象とするのはlogin.example.comだけで、example.comやcdn.login.example.comは自動的には含まれません。ログイン用ドメインやAPI用ドメインなどを個別に処理するときに適しています。条件にはドメイン名を指定し、プロトコル、ポート、パスは付けないでください。URL全体を入力しても、パスを条件にするルールにはなりません。
特定のAPIリクエストだけを変更し、同じドメインの他のパスはそのままにしたい場合、DOMAINだけではその細かさを表現できません。まずパス単位の処理が本当に必要かを判断してください。ドメインの後ろにスラッシュを追加するだけでは実現できません。ドメインルールで選択するのは接続ポリシーであり、ログイン用ドメインを条件にしても、ログインに関係する他の依存ドメインまで自動的に処理されるわけではありません。
DOMAIN-SUFFIX：ルートドメインとサブドメインを対象にする
[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTDOMAIN-SUFFIXは、ドメインの末尾にある境界を基準にマッチします。ここでのexample.comはルートドメインとそのサブドメインを対象とし、www.example.comやa.b.example.comが含まれます。文字列のどこかに同じ文字があればマッチするわけではありません。notexample.comはこのドメイン境界に該当せず、example.com.other.testもサブドメインではありません。
例では、portalの完全一致ルールが先にあるため、まずDIRECTで処理されます。example.comに属するその他のドメインは、後方一致ルールによってPROXYに振り分けられます。後方一致ルールを先頭に置くと、portalの例外が適用される機会はありません。完全一致ルールに自動的な優先順位があるのではなく、先に調べられるかどうかは記載順で決まります。
DOMAIN-KEYWORD：より広い文字列範囲にマッチ
[Rule]
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECTDOMAIN-KEYWORDは、ドメイン内のキーワードにマッチします。example.comに加えて、myexample.testも対象になる可能性があります。特定のドメインとそのサブドメインを処理したい場合、キーワードは通常、後方一致より範囲が広く、偶然同じ文字列を含む別のサイトまで処理するおそれがあります。よく使われる短い文字列をキーワードにすると、誤マッチの原因を特定しにくくなります。
まずDOMAINで個別の例外を指定し、DOMAIN-SUFFIXで明確なドメインの範囲を指定する方法がおすすめです。共通のサフィックスを持たない複数のドメインを名前の一部で分類する必要があり、対象範囲を確認できている場合に限り、DOMAIN-KEYWORDを検討してください。ドメイン一覧の管理を省く目的でキーワードに置き換えると、リクエストが分類された理由を後から説明しにくくなります。
ドメイン条件の境界と不足
Webページでは、メインサイト、静的リソース、認証、APIなどで複数のドメインにリクエストすることがあります。メインサイトが意図したルールにマッチしても、ページ内のすべてのリソースが同じポリシーで処理されるとは限りません。ページの表示は正常でも画像の読み込みやログインに失敗する場合は、メインドメインにルールを追加し続けるのではなく、実際に失敗したリクエストのドメインを確認してください。外部サービスへの依存も、記録に基づいて処理し、推測で対象範囲を一括して広げないでください。
アドレスを直接指定して接続すると、利用可能なドメイン情報がなく、ドメインルールの条件にマッチしないことがあります。暗号化された通信から取得できるドメイン情報は接続状況によって異なり、すべてのリクエストで元のドメインを復元できるとは限りません。記録にアドレスしか表示されない場合は、DOMAIN条件にそのアドレスを当てはめるのではなく、アドレスルールを確認してください。用語の意味は用語解説もご覧ください。
GEOIP、IP-CIDR、USER-AGENT
接続先がアドレスで示される場合や、振り分けにアドレスの所属情報が必要な場合は、アドレス系のルールを使用できます。ドメインルールと同じ一覧でマッチし、自動的に後ろへ配置されるわけではありません。USER-AGENTは確認可能なリクエストヘッダーを条件とするため、必要な入力情報が異なります。複数の種類を同じリストに並べるときは、それぞれの条件がどこから得られるかを確認してください。入力情報がないことを構文エラーと取り違えるおそれがあります。
IP-CIDRとIP-CIDR6
[Rule]
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR,198.51.100.8/32,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXYIP-CIDRはIPv4アドレスの範囲を表します。スラッシュの後の数字はネットワークプレフィックス長で、ポート番号や優先順位ではありません。/32は単一のIPv4アドレス、/24はより広いアドレスブロックを表します。IP-CIDR6はIPv6の範囲を表し、単一のアドレスには/128を指定できます。例に記載したアドレスはドキュメント用で、実際のサービスへの接続確認には使えません。
一般にプレフィックスが短いほど、対象範囲は広くなります。「対象を確実に含める」ためにネットワーク範囲を安易に広げると、無関係な接続まで別の経路に振り分けることがあります。記述前に実際のアドレスとネットワーク境界を確認してください。アドレスがドメインの名前解決結果であれば、今後別のアドレスが返される可能性も考慮しましょう。一度の解決結果だけでは、サービスが長期的に使用するすべてのアドレス範囲は分かりません。
GEOIP：アドレスデータベースに基づく判定
[Rule]
DOMAIN,service.example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYGEOIPは、アドレスデータベースに記録された地域分類に基づいてマッチします。例では、明示したドメインの例外を先に処理し、CNに分類される接続先アドレスをDIRECT、それ以外をFINALで処理します。地域分類は、ドメインの登録地域、コンテンツの言語、サービス提供元の所在地とは異なり、接続速度を示すものでもありません。データベースの情報と実際のネットワーク割り当てには時間差があり、複数地域での運用やアドレス変更によって、予想とデータベースの結果が異なることがあります。
地域分類だけでは安定して処理できない重要な接続先には、GEOIPより前に明確なドメインまたはアドレスの例外を追加し、理由を記録してください。実際の結果を確認せずに、地域全体のポリシーを頻繁に切り替えないでください。GEOIP,CN,DIRECT,no-resolveを使用する場合は、前の章で説明した名前解決の制約も考慮してください。利用可能なアドレスがなければ、想定した判定ができない場合があります。
USER-AGENTを使用できる範囲
[Rule]
USER-AGENT,ExampleClient*,DIRECT
FINAL,PROXYUSER-AGENTは、クライアントが読み取れるUser-Agentリクエストヘッダーを確認します。例では、ExampleClientで始まる値をワイルドカードで表していますが、特定の実在アプリを示すものではありません。OS上のアプリ名で振り分ける汎用機能ではなく、暗号化された接続から任意のリクエストヘッダーを取得できるわけでもありません。アプリの表示名、プロセス名、User-Agentは異なる場合があり、互いに置き換えて指定できません。
HTTPSでは、通常の接続処理だけで暗号化されたHTTPリクエストヘッダーを直接読み取ることはできません。USER-AGENTであらゆるアプリの通信を処理できると考えないでください。このページの例では、証明書の追加や復号範囲の拡大は必要ありません。ヘッダーを確認できるか分からない場合は、検証可能なドメインルールまたはアドレスルールを優先してください。対象にそのヘッダーがなければ、このルールにマッチする入力情報もありません。
条件の表現方法を選んでから例外を設定
業務ドメインの管理にはドメイン条件、固定アドレス範囲にはIP-CIDR、アドレスデータベースによる分類にはGEOIPを検討してください。USER-AGENTは、ヘッダーを読み取れることを確認し、ヘッダーによる区別が必要な場合に限って使います。ルールの種類を増やせば設定が充実するわけではありません。同じ対象に複数の条件を重ねると、特に異なるポリシーを指定した場合、理解や管理が難しくなります。
アドレスルールを検証するときは、アドレスファミリー、実際の接続先アドレス、マッチしたルールを記録してください。同じドメインでも、テストによってIPv4とIPv6が使われ、異なるルールにマッチする場合があります。比較テストでは、ネットワークと接続先をできるだけ同じ条件に保ってください。IPv6の例外を追加する場合も、対象範囲を確認してから指定し、IPv6通信をすべて一律に処理して局所的な設定ミスを隠さないようにしましょう。
ポリシー、Global Routing、優先順位
ルール条件は「マッチするか」を決め、ポリシーは「マッチ後にどう処理するか」を決めます。PROXY、DIRECT、REJECTは、このページの例で使う基本的なポリシーです。これらはHomeのGlobal Routingとは異なるレイヤーにあります。Global Routingは、設定による振り分けか全体に適用する状態かを決めます。Ruleのポリシーは、設定による振り分けの中で個々の接続の処理方法を指定します。トラブル対処では、外側の状態を確認してから内側のルールを見てください。
3つの基本ポリシーの動作
| ポリシー | 処理内容 | よくある誤解 |
|---|---|---|
PROXY | 現在有効なプロキシ出口を使用。 | ポリシーを書いてもサーバーは自動生成されない。 |
DIRECT | 接続先へ直接接続。 | 直接接続にもローカルネットワークと名前解決が必要。 |
REJECT | マッチしたリクエストを拒否。 | 拒否によってページに必要なリソースまで影響することがある。 |
PROXYを使うには、有効なサーバー情報と出口の選択が必要です。出口の認証に失敗しても、PROXYにマッチしたルール自体は正しい場合がありますが、その後の接続は完了できません。DIRECTでも必ず接続に成功するわけではなく、システムやネットワークの条件から外れるわけでもありません。REJECTはリクエストを明示的に拒否するポリシーで、意図したブロックに使います。広範囲のキーワードをそのままREJECTに指定し、リソースが読み込めない問題をサーバー障害と取り違えないでください。
Global Routingの3つの状態
設定に基づく振り分けはConfig、全体をプロキシ経由で処理する状態はProxy、全体を直接接続する状態はDirectです。ルールを確認するときはConfigに戻してください。ProxyまたはDirectのままでは、Ruleを変更しただけでルールが意図どおり動作するか検証できません。状態の切り替えは診断に使い、正しいルールの代わりとして常用しないでください。
このページで説明する振り分けは、クライアントの処理経路に入った後のものです。システム側のネットワーク処理やGeneralのバイパス範囲も実際の対象範囲に影響するため、「全体」をシステム上のすべての通信が必ず同じ経路を通るという意味に捉えないでください。具体的に観察できるリクエストをテストし、ステータスバーに接続表示があるだけで、すべての接続先が想定したポリシーを使っていると判断しないようにしましょう。
上から順に確認し、最初にマッチしたルールを適用
[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYRuleリストは通常、上から順に確認され、最初にマッチしたルールのポリシーが適用されます。「より正確な」ルールを探して確認を続けることはありません。上記の例では、単一ドメインの例外を後方一致ルールより前に、明示的なアドレス範囲を地域ルールより前に置き、最後にフォールバックしています。この順序は作成者の意図を示すもので、エンジンが精度を自動で順位付けした結果ではありません。同じ接続先に複数のルールが適用される場合は、先にあるルールが結果を決めます。
FINALは通常の条件付きルールではない
FINAL,PROXYは種類とポリシーだけを指定し、それ以前のルールにマッチしなかったリクエストを処理します。ドメインを追加する必要はありません。途中に置くと、それ以降のルールで残りのリクエストを処理できなくなります。設定を管理するときは、意図したフォールバックが末尾に1つだけあることを確認してください。ファイルを統合した結果、FINALが複数できていないかも確認しましょう。末尾をPROXYにするかDIRECTにするかは設定の目的によって異なります。現在のネットワークとアクセス要件に基づいて選び、どちらかが常に正しいと考えないでください。
ルールを並べ替える前に、具体的なドメインを1つ選び、先頭から順に条件を確認して最初にマッチしたところで止める手順を紙上で試してください。次に、ルール一覧に含まれない対象でも同じように確認し、FINALに進むことを確かめます。推論した結果と実際の記録が異なる場合は、マッチエンジンがキーワードの長さやドメイン階層で自動的に並べ替えると考える前に、使用中のファイル、状態、入力情報を確認してください。
HostとURL Rewriteの違い
HostとURL Rewriteはどちらもアクセス結果に影響する場合がありますが、処理対象は異なります。Hostはドメインとアドレスの対応を指定し、URL RewriteはURLの式に基づいて処理します。どちらもRuleのポリシー選択とは別の機能です。リクエストの接続先アドレスが想定と異なる場合や、別のURLに移動する場合は、名前解決のマッピング、書き換え結果、振り分けルールを分けて確認してください。Ruleだけを調べても原因を特定できないことがあります。
Host：名前解決のマッピングを指定
[Host]
fixed.example.com = 192.0.2.10
service.example.com = 198.51.100.20
[Rule]
DOMAIN,fixed.example.com,DIRECT
DOMAIN,service.example.com,PROXY
FINAL,PROXYここでは2つのHost設定例で、完全なドメイン名を指定したアドレスに対応付けています。アドレスはドキュメント用の例です。1つ目のRuleではfixed.example.comをDIRECTで処理しており、「どのアドレスに対応付けるか」と「どのように接続するか」は別々に指定する必要があります。Hostを設定したからといって、そのドメインが必ず直接接続になるわけではありません。また、DOMAINをPROXYに指定しても、誤ったアドレスマッピングが自動的に修正されることはありません。
固定マッピングを使うと、通常のDNS応答への依存を減らせますが、サービスがアドレスを動的に変更する際の柔軟性も失われます。動的な構成や複数地域の接続先を使うサービスでは、一度の名前解決で得たアドレスを長期間固定すると、次第に使えなくなることがあります。用途を確認し、継続的に管理できる場合に限って使用してください。一部のネットワークでのみ接続できない場合は、DNSを一括して置き換えるのではなく、Host設定を単独の変数として外して比較します。
Hostは証明書の識別情報を変更しない
ドメインを特定のアドレスに対応付けても、そのアドレスのサービスが正しいサイト設定や有効な証明書を自動的に持つわけではありません。HTTPSでは引き続き、アクセスするドメインに対応する識別情報が検証されます。サーバーがリクエスト内のホスト名に基づいてサイトを選ぶ場合もあります。マッピング後に証明書エラーが起きたら、そのアドレスが対象ドメインのサービスを実際に提供しているかを確認してください。アドレスの誤りを隠すために、識別情報の検証を無視しないでください。
同様に、HostはWebページをリダイレクトする機能ではありません。通常、アドレスマッピングだけでブラウザのアドレス欄に表示されるドメインが別の名前に変わることはありません。ブラウザが新しいページに移動する理由を調べる場合は、サーバーの応答またはURL Rewriteを確認してください。アドレスの変化と、画面に表示されるURLの変化を混同しないことが大切です。このようにレイヤーを分けて考えると、表面上似ている問題に誤った方法を使わずに済みます。
URL Rewrite：式と処理内容を確認
[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302この例では、マッチしたHTTP URLを対応するHTTPS URLにリダイレクトします。左側は正規表現です。^は文字列の先頭を示し、ドメイン内のピリオドはバックスラッシュでエスケープし、(.*)で後続部分をキャプチャします。中央には置換先を指定し、$1で最初のキャプチャグループを参照します。末尾の302は一時的なリダイレクトを示します。これは接続先ドメインをPROXYに渡す構文でも、サーバーにHTTPSを設定するものでもありません。
式を作成するときは、プロトコルとドメインの範囲を限定してください。エスケープされていないピリオドは任意の1文字を表します。また、先頭や末尾の境界がないとマッチ範囲が広がることがあります。ルートパス、クエリパラメーター付きのパス、似ているものの対象外であるドメインをそれぞれテストし、キャプチャ内容が欠落したり重複して連結されたりしていないか確認してください。個人用のクエリパラメーターを含む実際のURLを共有メモに貼り付けないでください。例にはexample.comを使用します。
確認できる範囲とリダイレクトループ
URL Rewriteでは、対象のURL情報を識別できる必要があります。通常の暗号化接続でURLのパス全体を読み取れるとは限らず、HTTPの例がすべてのHTTPSコンテンツにも適用できると考えないでください。この章では復号範囲を広げる必要はありません。ルールが動作しない場合は、まず入力URLを確認できるかを調べ、その後で式を確認してください。正規表現をすべてのドメインに広げてもリスクが増えるだけで、足りない情報を補うことはできません。
別のルールによって転送先が元のアドレスに戻されると、リダイレクトループが発生することがあります。ブラウザの履歴では、単なるタイムアウトではなく、転送が繰り返される形で確認できます。トラブル対処では、追加したRewriteを一時的に無効にして元のリクエストに戻ることを確認し、その後1つずつ有効にして比較します。Host、Rewrite、Ruleは分けてテストし、各段階で変更する仕組みは1つだけにしてください。比較用に元のURL、最終URL、マッチ結果を記録しておきます。
ルールの組み合わせ、統合、設定の管理
管理しやすい設定にするために大切なのは、ルールの数ではなく、各条件の用途が明確であることです。よくある構成では、明示的な個別例外を先に置き、続いて業務ドメインの集合を指定し、必要なアドレス条件や地域条件を後に置いて、最後にフォールバックします。これは一般的な例であり、固定の基準ではありません。設定の目的に応じて順序を変えても構いませんが、具体的なリクエストが現在の結果になる理由を説明できるようにしてください。
最小限の検証可能な例から始める
[Rule]
# 個別の例外をドメイン範囲より先に処理
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
# 利用可能な接続先アドレスだけを処理
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
# 地域判定の後にまとめてフォールバック
GEOIP,CN,DIRECT
FINAL,PROXYこの例はルール部分の構成方法を示すもので、サーバー情報や認証情報は含みません。まずportalがDIRECTで処理されるか確認し、次に同じサフィックスを持つ他のドメインがPROXYに進むかを確認します。最後に、関係のないドメインがアドレス分類またはFINALで処理されるかを確認してください。ドキュメント用のアドレスは実際のテストサーバーとして使わず、自分で接続情報を確認しており、アクセス権のあるテスト対象に該当する条件を置き換えてください。
REJECTを追加するときも、必要最小限の範囲に限定してください。まず、主要機能に影響しないことを確認した完全なドメインを指定し、実際の記録で対象リクエストが意図したものか検証します。リクエスト数を減らすためだけに、業務ドメイン全体を拒否しないでください。静的リソースだけを提供しているように見えるドメインが、認証やページの初期化に使われている場合もあります。誤って拒否した場合、すべての通信が切れるのではなく一部だけが正常に動作しなくなることがあります。
統合前に重複と終端条件を整理する
2つのファイルを単純に連結すると、セクションの重複、競合するポリシー、途中に配置されたFINALが生じることがあります。統合前に1つの明確なRuleリストに整理し、各ルールの位置を確認してください。同じ条件と同じポリシーのルールが重複している場合、通常は管理の手間が増えるだけです。ポリシーが異なると、後のルールが長期間マッチしないまま残り、どちらの処理も有効だと誤解されるおそれがあります。
テキストの重複だけで競合を判断することはできません。DOMAINとDOMAIN-SUFFIXは記述が異なっていても、同じ接続先を対象にする場合があります。IP-CIDRとGEOIPも、アドレス範囲が重なることがあります。代表的な接続先をいくつか選んで順に確認し、例外が範囲の広い条件より前にあることを確かめてください。統合後は、意図したフォールバックが1つだけ残っていることと、すべてのポリシー名が現在の設定環境で解決できることを再確認します。
リモート更新とローカル編集の違い
既存サブスクリプションの更新では主にサーバー情報が更新されます。一方、リモート設定の更新ではRuleやGeneralなどのテキストが更新される場合があります。これらを同じものとして扱わないでください。更新後に動作が変わった場合は、何が更新されたのかを最初に確認しましょう。サーバー一覧の変化は出口の選択に、ルールテキストの変化はマッチ経路に影響する可能性があります。更新前後のファイルを別々に保存しておくと、記憶だけに頼るより差分を見つけやすくなります。
継続して利用する場合は、検証済みのローカル変更を別のコピーに保存し、入手元、目的、元に戻す方法を記録しておくと便利です。リモートの内容を更新する前に、そのファイルが上書きされるか確認してください。ローカルで追加した内容がすべて自動的に保持されるとは限りません。読み込み方法とサブスクリプション更新の違いは、Subscribe、Add Server、QRコード、クリップボードからの読み込み方法をご覧ください。
コメントには理由と取り消し条件を記録
有用なコメントはルールを言い換えるだけでなく、例外が必要な理由、検証方法、取り消せる条件を明確にします。たとえば「このAPIはメインサイトと同じ出口が必要。テスト時にログインと後続APIを確認」と記録するほうが、「APIルール」とだけ書くより役に立ちます。サブスクリプションの認証情報、完全な個人用URL、サーバーのパスワードをコメントに保存しないでください。設定内容を問い合わせのために共有する場合は、先に機密情報を伏せてください。
変更のたびに、変更した条件、変更前の結果、期待する結果、実際の結果を簡潔に記録してください。ルールを追加しても問題が改善しない場合は、別の条件を試す前に追加分を元に戻しましょう。効果のなかった修正をリストに残し続けないでください。ルール管理の目的は、設定が複雑になって追跡できない例外を増やすことではなく、現在の動作を後から再現して説明できるようにすることです。
マッチの確認と接続のトラブル対処
ルールと接続の問題はどちらもページを開けない症状として現れますが、対処方法は異なります。ルールの確認ではリクエストが意図したポリシーに進んでいるかを調べ、接続の確認ではそのポリシーに対応するネットワーク経路が使えるかを調べます。「現在の接続状態」「マッチした条件」「出口への接続結果」を分けて記録してください。VPNスイッチがオンなのは設定による接続が開始されたことを示すだけで、サーバー、DNS、接続先サービスがすべて正常である証拠にはなりません。
再現可能なテスト条件を用意
開始前に、ネットワークの種類、Global Routingの状態、現在の設定名、選択中のサーバー、具体的なテスト対象を記録してください。まず既存の設定で基本的な接続を確認し、その後Configで対象ルールを調べます。テストのたびに接続を開始し直し、アプリが以前のセッションを再利用しないようにしてください。似たページを複数開いて体感速度を比べるのではなく、実際のリクエストが意図したポリシーにマッチした証拠を確認します。
Connectivity Testは、登録済みサーバーへの接続状況を確認するのに役立ちます。ただし結果はテスト時の条件に限られ、すべてのドメインやすべてのプロトコルのリクエストが成功することを示すものではありません。サーバーのテストに成功しても、DNS、振り分け、サーバー側の制限、アドレスファミリーの違いによって接続先サイトにアクセスできないことがあります。サーバーテストの成功は確認項目の1つであり、ルールの検証を省略する理由にはなりません。
想定したルールにマッチしない場合
- Global RoutingがConfigであることと、Configで選択されているのが編集したファイルであることを確認します。
- リクエストが実際に使用するドメインまたはアドレスを確認します。ブラウザのアドレス欄だけですべてのリソースの接続先を判断しないでください。
- リストの先頭から確認し、先にマッチする範囲の広い条件、重複条件、途中に置かれたFINALがないか調べます。
- 半角カンマ、セクション名、ポリシー名、no-resolveが入力条件に与える影響を確認します。
記録にアドレスしか表示されない場合は、ドメインを実際に利用できないのか確認してから、IP-CIDRまたはGEOIPを調べてください。意図しないDOMAIN-KEYWORDにマッチした場合は、キーワードの対象範囲を狭めることを検討します。ルール自体が処理に参加していない場合は、Generalのバイパス設定も確認してください。問題の原因となる条件を失わないよう、最初から設定ファイル全体を削除しないでください。
正しいポリシーにマッチしても接続できない場合
| 確認された結果 | 優先して確認 | 最初に行わないこと |
|---|---|---|
| PROXYにマッチした後に失敗。 | 現在の出口、認証情報、接続先への到達性。 | 同じドメインのルールを繰り返し追加する。 |
| DIRECTにマッチした後に失敗。 | システムネットワーク、DNS、接続先アドレス。 | 直接接続なら必ず成功すると考える。 |
| ページの一部のリソースだけ失敗。 | 失敗したリソースの個別ドメインとポリシー。 | メインサイトに合わせてキーワード範囲を広げる。 |
| リダイレクトが繰り返される。 | URL Rewriteとサーバー側のリダイレクト。 | プロキシ出口だけを変更する。 |
PROXY経由の接続に失敗した場合は、ルールを変えずに、自分がすでに利用できる別の有効な出口で比較できます。出口を変えて復旧した場合は、元の出口または接続先までの経路に問題がある可能性が高まります。DIRECT経由で失敗した場合は、同じネットワークでシステムからアクセスできるかを確認してください。比較時には、各回に何を1つだけ変更したか記録し、ネットワークの変動と設定変更を混同しないようにします。
一部のリソースだけ失敗する場合と設定の切り戻し
ログイン、画像、動画、APIに失敗した場合は、メインページと同じドメインや接続を使うと決めつけず、該当するリクエストを確認してください。REJECTが依存リソースを拒否していないか、異なるドメインが互換性のない出口経路に振り分けられていないかも調べます。設定を追加してから問題が起きた場合は、まず元の状態に戻して関連性を確認し、その後1つずつ変更を戻してください。修正を追加し続けるより、原因を特定しやすくなります。
問題の記録を整理するときは、設定の一部、機密情報を伏せた接続先名、マッチしたルール、エラーの状況だけを残してください。認証情報、個人用サブスクリプションURL、機密性の高いリクエスト内容は削除します。プロトコルパラメーターの不一致については、VMessとVLESSの設定項目の違いをご覧ください。よくある接続の症状は、よくある質問で種類ごとに確認できます。認証の問題をルールキーワードの問題と取り違えないでください。
検証が終わったら、普段使用しているGlobal Routingの状態に戻し、動作を確認した設定を保存して、一時的なHost、Rewrite、テストルールを削除してください。最初から手順を確認する場合は、使い方ガイドに戻り、読み込み、出口の選択、VPN設定の許可、接続確認を順にチェックしてください。システム要件、デバイスの互換性、アプリの入手方法はApp Storeの製品ページをご確認ください。