公式マニュアル · 設定リファレンス

Shadowrocket
ルール・設定ガイド

設定項目ごとに構文を確認し、接続ログでルールの適用結果を調べます。

このページはShadowrocket公式マニュアルの設定リファレンスです。自分のサブスクリプションまたはサーバー情報をすでにお持ちで、通信の振り分け動作を確認したい方向けに、設定構成、ルールの順序、ポリシーの適用範囲を解説します。初回の読み込みやサーバー選択、接続の確立については、まずクイックスタートガイドをご覧ください。基本的な接続を確認した後、このページで設定やルールの判断根拠を確認できます。

ShadowrocketはAppleプラットフォーム向けのクローズドソースの商用アプリで、主にiPhoneとiPadで利用できます。入手先はApp Storeのみです。システム要件と購入対象となるデバイスは、App Storeの掲載内容をご確認ください。アプリの買い切り購入と通信サービスの契約は別です。接続情報はご自身でご用意ください。本サイトはノードやサブスクリプションを提供・販売・推奨していません。正規品の確認と購入方法はApp Store正規版の購入案内をご覧ください。

設定形式 .conf
編集前にバックアップ
サンプルのドメインは構文説明用です

設定ファイルの構成と編集時の注意点

設定ファイルは通信の処理方法を定めるもので、サーバーアカウントそのものではありません。この違いを理解しておくと、「読み込み後にサーバーが表示された」ことと「振り分け設定が選択された」ことを混同せずに済みます。サーバー情報は接続先や使用するプロトコル、認証方法を定めます。一方、設定ファイルはどのリクエストを直接接続し、どれをプロキシ経由にし、どれを拒否するかを定めます。両方が必要ですが、片方を読み込んでも、もう片方の準備が整ったとは限りません。既存のサブスクリプションを使う場合は、まずHomeでサーバー情報を確認し、次にConfigで実際に有効な設定を確認してください。

セクション名、フィールド、ルール行

Shadowrocketの設定ファイルは、角括弧で囲んだセクション名で用途を分けます。[General]には共通設定を記述し、通常はフィールド名、等号、値の順に書きます。[Rule]には順序のある振り分けルールを、[Host]には指定したホスト名のアドレス対応を記述します。[URL Rewrite]は条件に合うURLを書き換えるセクションです。セクション名は単なる見出しではなく、記述場所によって解析結果が変わります。Generalの等号形式をRuleに使ったり、説明用の日本語をルールのパラメーターに付け加えたりしないでください。

[General]
bypass-system = true

[Rule]
DOMAIN,router.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY

[Host]
router.example.com = 192.168.1.1

この例は各セクションの関係を示すもので、あらゆるネットワークで使える完成済み設定ではありません。1行目は指定したホストへの直接接続、2行目はサンプルのドメインとサブドメインへの適用、3行目はプライベートアドレス範囲への適用、最後の行はフォールバックを示しています。Hostの対応付けはサンプルのホスト名をアドレスに結び付けるだけで、そのアドレス上にサービスが存在することを保証しません。保存時は、用途を理解している既存の必須フィールドを残してください。リモート配信の設定を使っている場合は、次回の更新でローカルの変更が上書きされないかも確認しましょう。

コピーを保存し、有効な設定を確認する

編集前にConfigで現在選択されている設定を確認し、名前と復元場所を記録してから別のコピーを保存してください。ファイルを開いて編集しただけでは、そのファイルが通信処理に使われているとは限りません。保存後は設定一覧に戻り、対象が選択されていることを確認してから、新しい接続で検証します。編集画面に構文エラーが表示された場合は、修正してから有効にしてください。解析エラーを残したまま設定を追加すると、後で原因を特定しにくくなります。

設定ファイルとサーバー情報のバックアップは別々に考えてください。ルール設定を復元しても、サーバーの認証情報まで復元されるとは限りません。サブスクリプションを再読み込みしても、手動で追加したルールが戻るとは限りません。移行前にサーバー、設定、必要な項目を個別に確認しましょう。設定には個人用ドメイン、サーバー識別情報、認証情報が含まれることがあります。トラブルシューティングの資料を共有する前に、こうした情報を削除し、問題を再現するために必要な最小限のルールと加工済みの接続ログだけを残してください。

設定例の読み方

例にあるexample.comは構文説明用で、利用可能なサブスクリプションの接続先ではなく、このドメインに特定のポリシーが必要という意味でもありません。例のアドレスやルールは、ご自身の環境に合わせて置き換えてください。コードブロックの空行は項目を区切るためのものです。まとまった設定は全体を確認し、抜粋した行は対応するセクションに戻して使ってください。見慣れないオプションは、まずアプリが認識するかを確認し、その後で適用範囲を調べましょう。名前が似ていても動作が同じとは限りません。字面だけで判断して一括追加しないでください。

