Shadowrocket
ルール・設定リファレンス
設定セクションごとに項目を確認し、リクエストの宛先に合わせてルールを選び、マッチング記録で結果を検証します。
このページは、Shadowrocketの設定を体系的に確認するためのマニュアルです。すでにご自身のサブスクリプションまたはサーバー情報があり、ルールを調整したい方を対象としています。初回の読み込み、認証、接続については、まずはじめにの手順を確認してから、各設定項目の役割をこのページでご覧ください。掲載例は個別の知識を説明するもので、サーバーの認証情報を含む完全な接続設定ではありません。
01 / 設定ファイル
設定セクションと適用範囲
サーバー、サブスクリプション、設定ファイルを区別する
サーバー情報には接続先や認証パラメータが保存されます。Subscribeは、登録済みのサブスクリプションと、その中のサーバー情報を管理します。Configの設定ファイルは、解析、ルール、リクエストの処理方法を定義します。三者は関係していますが、互いに置き換えられるものではありません。サブスクリプションの更新に成功しても、現在どのルールファイルを使っているかは判断できません。ルールファイルを読み込んでも、サーバーのアドレス、ポート、認証情報がそろうわけではありません。確認を始める前にHomeで利用可能なサーバー情報があることを確認し、Configで現在選択中のファイルを確認してください。接続情報の問題をルール構文の問題と取り違えずに済みます。
サブスクリプションとルール設定では、更新のタイミングが異なる場合もあります。サブスクリプションの更新は、通常、その内容を更新するものであり、手動で管理しているルールまで同期して変更されるとは限りません。一方、リモート設定の更新によって、以前編集したセクションが変更される場合もあります。編集前にコピーを保存し、リモート由来の内容と自分で管理している内容を記録してください。サブスクリプション情報は利用中のサービス提供元から入手してください。公開する設定のスクリーンショットやテキストには、アカウント情報や個人用リンクを含めないでください。
角括弧でセクションを指定し、項目は所属するセクション内で解釈する
Shadowrocketの設定ファイルは、セクションごとに内容を整理します。[General]には共通設定、[Rule]には順序に沿って照合するルール、[Host]には指定したドメインのアドレス対応、[URL Rewrite]には条件に合うURLの書き換え方法を記述します。セクション名はコメントではないため、自由に翻訳しないでください。また、Ruleに切り替える前のセクションへルールを貼り付けないようにします。以下は基本的な構成例です。それぞれ異なる目的に使うもので、すべての設定ファイルに各項目が必要という意味ではありません。
[General]
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY
[Host]
printer.example.com = 192.168.1.20
[URL Rewrite]
^http://example\.com/ https://example.com/ 302例を読むときは、セクションの境界とルールの順序を分けて考えます。GeneralはRuleのように、ドメインごとのポリシーを一つずつ決めるものではありません。Hostのアドレス対応も、DIRECTを指定するルールではありません。ドメインをLAN内のアドレスに対応させた場合も、そのリクエストが最終的にどのルールに一致するかを確認してください。「名前の解決先」「ポリシーの選択」「接続の確立」という3つの観点で見ると、ファイルにドメインが記載されているかだけを見るより、実際の動作を判断しやすくなります。
編集・保存・選択はそれぞれ別の操作
Configで編集したら、まず保存を完了し、使用する予定のファイルが保存されたことを確認します。元のファイルとテスト用コピーを両方残す場合は、用途を判別できる名前を付け、一覧での位置だけで判断しないようにしてください。次に、Global RoutingがConfigになっていることを確認します。ProxyまたはDirectのままでは、Ruleの振り分け結果を想定どおりに検証できません。テストではリクエストを新たに発行してください。必要に応じて既存の接続を終了してから対象のページを開きます。確立済みの接続は、テキストを保存しただけでは最初からルール照合をやり直しません。
出所が明確な既存設定は、すべてのセクションを削除して組み直すのではなく、必要な箇所だけ変更してください。共通項目は連携して動作する場合があり、1行削除しただけでDNS、LANへのアクセス、接続方法に影響することがあります。内容を説明できない項目は残し、アプリ内の該当する説明を確認してください。検証可能な条件を一度に1つだけ変更し、テストに成功してから次に進みます。問題が起きたときは、例外ルールを追加し続けるよりコピーから復元するほうが、原因を特定しやすくなります。
02 / 共通設定
General、Global Routing、DNS
ルーティングモードによってルールの適用有無が決まる
ルールを調べる前に、まずGlobal Routingを確認してください。Configは現在の設定ファイルに従ってポリシーを選択します。Proxyはクライアントが処理するリクエストに現在のプロキシ選択を適用し、Directは直接接続する方向で処理します。これは異なる処理モードであり、同じルールファイル内の3つの優先順位ではありません。Proxyでは接続できてConfigでは失敗する場合、サーバーが直ちに無効だと判断せず、実際に一致したルールを確認してください。逆に、Directでアクセスできても、プロキシ経由で接続できることの証明にはなりません。
| 画面上の項目 | 確認するポイント | 検証できる内容 |
|---|---|---|
| Config | 現在の設定と最初に一致するルール | 特定の宛先にそのポリシーが適用される理由 |
| Proxy | 現在のプロキシ選択と接続パラメータ | 同じリクエストをプロキシ経由で処理できるか |
| Direct | ローカルネットワークと宛先への到達性 | 直接接続に必要な条件がそろっているか |
ここでいう「クライアントが処理する」ことが重要な境界です。アプリ外のシステム動作、既存の接続、設定内の特殊な処理条件が、実際に観測されるリクエストに影響します。モードを切り替えた後は、同じ宛先に同じ方法でリクエストを再送してテストしてください。Webページへのアクセスとアプリのバックグラウンド接続を比較することはできません。切り替え方法を順に確認するには、Global RoutingのConfig、Proxy、Directの説明を参照し、このページのルール解説を使って一致結果を確認してください。
Generalは共通条件を設定するセクションで、ルールの優先順位を切り替えるものではない
Generalでよく使われる項目は key = value の形式です。利用可能なオプションはアプリ内の設定エディタと説明で確認してください。別の構文体系で使われる同名の項目を、そのままファイルに移さないでください。項目名が似ていても同じ意味とは限りません。以下は最小限のDNS例です。systemはシステムが提供する名前解決設定を使うという意味で、特定のDNSサーバーアドレスを固定で記述するものではありません。DNSを変更する前に、問題が名前解決の段階か接続確立の段階かを確認してください。
[General]
dns-server = system
[Rule]
DOMAIN,api.example.org,DIRECT
FINAL,PROXYDNSは名前をアドレスに解決し、ポリシーはリクエストをどの経路で処理するかを決めます。両者は連携しますが、同じものではありません。ドメインがDIRECTに一致していても、名前解決に失敗する場合があります。アドレスを取得できても、プロキシ認証、宛先ポート、リモート接続の問題で失敗することがあります。切り分けでは、まずドメインと名前解決結果を確認し、次に一致したルールと接続エラーを見てください。「DNSを切り替えたら一時的に直った」という現象だけで、すべてのルールが正しいとは判断できません。
アドレスルールによって名前解決が必要になる場合がある
ドメイン名でリクエストを開始し、その後のルールで宛先IPやGEOIPを判定する場合、照合に先立ってアドレスの取得が必要になることがあります。この名前解決は所要時間に影響するほか、ログに対象リクエストに関連するDNS記録が表示される原因にもなります。アドレスルールをドメインルールより前に多数置くと、本来ドメインだけで判断できるリクエストにも、追加のアドレス判定が必要になることがあります。通常は、明確なドメイン例外を先に置き、次にアドレス情報が必要な範囲ルールを配置すると、設定の意図が分かりやすくなります。
アドレスルールの no-resolve は、そのルールのためにドメインを積極的に名前解決しないようにするオプションです。すべてのDNSを停止するスイッチではありません。リクエストに宛先IPがすでに含まれていれば、アドレス照合の対象になります。一方、ドメイン名しかなく利用可能なアドレスがないリクエストは、後続のルールに進む場合があります。有効にしたら、ドメイン名で開始するリクエストとIPで開始するリクエストを別々にテストしてください。片方だけのテストでは不十分です。具体的な記述方法はアドレスの章を参照してください。ログを1件減らすために、すべてのIPルールへ安易にこのオプションを追加しないでください。
IPv4とIPv6の実際の接続先も区別する必要があります。同じドメインから複数のアドレスが返されることがあり、アプリが選ぶアドレスは手動で調べたときの先頭のアドレスとは限りません。IPv4のプライベートアドレス範囲だけを対象にしたルールで、すべてのIPv6ケースまで自動的に網羅できるわけではありません。「同じドメインなのに経路が変わる」場合は、実際の宛先アドレス、名前解決キャッシュ、接続の再利用を確認し、必要に応じてもう一方のアドレスファミリーのルールを検討してください。観測条件を記録しておくことで、再現可能な結論を得られます。
03 / ドメイン名の照合
DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD
DOMAIN：特定のホスト名だけに適用
DOMAINは完全一致でドメイン名を照合します。API、ログイン先、サービス用ホストなどに個別のポリシーを設定する場合に適しています。たとえば DOMAIN,api.example.org,DIRECT はapi.example.orgに適用され、example.org本体やstatic.example.orgには適用されません。入力するのはホスト名だけです。プロトコル、ポート、パス、クエリパラメータは付けないでください。特定のURLを処理したい場合は、ホスト全体のルーティングが必要なのか、後述するURL Rewriteが必要なのかを先に確認してください。
[Rule]
DOMAIN,api.example.org,DIRECT
DOMAIN,static.example.org,PROXY
FINAL,PROXYブラウザーのアドレスバーに表示されるホスト名だけでは、ページ上のリクエスト全体を網羅できないことがあります。ページが別の画像、スクリプト、ログイン先、APIのホストを読み込む場合があり、メイン文書がDIRECTになっていても、それらもDIRECTになるとは限りません。ルールの検証では、ログに記録された実際のリクエストドメインを確認してください。ページ本体は表示されるのにログインやリソースの読み込みに失敗する場合は、エラーが発生しているホストを一つずつ確認します。無関係なサービスまで含む可能性のあるキーワードに、いきなり範囲を広げないでください。
DOMAIN-SUFFIX：ドメイン階層に基づいて複数のホストに適用
DOMAIN-SUFFIXはドメインのサフィックス（末尾）で照合します。example.comを指定すると、通常はexample.com本体のほか、www.example.comやimg.example.comなどのサブドメインも対象になります。これはドメイン階層に基づくサフィックス判定で、任意の文字列を含むかどうかの判定ではありません。notexample.comは同じドメインのサブドメインとして扱われません。同じサービスのドメインとその配下のホストに共通のポリシーを適用し、一部のホストだけを先行するDOMAINルールで個別に処理する場合に適しています。
[Rule]
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTこの例では、local.example.comは先に完全一致のルールに一致し、example.comに属するほかのホストは後続のサフィックスルールで処理されます。2行の順序を入れ替えても、名前がより具体的だからといって完全一致のルールが自動的に優先されるわけではありません。また、サービスが使用するコンテンツ配信ドメインは、サービス自身のメインドメイン配下にない場合があります。サフィックスを1つ追加するだけですべてのリソースが同じポリシーになるとは限りません。ブランド名からドメイン群を推測せず、実際のリクエストを確認して追加してください。
DOMAIN-KEYWORD：手軽だが範囲を絞りにくい
DOMAIN-KEYWORDは、ドメイン名に指定したキーワードが含まれるかどうかで照合します。異なる名前空間にまたがって共通の特徴を処理する必要がある場合に便利です。ただし、サフィックスより範囲が広くなります。たとえばexampleを指定すると、example.comだけでなく、その文字列を含む別のドメインにも一致する場合があります。短すぎる語、一般的すぎる語、意味が曖昧な語を、広範囲の振り分け条件に使うのは避けてください。特定のホストやメインドメインが分かっている場合は、DOMAINまたはDOMAIN-SUFFIXを優先すると、ルールの適用範囲を説明しやすくなります。
| 種類 | 指定例 | 適用範囲 |
|---|---|---|
| DOMAIN | api.example.org | 完全なホスト名 |
| DOMAIN-SUFFIX | example.org | メインドメインとそのサブドメイン |
| DOMAIN-KEYWORD | example | ドメイン名にキーワードを含む |
ドメインルールは、照合時にクライアントが宛先名を取得できることが前提です。アプリがIPアドレスへ直接接続する場合や、現在のリクエスト記録にアドレスしかなく利用可能なドメイン名がない場合は、ドメインルールを増やしても効果がないことがあります。ログに判定可能な情報があるかを先に確認し、ドメインルールとアドレスルールのどちらを使うか決めてください。「このWebサイトにアクセスしている」という利用者側の説明だけで、すべての接続にそのサイトの完全なドメイン名が含まれると考えないでください。
ドメインルールを管理するときは、リダイレクトとキャッシュにも注意してください。入力したアドレスが別のホストへ転送されることがあり、ブラウザーが以前の接続を再利用する場合もあります。変更後は対象を開き直し、新しいリクエストを観察してください。まだ判断できない場合は、可能な範囲で古い接続を終了して再テストします。国際化ドメイン名を使う場合は、クライアントに実際に記録された名前の形式を確認し、表示名、エンコード形式、URLパスを同じ照合パラメータとして扱わないようにしてください。
04 / アドレスとリクエストの特徴
IP-CIDR、GEOIP、USER-AGENT、FINAL
IP-CIDRとIP-CIDR6：宛先アドレスの範囲を照合
IP-CIDRは、アドレスとプレフィックス長でIPv4ネットワークの範囲を指定します。192.168.0.0/16は該当するプライベートアドレス範囲を対象にし、192.168.1.20/32は1つのIPv4アドレスだけを表します。プレフィックスが長いほど範囲は狭くなりますが、この「より具体的」という性質はアドレス集合を表すもので、ルールの順序を変えるものではありません。IP-CIDR6はIPv6用で、たとえばfd00::/8は該当するローカルアドレス範囲を表します。プレフィックスを誤ると、意図した範囲を大きく超えて適用されることがあります。
[Rule]
IP-CIDR,192.168.1.20/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,fd00::/8,DIRECT,no-resolve
FINAL,PROXY上記の例は一部のアドレス範囲を示すだけで、LAN向けの処理を網羅する一覧ではありません。DIRECTはプロキシサーバーを経由せずに送信する指定であり、接続先機器が稼働中であること、経路があること、アクセス権限があることを保証しません。プリンターやローカルサービスにアクセスできない場合は、機器のアドレスが変わっていないか、現在のネットワークで機器間通信が許可されているか、必要なシステム権限があるかを確認してください。ルールに一致したというだけで、その後のすべてのエラーをアプリの問題と判断しないでください。
no-resolveは任意で追加できる照合オプションで、そのアドレス判定のためにドメイン名を積極的に解決しないことを意味します。リクエストに宛先アドレスが含まれていれば一致する場合があります。ドメイン名しかなく、適用可能なアドレス情報がない場合は、後続のルールに進むことがあります。LAN内のサービスにドメイン名でアクセスする場合、このオプション付きのプライベートアドレスルールだけでは、期待どおりに動かない可能性があります。既知のホストをDOMAINで個別に指定してから、必要に応じてアドレス範囲のルールを併用してください。
GEOIP：アドレスデータベースに基づく地域判定
GEOIP,CN,DIRECTは、使用中のデータベースで宛先アドレスがCNに分類された場合にDIRECTを適用する指定です。ドメインのサフィックスを判定するものでも、Webページの言語、アカウントの地域、サービスの運営者を識別するものでもありません。中国語のページが別の地域のインフラを使う場合もあり、同じドメインでも名前解決の条件によって異なるアドレスが返ることがあります。GEOIPは広範囲のアドレスを分類する条件として使い、サービスごとに必要なドメイン例外の代わりにしないでください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYアドレスデータベースの地域判定と、実際の通信経路で接続できるかどうかは別の問題です。ある地域に分類されても、直接接続が速いとは限らず、接続成功も保証されません。ネットワークによって観測される宛先アドレスが変わることもあります。切り分けでは、実際の宛先IP、一致したルール、エラーの種類を記録してください。特定のサービスに決まったポリシーを適用する必要がある場合は、結果が一度想定と違っただけでGEOIPルール全体を置き換えるのではなく、対象範囲を説明できるドメインルールを追加してください。
USER-AGENT：リクエストの特徴を取得できる場合にのみ有効
USER-AGENTは、取得可能なUser-Agentの特徴に基づいて照合します。たとえば USER-AGENT,ExampleApp*,DIRECTでは、アスタリスクを該当するワイルドカードとして指定します。アプリ名やプロセスを識別して通信を振り分ける機能とは異なり、暗号化されたすべての接続からこの情報を取得できるとも限りません。通常のHTTPS接続ではヘッダーが暗号化された内容に含まれるため、クライアントが取得できない場合があります。このルールは条件が明確な場合の補助として使い、特定のアプリのすべてのリクエストを同じ経路に振り分けられると考えないでください。
FINAL：ほかのルールに一致しないリクエストの処理を指定
FINALにはドメインやアドレスのパラメータは不要で、形式は FINAL,PROXYまたはFINAL,DIRECTです。マッチングリストの末尾に置き、それ以前の条件に一致しなかった場合の処理を指定します。途中に置くと、通常は後続のルールが照合されなくなります。フォールバックポリシーは、設定の目的に合わせて選んでください。PROXYには利用可能なプロキシが必要で、DIRECTにはローカルネットワークからの直接アクセスが必要です。どちらも接続成功を保証するものではありません。
これらのルールを組み合わせるときは、リクエストにどのような確かな情報があるかを先に確認してください。ドメイン名が分かる場合はドメインで意図を示し、アドレス範囲が必要な場合にCIDRを使います。地域判定はより広い条件として配置し、最後にFINALで締めくくります。USER-AGENTなど、リクエスト情報を取得できることが前提のルールでは、その情報が得られない場合の処理も用意してください。こうすることで、「一致した場合の処理」だけでなく、「一致しなかった場合の行き先」も明確になります。
05 / ポリシーの結果
PROXY、DIRECT、REJECT、Proxy Group
ポリシーは処理の方向を示すもので、接続可能かどうかの結論ではない
ルールの最後の主要項目には、通常、処理ポリシーを指定します。PROXYはプロキシ経由、DIRECTは直接送信、REJECTは該当するリクエストの拒否を意味します。これらの名称が示すのはクライアントの処理方法であり、宛先が正常かどうかではありません。ログにPROXYと表示されても、該当する処理経路に入ったことが分かるだけです。その後、サーバー認証、リモート接続、宛先サービスの問題で失敗する場合があります。DIRECTと表示されても、システムのネットワーク条件すべてを回避できるわけではなく、ローカルネットワークや宛先の状態に左右されます。
| ポリシー | 処理内容 | 続けて確認する項目 |
|---|---|---|
PROXY | 現在のプロキシ経由で処理 | 実際に選択されたサーバーと接続パラメータ |
DIRECT | プロキシサーバーを経由せずに送信 | ローカルネットワーク、名前解決、宛先への到達性 |
REJECT | 条件に一致するリクエストを拒否 | 拒否範囲に必要な依存先が含まれていないか |
この点を理解しておくと、変更する場所を誤って何度も修正する事態を避けられます。対象のDOMAINに正しく一致してPROXYが適用されているのに認証エラーが出る場合は、DOMAINをDOMAIN-SUFFIXに変えるのではなく、まず既存のサーバー情報を確認してください。一方、ログで対象が先行するDIRECTルールに処理されている場合は、プロキシが利用可能でも、まずルールの範囲や順序を修正する必要があります。ポリシー選択が正しいことを確認してから、そのポリシーで接続できるかを判断してください。
PROXYとカスタムグループの関係
PROXYは組み込みのポリシー名であり、手動で作成する必要があるサーバー名ではありません。カスタムProxy Groupを使う設定では、定義済みのグループ名をルールで参照し、宛先ごとに異なる選択肢へ振り分けることもできます。参照する前に、グループが実際に定義され、グループ内のメンバーを現在の設定で認識できることを確認してください。スペル、スペース、名称は定義と一致させます。ルールの末尾に新しい名前を書いただけでは、サーバーを含む利用可能なグループは作成されません。
[Rule]
DOMAIN,api.example.org,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,blocked.example.org,REJECT
FINAL,PROXY上記の例では、未定義のグループへの依存を避けるため、組み込みポリシーだけを使っています。既存の設定でカスタムグループを使用している場合は、もう1段階確認します。まずリクエストがどのグループに入ったかを確認し、次にそのグループが最終的にどのメンバーを選んだかを確認してください。グループ名が正しくてもメンバーが利用できない場合と、ルールに一致していない場合は別の問題です。自動選択タイプのグループはネットワーク条件の変化で選択メンバーが変わることもあります。比較テストでは、グループの表示名だけでなく、実際に使用されたサーバーも記録してください。
DIRECTとREJECTは対象範囲を考慮して使う
DIRECTは、既知のLAN内ホストなど、ローカルネットワーク経由が明確に必要なリクエストに使います。サービスが「ローカルらしい」という理由だけで広範囲を直接接続にせず、実際のドメインと依存先を確認してください。REJECTは明確に停止したいリクエストに適していますが、範囲が広すぎるとログイン、リソースの読み込み、基本機能に影響する可能性があります。拒否範囲を説明可能なホストに絞ってログで検証すると、意味が曖昧なキーワードを使うより制御しやすくなります。
宛先が拒否されたときのアプリの動作は一様ではありません。すぐにエラーを表示するページもあれば、アプリが何度も再試行する場合や、画面が待機中のままになる場合もあります。こうした現象だけでプロキシサーバーの故障とは判断できません。REJECTを追加した後に問題が起きたら、まずそのルールを戻し、同じ操作を再実行して関連リクエストが復旧するかを比較してください。そのうえで範囲を絞るか判断します。拒否ルールの後に同じ宛先のDIRECTを追加しても、前のルールを自動的に上書きすることはできません。順序を変えない限り、後のルールは照合されません。
クライアントの購入と接続サービスは別々に管理
ShadowrocketはAppleプラットフォーム向けの有料クライアントです。クライアントの買い切り購入 ≠ 接続サービスのプラン。ルールにPROXYと記述しても、新しいサーバーが作成されたり、サブスクリプション情報が補われたりすることはありません。既存のサブスクリプションは利用中のサービス提供元から入手し、認証情報や有効期限も提供元が管理します。アプリの入手先を確認するには、App Storeで正規版を確認する方法をご覧ください。アプリの購入と接続情報の準備は別々に確認し、App Storeでの決済が完了したことを接続設定の完了と混同しないでください。
グループやポリシーを管理するときは、シンプルで説明しやすい基準を保つことをおすすめします。まず組み込みポリシーで接続経路を確認してからグループを導入し、まず個別のメンバーを検証してから自動選択の動作を評価します。こうすると、エラーが起きても段階ごとに戻せます。ルール、グループ名、メンバー、接続パラメータの4つの変数を同時に調べる必要がありません。初回接続がまだ完了していない場合は、複雑なポリシー構成を作る前に、はじめにの手順に戻ってください。
06 / 優先順位
上から順に照合し、最初に一致したルールを適用
「より具体的なルールが自動的に優先」はしない
Ruleはファイルに記載された順番で照合されます。対象がある条件に一致すると、そのルールで指定されたポリシーが適用され、後続の通常ルールで再選択されることはありません。DOMAINがDOMAIN-SUFFIXより自動的に優先されることはなく、単一アドレスのルールが大きなネットワーク範囲より自動的に優先されることもありません。REJECTも、意味が強そうだからといって自動的に優先されるわけではありません。優先順位を決めるのは、まず設定ファイル内の位置です。この原則を理解すると、「ルールを書いたのに効かない」現象の多くは、前に一致するルールを探すことで説明できます。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYapi.example.comは1行目でDIRECTになります。www.example.comは1行目に一致せず、2行目でPROXYになります。それ以外のドメインはGEOIPを確認し、最後にFINALが適用されます。これは明確な停止点がある判定の流れであり、一致したルールすべてに点数を付ける仕組みではありません。www.example.comの名前解決結果が後続のGEOIPに一致しても、先行するサフィックスルールでポリシーが決まっているため、DIRECTに切り替わることはありません。
順序の競合を反例で確認する
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,api.example.com,DIRECT
FINAL,PROXYこの反例では、api.example.comは先にサフィックスルールに処理されるため、下にある完全一致のルールでは例外を実現できません。修正するには、同じルールを末尾にコピーするのではなく、完全一致の例外を範囲ルールより前に移動します。同じ条件のルールが複数ある場合、通常は先にあるルールが結果を決めます。重複した項目は読みづらさを増し、後から追加した内容で古い設定を上書きできたと誤解させることもあります。整理するときは重複と範囲の重なりを確認してください。
個別の例外、サービス範囲、広い分類の順に配置
管理しやすい構成の一例は、明確な許可・拒否の例外、サービスのドメイン範囲、宛先アドレスと地域の判定、最後にFINALという順です。これはアプリが強制する固定テンプレートではなく、ルールの意図を読みやすくする方法です。サービスの要件が異なる場合は順序を変えてもかまいませんが、各ルールを直前のルールより上に置く必要がある理由を説明できるようにしてください。「見た目を整える」ためにRule全体をアルファベット順に並べ替えると、既存の優先順位が変わる可能性があります。
例外どうしの範囲が重なる場合もあります。特定のメインドメインにはPROXYを適用し、その中のあるAPIにはDIRECTを、別のホストにはREJECTを適用するなら、2つの個別ホストルールをメインドメインのサフィックスルールより前に置きます。同じ文字列を含むDOMAIN-KEYWORDを追加する場合は、既存の例外より先に一致しないか確認してください。確認時は個々のルールが正しいかだけでなく、上にある広い条件と、下にある一致できなくなるルールについても調べてください。
設定更新後は現在のルール一覧を再確認
リモート設定の更新によって、ルールの順序が変わったり、ローカルの変更が削除されたり、新しい範囲ルールが追加されたりすることがあります。更新に成功したことは、内容を取得できたことを示すだけで、これまでの個別設定が保持されたことを保証しません。更新後は、重要な例外、末尾のFINAL、カスタムグループの参照を確認し、よく使う宛先を実際にテストしてください。個別の例外を長期的に管理する必要がある場合は、安定して管理できる方法を選び、変更内容を記録しておきます。更新のたびに記憶を頼りに差分を探し直す運用は避けてください。
順序の問題を特定するときは、まずリクエストの想定される判定過程を書き出します。対象名は何か、アドレス情報があるか、最初に一致する可能性があるルールはどれか、想定するポリシーは何かを確認してください。その後、この流れをログの結果と一つずつ照合します。結果が異なる場合は、まず誤ったファイルを使っていないか、Global RoutingがConfigか、新しい接続を観察しているかを確認します。これらの基本条件が一致してから、キーワードごとの照合範囲を調べてください。
パフォーマンスと読みやすさの両立も大切です。正確なドメインルールを、名前解決が必要なアドレス判定より前に配置すると、不要な判定への依存を減らせることがあります。ただし、行数を減らすために複数の明確な対象を広範囲なキーワードにまとめないでください。説明でき、再現可能な動作を優先し、実際に重複している内容だけを整理します。短くても範囲を説明できないファイルより、少し長くても役割が明確なファイルのほうが管理しやすい場合があります。
07 / 名前解決と書き換え
HostとURL Rewriteの役割の違い
Hostはアドレスの対応を変更し、ポリシーは選択しない
Hostは、printer.example.comを現在のネットワーク上の機器に割り当てるなど、ドメイン名に対応するアドレスを明示的に指定します。「この名前はどのアドレスを指すか」を解決するもので、「このリクエストをどの経路にするか」を決めるものではありません。そのためHostとRuleを併用する必要がある場合もあります。Hostで宛先アドレスを指定し、Ruleで処理の方向を決めます。対応先を追加しても、そのLAN内アドレスに適さないプロキシ経路を使い続けていれば、アクセスに失敗することがあります。
[Host]
printer.example.com = 192.168.1.20
[Rule]
DOMAIN,printer.example.com,DIRECT
FINAL,PROXYこの例では、2つの目的を別々に記述しています。名前を指定した機器のアドレスに対応させ、その名前へのリクエストにはDIRECTを適用します。実際に使う前に、機器のアドレスが安定していること、サービスのポートが正しいこと、ローカルネットワークでアクセスできることを確認してください。別のネットワークに移動すると、同じプライベートアドレスが別の機器を指す場合や、機器が存在しない場合があります。LAN内のアドレス対応を、あらゆるネットワークで使える汎用設定として扱わないでください。機器や環境を変更する場合は、アドレス対応とルールの両方を確認します。
固定アドレスを指定すると、サービスが本来利用する動的な名前解決結果も変わります。公開サービスは、DNSによって接続先アドレスや地域を変更することがあります。特定のアドレスを長期間固定すると、時間が経ってから動作しなくなる可能性があります。HTTPSでは、指定したアドレスに接続しても、証明書は引き続きリクエストのホスト名に対して検証されます。アドレスを指定したからといって、別の名前に証明書が適合するわけではありません。証明書エラーが発生した場合は、Hostの項目を追加し続けるのではなく、宛先サービスと名前が実際に対応しているかを確認してください。
URL RewriteはURLに一致させるもので、ドメインのルーティングではない
URL Rewriteは、指定した式に一致するURLを書き換えたり、リダイレクトしたりする機能です。カンマ区切りのRuleとは構文が異なり、通常はマッチング式、置換先、処理方法を指定します。以下の例では、指定したホストのHTTPアドレスをHTTPSへリダイレクトし、ステータスコードに302を使います。これは条件を限定した例です。すべてのサイトに適用すると、同じHTTPSのパスやサービスが提供されているとは限らないため、範囲を広げないでください。
[URL Rewrite]
^http://example\.com/ https://example.com/ 302式の先頭の ^ はURLの開始位置から照合することを示します。ドメイン名のピリオドは \. と記述し、正規表現における任意の1文字ではなく、文字としてのピリオドを表します。ドメインの後ろのスラッシュもホストの範囲を明確にします。必要な条件を省略すると、example.comだけを処理するつもりの式が、別の文字列に一致することがあります。式を作るときは、一致するURLと一致しないURLの両方を用意し、範囲が想定を超えていないことを確認してください。
パスを維持するには、キャプチャ範囲を明確に指定
[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302ここではキャプチャグループでスラッシュ以降を保存し、置換先に $1 を指定して、後続のパスと一致したクエリ部分を保持します。これは前の固定の置換先を使う例とは別の方法で、両方を判断なく同時に残すものではありません。ログイン状態、署名、機密性の高いクエリパラメータを含むURLには特に注意してください。書き換えによってサーバー側の検証に失敗したり、リクエスト本来の意味が変わったりする可能性があります。自分で検証できる対象でテストしてから、適用範囲を決めてください。
リダイレクトループが発生しないかも確認してください。元のアドレスから新しいアドレスに移動した後、別のルールで元に戻されると、リダイレクトが繰り返されることがあります。ループを防ぐには、旧プロトコルや旧パスに範囲を絞り、置換後のURLが同じ条件に再び一致しないようにします。デバッグでは最終的にページが開くかだけでなく、リダイレクト先を順に確認してください。キャッシュされた古いリダイレクトがテストを妨げる場合もあるため、必要に応じて新しいリクエスト条件で再検証します。
暗号化された情報を取得できるかどうかで書き換えの可否が決まる
通常のHTTPS接続ではURLのパス全体が暗号化されているため、ドメインが見えていても、その中の任意のパスをクライアントが照合できるとは限りません。HTTPSの内容を処理する機能には追加条件があり、信頼設定にも影響します。URL Rewriteを1つ追加するだけで自動的に動作するものではありません。このページでは、システムの信頼設定の変更を通常の振り分け手順として案内していません。特定のホストをPROXYまたはDIRECTで処理したいだけなら、Ruleに戻ってドメインルールで指定してください。コンテンツの書き換えを使う必要はありません。
これら2つのセクションを管理するときは、必要な項目だけを残し、それぞれの目的を明確にしてください。使わなくなった一時的なアドレス対応、範囲の広すぎる書き換え式、不要なリダイレクトは、トラブルの切り分けを難しくします。削除前にコピーを保存し、削除後は影響を受ける宛先を再テストしてください。ページが1つ開かないだけなら、まずリクエスト、名前解決、ポリシーの証拠を確認します。Hostと書き換えルールを同時に追加して、互いに影響する複数の変更に問題を広げないでください。
08 / 検証とメンテナンス
Logsで問題を特定し、コピーから設定を復元
再現可能な観測条件を整える
検証を始める前に、現在のネットワーク、Global Routing、選択中の設定ファイル、実際に選択されているプロキシを記録します。次に、ページを開く、APIにリクエストするなど、対象と操作を具体的に1つ決めてください。「アプリ全体が使えない」といった曖昧な条件では検証できません。Connectivity Testは接続条件を確認する補助になりますが、1回成功しただけで実際のリクエストを検証したことにはなりません。プロキシ接続の確立、ドメインの名前解決、対象APIの応答は、それぞれ別に確認する必要があります。
テスト中は、ほかの条件をできるだけ変えないでください。ネットワークを切り替え、サーバーを変更し、DNSとルールも同時に変更すると、改善してもどの変更が効果をもたらしたか判断できません。ルールを保存したらリクエストを再実行し、接続の再利用やキャッシュに注意します。必要な場合は、現在の処理を安全に終了できることを確認してから接続を再確立してください。特定のネットワークでだけ発生する問題は、各ネットワークでの結果を別々に記録し、1回成功したからといって以前の失敗を無視しないでください。
「リクエスト・ルール一致・接続」の順にログを確認
Logsに表示される具体的な項目は、アプリ内の表示に従ってください。まずリクエストの宛先を探し、今回テストしたホストであることを確認します。次に適用されたポリシーと、確認できるルール情報を調べ、最後に接続エラーや応答の状態を見ます。記録にIPしかない場合は、すぐにドメインルールの不具合と判断せず、リクエストから利用可能な名前を取得できるか確認してください。REJECTに一致したことが明確なら、サーバーのポートを調整するのではなく、まず拒否ルールの範囲を見直します。
| 観測結果 | 優先して確認 | 同時に変更しない項目 |
|---|---|---|
| 該当する新しいリクエストがない | テスト操作、既存の接続、クライアントの処理範囲 | ルールリスト全体 |
| 想定外のポリシーに一致 | Global Routing、現在の設定ファイル、上位のルール | サーバーの認証パラメータ |
| ポリシーは正しいが接続できない | 名前解決、認証、宛先アドレス、到達性 | 正しいことを確認済みのマッチング範囲 |
| 更新後に動作が変わった | 設定の差分、グループ参照、最終フォールバック | すべてのネットワーク設定 |
「名前解決に失敗する」場合は、記録からアドレスを取得できているかを確認し、GeneralとHostの関連設定を調べます。「接続がタイムアウトする」場合は、プロキシ経由の接続が確立できないのか、宛先サービスが応答しないのかを切り分けます。「認証に失敗する」場合は、既存のサーバー情報がそろっているかを確認します。異なるエラーに同じ万能な対処法を使わないでください。1つの記録だけで判断できない場合は、時刻を基準に前後の名前解決と接続の記録を照合できます。ただし、同じ時刻のすべてのバックグラウンドリクエストを今回のテストに関連付けないでください。
最小構成に絞り、項目を一つずつ戻す
複雑な設定はコピーを使って項目を減らし、原因を特定できます。ただし、減らすときは接続に必要な既存情報を残してください。まず対象に関係のない一時的な書き換えとアドレス対応を削除し、完全一致のドメインルール1つとFINALで判定を明確にします。最小構成のコピーで期待どおりに動作したら、元の項目を何回かに分けて戻し、その都度同じ宛先を再テストします。これにより、完全なファイルに修正を追加し続けるのではなく、どの項目群が結果を変えたかを特定できます。
[Rule]
DOMAIN,api.example.org,DIRECT
FINAL,PROXYこの例はルール選択の検証用であり、バックアップしていない完全な設定ファイルに上書きしないでください。api.example.orgにはDIRECTが適用され、それ以外で一致しないリクエストにはPROXYが適用される想定です。結果がまだ異なる場合は、コピーが選択されているか、Configになっているか、記録が新しいリクエストのものかを確認します。想定どおりでも宛先に接続できない場合は、ルールのキーワードをさらに広げるのではなく、接続経路を確認してください。
変更履歴とプライバシーに配慮して管理
変更ごとに、対象、関連する項目、想定結果、実際の結果、復元方法を簡潔に記録してください。設定をエクスポートするときは、サーバーアドレス、認証情報、個人用サブスクリプションリンク、機密性のあるHostの対応が含まれていないか確認します。共有する場合は、個人情報を取り除いた必要最小限の断片だけを使用してください。ログにアクセス先やクエリ情報が含まれることもあるため、問題の説明に必要な内容だけを残します。読み込みや接続に関するよくある質問はFAQをご覧ください。初めて操作する場合ははじめにに戻ってください。
機種変更の前に、アプリの入手、サーバー情報、設定ファイルの復元方法をそれぞれ確認してください。App Storeからアプリを再入手しても、個人設定がすべて自動的に復元されるとは限りません。システム要件と購入の適用範囲は、App Storeページの記載をご確認ください。設定の移行については設定のバックアップと機種変更時の復元方法を参照してください。復元後はファイルと認証情報を確認し、重要なルールを再テストします。ファイル名が同じというだけで内容まで一致すると判断しないでください。
メンテナンスの完了は「変更がなくなった」ことではありません。重要な宛先が想定どおりにルールに一致し、一致しないリクエストには明確なフォールバックがあり、設定内の例外それぞれに説明できる目的があり、問題時には利用可能なコピーに戻せることが基準です。ルールの選択と接続結果を分けて検証し、リモートの内容と個別の変更を分けて管理しておけば、ネットワーク環境の変化や設定更新後も同じ観測手順で切り分けを続けられます。