公式マニュアル · 設定項目
Shadowrocket ルール・設定ガイド
このページでは、設定の構成、ルール条件、評価順を体系的に確認できます。既存のサブスクリプションを初めて読み込んで接続する場合は、先に使い方ガイドをご覧ください。ガイドでは操作の流れを、本ページでは項目と判定ロジックを解説します。Configの編集、ルールの適用確認、設定差分の比較にお役立てください。
以下の例は、利用者自身がサブスクリプションまたはサーバー情報をすでに持っていることを前提としています。例にある example.com、ローカルネットワークのアドレス、ポリシーは構文の説明用で、そのまま使える接続サービスではありません。各項目の意味を確認してから自分の設定に取り込み、断片だけで既存ファイル全体を置き換えないでください。
1. 設定ファイルの構成と編集時の注意点
編集する前に、現在どの設定ファイルが有効か確認します。Shadowrocketでは複数の設定ファイルを保存できますが、Configリストにファイルがあることと、接続に使用中であることは別です。Configを開いて選択中のファイルを確認し、ファイル名と入手元を控えてから内容を確認してください。画面上のルールが想定と異なる場合、似たルールを追加する前にファイルの選択間違いを確認します。リモートから取得したファイルでは、ローカルでの変更と再更新後の内容も区別してください。
セクション名で項目の意味が決まる
設定テキストは角括弧で囲まれたセクション名ごとに分かれています。[General]には全体の動作に関する設定、[Rule]には順に評価する振り分け条件、[Host]にはホスト名とアドレスの対応、[URL Rewrite]にはURLの書き換えルールを記述します。同じ行でも、置くセクションによって意味は異なります。ドメインルールをGeneralに貼り付けても、文字列が正しいだけでルールとして認識されるわけではありません。構成を確認するときは、セクション名から次のセクション名までを読み進めてください。
[General]
bypass-system = true
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY
[Host]
example.com = 192.0.2.10
[URL Rewrite]
^http://example\.com/ https://example.com/ 302上記は4つのセクションがどのようにつながるかを示す例であり、すべてを有効にすることを推奨するものではありません。Hostのアドレスは文書用の例で、URL Rewriteも明示的なHTTPアドレスの転送例です。改行は項目の区切り、半角カンマはルール内のフィールドの区切り、一部の設定ではイコール記号は項目名と値の区切りに使います。全角の句読点、コピー時に混入した不可視文字、誤ったセクション名がないか、接続を試す前に確認してください。テキストの誤りをネットワーク障害と取り違えないためです。
ローカルコピーとリモート更新
編集を始める前に、元に戻せるコピーを保存してください。リモート設定を使っている場合は、更新によってどの内容が置き換わるかを先に確認します。取得元のファイルに個人用ルールを直接追加すると、次回更新時に元の内容で上書きされることがあります。取得元のファイルを参照用に残し、明確に分けたローカルコピーで試し、変更の目的を記録する方法が安全です。Generalの置き換え、Ruleの並べ替え、Hostの追加を一度に行い、ひとつのアクセス結果だけですべての変更を判断するのは避けてください。
Subscribeと設定ファイルも別のものとして理解しましょう。既存のサブスクリプションは通常サーバー情報の管理に使い、設定ファイルは接続の処理方法を記述します。利用の流れで関連することはありますが、一方を更新しても、もう一方が変更されたとは限りません。サーバーリストだけが更新され、ルールが変わっていない場合は、Subscribeを何度も更新せず、Configで実際のファイルを確認してください。逆に、ドメインのポリシーを変更しても、サーバーのアドレス、ポート、認証情報が補われることはありません。
小さな変更で検証可能な結果を得る
1回の変更では、テスト用ドメインをDIRECTにする、範囲が広すぎるREJECT条件を絞るなど、目的をひとつに限定します。変更前に、どのルールが適用されるか、どのポリシーが使われるか、新しい接続をどう確認するかを書き出してください。保存して設定を確認したら、対象の接続を新たに開始し、結果を確かめます。既存の接続は以前の処理経路を引き継ぐ場合があります。すでに開いているページを更新しただけで、新しいルールがすべてのリクエストに適用されたと判断しないでください。
設定を共有する前に、個人の接続情報、サブスクリプションURL、認証情報を削除してください。ルール例にはテスト用ドメインを残せますし、障害の説明には必要な項目名を含められますが、設定全体には問題と関係のない情報まで含まれていることがあります。協力を求める場合は、関係するセクション、ルールの相対的な順序、個人情報を伏せた接続ログを共有してください。再現しやすくなり、無関係な項目に議論が流れるのも防げます。特定のドメインが意図しない経路に振り分けられる問題の確認にも有効です。
2. General：全体設定とDNSの前提
Generalは設定全体の動作に関わる項目を扱い、個々のドメインにポリシーを選ぶものではありません。このセクションを確認するときは、まずフィールド名、次に値の形式、最後に調査中の問題との関連性を見ます。たとえばドメインを解決できない場合はDNSの経路を確認します。特定のドメインが誤ってDIRECTになる場合は、まずRuleと現在のGlobal Routingを確認します。問題をすべてGeneralのせいにすると、調整箇所が増え、もともと明確だったルール順序の問題を見落としやすくなります。
フィールドと値は形式に合わせて記述
Generalでは、フィールド名、イコール記号、値の順で記述するのが一般的です。真偽値には true または falseを使い、アドレスを指定する項目には、そのフィールドで認められた形式を使います。値の欄に日本語の説明を書いたり、他の人の設定にある項目を見ただけで自分のネットワークにも適すると判断したりしないでください。項目の意味が不明な場合は、アプリ内の設定編集に関する説明で用途と指定可能な値を確認します。名前から推測して変更するより、元の値を保つほうが結果を理解しやすくなります。
[General]
bypass-system = true
dns-server = systembypass-systemはシステム関連トラフィックをバイパスする動作を制御します。「すべての接続を直接アクセスさせる」という意味ではなく、Global RoutingのDirectの代わりにもなりません。この項目を変更する場合は、すべての通信に同じ変化が起こると考えず、影響を受けるシステムトラフィックの経路を確認してください。通常のウェブ閲覧の問題がシステムサービスと無関係なら、ひとつのドメインを直すために変更範囲を広げず、現在の設定を保つことを検討してください。
DNSの名前解決とルール判定は別の処理
dns-server = systemはシステムのDNS経路を使う指定です。独自のDNSアドレスを使う場合は、現在のネットワークから到達できるか、設定の説明と合わせて確認してください。ルール判定には、条件に応じたリクエスト情報が必要です。ドメインを使う条件もあれば、接続先IPを使う条件もあります。DNSはドメイン名をアドレスに解決し、Ruleは処理ポリシーを選びます。相互に影響しますが、互いの代わりにはなりません。PROXYルールを追加しても、到達不能なDNSサーバーが復旧するわけではありません。
DNS over HTTPSを使う場合は、DNSリクエストの転送方式と、最終的なウェブサイトへの接続ポリシーを区別してください。DNSリクエストがHTTPSで送信されても、その後のウェブ通信すべてに同じポリシーが適用されるとは限りません。ウェブサイトがPROXYを通るかどうかは、現在のモードと適用されるルールで決まります。DNSサーバーのホスト名自体を先に解決する必要がある場合は、その名前解決経路も考慮してください。異なる提供元のアドレスを一度に多数設定し、たまたまアクセスできたことだけで、すべて正常だと判断しないでください。
比較できる基本設定から始める
DNSを変更する前に、元に戻せる設定を保存し、問題を安定して再現できるテスト用ドメインを選び、使用中のネットワーク種別を記録してください。同じネットワーク、サーバー、ルールのまま、DNS設定だけを変更して、名前解決の結果と接続ログに変化があるかを確認します。モバイル通信への切り替え、サーバー変更、DNS変更を同時に行うと、どれが差を生んだのか判断できません。ネットワークを切り替えた後はキャッシュが残る場合もあるため、検証には新しいリクエストを使い、古いタブだけを確認しないでください。
遅延テストに数値が出るのにウェブページが開かない場合、何らかのテストリクエストが応答したことは分かりますが、DNS、接続先、ページ内のすべてのリソースが正常とは限りません。ウェブページは複数のホスト名にリクエストを送ることがあり、そのうちひとつでも名前解決に失敗すれば表示に影響します。まず実際に失敗したドメインを特定し、アドレスが取得できたか、どのポリシーが適用されたか、接続がどの段階で止まったかを確認してください。この症状については、DNS名前解決に失敗した場合の確認手順もご覧ください。
アプリ内のフィールドが例と異なる場合は、アプリ内の説明に従い、未知の項目を無理に追加しないでください。Generalに多くの設定をコピーして「補完」するのではなく、意味を説明できる最小限の設定にすると保守しやすくなります。残す各フィールドについて、「何を変えるのか」「なぜ必要なのか」「どう元に戻すのか」を説明できるようにしてください。DNSの選び方について詳しくは、システムDNS、カスタムDNS、DNS over HTTPSをご覧ください。本ページでは主に、トラフィックの振り分けを判定するための前提を説明します。
3. ドメインルールと USER-AGENT 条件
ドメインルールは、「特定のホスト名、または関連するホスト名のグループにどのポリシーを適用するか」を指定する場合に適しています。基本的なルールは、タイプ、照合する値、ポリシーで構成され、半角カンマで区切ります。照合値には通常ホスト名を指定し、完全なウェブアドレスは指定しません。プロトコル、ポート、パスも含めないでください。同じホスト上の特定ページだけに異なるポリシーを適用したい場合は、ドメインルールに必要な情報があるか確認します。ドメインルールだけではパスを区別できません。
DOMAINとDOMAIN-SUFFIXの適用範囲
DOMAINはホスト名を完全一致で照合するため、特定の接続先だけを個別に扱う場合に適しています。DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致するため、同じドメイン体系のリクエストをまとめて処理する場合に便利です。後者は任意の文字列の末尾を照合するものではなく、ドメイン境界を考慮します。文字列の最後が同じなら一致すると考えないでください。タイプを選ぶ前に、対象にしたいホスト名を列挙すると、範囲が広すぎないか確認しやすくなります。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXYこのルールでは、api.example.comが最初にDOMAINに一致してDIRECTになり、www.example.comは1行目に一致せず、次のDOMAIN-SUFFIXに一致してPROXYになります。上の2行を入れ替えると、完全一致のドメインも先にサフィックスルールに適用されます。これは完全一致のタイプが機能していないのではなく、前の行で判定が終わるためです。例外を残す場合は、狭い条件を広い条件より前に配置してください。タイプ名によって自動的に優先されるわけではありません。
DOMAIN-KEYWORDの一致範囲
DOMAIN-KEYWORDはドメインに指定したキーワードが含まれるかを調べます。特定の組織やドメイン体系に限定されません。キーワードが短いほど、意図しない対象に一致する可能性が高まります。文字列による条件が本当に必要な場合に使い、明確なドメインを多数指定する代わりに、よく使われる単語ひとつで済ませないでください。REJECTに設定する場合は特に注意が必要です。誤って一致した正常なリクエストまで遮断され、画像の欠落、ログインの失敗、ページの読み込み継続などにつながることがあります。
[Rule]
DOMAIN,downloads.example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
FINAL,PROXYこの例では、確定したホスト名の例外を先に設定し、その後にキーワードで遮断します。downloads.example.comには文字列 ads も含まれるため、例外の位置が結果を左右します。実際の調査では、「広告ドメインかどうか」という主観的な判断ではなく、比較対象となったホスト名とルールの文字列を確認してください。一致範囲が想定より広い場合は、例外を増やして補うよりDOMAINまたはDOMAIN-SUFFIXに変更することを検討してください。
USER-AGENTを使う際の制約
USER-AGENTはリクエストから取得できるUser-Agentフィールドを照合します。値には、対応するワイルドカード形式を使えます。アプリの識別機能ではなく、特定のプロセスを確実に示すものでもありません。リクエストにこのフィールドがない場合があり、複数のアプリが似た値を使うこともあります。暗号化されてフィールドを参照できない通信では、読み取れるとは限りません。長期的に安定した振り分けが必要な場合は、まず明確なドメインや接続先アドレスを検討し、この条件が適切か判断してください。
[Rule]
USER-AGENT,ExampleClient*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY表のExampleClientはフィールドの先頭部分を示す例で、実在のアプリを表すものではありません。USER-AGENTルールを検証する前に、リクエストにそのフィールドが含まれ、アプリから取得できることを確認してください。ルールに一致させるためだけに、追加の通信復号設定を導入しないでください。暗号化された通信で何を参照できるかは、通常のドメイン振り分けとは分けて評価します。フィールドの内容を確認できない場合は、観測可能なドメインルールのほうがテスト条件と元に戻す方法を明確にできます。
| タイプ | 照合対象 | 主な注意点 |
|---|---|---|
DOMAIN | 完全なホスト名 | 明確な例外に適しています。サブドメインは自動的に含まれません。 |
DOMAIN-SUFFIX | ドメインとそのサブドメイン | ドメイン境界と前にあるルールを確認してください。 |
DOMAIN-KEYWORD | ドメイン内の文字列 | 適用範囲が広がりやすいため、誤一致を確認してください。 |
USER-AGENT | 参照可能なリクエストフィールド | アプリ名やプロセス識別子と同じではありません。 |
4. IP-CIDR、IP-CIDR6、GEOIP
IPルールはウェブサイトの文字列名ではなく、接続先アドレスを比較します。ひとつのドメインが複数のアドレスに解決されることがあり、同じアドレスに複数のドメインが割り当てられることもあります。そのため、アドレス条件とドメイン条件は同じではありません。特定のウェブサイトに安定したポリシーを適用する場合は、まずドメインルールが適切か確認してください。明確なローカルネットワークの範囲、単一の接続先アドレス、またはアドレスの帰属範囲を扱う場合は、IP条件を使います。短く書けるかではなく、表したい範囲に基づいて選んでください。
プレフィックス長でアドレス範囲を指定
IP-CIDRはIPv4アドレスの範囲に使用します。スラッシュの後の数字はネットワークプレフィックス長で、ポート番号や利用可能なアドレス数ではありません。たとえば 192.168.0.0/16はプライベートアドレスの範囲を表し、192.0.2.10/32は特定のIPv4アドレスを表します。ネットワークアドレスとプレフィックスを明確に指定し、自分の端末に現在割り当てられているアドレスをネットワーク全体と取り違えないでください。範囲の指定を誤ると、想定より多くの接続先に適用されるおそれがあります。
[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,192.0.2.10/32,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXYIP-CIDR6はIPv6アドレスの範囲に使用します。例にある 2001:db8::/32は文書用の範囲で、実際のネットワークを表すものではありません。接続先がIPv4とIPv6の両方に対応している場合、IPv4条件だけを設定しても、もう一方の接続が同じ扱いになるとは限りません。接続ログで接続先のアドレス種別を確認してください。同じウェブページでも結果が異なる場合、ルールの適用順が変わったのではなく、選択されたアドレスが異なる可能性があります。
no-resolveはDNSを無効にする設定ではない
no-resolveは、一部のアドレスルールに追加できるオプションで、そのルールの判定のためにドメイン名の解決を積極的に行わないようにします。設定全体の名前解決を止めたり、接続先にアドレスが割り当てられないことを意味したりするものではありません。リクエスト自体がIPアドレスを使う場合や、判定時に利用可能なアドレスがすでにある場合は、アドレス条件との照合が行われます。ローカルネットワークのアドレスルールでは、ネットワーク範囲の判定だけを目的とする余分な名前解決を避けるために使われることがありますが、追加するかどうかは対象に応じて判断してください。
利用可能なIPアドレスがない場合、no-resolveを付けたルールはドメイン名だけから接続先のネットワーク範囲を判断できません。一方、このオプションを付けないアドレス条件では名前解決が関わり、DNS経路が判定に影響することがあります。多くのアドレスルールをドメインルールより前に置くと、名前解決の動作も把握しにくくなります。処理経路を明確にするには、既知の接続先を明示的なドメイン条件で先に処理し、残りをアドレス条件で扱うと確認しやすくなります。
GEOIPはアドレスの帰属先を判定する
GEOIP,CN,DIRECTは、アドレスの地理情報データベースに基づき、CNに分類された接続先をDIRECTで処理します。ウェブページの言語、ドメインの末尾、企業の登記地、ユーザーの所在地で判定するものではありません。中国語のコンテンツを提供するウェブサイトが別の地域のアドレスに接続することもあり、同じドメインでも名前解決の結果により帰属先が異なる場合があります。GEOIPの結果を確認するときは、ウェブサイト名だけで誤判定と決めつけず、実際の接続先IPも確認してください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYこのルールでは、まずexample.comのドメイン体系を処理し、それ以外のリクエストをGEOIPで判定します。GEOIPを前に置くと、解決されたアドレスが先に一致し、後続のドメインルールが評価されない場合があります。アドレスの帰属先データベースには更新や判定範囲の限界があり、業務上の分類を正確に示すものではありません。特定の重要なドメインに固定ポリシーを適用したい場合は、すべてのアドレスが同じ帰属先に保たれることを期待するより、明確な条件を先に設定するほうが確実です。
ローカルネットワークの接続先を調べるときは、「ルールがDIRECTを選ぶこと」と「端末からその接続先に到達できること」を区別してください。DIRECTは直接接続を選ぶだけで、ローカルネットワークの経路を追加したり、接続先ポートを修正したり、アクセス権を変更したりするものではありません。ルールが正しく一致してもアクセスできない場合は、現在のWi-Fi、接続先端末の状態、アドレスが変わっていないかを確認してください。実際の接続先アドレスを確認してからネットワーク範囲のルールを調べ、古いアドレスやサービスが待ち受けていない問題をIP-CIDRの構文エラーと取り違えないようにします。
5. PROXY、DIRECT、REJECTとGlobal Routing
ルールの最後の主要なフィールドには、通常、処理ポリシーを指定します。条件は「どのリクエストか」を示し、ポリシーは「一致した後にどう処理するか」を示します。PROXY、DIRECT、REJECTは異なる処理結果であり、速度の段階や接続品質のランクではありません。設定を確認する際は、まずポリシーを一覧にし、それぞれが用途に合うかを確認してから、各条件が正しいポリシーに接続されているかを調べるとよいでしょう。
ポリシー名と処理内容
PROXYはリクエストをプロキシ経路に送りますが、利用可能なサーバー情報と選択内容に依存します。ルール中のテスト用ドメインからサーバーが生成されるわけではなく、サブスクリプション内の無効な項目が修復されるわけでもありません。DIRECTは接続先への直接接続を選びますが、ローカルネットワーク、名前解決の結果、接続先サービスの状態に左右されます。REJECTは一致したリクエストを遮断するため、遮断すべき対象が明確な場合に使います。範囲が曖昧な条件に適用すると、個別のページ障害のように見える問題が起きやすくなります。
| ポリシー | 一致後の処理 | 確認する点 |
|---|---|---|
PROXY | プロキシ経路を使う。 | 既存のサーバーが有効か、接続先につながるか。 |
DIRECT | 接続先に直接接続する。 | ローカルネットワーク、名前解決、接続先アドレスに到達できるか。 |
REJECT | リクエストを遮断する。 | 条件の範囲が広すぎないか、関連リソースまで誤って遮断していないか。 |
設定でカスタムポリシー名を使用する場合は、現在の設定内でその名前が定義されており、参照する文字列と完全に一致することを確認してください。他の人のファイルにあるポリシーグループ名を自分のルールの末尾に貼り付けても、既存のサーバーに自動的に対応するわけではありません。スペース、大文字・小文字、名前の変更もひとつずつ確認してください。初めてトラブル対処をする場合は、意味を説明できる基本ポリシーで比較し、その後に複雑なポリシー構成を追加すると、問題を特定しやすくなります。
Global Routingで設定の適用方法を選ぶ
Global RoutingのConfig、Proxy、Directは、それぞれ設定に従う、プロキシ経路を使う、直接接続するモードです。Ruleでリクエストを個別に振り分ける場合は、Configを選んでください。ProxyとDirectは全体の経路を比較するために使えますが、各ルールが正しく動作するかの確認にはなりません。モードが変わっているときの接続結果から、Ruleの特定の行が有効だとは判断できません。障害を記録する際は、モードと設定ファイルの両方を明記してください。どちらかが欠けると再現条件が不完全になることがあります。
| 画面上の表記 | 説明 | 確認に適した目的 |
|---|---|---|
| Config | Config：現在の設定に従って接続を処理する。 | Ruleの条件、順序、ポリシーを検証する。 |
| Proxy | Proxy：全体をプロキシ経路にして比較する。 | 既存のサーバー経路と設定による振り分け結果を比較する。 |
| Direct | Direct：全体を直接接続にして比較する。 | ローカルネットワークの経路とプロキシ経路を比較する。 |
モードを比較して原因を絞り込む
ある接続先がProxyではアクセスできるのにConfigでは失敗するとしても、すぐに設定全体が使えないと判断しないでください。Configに戻り、その接続先に適用されたルールを確認します。REJECTで遮断された、到達できないDIRECT経路に送られた、異なるカスタムポリシーが使われた、といった可能性があります。どちらのモードでも失敗する場合は、サーバー、DNS、接続先サービスをさらに確認してください。モードの比較は手がかりであり、特定のフィールドに必ず誤りがあるという結論ではありません。
Global Routingを切り替えた後は、新しい接続で確認してください。すでに確立したセッションが通信を続けたり、アプリが既存の接続を再利用したりする場合があります。モードを何度も切り替え、同じページをすぐに再読み込みしても、正確な比較にならないことがあります。他の条件を変えず、識別しやすいリクエストを新たに実行し、接続ログで経路を確認してください。ページ表示だけを見るとキャッシュの影響も受けます。以前のページが表示されても、直前のネットワークリクエストが成功したとは限りません。
クライアントの購入と接続サービスは、常に分けて考えてください。ShadowrocketはAppleプラットフォーム向けの有料クライアントです。クライアントの買い切り ≠ 回線プランです。利用者自身が持つサブスクリプションまたはサーバー情報が別途必要です。アプリの入手方法、正規アイコン、開発者の確認についてはApp Storeからの正規ダウンロードと確認方法をご覧ください。対応デバイスとシステム要件はApp Storeページの記載をご確認ください。設定項目は既存の接続動作を管理するものであり、接続リソースを提供するものではありません。
6. 評価順、例外ルール、FINAL
Ruleの基本は、上から順に条件を評価し、一致した時点で対応するポリシーを使って処理を終えることです。より直感的に適切と思える条件を下まで探し続けることはありません。「完全一致のドメインは常にネットワーク範囲より優先される」といった自動的な優先順位は、ルールの種類にはありません。優先順位はまず、ファイル内での位置によって決まります。ルールが適用されない理由を調べるときは、そのルール自体の構文を繰り返し確認するだけでなく、上にある項目から確認してください。
例外を先に、広い範囲を後に
目的に応じて条件を並べる方法として、明確な例外を先に置き、より広いドメインやアドレス範囲を後に、最後にデフォルトルールを置くことをおすすめします。これは保守しやすくするための並べ方で、すべてのファイルに同じ分類順を強制するものではありません。結果を決めるのは、各接続先が最初に一致する位置です。たとえばローカルネットワークのサービスを個別に処理する場合、上にある広範なドメイン条件やアドレス条件が先に適用されないか確認してください。ローカルネットワークに属するからといって、自動的に優先されるわけではありません。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYこの例では、api.example.comは最初のルールに一致して、サフィックス判定には進みません。ads.example.comは2行目で遮断され、その他のexample.comのサブドメインにはPROXYが適用されます。その後、まだ一致していない接続先に対してアドレス範囲とGEOIPを判定します。ルールを読むときは、具体的な接続先を3つ選び、1行目から順に手作業でたどり、最初に条件を満たす行に印を付けてください。例外の配置間違い、条件の重複、デフォルトルールの早すぎる配置を見つけやすくなります。
FINALは条件にかかわらないデフォルトルール
FINALは、それより前のどの条件にも一致しなかった接続を処理します。よく使われる書き方は FINAL,PROXY または FINAL,DIRECTです。ドメインやアドレスの照合値はないため、通常のドメインルールとはフィールド数が異なります。Ruleセクションの有効なルールの最後に配置してください。その後にDOMAINの項目を追加しても、より具体的だからといって再評価されるわけではありません。「記述したのに適用されない」という誤解につながります。
FINALのポリシーを選ぶ前に、デフォルトの経路を明確にしてください。FINAL,PROXYは個別に分類されなかった接続をプロキシ経路に送り、FINAL,DIRECTは直接接続します。どちらが適切かは、前にあるルールとの組み合わせで変わります。同じ条件でもデフォルトルールが異なれば、対象範囲が変わります。FINALの変更は影響範囲が広いため、重要な接続先が実際にどこで一致するかを先に確認してください。ひとつのサイトを直すために、未分類の通信すべての経路を変更しないようにします。
重複ルールとリモート設定の整理
ルールが重複していても構文エラーになるとは限りませんが、読み解く負担が増えます。条件が完全に同じでポリシーだけが違う場合、後のルールは通常、前のルールに隠れて適用されません。条件が似ていても範囲が異なる場合は、対象ごとに判断が必要です。整理するときに単純なアルファベット順に並べ替えると、意図した例外の順序が壊れることがあります。まず各グループの目的を記し、明らかに不要な項目を削除してから、重要なドメインを再確認してください。
複数の取得元からルールをまとめる際によくある問題は、セクション名の重複、FINALの重複、既存のデフォルトルールより後にセクション全体を挿入してしまうことです。まず断片がどのセクションに属するか確認し、不要なセクション見出しを取り除いてから、意図した位置にルールを追加してください。カスタムポリシーを参照する断片では、その依存先が存在することも先に確認します。テキストに貼り付けられるからといって、現在の設定の構成、ポリシー、デフォルト経路と互換性があるとは限りません。
長いルールリストを管理する場合、変更記録には「何を追加したか」だけでなく「なぜここに置いたか」も記してください。たとえば、完全一致ドメインをサフィックスルールより前に置くのは、直接接続する例外を保つためかもしれません。キーワードルールを削除したのは、正常なリソースまで対象になったからかもしれません。こうした背景は、項目数より後のトラブル対処に役立ちます。想定外のルールが適用されたら、まず関連する数行に絞って検証し、確認後に全体へ戻してください。逆のルールを次々に追加して当たりを待つのは避けましょう。
7. HostとURL Rewriteの役割と範囲
Host、URL Rewrite、Ruleは、それぞれアドレスの対応付け、リクエストURLの書き換え、処理ポリシーの選択を行います。別々の機能として扱ってください。設定ファイルにすべてのセクションがあるからといって、トラブル対処のたびに同時に変更する必要はありません。特定のドメインをPROXYに通すだけならRuleを使います。明確なホスト名にアドレスを割り当てる場合はHostを検討します。条件に一致するURLを変更する必要がある場合にのみ、URL Rewriteを確認してください。機能の範囲を区別すると、効果が分かりにくい修正を減らせます。
Hostでホスト名とアドレスを対応付ける
Hostの基本的な書き方は、ホスト名、イコール記号、接続先アドレスです。完全なウェブURLは指定しません。変更されるのはホスト名に対応するアドレス情報で、PROXYやDIRECTを直接指定するものではありません。Hostでドメインにアドレスを割り当てても、接続は現在のモードと関連ルールに従って処理されます。Hostの行末にポリシー項目を追加して、ドメインの振り分けも同時に行おうとしないでください。アドレスの対応付けとポリシー条件は、それぞれのセクションに記述します。
[Host]
service.example.com = 192.0.2.10
[Rule]
DOMAIN,service.example.com,DIRECT
FINAL,PROXY例のアドレスは文書での説明用で、実際のアクセスには使えません。実際の対応付けを設定する前に、接続先サービスが提供する信頼できる設定に基づいたアドレスか、いつ元に戻す必要があるかを確認してください。ウェブサイトは動的なアドレスや複数の接続先を使い、異なるアドレスで別のコンテンツを提供することもあります。以前使えたアドレスを長期間固定すると、サービスの変更後に機能しなくなる場合があります。診断目的で一時的にHostを変更する場合は、元の状態を記録し、テスト後に戻して、診断用の設定に依存し続けないようにしてください。
Hostを使って、任意のサーバーを目的のウェブサイトに変えることはできません。HTTPS接続にはホスト名、証明書、サーバー側の処理が関係します。アドレスに接続できても、証明書やコンテンツが一致するとは限りません。マッピング変更後に証明書エラーが発生しても、アクセスを維持するために検証要件を下げないでください。ドメインとアドレスが本当に同じサービスに属するか確認します。複数のアドレスを使う接続先では、アドレスの固定によって利用可能性や接続先の選択が変わることにも注意してください。
URL Rewriteで条件に合うアドレスを書き換える
URL Rewriteの項目には通常、照合式、置換先、処理方法が含まれます。以下は、特定のホスト名を含むHTTPアドレスをHTTPSに転送する例で、302は一時的なリダイレクトを表します。正規表現のドットはエスケープしないと任意の文字を意味します。先頭のアンカーは、アドレスの先頭から照合するために使います。この例は基本構成を示すものです。有効にする前に、管理された接続先で一致範囲と実際の応答を確認し、すべてのドメインに適用しないでください。
[URL Rewrite]
^http://example\.com/ https://example.com/ 302書き換えルールを設定しても、接続先がHTTPSを提供していることや、転送後もログイン、パス、リクエストメソッドの意味が保たれることは保証されません。パスを維持する必要がある場合は、キャプチャグループと置換時の参照の関係を理解し、ウェブサイトのトップページだけでなく複数のアドレスを使って検証してください。書き換え後の接続先が別の逆向きルールに一致し、転送ループにならないようにします。ブラウザにリダイレクトが多すぎると表示された場合は、条件と接続先の範囲が重なっていないか、まず確認してください。
参照可能な情報と追加設定を分けて評価
暗号化されたリクエストでURL単位の処理が可能かどうかは、アプリから取得できるリクエスト情報と、関連機能の前提条件を満たしているかによります。ドメインの振り分けが機能しているからといって、すべてのURLパスを読み取れると考えないでください。また、ひとつの書き換え例を試すために、理解していない通信復号設定まで有効にしないでください。証明書と暗号化通信の処理には別の信頼境界が関わります。明確な必要性と影響を理解したうえで個別に設定してください。本ページでは通常のルール振り分けの前提条件にはしていません。
Host、URL Rewrite、Ruleを併用している場合、トラブル対処では一度にひとつの種類だけを無効にしてください。まず元のアドレス対応に戻して新しいリクエストを送り、接続先IPを確認します。次にURLが想定どおりに書き換わるかを確認し、最後に適用されたポリシーを調べてください。「誤ったアドレスへの接続」「誤った転送先へのリダイレクト」「誤った経路の選択」を切り分けられます。3種類の問題すべてをDOMAIN-SUFFIXの追加で解決しようとしないでください。ポリシーが正しくても、アドレスの誤りやリダイレクトループは解消できません。
8. 設定の検証、原因の特定、元に戻す方法
設定の検証では、テストページがたまたま開くことではなく、結果を再現でき、理由を説明でき、変更を元に戻せることを確認します。始める前に、使用中のネットワーク、Global Routing、設定ファイル、サーバーを記録し、問題を安定して再現できる接続先を選んでください。次に、設定が保存され、実際に使用中であることを確認してから新しい接続を行います。ここを確認しないと、その後の結果が古いファイル、既存のセッション、ページキャッシュによるものかもしれず、変更したルールの判断に使えません。
接続の流れに沿って問題を切り分ける
ひとつのアクセスを、ドメインの名前解決、条件判定、ポリシー選択、接続先への接続、コンテンツの応答という複数の確認箇所に分けられます。まずどの段階で失敗したかを特定してください。名前解決の結果がない場合はDNS、誤ったルールに一致した場合は順序、PROXYの接続に失敗した場合は既存のサーバー情報と到達性、接続先の応答に問題がある場合はウェブサイトのサービスを確認します。これはすべてのネットワーク処理が必ず同じ順序で行われるという説明ではなく、操作時に変数をひとつずつ切り分け、無関係な項目を同時に変更しないための手順です。
- Configの選択状態とGlobal Routingを確認し、ファイルとモードの食い違いを除外する。
- アドレスバーだけでなく、実際のリクエストのホスト名、接続先IP、アドレス種別を確認する。
- 適用されたルールとポリシーを確認し、ファイルの順番に沿って手動で見直す。
- 他の条件は変えず、フィールドをひとつだけ変更して、新しい接続を行う。
- 重要な機能を再テストし、復旧を確認したら変更理由と元に戻せるコピーを保存する。
ウェブページはメインページ、画像、API、認証など複数のリクエストを含むことがあります。トップページは表示されるのにログインできない場合、関連ドメインのひとつがREJECTで遮断された、または別の経路を通った可能性があります。アドレスバーのホスト名だけで、すべての通信を判断しないでください。実際に失敗したリクエストを特定し、その条件を確認します。ひとつのキーワードルールが複数のリソースに一致する場合、サイト全体とすべてのサブドメインを同じポリシーに変更するより、まずルールを絞って比較したほうが原因を見つけやすくなります。
症状に応じて次に確認する項目を選ぶ
| 症状 | 優先して確認する項目 | すぐに決めつけないこと |
|---|---|---|
| ルールを変更しても結果が変わらない | 現在のファイル、Global Routing、前にあるルール、既存の接続。 | そのルールタイプに対応していないと決めつけない。 |
| 遅延の数値は出るがページが開かない | DNS、実際に使われるドメイン、接続先への接続。 | テストの応答をウェブページ全体の利用可能性と同一視しない。 |
| 一部のリソースだけ表示されない | 関連ドメイン、REJECT条件、ポリシーの違い。 | メインページのドメインだけを確認しない。 |
| ネットワークを切り替えると結果が変わる | 名前解決の結果、アドレス種別、接続経路、ネットワーク権限。 | 設定ファイル全体をすぐに書き換えない。 |
| Hostの変更後に証明書エラーが発生する | ドメイン、接続先アドレス、実際のサービスが対応しているか。 | アドレスの確認を省略するために検証を弱めない。 |
Connectivity Testはサーバー応答の比較に役立ちますが、測定対象や方法は実際の通信と完全には同じではありません。数値が正常でも、すべての接続先、プロトコル、リソースが正常とは限りません。特定のテストに応答がなくても、サービスの状態を考慮せず、すべての接続が失敗したと判断しないでください。テスト結果を手がかりとして、実際の接続ログと照合します。既存サーバーの項目を確認する場合は、読み込み元に戻ってひとつずつ確認し、アドレスや認証情報の誤りをルール変更で隠さないでください。
最小構成で再現し、確認後に設定へ戻す
設定ファイル全体が長い場合は、調査専用のテストファイルにコピーし、現在の問題を理解するために必要なGeneral設定、明確な対象条件ひとつ、FINALだけを残します。基本経路を検証した後、元のルールをグループごとに追加し、問題が再発する箇所を特定します。追加のたびに元の相対順序を保ち、対象範囲を記録してください。数百行の中で推測を繰り返すのではなく、他のルールを遮る具体的な項目を見つけられます。検証後は正式なファイルに戻り、確認できた変更を統合し、テスト用ファイルを誤って継続使用していないことも確認します。
[Rule]
DOMAIN,api.example.com,DIRECT
FINAL,PROXYこの断片は、「指定した接続先とその他の接続を分けて検証する」方法を説明するためのもので、接続に必要な情報をすべて含むものではありません。再現手順には、想定するポリシー、実際のポリシー、該当ルールの位置を記載し、サブスクリプションURL、認証情報、個人を特定できる情報は隠してください。設定更新後に問題が再発した場合は、更新前後の関連部分を比較し、取得元の内容が変更を上書きしたのか、サーバー、DNS、接続先アドレスが変化したのかを確認します。すべての更新を同じ原因だと決めつけないでください。
元に戻した後は、問題のあった重要な接続先にアクセスできることを再確認してから調査を終えてください。症状、最初に一致した条件、最終的に行った変更、元に戻す方法を簡潔に記録します。一般的な疑問はよくある質問、初回接続の手順は使い方ガイド、購入・復元・App Storeでの確認は正規購入の確認方法をご覧ください。ルール保守の完了とは、次に同様の問題が起きたとき、記憶に頼って再び設定を試行錯誤するのではなく、同じ手順で検証できる状態にすることです。