リモートルールファイルやローカル設定の保守も必要です。例外を追加する場合は、変更理由、検証対象、意図したポリシーを記録し、更新のたびに例外が残っているか確認しましょう。出所が分からない長いリストを増やすより、説明できるルールを少数に保つほうが管理しやすくなります。このガイドは「動作条件の設定、マッチ範囲の指定、ポリシーの選択、結果の確認」の順に説明します。トラブルシューティングでも同じ順序で確認してください。

GeneralとGlobal Routing

Ruleの内容を確認する前に、Global Routingの状態を確認してください。設定ファイルを保存していても、現在のモードがConfigでなければルールは適用されません。これは「ルールが効かない」と判断する際によくある前提条件の見落としです。画面上のConfig、Proxy、Directは、それぞれ設定による振り分け、プロキシ経由、直接接続のモードを示します。特定のルールの優先順位を変えるものではなく、通信全体の処理方針を決めます。振り分けを検証するときはConfigを明示的に選び、毎回の検証前にモードが変わっていないことを確認してください。

画面上の表示	用途	確認ポイント
Config	有効な設定に基づいて通信を振り分ける	設定の選択状態とルールの適用
Proxy	プロキシ経由で通信を処理する	サーバーの利用可否と接続パラメーター
Direct	直接接続で通信を処理する	現在のネットワークから接続先に到達できるか

Generalは別のルール一覧ではない

[General]のフィールドは共通動作を制御するもので、ドメインごとのRuleの代わりにはなりません。たとえばbypass-systemやskip-proxyは、システムや特定の接続先を迂回する処理に関係し、通常のRuleとは異なる段階で動作します。接続が先行する迂回処理で扱われている場合、RuleにPROXYを1行追加しただけでは期待した結果にならないことがあります。トラブルシューティングではルールだけでなく、共通設定によって通信が想定外の経路に入っていないかも確認してください。

[General]
bypass-system = true
skip-proxy = 127.0.0.1, localhost, *.local
dns-server = system

この例ではシステムの迂回動作を維持し、ローカルホストやローカルドメインの形式を記載しています。DNSにはシステムの名前解決設定を使います。各フィールドを確認するための例であり、既存の設定を置き換えてそのまま使うことは推奨しません。特にskip-proxyの一覧は共通フィールドの値であり、Ruleでも同じワイルドカード形式が使えることを意味しません。既存ファイルを読むときは、まずその行がどのセクションにあるか確認し、カンマ区切りの各項目をフィールドの意味に沿って解釈してください。異なる構文を混同しないようにしましょう。

接続スイッチ、オンデマンド接続、ルールの役割

Homeの接続スイッチは通信処理の開始・停止を切り替えます。Global Routingは動作モードを決め、有効な設定内のRuleはConfigモードで適用するポリシーを決めます。この3つをそれぞれ確認してください。On Demandは条件に応じて接続を確立するかを扱う機能で、ドメインごとにPROXYやDIRECTを選ぶものではありません。ネットワーク切り替え後に状態が変わった場合は、まず接続が維持されているか、次に動作モード、最後にルールの順序を確認します。

初回接続時に、VPN構成の追加を許可するようシステムから求められる場合があります。この許可は、アプリが該当するシステムのネットワーク機能を使用できることを示すもので、サーバーへの到達性やルールの正しさを保証するものではありません。初回接続の手順が完了していない場合は、クイックスタートガイドに戻り、順に操作してください。システム要件はApp Storeの掲載内容をご確認ください。古いスクリーンショットだけを根拠に、現在のデバイスの対応状況を判断しないでください。

モードを切り替えて比較する

同じ接続先に対して、新しく確立した接続の結果をDirectとProxyで短時間比較すると、直接接続とプロキシ経由のどちらに問題があるかを切り分けられます。比較後はConfigに戻してください。テスト中は接続先、ネットワーク、サーバーを変えず、条件をそろえましょう。Proxyではページを開けてConfigでは失敗する場合、振り分け経路の確認が必要だと分かりますが、すべてのDIRECTルールに問題があるとは限りません。ページが複数のドメインに接続している可能性があるため、関連する接続ログを個別に確認してください。

同様に、Directでページを開けたからといって、常に直接接続するべきとは限りません。ネットワークの場所、名前解決の結果、接続先サービスのアクセス条件は変わることがあります。適切な設定は明確な要件を表すものであり、一度のテスト結果を一般化するものではありません。Generalの設定が不確かな場合は、まず動作が分かっているコピーに戻し、各項目を個別に確認してください。複数のスイッチを繰り返し切り替えて試すと、本来の処理範囲が分からなくなるおそれがあります。

