Shadowrocket
ルールと設定項目
現在の設定とGlobal Routingを確認し、設定セクションごとにマッチ条件、ポリシー、名前解決の結果を調べます。
このページは、設定内容を確認するためのリファレンスマニュアルです。既存設定の確認や振り分け順の調整、設定項目の誤りの特定に役立ちます。初めて設定を読み込む場合は、お手持ちのサブスクリプションやサーバー情報を使って、まずクイックスタートガイドに沿って接続してください。その後、このページで各ルールの役割を確認できます。例は構文の説明用であり、接続情報は含まれていません。ご自身が利用できる有効なサービスの代わりにはなりません。
ShadowrocketはAppleプラットフォーム向けのクローズドソースの有料アプリで、主にiPhoneとiPadで利用されています。入手先はApp Storeのみです。システム要件はApp Storeのページをご確認ください。クライアントの買い切り購入と回線プランは別です。本サイトではノードやサブスクリプションの提供・販売・推奨は行っていません。購入や復元についてはApp Store正規品の確認方法をご覧ください。
設定ファイルの構成と適用条件
設定ファイルはサーバー一覧ではありません
設定ファイルはクライアントによるリクエストの処理方法を指定し、サーバー情報は接続方法を指定します。両者は分けて確認してください。サブスクリプションを読み込んだ後、Homeに項目が表示されても、サーバーデータがクライアントに取り込まれたことを示すだけで、ルールファイルが有効になったとは限りません。逆に、設定ファイルを正常に保存できても、PROXYポリシーで使用する接続が利用可能とは限りません。問題を調べる際は、まずこの2つを切り分けてください。サーバーの認証情報の問題を、ルールの置き換えで解決しようとしないことが大切です。
Configで現在選択されている設定を確認し、Global RoutingがConfigになっているかを確認します。このモードでは現在の設定に従ってトラフィックを処理するため、本ページのRuleの例を読む前提となります。ProxyまたはDirectに切り替えるとリクエストの処理経路が変わるため、同じルールのマッチ結果を前提に設定の正誤を判断できません。ファイル名は識別のためのもので、同じ名前でも内容が同じとは限りません。複数のファイルがある場合は、選択状態と実際に保存されている内容を確認してください。
セクションごとに役割を分ける
| 設定セクション | 主な役割 | 確認ポイント |
|---|---|---|
[General] | 共通動作と名前解決の設定 | 項目名、値、適用範囲 |
[Rule] | リクエストのマッチングとポリシー選択 | 条件、順序、フォールバック |
[Host] | 指定ドメインのアドレス対応付け | ホスト名とアドレスの対応 |
[URL Rewrite] | 条件に合致するURLの書き換え | 正規表現、遷移先、ステータスコード |
セクション名は角括弧で囲み、以降の行をどの構文として解釈するかを決めます。Generalではキーと値、Ruleでは英語のカンマで区切ったルール項目、Hostではドメインとアドレスの対応付けが一般的です。ドメインルールをHostの下に貼り付けたり、共通設定をRuleの下に貼り付けたりすると、記述が完全に見えても意図した効果は得られません。編集時は、キーワードだけで検索するより先にセクション名を確認し、その下に内容を追加してください。
[General]
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
[Host]
router.example.com = 192.168.1.1上のファイルには、役割の異なる3つのセクションがあります。ドメインのサフィックスルールは接続ポリシーを選び、Hostの行は特定のホスト名の名前解決先を指定します。両者は同じ種類の上書き設定ではありません。この例ではマッチ範囲を分かりやすくするため、フォールバックにDIRECTを使用しています。あらゆる場面でこの値が適切という意味ではありません。フォールバックを変更する場合は、マッチしなかったリクエストをどう処理するかを明確にしてから、選択した接続が利用可能か確認してください。ファイル名だけで用途を判断しないでください。
元に戻せる編集手順を整える
変更前に現在の設定をエクスポートするか、コピーを保存し、試験用ファイルには用途が分かる名前を付けます。コピーを開いたら、一度に変更するのは1つの設定セクション、または密接に関連するルールのまとまりだけにしてください。保存後、Configで選択中の項目をもう一度確認します。別のファイルを編集した場合、テキストを保存しただけでは使用中の設定は切り替わりません。テスト後は変更の目的を記録し、問題がなければ維持し、失敗した場合は検証済みのコピーに戻してください。不確かな項目を重ねて追加しないようにします。
設定テキストでは句読点も構文の一部です。ルールには半角カンマ、キーと値の設定には半角イコール、アドレス範囲にはスラッシュを使います。リッチテキストからコピーした場合は、日本語の句読点、見えない空白、改行で途中が切れた項目が混入していないか確認してください。エディター上で長いルールが折り返して表示されても、実際の改行とは限りません。ファイル内の実際の行を基準に判断します。コメントでルールの意図を説明することはできますが、ポリシー項目の代わりにはなりません。また、接続パスワードを説明文に記載しないでください。
リモート設定の更新と手動編集では、内容が上書きされる可能性にも注意が必要です。リモートから更新されるファイルを編集している場合、次回の更新でローカルの変更が変わることがあります。まずファイルの取得元とアプリ内での更新動作を確認し、独自ルールを管理するローカルコピーを作成するか判断してください。通常、サブスクリプションの更新対象はサーバーデータ、設定の更新対象は設定テキストです。どちらもアドレスを使うからといって、同じ操作ではありません。保存や移行の手順は設定のバックアップと機種変更時の移行メモもご覧ください。
GeneralとDNSの名前解決範囲
共通設定とルール選択を分けて考える
Generalは設定全体に共通する動作を定義し、Ruleのように1行ずつマッチさせるものではありません。ここでの設定はドメインの名前解決、アドレス処理、接続環境に影響することがありますが、別の振り分けリストとして扱うことはできません。用途が分からない項目は、まずアプリ内の設定編集画面や設定説明でサポート状況を確認してから、値が有効か判断してください。他のテキストで使われているキー名でも、現在のアプリが認識するとは限りません。用途を確認できない項目は、使用中の設定に追加しないでください。
DNSはホスト名をアドレスに変換し、Ruleはリクエスト情報に基づいてポリシーを選びます。名前解決に成功してもプロキシ接続が成功するとは限らず、ポリシーが正しくても名前解決結果が正しいとは限りません。たとえば、ドメインルールがPROXYにマッチしていてもサーバーへの接続に失敗する場合、接続パラメーターに問題がある可能性があります。また、DIRECTでリクエストを処理できても、アクセスできないアドレスが返る場合は、名前解決元や接続先を確認してください。2つの段階を分けて検証すると、変更範囲を絞り込めます。
まずシンプルな名前解決の基準を保つ
[General]
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTdns-server = systemは、この設定の名前解決元としてシステムDNSを使用することを示します。この例の目的は、元に戻しやすい基準を作ることです。あらゆるネットワーク環境で同じ結果になることを保証するものではありません。システムDNSを使う場合、現在のネットワークのDNS設定が結果に影響します。ネットワークを切り替えると、名前解決結果やアクセス可否が変わることがあります。2回のテストを比較する際は、ネットワーク環境が同じか記録してください。環境の違いをルール変更の影響と誤認するおそれがあります。
DNSサーバーを変更する場合は、まず利用者自身のネットワーク要件と、現在のアプリが受け付ける値の形式を確認し、設定を1つだけ変更してください。名前解決元の変更、Hostマッピングの追加、ルール順の変更を同時に行うと、結果の原因を特定しにくくなります。名前解決サービスのアドレスとプロキシサーバーのアドレスは別の項目です。既存のサブスクリプションアドレスをDNS設定に入れても、サーバーは読み込まれません。設定後はリクエストを再実行し、ログで取得したアドレスが想定どおりか確認してください。
ドメイン、アドレス、no-resolve
リクエストからドメイン名を取得できる場合、ドメインルールはマッチングに使えます。一方、アドレスルールには接続先アドレスの情報が必要です。ドメイン名しか分からず、アドレスがまだ取得されていないリクエストでは、判断のために名前解決が必要となるアドレスルールがあります。そのため、ルール順が追加の名前解決の有無に影響することがあります。名前解決の遅延を調べる際は、DNS設定だけでなく、判定のために名前解決を行う先行アドレスルールや、本来先にマッチできるドメインルールが後ろにないかも確認してください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECTno-resolveはアドレスルールに指定できる修飾項目で、そのルールの判定のためにドメイン名を積極的に名前解決することを防ぎます。設定全体でDNSを無効にするものでも、その後の接続で名前解決が不要になるものでもありません。クライアントが接続先アドレスをすでに把握していれば、そのアドレスを基にルールを判定できます。アドレスがない場合、この項目によって追加の名前解決が行われ、ドメインがアドレス範囲に分類されるとは期待できません。すべてのルール末尾に追加しないでください。ドメインルールやFINALの意味も変わりません。
アドレスファミリーとキャッシュによる違い
同じホスト名から複数のアドレスが返ることがあり、異なるアドレスファミリーが同時に使われる場合もあります。IPv4のアドレス範囲ルールを1つ設定しても、IPv6の接続先には自動で適用されません。逆に、IPv6ルールを設定しても、ネットワークがそのアドレスに接続できるとは限りません。まず実際に使われている接続先アドレスを確認し、ルールに含まれているか判断してください。特定の失敗を解決するために片方のアドレスファミリーを安易に無効化すると、接続先ネットワークや接続設定の問題を見落とすことがあります。関連する設定はアプリ内の説明を確認してください。
名前解決設定を変更した後も、既存の接続やアプリ・システムのキャッシュが確認結果に影響することがあります。ページを再読み込みしても新しい接続が確立されるとは限らず、設定テキストを変更しても既存接続で最初からルールが適用されるとは限りません。関連するリクエストを終了してから、判別しやすいアクセスを再実行してください。必要に応じて、アプリ内で提供される操作に従って名前解決状態を更新します。ドメイン、返されたアドレス、マッチしたポリシー、接続結果を記録すると、「開けた／開けない」だけを記録するより比較しやすくなります。
DOMAIN系ルールの範囲と書き方
完全一致とサフィックス一致
DOMAINは1つの完全なドメイン名に一致し、DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致します。まず異なるのは適用範囲であり、どちらかが本質的に優先されるわけではありません。特定のホストだけを対象にするなら完全一致のほうが影響範囲を限定しやすく、ドメイン配下全体を対象にするならサフィックス一致のほうが管理しやすくなります。どのホストを含め、どのホストを除外したいかを先に整理してから種類を選ぶと、記述が短いという理由だけで振り分け範囲を広げずに済みます。
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXYこの例では、api.example.comにPROXYを適用し、その他のexample.com配下のホストにはDIRECTを適用します。この例外は、範囲の広いルールより前に置く必要があります。対象のホストもサフィックス条件に一致するためです。2行の順序を逆にすると、サフィックスルールが先にマッチし、後ろの完全一致ルールではリクエストの処理を決められません。完全一致というルール種類が、前のルールを自動的に飛び越えるわけではありません。実行順はテキスト上の位置で指定します。
ドメイン欄にはホスト名を入力し、プロトコル、パス、クエリパラメーター、ポートは含めません。アクセスURLのページパスはDOMAINのマッチ対象ではありません。ページURL全体を貼り付けても、通常は意図したホスト名のマッチを表現できません。パスに応じてURLを変更する必要がある場合は、URL Rewriteを確認してください。ドメインルールにスラッシュを追加する方法ではありません。編集後は項目を種類、マッチ値、ポリシーの3つに分け、それぞれの役割が明確か確認します。
キーワードマッチは範囲を絞る
| 種類 | マッチ値の例 | 適用する条件 |
|---|---|---|
| DOMAIN | api.example.com | 指定した完全なホスト名 |
| DOMAIN-SUFFIX | example.com | ドメインとそのサブドメイン |
| DOMAIN-KEYWORD | example | ドメイン内の指定文字列 |
DOMAIN-KEYWORDはドメイン内のキーワードを調べます。適用範囲をサフィックスルールより直感的に把握しにくいことが多いため注意してください。同じ文字列が無関係なホスト名に含まれる場合があるので、明確なドメインの管理範囲を表す用途には適しません。キーワードは正規表現ではありません。ドット、アスタリスク、括弧を正規表現として入力しても、正規表現のようにマッチするとは限りません。対象のドメイン一覧が明確な場合は、範囲を正確に表せる条件を優先してください。
[Rule]
DOMAIN,keep.example.com,DIRECT
DOMAIN,ads.example.com,REJECT
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECTこの例では、最初の2行でDIRECTの例外と特定ホストの拒否を設定し、その後にキーワードルールで残りの該当ドメインを処理します。ここにあるads.example.comは構文の説明用であり、実際のコンテンツ分類を示すものではありません。ホストを拒否すると、ページの読み込みに必要な機能にも影響する可能性があります。使用前に対象の用途を確認してください。誤って拒否した後にページが真っ白になった場合は、すぐに広い許可ルールを追加するのではなく、実際のリクエストログから依存関係を調べてください。
サブドメイン、別名、リクエストから確認できる情報
1つのページから、API、画像、認証、静的リソースなど複数のホストへリクエストが送られることがあります。ブラウザーのアドレス欄に表示されるドメインにルールを書いても、他のホストに同じポリシーが自動適用されるわけではありません。一部のコンテンツが読み込めない場合は、失敗したリクエストのホスト名を一覧にして、それぞれが現在のサフィックス範囲に含まれるか確認してください。同じ接続先アドレスを使っているという理由だけで、異なるドメインを同じドメインルールの範囲に含めないようにしてください。
ドメインの別名や名前解決の連鎖は、元のリクエストのホスト名と区別して確認してください。DNSの結果が別の名前を指していても、あらゆるマッチングで必ずその名前が参照されるとは限りません。実際に確認できる情報は、現在のリクエスト記録を基準にしてください。アドレスを直接指定してアクセスすると、DOMAIN系ルールのマッチに必要なドメイン情報をクライアントが取得できない場合があります。その場合はアドレスルールとフォールバックを確認してください。ページタイトルやアプリ名からリクエストのホスト名を推測しないでください。
サフィックスルールを検証する際は、少なくともルートドメイン、サブドメイン1つ、範囲外のドメイン1つを選んで確認してください。さらに、先行する例外ルールについて個別にリクエストを行い、ログ上のポリシーが異なることを確認します。一時的なテスト用に完全一致ルールを追加した場合は、理由をテスト記録に残し、完了後に維持するか削除するか決めてください。例外が増えたら、重複行をまとめ、不要になったホストを削除しましょう。ルールを無制限にファイルの先頭へ追加するより、管理やロールバックが簡単になります。
アドレスルールとUSER-AGENT条件
IP-CIDRとアドレス範囲
IP-CIDRはIPv4アドレス範囲をCIDR表記で指定します。スラッシュの後の数字はプレフィックス長で、ポート番号でも一致するアドレス数でもありません。プレフィックスが長いほど範囲は狭くなります。ルールを確認する前に、先頭の数文字を比べるだけでなく、対象アドレスがどのネットワークに属するか確認してください。複数の範囲が重なる場合も、ポリシーはルールの位置に従って選択されます。そのため、広い範囲に含まれる狭い範囲の例外は、広い範囲より前に置いてください。
[Rule]
IP-CIDR,192.168.1.10/32,REJECT,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行目が1つのIPv4アドレスだけに一致し、その後の2行が一般的なプライベートアドレス範囲に一致します。1行目はより広い範囲より前にあるため、そのアドレスは先に拒否されます。後ろに置くと、既存のDIRECTルールが先に適用されます。プライベートアドレスのルールを設定しても、異なるネットワークで同じアドレスが同じ機器を示すとは限りません。ネットワークを切り替えると別のホストを指すことがあります。これらの範囲を使う際は、現在のLANと利用者自身の接続環境を踏まえて判断してください。
IP-CIDR6はIPv6アドレス範囲に使います。IPv4の記法で代用することはできません。例にあるIPv6範囲はIPv4のプライベートアドレスと1対1で対応するものではなく、アドレスファミリーごとに別々に表現することを示しています。サービスが両方のアドレスを持つ場合、実際の接続先に応じてマッチするルールが変わります。トラブルシューティングでは完全なアドレスを記録し、画面にドメイン名が表示されていても、実際に使われたアドレスファミリーを見落とさないでください。
GEOIPはドメイン分類ではありません
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYGEOIPはアドレスの地域データベース情報に基づいてマッチします。ドメインのサフィックス、ページの言語、サイト名で代用して判断することはできません。ドメインが異なる配信先アドレスを使う場合、実際のアドレスによってマッチ結果が変わることがあります。GEOIPはアドレスの分類条件を表す用途に適していますが、特定のサービス全体で常に同じポリシーを使う保証にはなりません。特定のドメインを明確に処理したい場合は、地域ルールより前にドメインルールを置き、明確な条件で例外を指定してください。
アドレスデータベースとサービスの実際の設置場所には差があることがあり、地域判定はサービス運営主体の所在地を意味しません。直感と異なる結果が出た場合は、先に接続先アドレスとログを確認してから、完全一致のドメインルールを追加するか判断してください。1つのドメインを修正するために地域トラフィック全体のポリシーを変えると、通常は影響範囲が広がります。アドレス取得に名前解決が必要なリクエストは、前章のDNSとno-resolveの範囲もあわせて確認してください。
USER-AGENTを使える条件
[Rule]
USER-AGENT,ExampleClient*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTUSER-AGENTは取得可能なリクエストヘッダー情報に基づいてマッチします。ここにあるExampleClient*はワイルドカードの書き方を説明する例であり、実在のアプリ識別子ではありません。アプリ名や端末のプロセスに基づいてマッチするものではありません。関連するリクエスト情報を取得できる場合にのみ判定できます。すべてのアプリ接続に同じヘッダーが含まれるとは限らず、特定アプリのすべての通信を安定して分類する方法としても使えません。
暗号化されたリクエストの内部ヘッダーは、常に確認できるわけではありません。USER-AGENTルールをマッチさせるためだけに、証明書を安易に追加したりHTTPS処理設定を変更したりしないでください。こうした操作は独立した信頼性とアクセス範囲に関わるため、明確な権限と用途が必要です。通常のドメイン振り分けには、まずDOMAIN系ルールを使ってください。テストでリクエストヘッダーを確認できても、バックグラウンド接続、他のAPI、後続のリクエストでも同じ条件が成立するとは限りません。
複合ルールでは、まず明確なホストの例外を配置し、必要に応じてアドレス範囲や地域条件を追加します。リクエストヘッダー条件を使う場合は、情報を取得できるか、マッチ範囲が適切かを個別に確認してください。マッチしない原因を調べるときは、条件に必要な項目が存在しない、項目はあるが値が一致しない、先行ルールですでにマッチしている、の3つに分けます。それぞれ対処方法が異なり、すべてをワイルドカードの調整で解決できるわけではありません。各ルールが必要とする情報をメンテナンス記録に残すと、後から原因を推測し直す手間を減らせます。
ポリシー、Global Routing、マッチ順
まずモード、次にポリシーを確認
Global Routingは現在適用されている全体の処理モードを決めます。Configは設定に基づく振り分け、Proxyはプロキシモード、Directは直接接続モードです。具体的な動作は、アプリの現在の設定やリクエストの種類をあわせて確認してください。Ruleの各行に沿って本章の例を説明できるのは、Configが選択されていることを確認した後です。モード切り替えは問題の切り分けに使えますが、ルール修正の代わりにはなりません。テスト後は、元の明確な選択状態に戻してください。
| 区分 | 英語表記 | 確認内容 |
|---|---|---|
| Global Routing | Config | 現在の設定とルールを確認 |
| Global Routing | Proxy | プロキシ経由の処理経路を確認 |
| Global Routing | Direct | 直接接続の処理経路を確認 |
| Ruleのポリシー | PROXY | 選択中のプロキシ経由で処理 |
| Ruleのポリシー | DIRECT | 接続先へ直接接続 |
| Ruleのポリシー | REJECT | マッチしたリクエストを拒否 |
画面上のProxyとルール中のPROXYは異なる階層の設定です。名前が似ていても、完全に同じものではありません。前者は全体モードの選択、後者はルールにマッチしたときに使うポリシーです。DIRECTは選択中のプロキシを経由せずに接続しますが、接続先アドレスとローカルネットワークが通信可能である必要があります。REJECTはリクエストを明示的に拒否します。接続失敗時の自動的な代替ポリシーではありません。拒否されたリクエストは、失敗した後に次の許可ルールを探すこともありません。
マッチしたら終了、例外は先に
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYこの例は上から順に確認します。APIホストには先にPROXYを適用し、指定ホストを先にREJECTで拒否し、残りのドメイン範囲にはDIRECTを適用します。前のドメイン条件で結果が決まらない場合にのみ、後続のアドレス条件がポリシーを決めます。ルールの種類に自動的な並べ替えはなく、「より具体的な条件が常に優先される」という暗黙の優先度もありません。テキスト上の位置は優先順位を表す重要な要素です。例外を追加する際は、直前の1行だけでなく、それより前にマッチする可能性のあるルールをすべて確認してください。
よくある「ドメイン優先、アドレスはフォールバック」という順序は、設定を管理する人が並べたものです。すべての設定が自動的にこの順序になるわけではありません。アドレスルールを前に置くと、本来ドメインに基づいて処理したいリクエストが先に決まることがあり、名前解決にも影響する場合があります。実際の動作は、利用可能なリクエスト情報と条件によって異なります。設定ファイルを読む際は、グループ分けのコメントから優先順位を推測せず、実際の順序を確認してください。コメントに例外と書かれていても、広い範囲のルールより後ろにあれば適用されません。
FINALの位置と意味
FINALは追加のマッチ値を持たないフォールバックルールです。一般的な書き方はFINAL,PROXYまたはFINAL,DIRECTです。前にある明示的な条件が先に判定されるよう、ルール一覧の末尾に配置してください。FINALを途中に置くと、それ以降のルールが想定どおりマッチする機会を失います。FINALを複数追加しても、順番に試す代替接続にはなりません。デフォルトのポリシーを決める前に、明示されていないリクエストをどう処理するかを決めてください。
PROXYにマッチした後に接続が失敗しても、クライアントが自動的にDIRECTへ切り替わるわけではなく、次のRuleを続けて確認するわけでもありません。ルールがポリシーを決め、その後に接続結果が得られます。後続の動作を変えるのは、別途明示的に設定した関連機能に限られます。プロキシの利用可否を確認する場合は、利用者がすでに所有する接続を個別にテストし、認証とトランスポートのパラメーターを確認してください。広範囲のDIRECTルールでプロキシの問題を隠すと、「ページを表示できた」というログが本来の検証として意味を失います。
用途に沿ってメンテナンス順を整理する
完全一致の例外、ドメイン範囲、LANアドレス、その他のアドレス分類、FINALの順に整理し、それぞれの用途を記載する方法があります。順序は固定のテンプレートではありません。各例外がその位置にある理由を説明できることが重要です。重複ルールを見つけたら、同じホストに見えるという理由だけで削除せず、ポリシーが異ならないか、意図的な上書きではないかも確認してください。範囲の広いルールより前の完全一致例外には意味があります。一方、範囲の広い同一ポリシールールの後ろにある重複行は、通常メンテナンスの手間を増やすだけです。
ConfigとProxyのテスト結果を比較するときは、マッチしたルールと使用した接続の両方を記録してください。Proxyで接続できてConfigで失敗する場合は、DIRECTまたはREJECTに振り分ける条件を優先して確認します。どちらも失敗する場合は、接続設定とネットワークを確認してください。Directで成功しても、プロキシのパラメーターが正しいとは限りません。各モードの詳しい説明はGlobal Routingの3つのモードに関するメモをご覧ください。変更時は、現在のアプリ内で実際に記録された内容を基準にしてください。
HostマッピングとLANの適用範囲
アドレスを対応付ける設定であり、ポリシー選択ではない
Hostは指定したホスト名にアドレスを対応付けます。解決するのは「この名前がどのアドレスに対応するか」であり、「このリクエストをどの接続経路で処理するか」ではありません。マッピング後も、適用されるルールと現在のモードを確認する必要があります。特に、Hostでホスト名をLANアドレスに対応付けたからといって、リクエストが必ず直接接続になるわけではありません。先行するドメインルールによってPROXYが選ばれる場合があります。設定を読む際はHostとRuleをあわせて確認し、それぞれの役割は分けて考えてください。
[Host]
router.example.com = 192.168.1.1
service.example.com = 192.168.1.20
[Rule]
DOMAIN,router.example.com,DIRECT
DOMAIN,service.example.com,DIRECT
FINAL,PROXYこの例では、2つのホストにアドレスを明示的に割り当て、完全一致のドメインルールで直接接続する意図を示しています。利用者がアクセス権を持ち、現在のネットワークに実在する機器にのみ適用してください。例にあるアドレスは、あらゆるネットワークからアクセスできる公開の接続先ではありません。現在のLANで異なるアドレス範囲を使っている場合、例をそのままコピーしてもサービスは利用できません。マッピングを設定する前に、接続先機器のアドレス、ポート、サービスが正常か確認してください。その後、覚えやすいアクセス名としてドメインを使います。
ホスト名、ポート、パスを分けて扱う
Hostの左側にはホスト名、右側には対応するアドレスを記述します。ページパス、プロトコルの接頭辞、ポートは含めません。マッピングはアプリがリクエストするポートを変更せず、通常のウェブリクエストを別のプロトコルに変えるものでもありません。接続先サービスが特定のポートだけで待ち受けている場合、アクセス側では引き続き正しいアクセス方法を使う必要があります。マッピングが適用されてもサービスに接続できない場合は、接続先とサービスの待ち受け状態を確認してください。Hostの値にパスを追加し続ける方法では解決しません。
Hostはサフィックスルールでもありません。特定のホストを1つマッピングしただけで、すべてのサブドメインに同じ結果が適用されるとは限りません。複数のホストが必要な場合は、アプリがサポートする記法とそれぞれの接続先を確認し、明確なホスト名で検証できる状態から始めてください。通常の振り分けにHostは必要ありません。ドメインをプロキシ経由にしたいだけなら、Ruleでポリシーを指定し、通常の名前解決を維持してください。アドレスを手動で固定すると、メンテナンスの手間が増えることがあります。
HTTPSのホスト名検証はなくならない
ホスト名をアドレスに対応付けても、リクエスト内のホスト名が置き換わるわけではなく、そのホスト名に接続先の証明書が自動的に適用されるわけでもありません。HTTPS接続では引き続き証明書の名前と信頼チェーンが検証され、接続先のサービスがホスト名に基づいてサイトを選択することもあります。マッピング後に証明書エラーが発生した場合は、サービスがそのホスト名に実際に対応しているか確認してください。検証を無効にする方法を通常の解決策として使わないでください。アドレスへの到達性、ドメインのマッピング、証明書の有効性はそれぞれ別の条件です。
利用者自身が管理するサービスでは、サーバー側の設定に合わせて正しいホスト名と証明書を用意し、現在のネットワークで検証してください。管理していないサービスの名前解決先を任意のアドレスに固定すると、誤った接続先にアクセスしたり、アドレス変更後も失敗し続けたりすることがあります。ネットワーク配信サービスでは、名前解決によって異なるアドレスが返されることがよくあります。一度確認したアドレスを長期間固定すると、通常の振り分けを妨げる可能性があります。明確な必要性がなければ、試験用マッピングを削除して通常の名前解決に戻してください。
ネットワーク切り替え後の管理とロールバック
LANマッピングで最も注意すべきなのはネットワークの切り替えです。同じプライベートアドレスでも、別のネットワークでは存在しない場合や、別の機器に割り当てられている場合があります。元のネットワークを離れても、用途がなくなったマッピングが自動的に公開アドレスへ切り替わることはありません。テストに成功したら、適用できるネットワークとサービスを記録し、他のネットワークでは関連設定を無効にする必要があるか検討してください。一度成功した記録だけでは、モバイル通信や別のLANでもマッピングが正しいとは判断できません。
トラブルシューティングでは、まず現在のネットワークを確認し、次に接続先アドレスへのサービス接続を直接テストします。その後、マッピング後のドメインリクエストで想定したアドレスとポリシーが使われているか確認してください。アドレスへ直接接続できない場合は、ネットワークまたは接続先サービスを優先して確認します。アドレスへ接続できてもドメイン経由では失敗する場合は、名前、証明書、アプリのリクエスト方法を確認してください。両方が正常でもポリシーが誤っている場合は、先行するRuleを確認します。段階ごとに検証すれば、結果に影響するルールを見落としたままHostのアドレスを何度も変更することを避けられます。
マッピングを削除または変更した後は、リクエストを再実行してください。既存接続や名前解決のキャッシュに以前の結果が残ることがあります。バックアップを保守する際は、各マッピングの用途とロールバック方法をコメントに記載し、機器の認証情報は記録しないでください。一時的な診断用マッピングなら、テスト終了後に通常使用する設定から取り除きます。長期間使用する場合は、接続先アドレスが変わっていないか定期的に確認してください。用途を明確に限定しておくと、後から確認する人が必要な設定か判断しやすくなります。
URL Rewriteの構文と適用範囲
URLを書き換える機能であり、ドメイン振り分けではない
URL Rewriteは正規表現でリクエストURLを判定し、設定に従ってURLを書き換えます。Ruleとは目的が異なります。Ruleは処理ポリシーを選び、書き換えは条件に合ったURLの動作を変更します。特定のホストをDIRECTまたはPROXYで処理したいだけなら、書き換えセクションを追加しないでください。あるアクセスURLを別のURLへ向ける明確な必要があり、アプリがそのリクエストをどのように処理するか理解している場合にのみ、ルールを設定してください。
[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302この例は、指定ホストのHTTPアドレスにマッチし、キャプチャした内容からHTTPSの遷移先を組み立てます。末尾の302はリダイレクトのステータスコードです。マッチ条件、遷移先、ステータスコードはスペースで区切ります。Ruleのカンマ区切り形式とは異なります。これは構成を説明する例であり、そのドメインが実際に対応サービスを提供していることを示すものではありません。あらゆるウェブサイトにそのまま適用できる汎用書き換えルールでもありません。実際の設定は、利用者が明確な権限を持ち、検証可能なアクセス先を対象にしてください。
アンカー、エスケープ、キャプチャグループ
正規表現の先頭にある^はURLの先頭からのマッチを指定し、末尾の$はURLの末尾までのマッチを指定します。ドメイン内のドットは、任意の1文字として解釈されないようバックスラッシュでエスケープします。括弧はキャプチャグループを作り、遷移先の$1は1番目のグループの内容を参照します。ルールを確認するときは、式全体を固定文字列のようにコピーするだけでなく、各記号の意味を確認してください。エスケープやアンカーが1つ足りないだけでも、意図した範囲を超えてマッチすることがあります。
[URL Rewrite]
^http://example\.com/old/(.*)$ https://example.com/new/$1 3022つ目の例は、指定ホストの/old/で始まるパスだけを処理し、それ以外のパスは対象になりません。キャプチャした部分は遷移先の組み立てに使われるため、実際の入力に何が含まれるか確認してください。クエリパラメーター、エンコード文字、末尾のスラッシュによってマッチ結果が変わることがあります。短いURLで試しただけで、すべてのリクエストが正しく処理されると判断しないでください。遷移先にスラッシュが余分に入る、パラメーターが失われる、不正なURLが生成される場合は、プロキシポリシーを変えるのではなく正規表現を調整してください。
リダイレクトによって新しいリクエストが発生する
リダイレクト応答を受けた側は、通常、遷移先のURLへ再度リクエストします。新しいリクエストではホスト、プロトコル、パスが異なる場合があるため、その後のポリシーとサービスの動作も改めて確認してください。元のリクエストがDIRECTでも、新しい接続先がDIRECTになるとは限りません。遷移先のホストが変わる場合は、2つのリクエストでマッチするルールをそれぞれ確認します。デバッグログに複数のリクエストが記録されても、必ずしもエラーではありません。想定どおりの有限で明確なリダイレクトになっているかが重要です。
遷移先を再び同じ条件にマッチするURLにすると、リダイレクトがループするおそれがあります。確認時は元のURL、書き換え後のURL、その遷移先が再び条件に該当するかの3点を列挙してください。範囲の広い正規表現を先に置くと、後ろの特定条件より先に処理されることもあります。範囲の狭い例外を先に置き、検証済みの通常ルールを後に配置してください。正規表現が複雑になったら、入れ子を増やすより、説明しやすい条件に分けるほうがトラブルシューティングしやすくなります。
HTTPSで確認できる情報とアクセス範囲
通常の接続転送では、暗号化されたリクエスト内の完全なパスやヘッダーを直接読み取れません。そのため、HTTPSのパスを対象とする書き換えルールが常に判定できるとは限りません。HTTPSの内容を処理する場合は、アプリ内の関連設定、証明書の信頼、対象範囲を別途理解する必要があります。本ページの簡単な例では、そうした機能を有効にする必要はありません。一般的な接続障害を直すためだけに内容処理の設定を加えると、問題の範囲がルール振り分けから信頼性や互換性に広がるため、避けてください。
利用者が接続先サービスの管理権限を持つ場合も、明確に必要なホストとパスだけを対象にし、元の設定をロールバック用の基準として残してください。書き換えは認証リダイレクト、別ホストへのリクエスト、フォーム送信、サーバー側のURL検証に影響することがあります。まず通常の読み取りリクエストでURLの変化を確認し、その後、実際の業務フローを検証してください。ページを一度表示できただけで、検証完了とは判断しないでください。機密パラメーターを含むURLをテストする場合、記録には必要な部分だけをマスキングして残し、アクセス情報全体を出力しないでください。
保守時は、各書き換えルールの目的、マッチ範囲、取り消し方法を記録してください。動作しなくなった場合は、該当行を一度無効化し、元のURLにアクセスできるか確認してから、サービス側の変更か式の問題かを判断します。Ruleと書き換えを同時に変更すると、どちらの層が結果に影響したか分かりにくくなるため、2段階に分けてテストしてください。ホストの振り分けだけが必要な場合はドメインルールを使います。書き換えが不要な設定には、このセクションを含めなくてもかまいません。構成をそろえるためだけに何もしない設定を追加する必要はありません。
設定の検証、障害の切り分け、ロールバック
理由を説明できるテスト用設定を作る
検証は、項目を次々に追加した複雑なファイルではなく、動作が分かっている状態から始めます。まず、利用者がすでに所有するサーバーで基本接続ができることを確認します。次にコピー上で、必要な共通設定、少数の明確なルール、FINALを1つ残します。今回の検証に関係しないHostや書き換えルールは一時的に外してください。誤りと決めつけるためではなく、変数を減らすためです。基準となる設定が安定したら、同じリクエストを使って1グループずつ戻し、その都度結果を確認してください。
[General]
dns-server = system
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXYこの例では、完全一致のPROXY例外、明示的な拒否、サフィックスに基づくDIRECT、デフォルトのPROXYという4種類の結果を確認できます。ただし、構文説明用の例にすぎません。実際の検証では、利用者にアクセス権があり状態を把握している接続先に置き換えてください。例示ドメインにウェブページがあるかどうかを、クライアントの動作判断に使わないでください。各テスト対象には検証目的を1つだけ持たせ、複数の未知のAPIに同時に依存しないようにします。結果に差があった場合、設定ファイル全体ではなく個別の条件に原因を絞り込めます。
保存しただけでは再テスト済みにならない
保存後、現在のConfig、Global Routing、使用中の接続をもう一度確認します。既存のテストリクエストを終了してから、新しいリクエストを実行してください。既存の長時間接続が以前の経路を使い続けたり、アプリのキャッシュで古い内容が表示されたりすることがあります。画面に変化がないからといって、新しいルールが無効とは限りません。アプリ内の接続情報やログを見る際は、リクエストのホスト、接続先アドレス、マッチ条件、実際の結果を確認し、変更後に生成された記録を見ていることを確かめてください。
| 確認された結果 | 優先して確認する項目 | 次の手順 |
|---|---|---|
| 設定を正常に読み込めない | セクション名、句読点、項目の形式 | 最小限のコピーからセクションごとに戻す |
| 想定したポリシーにならない | モード、選択中のファイル、先行ルールのマッチ | 最初に条件を満たすルールを確認 |
| ポリシーは正しいが接続できない | 接続パラメーター、接続先、ネットワーク | 名前解決と接続可否を個別に検証 |
| アドレスまたはリダイレクトに問題がある | Host、DNS、URL Rewrite | 関連する変更を無効にして比較 |
構文、マッチング、接続の障害を切り分ける
構文の問題では、設定を正常に読み込めない、特定の行が無視される、設定項目が想定どおり認識されないといった症状が現れます。まず半角の句読点、セクションの位置、余分な項目、実際の改行を確認してください。次に、最近追加した内容をコピーから取り除いて比較します。マッチングの問題では、リクエストに異なるポリシーが適用されます。リストの先頭から、最初に条件を満たすルールを確認してください。リクエストにドメイン名やアドレス情報がない場合は、「条件の判定に必要な情報が不足している」ことも独立した原因として確認し、項目名の入力間違いだけを疑わないようにします。
ポリシーが正しいのに接続できない場合は、サーバー、名前解決、接続先サービス、ローカルネットワークを引き続き確認してください。Connectivity Testは接続状況の確認に役立ちますが、1回のテストですべてのプロトコルや実際のリクエストを検証できるわけではありません。すでに利用しているサーバーのパラメーターは、アドレス、ポート、認証、トランスポート関連の設定など、ご自身のサービス情報と項目ごとに照合してください。レイテンシーテストの結果があっても、すべての接続先にアクセスできるとは限りません。1つの接続先で失敗しても、振り分け全体のデフォルトを変更しないでください。
REJECTによる失敗は個別に見分けてください。REJECTにマッチして接続先へアクセスできないのは、そのポリシーの直接的な結果であり、プロキシ接続品質の問題ではありません。拒否が意図しない通信に影響している場合は、マッチ範囲を狭めるか先行する例外を調整し、ページの依存関係を再テストしてください。特にドメインキーワードルールでは、意図しないマッチがないか確認します。修正時は、広いドメイン範囲全体を許可するルールで広すぎる拒否条件を相殺するのではなく、明確なホスト名を使う条件に変更してください。
ロールバックと変更履歴
変更のたびに、発生していた現象、変更した行、結果を確認したリクエストの3点を記録してください。後から再現できる内容にしつつ、実際のサブスクリプションアドレス、認証情報、アクセスログ全体を保存する必要はありません。設定をエクスポートする前に、利用者自身の機密データが含まれていないか確認します。他の人にトラブルシューティング用の設定を見せる場合は、関係するセクションだけを抜き出し、リクエスト条件をマスキングしてください。設定例に記載した値と実際の認証情報は、必ず分けて管理します。
リモート設定やサブスクリプションを更新した後は、どの情報が変わったか確認してから、同じテスト項目を再実行してください。サーバーデータの変更はPROXY接続に、ルールの変更はマッチングに影響する場合があります。2種類の更新結果を混同して結論を出さないでください。更新後に使えなくなった場合は、検証済みのローカルコピーに戻し、選択状態が実際に切り替わったことを確認します。以前のファイルをリストに残しただけではロールバックになりません。復元後に差分を1つずつ特定し、問題のあるファイルへ一時的な修正を積み重ねないでください。
このページでは設定の仕組みを解説しています。初回の読み込み、接続の開始、基本的な動作確認についてはクイックスタートガイドをご覧ください。項目名の簡単な説明は用語ガイドで確認できます。購入、元のアカウントでの復元、App Storeの互換性については購入済みアプリの復元方法をご覧ください。設定の変更で解決する内容ではありません。問題を該当する階層で捉え、最小限の変更で検証することが、読みやすい設定を長く保つ基本です。