Shadowrocket ルール設定ガイド
設定構成とマッチ順序
初回接続はどこから始めればよいですか？まずクイックスタートガイドに沿って、手元にあるサブスクリプションの読み込み、サーバーの選択、接続確認を行ってください。このページでは、その後の体系的な確認方法を説明します。設定の各セクションの連携、ルールが上から順に判定される理由、変更後に意図どおりか確認する方法を解説します。
このページは、利用者がすでにサブスクリプションまたはサーバー情報を持っていることを前提としています。クライアントの買い切り購入 ≠ 接続サービスのプラン。当サイトではノードやサブスクリプションを提供・販売・推奨していません。アプリの入手元を確認する場合は、まずApp Storeで正規アプリを確認する方法をご覧ください。Shadowrocketの入手先はApp Storeのみです。対応デバイスとシステム要件はApp Storeの製品ページをご確認ください。
01 設定ファイルの構成と適用範囲
設定ファイルとサブスクリプションは同じものですか？
いいえ。サブスクリプションは通常、サーバー接続情報をまとめて管理するものです。一方、設定ファイルは、使用するポリシーやドメインルール、名前解決や書き換えの動作など、リクエストの処理方法を指定します。既存のサブスクリプションを読み込んでサーバー一覧に項目が表示されても、ルール設定が有効になったとは限りません。確認時はHomeで選択できるサーバー、Configで現在使用中の設定、Global Routingの状態をそれぞれ確認してください。一つの項目で別の項目の確認を代用することはできません。
まずどこを見ればよいですか？角括弧で囲まれたセクション名を確認してから、その中の行を読みます。セクションごとに構文が異なります。Generalにはキーと値の設定、Ruleには行ごとの条件、Hostにはドメインとアドレスの対応、URL Rewriteにはマッチ式とアクションが記述されます。ドメインルールをGeneralに貼り付けないでください。テキストを保存できたからといって、意図した機能として解釈されるとは限りません。
[General]
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,DIRECT
[Host]
portal.example.com = 192.0.2.10この最小構成の例は何を示していますか？
GeneralではシステムのDNS設定を使用し、Ruleでは例示用のドメインサフィックスを判定してからアドレスの範囲を確認し、最後にデフォルトのポリシーを指定します。Hostのアドレスは文書用の例示アドレスで、マッピング形式を示すものです。サーバー接続情報は含まれておらず、利用可能な設定をすべて示したものでもありません。PROXYで実際に接続できるかは、選択中のサーバーとそのパラメーターによります。例をコピーする際は、個々の英語キーワードだけでなく、どのセクションに記述するかも含めて確認してください。
元に戻せる編集手順を作るにはどうすればよいですか？Configで現在使用中の設定を見つけ、原本を残してから、区別しやすいコピーを作成します。変更前のGlobal Routing、現在のサーバー、検証するドメインを記録してください。DNS、サーバー、デフォルトポリシーを同時に変更するのではなく、DOMAINルールを1つ追加するなど、毎回一つの要素だけを変更します。保存後はコピーが使用中であることを改めて確認してください。ファイルAを編集してファイルBでテストする、といった取り違えを防げます。
Generalの設定はすべてそのままコピーする必要がありますか？
必要ありません。Generalは基本動作に関する設定なので、具体的な問題に応じて項目ごとに確認してください。現在の設定にはDNS、接続処理、ネットワーク関連のオプションが含まれている場合があります。全体を置き換えると、正常に動作していた部分まで変わる可能性があります。意味がわからないキーは、アプリ内の編集画面で名前と使用可能な値を確認してください。意味を確認できない場合は、元の値を維持します。このガイドでは明確に説明できる例のみを掲載しており、汎用設定を求めてパラメーターを追加することは推奨しません。
リモート設定を更新すると、ローカルでの変更はどうなりますか？現在のファイルがリモートから取得したものであれば、更新後に編集内容が保持されるかは、アプリ内で実際に確認してください。すべての変更が自動で統合されるとは限りません。元の設定とローカルのテスト用コピーを残し、更新後に変更したルールの箇所を比較するのが安全です。動作が変わった場合は、サーバーの不具合とすぐに判断せず、使用中のファイル、ルールの順序、基本設定を先に確認してください。
メモには何を記録するとよいですか？ルールの目的、テスト対象、元に戻す方法を記録できます。ただし、公開する予定の例に自分のサブスクリプションURL、パスワード、その他の接続情報を書かないでください。トラブル対処の情報を共有する際は、セクション名、キーワード、順序を残し、機密情報は削除してください。スクリーンショットやテキストにクエリパラメーターが残っていないかも確認します。設定ファイルは、単なる保存用のテキストではなく、ネットワークの動作を指定するものです。
02 ドメインルールのマッチ範囲
DOMAINとDOMAIN-SUFFIXはどう使い分けますか？
特定の完全一致ドメインだけを対象にする場合はDOMAIN、ルートドメインとそのサブドメインを対象にする場合はDOMAIN-SUFFIXを使います。たとえばDOMAIN,api.example.com,PROXYは、この完全一致ドメインだけが対象で、別のホスト名まで自動的に含みません。DOMAIN-SUFFIX,example.com,PROXYはexample.comとそのサブドメインが対象です。違いは対象範囲であり、接続速度の差でも、どちらかが常に優先されるという意味でもありません。
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,DIRECT上の2行はなぜ矛盾しないのですか？1行目はapi.example.comに先にマッチし、例外としてPROXYを指定します。2行目は同じドメイン範囲のその他のリクエストを処理します。行を入れ替えると、範囲の広いサフィックスルールが先にマッチし、個別の例外が機能しない場合があります。ルールは例外を先に、共通の範囲を後に記述してください。範囲と順序を正しく把握すれば、同じルートドメイン配下のリクエストに異なるポリシーが適用される理由を説明できます。
| キーワード | マッチ対象 | 主な範囲 |
|---|---|---|
DOMAIN | 完全一致ドメイン | 他のサブドメインは自動的に含まれない |
DOMAIN-SUFFIX | ドメインサフィックス | ルートドメインとそのサブドメインを対象とする |
DOMAIN-KEYWORD | ドメイン内のキーワード | 複数の異なるドメインにまたがる場合がある |
DOMAIN-KEYWORDを慎重に使うべき理由は？
指定したキーワードがドメインに含まれるかどうかで判定し、Webサイトの運営元を判定するものではないためです。短い語句が互いに無関係な複数のドメインに含まれる場合があります。ブランド名や一般的な語句を指定すると、想定より広い範囲にマッチする可能性があります。example.comだけを対象にしたい場合は、通常、完全一致のドメインルールかサフィックスルールを使いましょう。ドメインから一般的な単語だけを抜き出して指定するのは避けてください。ルールにマッチしても、対象範囲が目的に合っているとは限りません。
[Rule]
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECTこの例はキーワードによる振り分けを推奨していますか？いいえ、構文を示すための例です。実際に使う前に、対象にしたいドメインと対象にしたくないドメインをそれぞれいくつか挙げ、キーワードが後者にも誤ってマッチしないか確認してください。範囲を明確に限定できない場合は、DOMAINまたはDOMAIN-SUFFIXに戻しましょう。ルールのメンテナンスでは、特に長期間使う設定や複数人が読む設定において、行数を減らすことより「なぜマッチするのか」を正確に説明できることが重要です。
ドメインルールに完全なURLを記述する必要はありますか？
必要ありません。ドメイン条件にはhttps://、ポート、パス、クエリパラメーターを含めません。api.example.comはドメインですが、https://api.example.com/accountは完全なURLです。後者をDOMAINのパラメーターとして直接指定することはできません。ページのパスでリクエストを区別したい場合は別の問題です。ドメインルールの末尾にスラッシュを追加しても解決しません。まず入力をドメイン、ポート、パスに分け、使用中のルールでその項目を判定できるか確認してください。
同じWebページ内で異なるポリシーが適用されるのはなぜですか？ページはメインサイト、画像、API、その他のリソースに同時にアクセスする場合があります。アドレスバーに表示されるドメインにルールを設定しても、すべてのリソースが自動的に対象になるわけではありません。検証時はページ名から推測せず、実際のリクエスト先を確認してください。一部のコンテンツだけ読み込めない場合は、失敗したリソースのドメインを特定してから、必要な範囲のルールを追加します。一つのリソースのために、曖昧なキーワードの対象範囲を広げないでください。
ドメインルールが期待どおりにマッチしないことがあるのはなぜですか？リクエストがIPアドレスを直接使用している、またはクライアントが取得できる宛先情報が想定と異なる場合があります。まず記録に対象ドメインが実際に存在するか確認し、次に条件の記述ミスを調べます。大文字・小文字、余分な空白、コピー時に混入した全角記号も確認してください。ルールの基礎はルールキーワード入門をご覧ください。実際のトラブル対処では、アプリ内で確認できる宛先を基準にしてください。
03 IP、GEOIP、USER-AGENT
IP-CIDRのスラッシュの後の数字は何を表しますか？
ネットワークプレフィックス長を表し、アドレス範囲を指定します。ポート番号でも、ルールの優先度でもありません。IPv4では/32が単一アドレスを表し、/24は一般に256個のアドレスを含むネットワークブロックを表します。範囲が広いほど、対象となる宛先が増える可能性があります。設定前に、1台のホストを対象にするのか、ネットワーク全体を対象にするのか確認してください。アドレスが似ているからといって、安易にプレフィックスを短くしないでください。範囲を誤ると、関係のないリクエストまで同じポリシーに送られる場合があります。
[Rule]
IP-CIDR,192.0.2.25/32,DIRECT
IP-CIDR,198.51.100.0/24,PROXY
IP-CIDR6,2001:db8::/32,DIRECT
FINAL,DIRECTこれらのアドレスを接続テストに使えますか？いいえ。文書用の例示アドレスです。1行目は単一アドレスのルール、2行目はIPv4ネットワークの範囲、3行目はIPv6プレフィックスを示しています。IP-CIDR6とIP-CIDRは異なるアドレスファミリーを扱うため、IPv4ルールを書いても同じサービスのIPv6アドレスが自動的に対象になるわけではありません。デバイスが両方のアドレスを取得する場合は、テストで実際に使われている宛先を確認し、アドレスファミリーの違いをルールの不規則な動作と誤認しないようにしてください。
no-resolveを検討するのはどんな場合ですか？
IPルールでは、ドメインのアドレスを取得して範囲を判定する場合があります。no-resolveは、そのルールのために追加のドメイン解決を行わない意図を示します。アプリ全体のDNSを停止するという意味でも、リクエストにアドレス情報が決して現れないという保証でもありません。リクエスト自体がIPを使う場合や、利用可能なアドレスがすでにある場合は、実際の条件に基づいてマッチを判断してください。使う前に、既知のアドレスだけを対象にするのか、ドメイン解決後のアドレスも範囲に含めるのかを明確にしましょう。
[Rule]
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYすべてのアドレスルールに同じオプションを付けないのはなぜですか？このオプションは、ドメインのリクエストがそのルールに到達したときの処理条件を変えるためです。名前解決の結果で対象を判定したい場合、追加の解決を制限すると、後続のFINALが使われる頻度が高くなる可能性があります。すでにあるIPだけを対象とする例外には適している場合もあります。一つの対象で変更前後の記録を比較してください。「オプションが多いほど完全」という考え方で設定を組み立てないでください。利用できる構文も、使用中のアプリで確認してください。
GEOIPはWebサイトの所在地を示すものですか？
いいえ。GEOIPは宛先IPの地理情報データに基づいて判定します。Webサイトの言語、登録情報、ページ内容から結果を推測することはできません。CDNを使うドメインは異なるアドレスに解決される場合があり、ネットワークを切り替えると判定結果が変わる可能性もあります。GEOIP,CN,DIRECTは、該当する地域情報のアドレスにマッチしたリクエストにDIRECTを適用するという意味です。「中国語のWebサイトはすべて直接接続する」という意味でも、「特定のドメインが今後ずっと同じポリシーになる」という意味でもありません。
ドメインルールをGEOIPより前に置くのはどんな場合ですか？名前解決でアドレスが変わっても特定のドメインに同じポリシーを適用したい場合は、明示的なドメイン例外を前のほうに置きます。GEOIPは広いアドレス分類に適していますが、細かいルールすべての代わりにはなりません。同じサービスの動作がネットワークによって異なる場合は、地理的な範囲を何度も変更する前に、解決されたアドレスとマッチしたルールを比較し、必要に応じてドメイン例外を追加してください。
USER-AGENTでアプリごとに確実に振り分けられますか？
汎用的なアプリ識別方法として扱うことはできません。USER-AGENTはリクエストから確認できる該当フィールドにマッチするもので、システム上のアプリ名にマッチするものではありません。暗号化された接続でフィールドを確認できるか、リクエストにそのフィールドが含まれているかによって、ルールが機能するかが変わります。複数のアプリが同じ文字列を使う場合もあれば、同じアプリが異なる文字列を使う場合もあります。マッチ式を検討する前に、実際のフィールドを確認してください。
[Rule]
USER-AGENT,ExampleClient*,DIRECT
FINAL,PROXYこの例は、USER-AGENTの記述位置とワイルドカードの使い方を示すだけで、ExampleClientという実在のリクエストがあることを示すものではありません。記録でフィールドを確認できない場合は、確認済みのドメイン条件やアドレス条件を優先してください。このルールをマッチさせるためだけに、暗号化トラフィックの処理範囲を広げないでください。ルール条件を確認できないことと、サーバーを利用できないことは別の問題です。それぞれ個別に検証してください。
04 Global Routingと接続ポリシー
Config、Proxy、Directとルール内のポリシーは同じですか？
完全には同じではありません。Global Routingは全体のルーティングモードを選ぶ入口です。ルール末尾のPROXY、DIRECT、REJECTは、マッチしたリクエストに適用するポリシーです。画面上の表示はConfig、Proxy、Directのまま、ルールキーワードは構文どおり大文字で記述します。トラブル対処を始める前に全体モードを確認してください。Ruleの条件や順序が正しくても、現在のモードで設定ルールが適用されていなければ、期待する結果を確認できない場合があります。
| 画面のモード | 説明 | 確認のポイント |
|---|---|---|
| Config | 設定 | 現在の設定ファイルのルールに従ってポリシーを選択 |
| Proxy | プロキシ | プロキシ経由の接続との比較に使用。ルールの検証には代用できない |
| Direct | 直接接続 | 直接接続の経路との比較に使用 |
上の表は、どのような状況でもすべてのトラフィックが完全に同じように処理される、という意味ですか？いいえ。ネットワークの接続状況、システムの動作、設定内の関連オプションも実際のリクエストに影響する場合があります。ここでは、ルーティングを確認するための入口を区別しています。特定のRuleを検証する場合はConfigに戻ってください。2つの接続経路を一時的に比較するにはProxyまたはDirectを使えますが、テスト後は元のモードに戻し、切り替えた手順を記録してください。
PROXYは特定のサーバーを指すものですか？
そのように考えるべきではありません。PROXYはプロキシ経由の処理を指定します。最終的にどのサーバーを使うかは、現在の選択と設定を確認する必要があります。ルールがPROXYにマッチしたことからわかるのは、そのポリシーが選択されたことだけです。サーバーアドレス、ポート、認証、トランスポートの各パラメーターが正しいとは限りません。手元にあるサーバー情報を使う場合は、元の情報と一つずつ照合してください。認証エラーを直すためにDOMAIN-SUFFIXを何度も変更しないでください。これらは異なる階層の設定です。
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,portal.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
FINAL,DIRECTDIRECTはShadowrocketを終了するという意味ですか？いいえ。DIRECTはマッチしたリクエストを直接接続するポリシーです。アプリの接続スイッチがオフになることを意味せず、ほかのリクエストも同じ経路を使うという意味でもありません。Configモードでは、一部のリクエストをDIRECT、別のリクエストをPROXYで処理できます。個々のリクエストを判断する際は、そのリクエストのマッチ結果を確認してください。ステータスバーや接続スイッチだけでは、特定の宛先への接続経路は判断できません。
REJECTは接続タイムアウトの解決に適していますか？
適していません。REJECTはマッチしたリクエストを明示的に拒否するポリシーで、通常は接続を開始したくない場合に使います。予備サーバーでも、タイムアウト後に自動復旧する仕組みでもありません。ドメインにREJECTを設定すると、関連するページのリソースやアプリの機能に影響する場合があります。テストでは、メインページ、API、関連リソースのどれを拒否するか把握してください。ページの一部が表示されない場合、異常ではなく拒否ルールの結果である可能性もあります。
最小限のポリシーテストはどう行いますか？まず識別しやすいテスト対象を選び、ルールの前方に完全一致のDOMAINを1つ追加します。最初はDIRECTを指定して確認し、次にPROXYに変更して比較します。サーバー、DNS、ネットワークは変えず、ポリシーだけを比較してください。両方とも失敗する場合は、ドメイン解決、宛先への到達性、サーバーパラメーターを調べます。片方の経路で成功する場合は、失敗した経路をさらに確認してください。設定ファイル全体をすぐに書き換える必要はありません。
クライアントを購入してもPROXYが使えるとは限らないのはなぜですか？App Storeの買い切り購入はクライアントの利用に対するもので、利用者のサーバー接続情報が自動入力されるわけではありません。アプリの入手元、サーバーの状態、ルールによる選択をそれぞれ確認してください。購入や復元についてはよくある質問、プロトコルのパラメーターについてはプロトコルの項目説明をご覧ください。この章ではポリシーとモードを説明し、接続サービスの情報は提供しません。
05 マッチ順序、例外、FINAL
ルールは種類ごとに自動で並べ替えられますか？
いいえ。Ruleは上から順に判定し、最初にマッチしたルールのポリシーを適用すると理解してください。DOMAINは、より正確だからといってDOMAIN-SUFFIXより自動的に前へ移動するわけではありません。後ろに書いたルールが、前のルールを自動的に上書きすることもありません。設定を編集するときは、最適な結果を自動計算するラベルの集まりではなく、順序に沿って判定する処理として考えます。マッチ結果を説明する際は、ファイルを上から確認して最初に条件を満たすルールを探してください。
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYこの設定例を上から読むにはどうすればよいですか？まず対象がapi.example.comか確認します。一致すればPROXYを使い、後続のサフィックスルールでは結果を変更しません。一致しなければ、example.comのドメイン範囲に属するかを確認し、次にアドレス例外とGEOIPを検討します。それまでにマッチしなかった場合に、FINALが処理します。この読み方はメンテナンス方法にもつながります。個別の例外を先に、範囲による分類を後に、最後にデフォルトを置きます。各ルールについて、なぜその位置にあるのか説明できるようにしてください。
FINALの指定を慎重に決める必要があるのはなぜですか？
FINALは、それより前のルールにマッチしなかった場合に適用する最終ポリシーです。コメントでも、エラー時だけ使う予備設定でもありません。設定で対象を十分に網羅していない場合、多くのリクエストがFINALに到達する可能性があります。FINAL,DIRECTとFINAL,PROXYは異なるデフォルトの選択を表し、あらゆる状況に適用できる正解はありません。設定前に、ルールで主にどの種類の宛先を指定するのか、未指定のリクエストにどの経路を使うのかを決めてください。見慣れた末尾をそのままコピーするのではなく、用途に応じて判断しましょう。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTこの最小限の設定例はどのような考え方ですか？列挙した例示ドメインだけをプロキシ経由にし、それ以外はDIRECTにします。「明示的に許可した宛先だけを直接接続する」意図に変える場合は、前のルールを再構成し、適切なデフォルトを選ぶ必要があります。FINALだけを変更しても、すべての動作が意図どおりになるとは限りません。デフォルトの変更は、まだ列挙されていないすべての宛先に影響するため、テスト範囲も広げてください。少なくとも例外を1つと、ルールに記載していない宛先を1つ確認します。
ルールを重複させるとマッチの信頼性が上がりますか？
上がりません。同じ条件のルールがすでにある場合、後ろの重複行を追加しても通常は問題を解決できません。ポリシーが異なると、後ろの設定が有効になると誤解されるおそれもあります。削除する前に、DOMAINとDOMAIN-SUFFIXのように条件が異なるものを重複と誤認していないか確認してください。「完全一致の例外」「ドメイン範囲」「アドレス範囲」「最終ポリシー」のように目的別に整理できますが、見た目を整えるためだけに検証済みの優先関係を変えないでください。
ルールを追加した後、先行ルールによる遮断をどう確認しますか？対象ドメインを使って1行目から順に判定し、新しいルールより前に範囲の広い条件がマッチしないか確認します。該当するルールがある場合は、新しいルールを前に移動するか、既存ルールの範囲を狭めるか判断してください。新しいルールをすべてファイル末尾に追加しないでください。特にFINALより後ろに記述しても、通常のFINAL判定前に適用されるとは期待できません。範囲が重なるルールは、どれが例外なのか、なぜ優先するのかを変更メモに記録しましょう。
ルールの順序を変えても、既存の接続にすぐ反映されないのはなぜですか？
ルールの判定は接続の確立に関係します。すでに確立した長時間接続や再利用中の接続では、以前の処理結果が維持される場合があります。設定を保存した後、新しいリクエストでテストしてください。必要に応じて、重要な処理に影響しないことを確認してから再接続します。接続を再利用中のページを更新しただけで、保存に失敗したと判断しないでください。比較する際はリクエスト、ネットワーク、サーバーを変えず、「古い接続が維持されている」のか「新しい接続も誤ったルールにマッチしている」のかを区別します。
変更による意図しない影響がないことをどう確認しますか？例外の対象だけでなく、同じサフィックスの別のサブドメイン、無関係なドメイン、アドレスを宛先とするリクエストもテストしてください。最も気になるリクエストだけを確認すると、範囲の広いルールによる変化を見逃しやすくなります。メンテナンス記録には、機密情報を含む設定全体ではなく、変更前後の該当部分を残してください。次に差が生じた際、範囲の変化、順序の変化、環境の変化を直接見分けられます。
06 DNS、Host、アドレス判定の境界
ドメインが名前解決できることと、ルールにマッチすることは同じですか？
いいえ。DNSはドメインからアドレスを取得する仕組みで、ルールはリクエストに適用するポリシーを決めます。相互に影響することはありますが、代わりにはなりません。DOMAINの記述が正しくても宛先を名前解決できるとは限らず、名前解決が成功してもPROXYの接続パラメーターが正しいとは限りません。トラブル対処では、リクエストで使われたドメイン、取得したアドレス、マッチしたルール、接続に使った経路に分け、どの段階で失敗したか確認してください。
GeneralのDNS設定はどのように変更すればよいですか？まず現在の値を残して現象を記録し、変更を一つずつテストしてください。以下のsystemはシステムのDNS設定を使うことを表す構文例であり、あらゆるネットワークへの固定的な推奨ではありません。特定のネットワークで専用の名前解決条件が必要な場合は、そのネットワークとアプリ内の設定に従ってください。複数のDNS関連設定を同時に変更すると、結果が改善しても何が有効だったのか特定しにくくなります。
[General]
dns-server = system
[Host]
portal.example.com = 192.0.2.10
[Rule]
DOMAIN,portal.example.com,DIRECT
FINAL,PROXYHostを使うと、ドメインルールがアドレスルールになりますか？
そのように考えるべきではありません。Hostは指定したドメインにマッピング結果を提供し、Ruleはルーティング条件を記述します。上の例では、アドレスのマッピングとDIRECTポリシーはそれぞれ別に指定しています。Hostを書けば自動的にDIRECTになるわけではありません。テストでは、リクエストで認識されたドメイン、アドレス、最終的なマッチ結果を確認してください。宛先がIPを直接使う場合、ドメインを指定したHostの項目はすべてのリクエストにマッチするワイルドカードの入口にはなりません。
まずHostを検討するのはどのような場合ですか？たとえば、内部ドメインの正しいアドレスがわかっていて、管理されたテストで名前解決結果の違いを確認したい場合です。使用する前に、マッピング先のアドレスが対象サービスのものか確認し、元に戻す方法も把握してください。例示アドレスを実際のWebサイトの代わりに使うことはできません。一般向けのドメインに任意の見知らぬIPを指定すると、サービスが一致しない、証明書エラーになる、接続に失敗するといった問題が起こる場合があります。Hostは、どんなアドレスでも目的のサービスに変える機能ではありません。
マッピング後も証明書エラーが発生するのはなぜですか？
HTTPSでは、IPアドレスに接続できるだけでなく、対象ドメインに対してサーバーが正しい証明書とサービスを提供する必要があります。Hostで名前解決先を変更しても、サーバーが提供する内容は自動的に変わらず、ドメインの検証もなくなりません。証明書に関するエラーが出た場合は、まずマッピングを元に戻して比較し、アドレスの記述ミスや接続先のサービスが合っているか確認してください。検証要件を緩和することを、一般的な名前解決の修正手順にしないでください。
DNSとGEOIPが連動するのはなぜですか？GEOIPはアドレスを基準に判定しますが、ドメインの解決結果はネットワーク、DNSサービス、サーバー側の振り分けによって変わることがあります。同じドメインから異なるIPアドレスが取得されると、異なるアドレス範囲に分類される場合があります。GEOIPがドメインルールを自動的に書き換えているという意味ではありません。特定のドメインに常に同じポリシーを適用する必要がある場合は、アドレスを無理に固定して動的なサービスを恒久的に制御しようとするのではなく、前方に明示的なドメイン例外を置く方法を検討してください。
キャッシュとIPv6を検証にどう含めればよいですか？
キャッシュの影響で、変更後の最初の結果が想定と異なる場合があります。古い接続が以前のアドレスを使い続けることもあります。テスト前に現在の名前解決結果を記録し、新しい接続を開始したうえで、キャッシュはアプリ内で利用できる操作に従って処理してください。対象アドレスを確認せずにスイッチを何度も切り替えても、リクエストが使う名前解決情報が変わったとは限りません。比較できる結果を得るため、できるだけ同じネットワークで、同じ時間帯に2回のテストを行ってください。
IPv6のアドレスファミリーは個別に確認する必要があります。IPv4用のIP-CIDRだけでは、IPv6リクエストも同じ範囲で制御されるとは限りません。同様に、Hostで一つのマッピングを設定しても、すべてのアドレス取得方法が想定どおりになるとは限りません。まずリクエストがIPv6を使用しているか確認し、そのうえでIP-CIDR6とドメインルールのどちらが目的に合うか検討してください。アドレスファミリーを確認する前に、ネットワーク全体の機能を切り替えることを最初の修正方法にしないでください。
07 URL Rewriteの用途と制限
URL RewriteとRuleはそれぞれ何を変更しますか？
Ruleは主に、接続に使用するポリシーを決めます。URL Rewriteは、マッチしたURLに対して指定された書き換え動作を実行します。リクエストを別のURLにリダイレクトしても、PROXYを使うよう指定したことにはなりません。ドメインにDIRECTを指定しても、ページのパスが変更されるわけではありません。パス単位で処理する必要がある場合は、完全なURLをDOMAINに入力するのではなく、本当に書き換えが必要か確認してください。2つのセクションは併用できますが、効果は個別に検証してください。
[URL Rewrite]
^http://example\.com/ https://example.com/ 302この設定例は何を示していますか？先頭はマッチ式、中央は転送先、末尾はリダイレクトのステータスコードです。http://example.com/で始まる、確認可能なリクエストを指定したHTTPSアドレスへリダイレクトする例です。ドメインのピリオドの前にバックスラッシュを置くことで、式中のピリオドを文字どおりのピリオドとして扱います。先頭の^はURLの先頭から判定することを示します。これは構成の説明用であり、任意のWebサイトにそのまま使える汎用ルールではありません。
マッチ式の範囲を制御する必要があるのはなぜですか？
正規表現のピリオド、アスタリスク、括弧などの記号にはそれぞれ意味があり、画面上に見える文字そのものを表すとは限りません。エスケープされていないピリオドは任意の文字にマッチする場合があり、開始位置の境界がないと意図しない箇所でマッチする可能性があります。記述する前に、マッチさせたい例とマッチさせたくない例を挙げ、一つずつ確認してください。ドメイン名が似ていても、式がそのドメインだけに適用されるとは限りません。範囲が広いほど、ログイン、API、リソースの読み込みへの影響を追跡しにくくなります。
転送先も慎重に確認する必要があるのはなぜですか？リダイレクト先のURLによって、その後のリクエストのアクセス先が変わります。転送先のドメイン、パス、クエリパラメーターはページの動作に影響する場合があります。特定のパスをすべてトップページに転送すると、元のページやパラメーターの情報が維持されないことがあります。キャプチャした内容を引き継ぐ必要がある場合に限り、アプリがサポートする置換構文を使い、影響範囲を限定したコピーで検証してください。理解できない式を、長期間使う設定にそのまま貼り付けないでください。
HTTPSのパスは通常のルールから直接読み取れますか？
読み取れるとは限りません。HTTPSではリクエストの内容が暗号化されるため、通常のドメインルーティング情報から完全なURLパスまで見えるとは限りません。パスを対象にした書き換えが機能しない場合は、ドメインのマッチ範囲を広げ続けるのではなく、まずリクエストの内容を確認できる条件を満たしているか判断してください。リクエストごとの処理条件はアプリ内で確認してください。このページでは、復号関連の設定を通常の振り分けに必要な手順とは扱わず、一度の書き換えのためにシステムの信頼設定を安易に変更することも推奨しません。
特定のドメインをプロキシ経由にするだけなら、どうすればよいですか？Ruleに戻り、DOMAINまたはDOMAIN-SUFFIXを明示的に指定すれば十分です。URL Rewriteを追加する必要はありません。リクエストURLを変更する必要があり、リクエスト内容を確認できることと転送後の動作を検証できる場合に限って、該当するセクションを検討してください。リクエスト内容に近い機能ほど、影響範囲を慎重に管理する必要があります。単純なルーティングの指定には、まず単純なルールを使いましょう。
リダイレクトループやパスの変化はどう調べますか？
まず追加した書き換え行を一時的に削除し、設定のコピーで元のリクエストが復旧するか確認してください。転送先が同じ式に再びマッチすると、リダイレクトが繰り返される場合があります。式自体がループしていなくても、サーバー側のルールによって元のアドレスに戻されることがあります。最後に表示されたページだけを見るのではなく、開始URL、転送先、失敗した段階を記録してください。原因の範囲を絞れるよう、候補の書き換えルールは一度に1つだけ有効にします。
HTTPをHTTPSに変更しても、常に成功するとは限らないのはなぜですか？転送先のサービスが該当するドメインとパスでHTTPSに対応し、証明書とサービスの設定も正しくなければなりません。書き換えによって、サービスに自動でプロトコル対応が追加されるわけではありません。転送後に接続できない場合は、まず転送先アドレス自体をテストし、その後に式の誤りを確認してください。URLの変更と接続ポリシーは別々に検証するため、ここでの失敗をFINALやGEOIPの変更で覆い隠さないでください。
08 設定の検証、トラブル対処、長期メンテナンス
変更が実際に反映されたことをどう確認しますか？
まずテスト条件を確認し、その後に結果を観察します。現在のネットワーク、サーバー、Global Routing、使用中の設定を記録し、完全なドメイン名を一つ選んで新しいリクエストを開始してください。次に、アプリ内で確認できる接続情報やログで、宛先ドメイン、宛先アドレス、マッチしたルール、適用されたポリシーを確認します。具体的な項目はアプリ内の表示に従ってください。ページが開くことは結果の一つにすぎません。それだけではどのポリシーが使われたか、設定全体が正しいかは証明できません。
テスト対象はどう選べばよいですか？少なくとも3種類を含めてください。変更した完全一致の対象、その対象に近い範囲で動作が変わらないはずの対象、FINALで処理される対象です。テスト後は、予想と実際の結果を一つずつ記録してください。一つだけを確認すると、範囲の広いルールによる誤マッチを見逃しやすくなります。アドレスルールではリクエストがIPv4とIPv6のどちらを使っているか確認します。書き換えルールでは開始URLと転送後のアドレスを記録してください。
| 現象 | 優先して確認する項目 | 次に行う比較 |
|---|---|---|
| 新しいルールにマッチしない | 使用中の設定、モード、前方のルール | 完全一致の対象と新しい接続 |
| PROXYにマッチしても接続できない | サーバーの状態と接続パラメーター | 同じ宛先への直接接続 |
| 一部のリソースだけ失敗する | 実際のリソースのドメインと拒否ルール | メインサイトと失敗したリソースを別々にテスト |
| ネットワークを切り替えると結果が変わる | 解決されたアドレス、アドレスファミリー、ネットワーク条件 | 同じ宛先で2回の結果を記録 |
Connectivity Testで何がわかりますか？
アプリ内のテスト条件における接続性の参考情報が得られますが、すべてのWebサイト、プロトコル、トランスポート条件が正常だと証明するものではありません。特定のサーバーでテストが成功しても、特定のドメインに接続できない場合は、そのリクエストの名前解決、ルール、実際の接続過程を確認してください。テストに失敗した場合も、まずテスト条件とサーバー情報を確認します。一度のテスト結果を固定的な性能評価として記録したり、数値一つで対象リクエストの確認を代用したりしないでください。
トラブル対処の手順をどう絞り込めばよいですか？最後に正常動作を確認した設定のコピーに戻し、問題が直近の変更後に発生したか確認してください。元に戻して復旧した場合は、変更を一つずつ再適用します。元に戻しても解決しない場合は、現在のネットワークと手元にあるサーバー情報を調べてください。これにより、設定変更と環境の変化を先に切り分けられます。サーバーの変更、DNSの変更、FINALの変更を同時に行って再試行すると、アクセスが復旧しても、どの変更が有効だったか判断できなくなります。
スイッチを繰り返し切り替えるのではなく、エラーをどう読み取ればよいですか？
まず名前解決、接続の確立、対象サービスの応答の各段階に分けてください。アドレスを取得できない場合は、ドメインとDNSを優先して確認します。アドレスがあるのに接続できない場合は、接続経路とサーバーパラメーターを調べます。接続確立後にサーバーエラーが発生する場合は、対象サービス自体も含めて判断してください。エラーメッセージによっては、前後の情報がないと判断できません。特定の語句だけで結論を出さないでください。エラーが発生したときの宛先とモードを記録するほうが、何度も再接続して「ときどき使える」とだけ記憶するより役立ちます。
問い合わせるときはどのような情報を伝えるとよいですか？iPhoneかiPadか、現在のモード、該当するルールの前後関係、失敗する宛先、実施済みの比較テストを説明してください。サブスクリプションURL、パスワード、UUID、その他の認証情報は公開しないでください。スクリーンショット内のクエリパラメーターも削除します。ドメイン名は例示名に置き換えてもかまいませんが、完全一致かサフィックスかという関係とルールの順序は維持してください。これらを変えると、問題の構造を分析できなくなります。
ルールが増え続けないように、どうメンテナンスすればよいですか？
ルールを追加するたびに目的と検証範囲を明記し、前方のルールに完全に覆われている重複項目を定期的に整理してください。一時的なトラブル対処用ルールは、検証後に残すか取り消すか決め、短期間のテストがいつの間にかデフォルト動作にならないようにします。リモート設定や既存のサブスクリプションを更新した後は、ルールファイルとサーバー一覧を別々に確認してください。更新時期や変更範囲が同じとは限りません。アプリのアップデートはApp Storeから行ってください。要件はApp Storeの製品ページをご確認ください。
他のマニュアルページに戻るのはどんな場合ですか？初回の読み込みと接続手順はクイックスタートガイド、画面上の用語は用語集、購入、復元、よくある現象はよくある質問をご覧ください。このページでは一貫して「設定ファイルの構成を確認し、マッチ範囲を絞り、優先順を確認し、実際のリクエストを検証する」ことを扱います。観察可能な問題を一度に一つずつ解決すれば、設定の動作を説明し、必要に応じて元に戻せる状態を保てます。