ドメインルールとマッチ範囲

ドメインルールは「どのホスト名にどのポリシーを適用するか」を決めます。よく使われる種類はDOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDで、違いはマッチ範囲にあり、名前の長さや優先度ではありません。いずれもRule内の実際の記述順に従って判定されます。作成前にURLから対象のホスト名を取り出し、プロトコル、ポート、パス、クエリーパラメーターをドメインの値に含めないでください。

DOMAIN：特定のホストを指定

DOMAIN,api.example.com,PROXYは指定したホスト名に適用され、単一のAPI接続だけを変更したい場合や、範囲の狭い例外を作りたい場合に向いています。example.com全体やすべてのサブドメインに適用されるわけではありません。アプリによってはログイン、画像、ファイルのダウンロードに別々のホストを使います。DOMAINを1つ追加してトップページが開いても、関連するすべての接続に同じポリシーが適用されているとは限りません。アプリ名からドメインを推測せず、実際の接続ログをもとに対象を追加してください。

DOMAIN-SUFFIX：ドメインとサブドメインに適用

DOMAIN-SUFFIX,example.com,PROXYは対象ドメインとそのサブドメインに適用されます。たとえばwww.example.comやapi.example.comが該当します。ドメインのラベル境界に沿って判定されるため、任意の文字列が末尾に一致するという意味ではありません。ルールにはexample.comをそのまま記述し、サブドメインを含めるためにhttps://やスラッシュ、パスを追加する必要はありません。範囲内の特定ホストを除外する場合は、正確なホストを指定するルールをこの広い範囲のルールより前に置いてください。

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

この順序は「ステータス用ホストには直接接続し、それ以外のサンプルドメインにはプロキシを使う」という意味です。先頭の2行を入れ替えると、ステータス用ホストが先にサフィックスルールに一致し、後の個別例外が適用されません。個別ルールが例外として機能するのは、DOMAINがDOMAIN-SUFFIXより自動的に優先されるからではなく、前に置かれているからです。設定を保守するときは、例外と対象の広いルールを隣り合わせにして、関係を確認しやすくしましょう。

DOMAIN-KEYWORD：範囲が広いため慎重に検証

DOMAIN-KEYWORD,example,PROXYはドメイン内のキーワードに基づいて一致するため、互いに関係のない複数のドメインに適用される可能性があります。ブランド名、サイトの運営者、ページ内容を認識するものではなく、英単語の意味を理解するものでもありません。短いキーワードは、特に複数の単語がホスト名で連結されている場合に、意図しない接続まで対象にするおそれがあります。キーワード指定が本当に必要な場合を除き、ドメイン自体から意図を確認しやすいDOMAINまたはDOMAIN-SUFFIXを優先してください。

ルールの種類	パラメーター例	適用範囲
DOMAIN	`api.example.com`	特定のホストを指定
DOMAIN-SUFFIX	`example.com`	ドメインとそのサブドメイン
DOMAIN-KEYWORD	`example`	キーワードを含むドメイン

ページのURLをもとにルールを書いても一致しない理由

ブラウザーのアドレスバーに表示されるのは入口のURLだけで、ページ内のリソースは別のホストから読み込まれる場合があります。リダイレクト、ログイン認証、メディア、APIリクエストはそれぞれ別の接続を確立することがあります。接続ログで実際に失敗した接続先を確認し、入口へのリクエストと後続リソースのどちらに問題があるかを分けて考えてください。ページにパスが表示されていても、DOMAINでパスに一致させようとしないでください。ドメインルールが指定できるのはホスト名の範囲であり、URLパスは別の条件です。

ドメインルールが一致するには、対象の接続でクライアントが判定可能なドメイン情報を取得できている必要もあります。IPアドレスへの直接接続、アプリ独自の名前解決、既存接続の再利用がある場合は、アドレスバーから想像する結果と異なることがあります。ドメインルールの後には、ドメイン条件に一致しない接続を扱うためのアドレスルールとFINALも設定してください。トラブルシューティングではログに表示された接続先を基準にし、「ドメインルールが適用された記録がない」ことだけから構文解析の失敗と判断しないでください。

長いルール一覧を整理する場合は、まず必要範囲の狭い個別例外を書き、次にドメイン全体へのルールを追加します。キーワードルールは明確な根拠がある場合に限って検討してください。範囲の広いルールを追加するたびに、一致すべき接続先と一致してはいけない接続先を1つずつ検証します。成功例だけを確認すると誤一致を見落とします。両方を検証すれば、キーワードが短すぎる、サフィックスの指定が誤っている、例外の順序が逆になっているといった問題を早く発見できます。

IPアドレスルールと補助条件

アドレスルールは接続先IPに基づいてポリシーを決めるもので、「あるウェブサイトがどこに属するか」を判断するものではありません。同じドメインでも複数のアドレスに解決され、ネットワークや時間によって結果が変わることがあります。サービスが分散基盤を使う場合もあるため、IP-CIDRとGEOIPはアドレスに関する条件として理解し、固定されたサイト分類とは考えないでください。同じドメインが直結になったりプロキシ経由になったりする場合は、まず各接続の宛先アドレスを比較し、アドレスルールが結果に関与しているかを確認します。

IP-CIDR：IPv4のアドレス範囲を指定

IP-CIDR,192.168.0.0/16,DIRECTはIPアドレスの範囲を指定します。スラッシュの後のプレフィックス長が範囲の広さを決め、数値が大きいほど範囲は狭くなります。単一のIPv4アドレスには/32を使えます。ネットワークアドレスはマスク境界に合わせてください。通常のURL、ポート番号、任意の開始・終了アドレスは指定できません。ローカルネットワークのルールを管理するときは、現在のネットワークで実際に使われているアドレス範囲を確認し、特定のプライベート範囲がすべてのローカルサービスに共通だと考えないでください。

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

1行目は単一アドレス、2行目はより広い範囲を指定しています。この例では1行目を追加しても最終的なポリシーは変わりませんが、範囲の違いを確認できます。2つのポリシーが異なる場合は、順序が結果に影響します。IPv6アドレスにはIP-CIDR6を使い、IPv6のプレフィックス形式で指定してください。ブラウザーにドメインが表示されていても、接続がIPv4だけとは限りません。トラブルシューティングの記録にIPv6の接続先がある場合は、対応するIPv6ルールと実際のネットワーク到達性を確認します。

no-resolve：ルール判定のための名前解決を制御

アドレスルール末尾のno-resolveは、そのルールに一致させるためだけにドメインの名前解決を行うことを避ける指定です。アプリ全体のDNSを停止したり、すべての名前解決を禁止したりするものではありません。接続先がすでにIPアドレスである場合や、処理中に判定可能なアドレスが得られている場合に、アドレスルールが必ず無視されるという意味でもありません。ドメインルールで先に処理し、アドレスルールは既知のアドレスを補う用途にしたい場合は、この指定で不要な名前解決を抑えられることがあります。実際のログで効果を確認してください。

GEOIP：アドレスデータベースに基づく分類

GEOIP,CN,DIRECTは、接続先アドレスのデータベース上の分類に基づいて一致します。ドメインのサフィックス、ページの言語、ユーザーの所在地を判定するものではありません。データベースには更新の遅れや帰属の違いがあるため、サービスの運営主体やデータの保存場所を示す証拠にはなりません。特定のドメインに常に同じポリシーを適用したい場合は、明示的なドメインルールのほうが説明しやすいでしょう。GEOIPは適用範囲を理解したうえで補助条件として使うのに適しています。

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

この例では、まず指定したドメインを処理し、次にアドレス分類で補完し、最後にFINALへ進みます。ドメインルールが一致した場合、その後にGEOIPを判定してポリシーを変更することはありません。反対に、範囲の広いアドレス条件を先に置くと、後続のドメインルールが意図どおり動かない場合があります。異なる種類のルールが条件ごとに投票するわけではありません。同じ順序に沿って判定され、最初に一致した条件がその接続の処理を決めます。

USER-AGENT：リクエスト情報を取得できる場合に適用

USER-AGENT,Example*,DIRECTは、User-Agentのパターンに基づいて一致させる書き方の例です。アプリ名による振り分けと同じではなく、デバイス上のすべてのアプリを識別できるとは限りません。一致するには、判定に必要な情報をリクエストから取得できる必要があります。暗号化されたHTTPS通信では、接続スイッチを有効にしただけでHTTPリクエストヘッダーを読み取れるとは限りません。情報を確認できない場合は、パターンを広げ続けるのではなく、確認可能なドメインやアドレス条件を使ってください。

トラブルシューティングでは、まず明確なDOMAINルールで比較対象を作り、その後にUSER-AGENTなどの補助条件を検討してください。ルールをテストするために、証明書の信頼範囲を広げたり、多数のリクエスト処理設定を変更したりしないでください。対象アプリがリクエストヘッダーを変更したり、異なるネットワークライブラリを使ったり、接続を再利用したりすると、パターンの一致結果も変わることがあります。ルールの信頼性は、名前がアプリに近そうかどうかではなく、判定に必要な情報を実際に取得できるかで決まります。

ポリシー、ルール順序、FINALによるフォールバック

ルールは一致条件と処理ポリシーで構成されます。一致条件は「この種類の接続に該当するか」を判断し、ポリシーは「一致した後にどう処理するか」を決めます。PROXY、DIRECT、REJECTは処理結果の違いであり、接続品質の段階ではありません。すべての接続先を同じポリシーにすると、一時的に問題を回避できる場合はありますが、元の設定にある振り分けの意図は失われます。接続先ごとの要件を明確にし、必要最小限の範囲を指定して適切なポリシーを選んでください。

ポリシー	処理内容	例
PROXY	選択中のプロキシ経由で処理	`DOMAIN,api.example.com,PROXY`
DIRECT	接続先に直接接続	`DOMAIN,router.example.com,DIRECT`
REJECT	一致した接続を拒否	`DOMAIN,blocked.example.com,REJECT`

上から順に判定し、最初に一致した時点で終了

Ruleのルール列では、条件を満たすルールが先に現れた順にポリシーが決まります。より具体的なDOMAINが、先にあるDOMAIN-SUFFIXを必ず上書きするとは限りません。アドレスルールがドメインルールより常に後になるという前提も誤りです。「例外を優先」するには、ルールの順序で実現する必要があります。複雑な設定を読むときは、対象ドメインだけを検索して直感に合う行で確認を終えるのではなく、関係する最初のルールから下へ順に確認してください。

[Rule]
DOMAIN,private.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

この例では、指定した2つのホストを個別に処理し、それ以外のサンプルドメインにはPROXYを適用します。ドメイン条件に一致しない接続はアドレスルールへ進み、それまでのルールに一致しない場合にFINALが適用されます。FINALを先頭に移すと、後続のルールは通常の判定に参加できなくなります。FINALにはドメインやアドレスのパラメーターは付けず、FINAL,PROXYと記述します。通常の3項目形式にしないでください。

PROXYに一致しても接続できるとは限らない

ルールが一致したことから分かるのは、条件に応じてポリシーが選ばれたということだけです。その後にサーバーへ到達できない、認証に失敗する、接続先に拒否される、名前解決に問題があるといったことも起こり得ます。PROXYは通常、現在選択されているプロキシ経由の接続先で処理されます。既存の設定に名前付きポリシーやポリシーグループがある場合は、その名前が存在し、意図した接続先を指しているかも確認してください。名前の入力ミス、参照先グループの削除、グループ内の選択先変更は、「ルールは合っているのに開けない」原因になり得ますが、一致条件の問題ではありません。

DIRECTは、現在のネットワーク制限を回避できるという保証ではなく、接続先に直接接続する指定です。ローカルネットワークから接続先にアクセスできない場合、DIRECTで失敗するのは接続経路の問題です。REJECTは接続を明示的に拒否するもので、ページのレイアウトを修正したり、キャッシュ済みの内容を削除したり、同じホスト上の用途を区別したりはしません。1つのホストがログインと他のリソースを提供している場合、ドメイン全体を拒否すると正常な機能も影響を受けることがあります。詳細はREJECTルールの書き方と適用範囲の制限をご覧ください。

FINALのポリシーを選ぶ

FINALはどのルールにも一致しなかった接続に適用する既定の処理であり、「自動判断」を有効にするものではありません。PROXYを選ぶと、明示的に分類されていない接続はプロキシ経由になります。DIRECTを選ぶと、分類されていない接続は直接接続されます。設定の目的、既存ルールの範囲、許容できる失敗の形に合わせて選んでください。FINALだけを変えても、これまで意識していなかった多くの接続の動作が変わることがあります。正常な接続と問題のある接続の両方を確認し、1つのページだけをテストして終わらせないでください。

保守しやすいようFINALは1つだけにして、ルール列の末尾に置いてください。FINALを複数記述しても予備の接続先にはなりません。前にあるFINALで判定が終了します。ルールの順序はサーバーの障害時切り替え機能でもありません。PROXYルールに一致した後に接続が失敗しても、後続のDIRECTルールが自動で試されることはありません。ルールの判定と接続の確立は別の段階です。接続失敗後の救済手段として後続のルールを考えないでください。

ルール一覧が長くなったら、完全に重複した項目を削除し、上の広いルールに覆われている項目がないか確認します。重要な例外は変更履歴を残してください。Ruleセクション全体を単純にアルファベット順に並べ替えると、優先関係が変わるので避けましょう。読みやすさは適用順序を理解しやすくするためのものです。同じグループの個別例外、範囲ルール、補助ルールを近くに配置し、末尾のフォールバックを見分けやすくすると、設定が要件に合っているか後から確認しやすくなります。

DNS、Host、接続先アドレス

DNSはホスト名をアドレスに変換し、振り分けルールは利用可能な条件に応じて接続ポリシーを選びます。Hostは指定したホストにアドレスを割り当てます。関連する機能ですが、互いの代わりにはなりません。ページが開かない場合は、アドレスを取得できていないのか、適切でないアドレスが返ったのか、アドレスは利用可能でも接続経路に問題があるのかを確認します。DNS設定をすべて変更すると現象が一時的に変わることがありますが、実際の障害箇所は分からないままです。

GeneralのDNS設定

dns-server = systemは、システムが提供する名前解決設定を使用する指定です。結果は現在のネットワーク環境に依存し、毎回同じ応答になるとは限りません。既存の設定で別の明示的な名前解決方式を使っている場合は、その意味を保ったまま、フィールドが認識されているか、アドレスに到達できるか、既存の設定と矛盾しないかを確認してください。インターネットで見つけたアドレスをそのまま追加したり、用途を理解していない追加パラメーターを混ぜたりして、ルールの有効性を判断しないでください。

[General]
dns-server = system

[Host]
router.example.com = 192.168.1.1

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

この例では、指定したホストをプライベートアドレスに対応付け、DIRECTを明示しています。HostとRuleを両方記述しているのは、名前解決の結果と接続ポリシーが別々の目的だからです。ローカルアドレスに割り当てたからといって必ず直接接続されるわけではなく、DIRECTルールだけで正しいアドレスが設定されるわけでもありません。実際のデバイスからそのプライベートアドレスに到達でき、対象のサービスが該当ポートで稼働している必要があります。

Hostは接続先サービスの正当性を変えない

Hostで接続先のアドレスを変えても、別のサーバーが元のドメインにとって正規のサービスになるわけではありません。HTTPSでは証明書とホスト名の検証も行われます。誤ったアドレスに割り当てた場合、ネットワーク接続が確立しても証明書エラーやサービスの不一致が生じることがあります。この場合は対応付けを取り消してアドレスを確認してください。本人性の検証を無効にする方法を通常の解決策として使わないでください。プライベートサービスでも、独自のドメインと証明書を正しく設定する必要があります。

Hostを管理するときはアドレスの変化に注意してください。モバイルデバイスがネットワークを切り替えると、以前使えていたプライベートアドレスに到達できなくなったり、別のデバイスを指したりすることがあります。固定の対応付けは、対象が明確で安定しており、検証できる場合に適しています。公共サービスの一度限りの名前解決結果を長期固定する用途には向きません。特に分散アドレスを使うドメインで単一のIPを固定すると、通常のアドレス選択を妨げ、地域によって使えたり使えなかったりする原因になることがあります。

名前解決とルール適用の順序

ドメインルールはドメイン名を直接使って判定できますが、アドレスルールには利用可能なIP情報が必要です。アドレス判定の一部では名前解決が行われることがあります。前述のno-resolveは、ルール判定のために名前解決を行うかどうかを制御します。明確なDOMAINルールがすでに一致している場合、その後のGEOIPが結果を覆すことはありません。接続ログを確認するときは、接続先ドメイン、解決されたアドレス、一致したルール、最終的なポリシーを合わせて見てください。アドレスの地域分類だけを比べないようにしましょう。

ログにIPアドレスしか表示されなくても、すぐにHostやDNSの不具合だと決めつけないでください。アプリが直接IPアドレスに接続しているか、現在のログ表示でドメイン名が確認できない可能性があります。逆にドメインが表示されても、すべての名前解決が同じ経路で行われているとは限りません。再現可能な単一リクエストを対象に、同じ接続先、同じネットワーク、新しい接続を使って、どの段階でルールの判定情報が得られるか順に確認しましょう。

キャッシュと既存接続による検証への影響

DNS設定やHostを変更しても、既存の接続先アドレスはすぐに切り替わらないことがあります。アプリが名前解決結果を保持している場合もあります。設定を保存した後、必要に応じて接続を確立し直し、対象アプリから新しいリクエストを送信してください。再生中のメディアや長時間維持されるメッセージ接続で新しいルールを検証しないでください。変更前に確立された接続である可能性があります。ページを再読み込みした場合も、接続ログを見て新しい接続が実際に発生したか確認しましょう。

無関係な複数のドメインで同時に名前解決に失敗する場合は、ドメインごとにHostを追加するのではなく、まず現在のネットワークと名前解決経路を確認してください。1つのドメインだけで問題が起きる場合は、入力ミス、既存の対応付け、対象サービスの状態を確認します。Hostはアドレスを明示的に管理するためのもので、あらゆるDNSの問題を解決する一覧ではありません。対応付けを少数に保ち、用途を明確にし、必要なら取り消せるようにしておくと、モバイルデバイスでネットワークを切り替える際も管理しやすくなります。

URL Rewriteとルールの適用範囲

URL RewriteとRuleの役割は異なります。Ruleは接続にPROXY、DIRECT、REJECTなどのポリシーを適用します。URL Rewriteは処理可能なリクエストURLを条件に一致させ、書き換えます。特定のドメインの接続経路を変える場合はRuleを使い、URL Rewriteで振り分けを代用しないでください。完全なURLの特徴に基づいて処理する場合は、リクエストを確認できるか、必要な処理条件を満たしているかを先に確認します。

正規表現が何に一致するかを理解する

URL Rewriteのマッチ部分には通常、正規表現を使います。先頭アンカー、文字のエスケープ、マッチ範囲を正しく区別してください。ドメインのピリオドは正規表現では特別な意味を持つため、文字としてのピリオドを表すには\.と記述します。先頭の^はURLの先頭から一致させる指定です。必要な境界がないとマッチ範囲が広がります。正規表現をDOMAINにそのまま入れないでください。両者で使うマッチ方法は異なります。

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

この例はリダイレクト構文を示すものです。指定したホストの特定のパスに一致させ、別のパスへリクエストを転送し、ステータスコード302を使用します。末尾の$は文字列の終わりを示すため、クエリーパラメーター付きのURLが自動的に同じ条件に一致するわけではありません。転送先のアドレスも構文説明用で、実際のサービスのテスト先ではありません。無条件に一致させるより、範囲を狭くして意図を説明できる条件から作ると、想定したリクエストだけにリダイレクトが適用されるか確認しやすくなります。

クエリーパラメーター、パスの境界、リダイレクトループ

URLではホスト名、パス、クエリー文字列はそれぞれ別の部分です。クエリーパラメーターを許可する場合は、マッチ範囲と保持方法を明確に設計してください。境界をすべて削除しても動作が変わらないとは限りません。パラメーターにはログイン状態、署名、一度限りの識別子が含まれることがあります。無計画に削除するとリクエストが失敗する可能性があります。認証に使われるリクエストは変更せず、まず個人情報を含まないテスト対象で式の実際の動作を確認してください。

書き換え後のURLが同じルールに再度一致しないことも確認してください。元の範囲に転送先が含まれていると、クライアントや接続先サービスが何度もリダイレクトし、ページの読み込みが繰り返されたり、リダイレクト回数の上限エラーが発生したりすることがあります。複数の書き換えルールが互いを指す場合もあります。トラブルシューティングでは「元のURL、書き換え先、サーバーが返す次のURL」の順序を書き出し、各段階を個別に確認してください。最初の式が一致するかだけで判断しないでください。

HTTPSではリクエスト全体が自動的に見えるわけではない

HTTPSではパスやリクエストヘッダーが暗号化通信に含まれるため、通常の振り分けで完全なURLを読み取り、書き換えられるとは限りません。ドメインで振り分けられるからといって、パスの書き換えも可能とは限りません。HTTPSのリクエストを処理する場合は、アプリ内の関連機能、証明書の信頼範囲、接続先アプリの検証方法も個別に理解してください。証明書を厳密に検証するアプリもあるため、すべてのリクエストが同じ方法で処理できるとは限りません。

REJECTとコンテンツ処理の違い

RuleのREJECTは一致した接続を対象にし、ページ内の各要素を個別に解析するものではありません。ページの内容と必要なAPIが同じドメインを使っている場合、そのホストを拒否すると他のリクエストにも影響します。URL Rewriteではより細かいURL条件を指定できますが、実際に情報を取得できるか、プロトコル方式や接続先の動作に左右されます。書き換えや拒否のルールを、すべてのアプリに適用できるコンテンツ整理機能と考えないでください。読み込みに失敗したからといって、ルールの目的を達成したとは限りません。

書き換えを検証するときは、個人情報を含むパラメーター付きの完全なURLを保存して公開するのではなく、元のURLの構成、想定する転送先、実際に発生したリダイレクトを記録してください。転送先が元のプロトコル要件を満たしているか、パスやパラメーターが意図せず失われていないかを確認し、最終ページで必要な機能が動作するかも検証しましょう。振り分けのテストと同様に、影響を受けるべきでないリクエストも確認し、正規表現が広すぎて同じサイトのログイン、支払い、その他の必須処理を変更していないか確かめてください。

一時的なテストルールと長期的に必要なルールは別々に記録し、根拠がなくなった式は削除してください。リモート設定の更新後は、関連ルールのマッチ範囲が変わっていないかも確認します。拒否ポリシーとドメイン範囲については、REJECTの仕組み、適用範囲、できないことをご覧ください。接続レベルの制約を理解してから、リクエストレベルの処理が本当に必要か判断しましょう。

ルールの検証、トラブルシューティング、保守

適切なトラブルシューティングでは、対象は何か、どのルールが一致したか、どのポリシーが適用されたか、どの段階で失敗したかの4点を確認します。「開けない」という説明だけでは、ルール、名前解決、接続経路のどこに問題があるか判断できません。開始前に繰り返しアクセスできるテスト対象を1つ選び、現在のネットワーク、有効な設定、サーバー選択を記録してください。テスト中に複数の条件を自動的に切り替えないようにします。共有するテスト資料からは個人用アドレス、パラメーター、認証情報を削除してください。

再現に必要な最小限のルールを用意する

まず復元できる設定のコピーを保存し、対象に範囲の狭いDOMAINルールを1つ追加します。対象を覆う可能性があるルールより前に配置してください。保存して選択状態を確認したら、Configモードで新しい接続を確立します。リクエストまたは接続ログで、利用可能な接続先、ルール、ポリシーの情報を確認してください。画面に表示される項目は異なる場合があるため、現在のアプリに表示される情報を基準にします。意図したポリシーに一致していることを確認できたら、一致条件の変更は続けず、名前解決の結果と接続経路の到達性を調べます。

[Rule]
DOMAIN,test.example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT

この例では、単一のテスト用ホストとそれ以外の接続を分け、ルール選択を確認しやすくしています。汎用の設定例ではありません。ご自身で管理している実際のテスト対象に、サンプルのホスト名を置き換えてください。検証後は有効だった変更を元の設定に反映し、従来のフォールバック方針に戻します。一時的な例のほうが短いからといって、元の設定に含まれる他の必須ルール、共通パラメーター、ローカルサービス向けの例外を無視しないでください。

現象を段階ごとに切り分け、すべてをルールの問題と決めつけない

確認された現象	まず確認する点	次の手順
想定した新しい接続がない	既存接続の再利用、対象アプリのキャッシュ	リクエストを再実行し、発生時刻の順序を確認
別のルールに一致する	ルールの順序、適用範囲、有効な設定	上から順に、最初に一致する条件を確認
PROXYに一致したが接続に失敗	サーバーパラメーター、名前解決、接続先の応答	ルールを変えずに接続経路を確認
一部のリソースだけ失敗する	リソースのホストと入口のホストが異なる	失敗した接続先を個別に特定

Connectivity Testは接続条件の確認に役立ちますが、その結果は対象アプリの実際のリクエストの代わりにはなりません。テストで応答があっても、対象ドメインが正しく名前解決されることや、すべてのプロトコル、ポート、リソースが利用できることは保証されません。テストが失敗した場合も、テスト方法を踏まえて判断する必要があります。診断ツールは原因範囲を絞る手掛かりとして使い、実際の接続先への新しい接続で最終的な動作を確認してください。

サブスクリプションの更新とルールの更新を分けて確認

既存のサブスクリプションを更新できない場合は、すぐにRuleを書き換えるのではなく、URLが完全か、現在のネットワークに問題がないか、アカウントが有効かを確認してください。サーバー一覧が空になる問題と、振り分けルールの適用ミスは別の段階の問題です。個別の共有リンクとサブスクリプションURLでは更新方法も異なるため、同じものとして重複読み込みしないでください。追加方法の見分け方はサブスクリプションを追加する4つの方法、形式の違いは共有リンクとサブスクリプションURLの違いをご覧ください。

リモート設定の更新後に動作が変わった場合は、変更されたセクションを比較し、自分で追加した例外が残っているか確認してください。サブスクリプション更新、設定の置き換え、サーバーの変更を同時に行ってから、1回の結果だけで原因を推測しないでください。サブスクリプションが空になる、解析に失敗するといった場合は、サブスクリプションの更新失敗・一覧が空の場合の確認項目をご覧ください。このページでは設定とマッチングの仕組みを扱い、サービスの入手先は推奨しません。

復元、再検証、継続的な保守

変更後に広範囲な不具合が起きた場合は、まず動作が分かっている設定のコピーに戻し、Global Routing、サーバー選択、共通設定も元に戻ったか確認してください。復元後は接続を確立し直し、同じ対象で再テストして、元の状態で動作するか確かめます。失敗した設定に矛盾する例外を重ねて追加しないでください。すべての一時ルールについて用途を説明できなければ、後のトラブルシューティングが偶然の結果に左右されやすくなります。

長期的な保守では、変更したセクション、変更理由、検証できた接続先、復元方法を簡潔に記録しておきましょう。定期的に無効になったドメイン、重複ルール、範囲の広すぎるキーワード、使わなくなったHostの対応付けを確認してください。購入の復元、互換性、App Storeでの検索については購入済みアプリの復元方法とApp Storeで検索できない場合の確認手順をご覧ください。操作手順を最初から確認する場合はクイックスタートガイドに戻ってください。