公式マニュアル / 設定ガイド

Shadowrocket
ルールと設定のリファレンス

現在の設定とGlobal Routingを確認し、「マッチ条件 → ルールの順序 → ポリシー」の順にリクエストの処理先を確認します。

章一覧を見る 使い方ガイドを見る

このページは、Shadowrocket公式マニュアルの設定リファレンスです。設定の編集、ルールによる振り分けの確認、問題の原因調査に役立ちます。既存のサブスクリプションの追加、VPN構成の許可、接続の確立については、まず使い方ガイドをご覧ください。基本操作のあと、このページで各ルールの動作を確認できます。Shadowrocketは主にiPhoneとiPadで利用できます。システム要件はApp Storeの掲載内容をご確認ください。

事前に、ご自身のサブスクリプションまたはサーバー情報をご用意ください。クライアントの買い切り購入と接続サービスの契約は別です。当サイトでは接続先やサブスクリプションを提供・販売・推奨していません。アプリの入手方法と正規購入の確認は、App Storeでのダウンロード方法をご覧ください。本文の例は構文と適用範囲の説明用です。使用中の設定全体をそのまま置き換えないでください。

01 / ファイルと適用範囲

設定ファイルの構成と適用条件

サーバー情報と設定ファイルを区別する

サーバー情報は、既存のどの接続先を使うかを決めます。設定ファイルは、どの条件のリクエストにどの処理を適用するかを決めます。両者には関係がありますが、同じものではありません。サブスクリプションを追加すると、HomeのSERVER一覧に項目が表示されることがあります。しかし、Configで適切な振り分け設定が選択されているとは限りません。反対に、PROXYを指定したルールがあっても、サーバーアドレス、ポート、認証情報が自動で補われるわけではありません。接続を確認する際は、使用中のサーバーと選択中の設定をそれぞれ確認してください。一覧の更新をルールの更新と取り違えないようにしましょう。

.confは設定テキストをまとめるファイル形式です。まず角括弧で囲まれたセクション名を確認し、次に各セクションの内容を読みます。Generalには全体設定、Ruleには順番に評価されるマッチルール、Hostにはドメインの対応付け、URL RewriteにはURLの書き換えルールが記述されます。セクション名は通常の説明文ではありません。角括弧の不足、別セクションへのルールの貼り付け、編集時の改行削除などで、解析結果が変わることがあります。個々のルールのスペルだけでなく、記述するセクションも確認してください。

短い例で各セクションの構文を確認する

[General]
bypass-system = true

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

[Host]
lab.example.com = 192.168.1.20

この例には、異なる3種類の記述形式があります。GeneralとHostでは設定値や対応関係を等号で記述し、Ruleではルールの各項目を半角カンマで区切ります。ドメインサフィックスルールでは、2番目の項目がマッチ対象、3番目がポリシーです。FINALには個別のマッチ値がないため、ポリシーを続けて記述します。例のプライベートアドレスはHostの形式を示すものです。実際のネットワークに該当するホストがある場合にのみ意味を持ちます。推奨設定ではなく、接続に必要な情報をすべて含むものでもありません。

異なるセクションの構文を混ぜるのはよくある間違いです。たとえば、DOMAIN-SUFFIXの後のカンマを等号に変えたり、Hostの対応付けをRuleとして記述したりするケースがあります。コードをコピーしたら、句読点が全角文字に変わっていないか、ドメインの前後にWebページからコピーした引用符が付いていないか、リッチテキストが混入していないかも確認してください。保存後は、まずアプリに解析エラーが表示されていないか確認します。行番号が示された場合は、その行だけでなく直前の行も確認してください。改行やセクション境界の欠落が、次の行でエラーとして現れることがあります。

保存・選択・適用をそれぞれ確認する

設定の編集後、まず保存します。次にConfigへ戻り、変更したファイルが実際に選択されていることを確認し、最後にHomeでGlobal RoutingがConfigになっていることを確認してください。未選択のファイルだけを編集しても、現在の接続には新しいルールが適用されません。また、ProxyやDirectの状態でのリクエスト結果をRuleの順序検証に使うこともできません。アプリ内の画面への移動方法は変わることがあるため、現在の画面表示に従ってください。「ファイルの内容」「選択中の設定」「実行状態」の3点は分けて記録しましょう。

リモート設定とローカル編集も分けて管理します。ファイルが後からリモートURLで更新される場合、ローカルで追加したルールが更新時に置き換わることがあります。変更を長期的に残す場合は、アプリで利用できるファイル管理方法を使って別のコピーを作成してから編集し、元のファイルも戻せるように保管してください。唯一の設定ファイルで複数のセクションを一度に変更するのは避けましょう。まずドメインルールを1つ検証し、問題がなければ他のルールを追加します。異常が起きたとき、内容の誤り、選択ミス、更新による上書きのどれが原因かを判断しやすくなります。

設定ファイルの各セクションの読み方を先に確認するには、.confの構成解説もあわせてご覧ください。この先の章を読む際は、現在のファイル全体を把握しておきましょう。1行だけの構文が正しくても、その設定ファイル全体が現在のネットワークや用途に適しているとは限りません。

02 / 全体設定とドメインの対応付け

GeneralとHost

GeneralはRuleの代わりではない

Generalの設定は、設定全体の処理環境に適用されます。Webサイトごとの振り分けルール一覧として扱うことはできません。たとえば、bypass-system = trueはシステム通信のバイパスに関する設定であり、「すべてのWebサイトをDIRECTにする」という意味ではありません。この種の設定により、一部の通信が通常のルール判定を通らない場合があります。リクエストを調べるときは、まずその通信が観察・処理の対象か確認してください。FINALが設定ファイルにあるだけで、端末上のすべての接続が必ずそのルールを通ると判断しないでください。

全体設定を変更する前に、解決したい問題を具体的に整理してください。ドメイン解決の失敗、LANへのアクセス異常、特定のリクエストが履歴に表示されないなど、問題を明確にして初めて、関連する設定を変更すべきか判断できます。ネット上で見つけたGeneralの設定一式をそのまま元の設定に上書きすると、DNS、バイパス、接続動作が同時に変わる可能性があります。その後アクセスが復旧しても、どの変更が効果をもたらしたのかわかりません。元の値を記録し、一度に1項目だけ変更して、同じリクエストで比較してください。

[General]
bypass-system = true

この例は、真偽値を記述する形式を示しています。設定名、等号、値はそれぞれ英語表記のままにしてください。設定名から推測して別の項目を追加したり、異なる設定形式のキーを.confに転記したりしないでください。アプリで認識される設定項目と実際の動作は、現在のアプリの対応状況をご確認ください。見慣れないキーがあれば、似た綴りを何度も試すのではなく、既存の設定説明やアプリの案内を確認してください。ファイルを保存できたことだけでは、すべての設定項目が想定どおりに動作する証拠にはなりません。

Hostは対応付けを変更し、ポリシーを直接指定しない

Hostは指定したドメインを指定したアドレスに対応付けます。つまり「この名前はどのアドレスに対応するか」を扱います。一方、Ruleは「このリクエストにどのポリシーを適用するか」を決めます。ドメインをHostに登録しても、DIRECTに設定したことにはなりません。ドメインルールが先にPROXYにマッチすれば、その結果に従ってリクエストが処理されます。また、Hostの対応付けが有効になると、その後の宛先アドレスに関する判定で別のアドレスが使われる場合があります。設定を分析するときは、名前、解決結果、ポリシーを分けて整理してください。

[Host]
lab.example.com = 192.168.1.20

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

この例では、対応付けとドメインルールの役割の違いを示すため、両方を記述しています。lab.example.comは例示用の名前、192.168.1.20はプライベートアドレスです。実際に使う場合は、ご自身のネットワーク内に存在するホストの情報に置き換えてください。ルールでDIRECTが選択されても、端末がそのプライベートアドレスにアクセスできるネットワーク環境は必要です。該当するLANに接続していない場合や、対象端末で必要なサービスが公開されていない場合は、ルールが正しくマッチしても接続できません。振り分けの判定と宛先への到達可能性を混同しないでください。

DNS・キャッシュ・接続再利用の影響を確認する

Hostはアプリケーション層の識別情報を自動で変更しません。HTTPSドメインにアクセスする場合、サーバー証明書はアクセス先の名前と一致する必要があります。そのドメインのサービスを提供していないアドレスに対応付けると、証明書エラーやハンドシェイクエラーが発生することがあります。この場合、DIRECTルールを追加しても通常は解決しません。まず宛先アドレスが正しいか、サービスが該当ポートで待ち受けているか、サーバーがそのドメインのサービスを提供しているかを確認してください。名前とサービスの不一致を、関係のない設定を緩めて隠さないようにしましょう。

ドメインの対応付けを変更した後、古いDNSキャッシュや既存の接続が一時的に確認結果に影響することがあります。対象アプリの該当セッションを終了してから、新しいリクエストを送信してください。必要に応じて、アプリ内で利用できるツールでDNSの結果を確認し、新規リクエストと既存接続を区別します。記録には、テストしたドメイン、想定アドレス、実際のアドレス、マッチしたポリシーを含めてください。「Webページが開かない」という記録だけでは、対応付けの未適用、サービスへの到達不能、リクエストが再発行されていない状態のどれかを判断できません。条件を揃えたテストのほうが、設定を何度も切り替えるより有効です。

最後に、同じ名前のHost項目、範囲の広いドメインルール、アドレスルールが同時に存在しないか確認してください。重複する対応付けの評価順に意図を持たせず、明確な1つの対応付けにまとめられるなら先に整理しましょう。公開Webサイトのアドレスはサービス構成の変更に伴って変わることがあるため、固定の対応付けを長期利用する場合はご自身で保守する必要があります。ご自身のLAN内のサービスでは、端末のアドレスが安定しているか確認してください。ルールの管理では、構文を解析できるだけでなく、設定内の名前と実際のネットワークの対応を維持することも重要です。

03 / ドメイン名によるマッチ

DOMAINとドメインルール

完全一致・サフィックス・キーワードで範囲を指定する

ドメインルールは、名前がわかっているリクエストの振り分けに使います。DOMAINは完全なドメイン名、DOMAIN-SUFFIXはそのドメインとサブドメイン、DOMAIN-KEYWORDは名前に指定した文字列が含まれるかを判定します。いずれもURLのパスをマッチ対象にしません。ドメイン名の後に続くスラッシュ、クエリパラメーター、ページ内のフラグメントは、これらのルールのマッチ値に含まれません。api.example.comだけを対象にする場合、https://を含む完全なURLを記述しないでください。同じホスト上の異なるページをドメインルールで区別することもできません。

ルール値の例マッチ範囲
DOMAINapi.example.com指定した完全なホスト名。ほかのサブドメインには拡張されません。
DOMAIN-SUFFIXexample.comexample.com自体とそのサブドメイン。文字列を含むすべての名前にマッチするわけではありません。
DOMAIN-KEYWORDexample名前に指定した文字列を含むもの。異なるドメインサフィックスにも該当する場合があります。

ルールを選ぶときは、要件を正確に表せる最も狭い範囲から使います。特定のホストにはDOMAIN、サブドメイン全体に共通のポリシーを適用する場合はDOMAIN-SUFFIX、異なるドメインサフィックスをまたいで文字列で判定する必要がある場合に限りDOMAIN-KEYWORDを検討します。キーワードが組織名やサービス名を示すとは限りません。同じ文字列を含む別の名前も範囲に入る可能性があります。短く一般的な語をキーワードにすると、意図していないリクエストまで影響を受けやすくなります。こうした誤マッチは構文エラーとして表示されないことがほとんどです。

広いルールの前に個別の例外を置く

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,REJECT
FINAL,DIRECT

この例では、api.example.comが最初の完全一致ルールにマッチし、DIRECTになります。www.example.comは最初のルールにはマッチしませんが、サフィックスルールにマッチしてPROXYになります。example.comに属さないもののexampleという文字列を含む名前は、キーワードルールまで到達した場合に拒否される可能性があります。アプリが3種類のルールの精度を自動比較するわけではありません。先にマッチしたルールで判定が終わります。キーワードルールを先頭に置くと、その文字列を含むリクエストに対して、後続の2つのルールで例外を設けられなくなります。

DOMAIN-SUFFIXの値には通常、example.comと記述します。先頭にアスタリスクは不要です。ワイルドカードの書き方と混同しないでください。このルールはドメインラベルの境界を考慮したサフィックス判定を行うため、末尾の文字が似ているだけのnotexample.comはexample.comのサブドメインとして扱われません。特殊文字を含む名前、国際化ドメイン名、アプリ内部で変換された名前については、リクエスト履歴に実際に表示される形式を確認してから記述してください。ブラウザーのアドレスバーに見える文字だけで判断しないようにしましょう。

リクエストのドメイン名はアドレスバーと異なることがある

1つのページから通常、複数のリクエストが発生します。メインのページはあるドメインから読み込まれ、画像、スクリプト、ログイン、APIは別のドメインを使うことがあります。アドレスバーのドメインにルールを追加しても一部のコンテンツに問題が残る場合、ルールが無効とは限りません。失敗したリクエストがどの名前を使ったか確認してください。同じ考え方はアプリにも当てはまります。アプリ名と、アプリが利用するすべてのサービスドメインは同じではありません。アイコンや製品名からドメイン一覧を推測することはできません。本ページではサービスのドメイン一覧を提供していません。実際のリクエスト履歴をもとに確認してください。

接続先がIPアドレスだけで、ルールに使えるドメイン情報がない場合、ドメインルールが名前を自動で推定することはできません。キャッシュ、アプリ内の名前解決、異なる接続方式などにより、履歴のホスト名が想定と異なることもあります。調査では、まず履歴にドメイン名が含まれているか確認し、ドメインルールが適用されるリクエストか判断してください。「DOMAINにマッチしない」ことだけを理由に、クライアントがルールを無視していると結論付けないでください。入力した名前を使わずにマッチ処理へ進んでいる可能性があります。

ドメインルールをテストするときは、少なくとも3つの比較対象を用意します。想定どおりにマッチする完全な名前、同じグループの別のサブドメイン、影響を受けてはいけない類似名です。一度に変更するルールの種類は1つにし、マッチしたルールとポリシーがどう変わるか確認してください。各キーワードの適用範囲を詳しく知りたい場合は、ルール構文の入門とマッチ範囲の比較をご覧ください。開けるWebページを1つ確認するだけでなく、境界となるケースを記録しておくと、後からの誤マッチを防ぎやすくなります。

04 / IPアドレス・地域・その他の条件

IP-CIDR、GEOIPなどのルール

IP-CIDRはアドレス範囲で判定し、Webサイト名では判定しない

IP-CIDRのマッチ値には、IPv4アドレスとプレフィックス長を指定します。192.168.0.0/16はプライベートアドレスの範囲を表し、192.168.0.0という1台のホストだけを指すものではありません。一般にプレフィックス長が大きいほど、対象のアドレス範囲は狭くなります。記述前に対象が属するネットワーク範囲を確認し、手軽さを理由に範囲をむやみに広げないでください。Webサイトが一時的にあるアドレスへ解決されたからといって、そのアドレス範囲全体に同じポリシーを適用すべきとは限りません。共有インフラでは、同じ範囲のアドレスが互いに関係のない複数のサービスに使われることがあります。

[Rule]
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

IPv6アドレス範囲にはIP-CIDR6を使用します。例のfc00::/7はIPv6のローカルアドレス範囲です。IPv6のアドレスをIP-CIDRにそのまま入力しても、同じ結果になるとは限りません。プライベートアドレスやローカルアドレスに対するDIRECTルールは接続方式を決めるだけです。対象ネットワークへの経路を作ったり、対象端末へのアクセス権を変更したりはしません。端末が該当ネットワークに接続していない、アドレスが競合している、サービスが待ち受けていない場合は、DIRECTにマッチしても接続に失敗することがあります。ネットワークとサービスの状態も確認してください。

no-resolveの要点は、このアドレスルールのためだけにドメイン解決を追加で発生させないことです。宛先がすでにIPアドレスの場合は、既存のアドレスに基づいて判定できます。一方、ドメイン名しかなく、利用可能なアドレス情報もないリクエストが、no-resolve付きのアドレスルールに必ずマッチするとは限りません。これはクライアント全体の名前解決を停止するスイッチでも、特定のドメインがDNSを常に回避するという指定でもありません。リクエストにアドレスがすでに含まれているか、先行するドメインルールで処理されていないかも確認してください。

GEOIPはアドレスの地域情報を示し、サービスの所属先を示すものではない

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

GEOIPは宛先アドレスと対応する地域データを使って判定します。GEOIP,CN,DIRECTは、地域コードCNに該当する宛先アドレスにDIRECTを選択するという意味です。登録事業者やユーザーの所在地で分類するものではありません。1つのドメインが異なる地域の複数のアドレスに解決されることがあり、アドレスデータベースと実際の配置が一致しない場合もあります。重要なドメインに確実なポリシーを適用する場合は、GEOIPの前にルールを記述してください。地域判定をサービスの正確な分類表として扱わないようにしましょう。

同じドメインが時間によって異なるポリシーにマッチする場合は、まず解決先のアドレスが変わったか確認し、次に地域ルールの位置を確認してください。記録がないまま、GEOIPが自動で順序を変えたと判断しないでください。また、宛先アドレスの地域と、プロキシの出口の地域は別の情報です。ルールが判定する対象を、後から観測した出口の状態で置き換えることはできません。アドレスに関する調査では、テスト時のドメイン、アドレス、マッチしたルールを記録してください。次のリクエストでは別の宛先になっている可能性があります。

USER-AGENTとFINALの適用範囲

[Rule]
USER-AGENT,ExampleApp*,PROXY
FINAL,DIRECT

USER-AGENTは、取得できるUser-Agent情報に基づいてマッチします。ExampleApp*は説明用のパターンであり、実在アプリの一覧ではありません。また、端末上のアプリ名でプロセスを識別するものでもありません。暗号化されたリクエストでは関連情報を常に確認できるとは限らず、このルールで特定アプリのすべての通信を確実に分類できるわけではありません。例をマッチさせるために、理解していない証明書設定や復号設定を追加しないでください。まず、現在取得できるリクエスト情報から検証可能なドメイン条件やアドレス条件を使ってください。

FINALは、それまでのルールにマッチしなかったリクエストを処理するフォールバックです。ドメインやアドレスを追加で指定する必要はありません。Ruleの最後に置き、先行するルールで処理されないリクエストの行き先を明確にします。FINALを途中に置くと、その後の通常ルールで残りのリクエストを処理できません。長い設定ファイルでは、まずFINALを検索し、1つだけ明確な位置にあるか確認してから、前の具体的なルールを確認してください。USER-AGENT、地域、アドレスの各ルールで利用できる情報は異なります。条件を増やすより先に、リクエストからどの情報を取得できるか確認しましょう。

05 / ポリシーと全体の動作モード

ポリシーとGlobal Routing

PROXY、DIRECT、REJECTが示す処理の違い

ルールの前半はマッチするかどうかを判定し、ポリシー項目はマッチ後の処理を決めます。PROXYは現在のプロキシ選択を使い、DIRECTは宛先に直接接続し、REJECTはリクエストを拒否します。ポリシー名はドメイン名でもサーバーアドレスでもありません。PROXYを一時的な説明文に置き換えても、アプリが自動で意味を理解することはありません。既存の設定で名前付きポリシーグループを使う場合は、そのグループが存在し、選択関係が正しく設定されていることを確認してから参照してください。このページでは、未定義のグループ名をコピー可能な例に含めないよう、基本的なポリシーを使用しています。

ポリシーマッチ後の処理あわせて確認する項目
PROXY現在のプロキシ選択で処理します。サーバー情報、認証、ネットワーク到達性、サービスの状態。
DIRECT宛先に直接接続します。ローカルネットワーク、名前解決結果、宛先サービスへの到達性。
REJECTマッチしたリクエストを拒否します。ルールの範囲が広すぎないか、必要な通信まで拒否していないか。

PROXYにマッチしても、リクエストの成功が保証されるわけではありません。サーバー情報の失効、認証の不一致、ネットワーク制限、宛先サービスの異常は、ルール判定の後に発生することがあります。同様に、DIRECTも「必ず成功させる」指示ではなく、接続経路を変更するだけです。トラブルシューティングでは、選択されたポリシーと、そのポリシーで接続に失敗した理由を分けて確認してください。ページが開いたかどうかだけでルールのマッチを判断すると、通信上の問題を構文エラーと取り違えることがあります。

Global Routingで設定に基づく振り分けを選ぶ

Global Routingには、設定のConfig、プロキシのProxy、直接接続のDirectという3つのモードがあります。これらの画面上の項目はRule内の大文字のポリシー名と関係しますが、同じ階層の設定ではありません。Configは選択中の設定に基づいてリクエストを処理します。ProxyとDirectは、それぞれの全体モードでの動作を確認するために使えます。DOMAINやIP-CIDRルールを検証する場合は、まずConfigに戻してください。設定ファイルが正しくても、観察中の通信がそのRuleセクションで判定されているとは限りません。

画面上のモード確認する項目テストの目的
設定 Config現在の設定、ルールの順序、ポリシー。このページの振り分け例を検証する。
プロキシ Proxy現在のプロキシ選択と接続状態。プロキシ接続の問題と振り分けの問題を切り分ける。
直接接続 Directローカルネットワークと宛先サービス。直接接続の経路が利用できるか確認する。

モードの切り替えは比較テストのための操作であり、長期的な解決策としてそのまま使うものではありません。Proxyでは成功し、Configでは失敗するリクエストは、ConfigでDIRECTが選択された、REJECTにマッチした、または想定と異なる設定ファイルが選択されている可能性があります。履歴で実際の結果を確認してから、該当するルールを修正してください。テスト後は元のモードに戻します。使用環境が変わったのに、以前と同じ条件で結果を解釈しないようにしましょう。

拒否ポリシーでは例外と戻し方を用意する

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

この例は、同じサフィックスに対する異なる処理を示すものです。例示した名前が実際にどのサービスで使われているかを示すものではありません。api.example.comは先にPROXYに指定され、metrics.example.comは個別に拒否されます。それ以外のexample.comのサブドメインにはDIRECTが適用されます。サフィックスルールを先頭に移動すると、2つの例外が意図どおりに動作しなくなります。ポリシーの設計とルールの順序はあわせて確認してください。最後のポリシー名の綴りだけを確認しても不十分です。

REJECTを使う場合は、アプリの機能間の依存関係に注意してください。一見補助的に見えるリクエストが、ログイン、リソース検証、セッション更新に必要な場合があります。一部の機能に問題が起きたら、ルールセクション全体を削除するのではなく、該当する拒否ルールだけを一時的に無効にしてリクエストを再実行してください。因果関係を確認した後で、マッチ範囲を狭めるか、先行する例外を追加します。Global RoutingとHomeの位置関係は、初回起動とHome画面の説明で確認できます。サーバー自体の利用可否は別途検証してください。

06 / 順序と競合

評価順序と優先順位

先にマッチしたルールで結果が決まる

Ruleセクションでは通常、ルールを記述順に確認します。マッチすると対応するポリシーが適用され、その後に「より具体的に見える」ルールを探すことはありません。したがって、優先順位を決めるのはまずルールの並び順であり、ルール名ではありません。DOMAINがDOMAIN-SUFFIXより自動的に優先されるわけではなく、IP-CIDRがGEOIPより常に後になるわけでもありません。「具体的な例外を先に、一般的な範囲を後に、最後にFINAL」という構成にすると、読み進める順序と実際の判定順序が一致します。

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

api.example.comでは、最初のルールにマッチした時点でDIRECTに決まり、example.comのサブドメインであることを理由に後からPROXYへ変わることはありません。www.example.comは最初のルールにマッチせず、2番目のルールにマッチして判定が終わります。プライベートアドレスへの直接接続では、先行するドメイン条件が適用されない、またはマッチしない場合に、IP-CIDRまで判定が進みます。GEOIPやFINALに進むのは、それ以前のルールにマッチしなかったリクエストだけです。1つずつ動作を確認する際は、各段階でどのリクエスト情報が使われるかを明確にしてください。すべてのリクエストが完全なドメイン名とアドレスを同時に持つと仮定しないようにしましょう。

ルールの重複自体ではなく、後続ルールが遮られる理由を確認する

完全一致のドメインルールとサフィックスルールが同じリクエストを対象にするのは、意図的な例外として適切な場合があります。一方、同一条件で異なるポリシーを指定している場合は、通常は統合するか、意図を明記する必要があります。同じ条件が後から再登場しても、同じリクエストに別の選択肢を与えることはできません。大きな設定を確認する際は、まず完全な重複、次に包含関係、最後にキーワードとサフィックスの重なりを探してください。行数だけでルールの充実度を判断しないでください。重複項目は管理の負担を増やしても、有効な動作を増やすとは限りません。

ルールを下部から先頭へ移動して問題が解消した場合は、元の位置でどのルールに遮られていたかを確認してください。追加したルールをすべて先頭に置く習慣を続けると、先頭に互いに競合する例外が増えていきます。先にマッチする広範な条件を特定し、必要な例外をその前に配置したうえで、用途ごとに分かりやすく整理してください。同じドメインに相反するポリシーを何度も追加すると、後から設定を管理する人が意図したルールを判断しにくくなります。

リクエスト一覧でルール移動の影響を検証する

編集前に、少なくとも「対象」「想定するポリシー」「想定するマッチ条件」を含む簡単なテスト表を作成できます。具体的な例外、一般的なサブドメイン、プライベートアドレス、フォールバック対象を1つずつ選びます。ルールを移動した後は、問題が起きていた対象だけでなく、ほかの比較対象も再確認してください。1つの例外を修正した結果、サフィックス全体に影響が出るといった問題を見つけられます。テスト対象には実際の用途に関係するものを選び、本ページの例示ドメインにアクセスできるかどうかを設定の正しさの基準にしないでください。

アドレスルールの順序にも同じ原則が当てはまります。たとえば、広いアドレス範囲をDIRECTにし、その一部の狭い範囲をPROXYにする場合は、狭い範囲を先に置きます。GEOIPが先にアドレスを処理すると、後続のアドレス例外が実行されないことがあります。ここでいう「具体的な条件を優先する」は、作成者が並び順で表現するルールです。実行時にプレフィックス長を自動比較して並べ替えるわけではありません。ネットワークのルーティングテーブルで使われる別の照合方法を、そのままRule一覧に当てはめないでください。

リモートルールの参照やその他の拡張項目を含む設定では、判定全体のどの位置にあるかも確認してください。手書きの数行だけを読んで、より前に広範な条件がないと判断することはできません。原因を説明できないマッチが発生したら、完全なファイルに戻り、Ruleの先頭から実際の順序に沿って確認してください。必要であれば、最小限のテスト用設定にコピーし、項目を少しずつ追加します。簡略化は影響条件の特定に使うものです。確認後は、必要なセクションを元の設定に戻してください。過度に削ったファイルを完全な設定の代わりに使い続けないようにしましょう。

07 / URLの書き換えと組み合わせ例

URL Rewriteとよくある記述

URLの書き換えはプロキシのポリシー指定とは異なる

URL Rewriteはパターンに基づいてリクエストURLを処理します。RuleでPROXY、DIRECT、REJECTを選ぶ操作とは別の機能です。ドメインの振り分けは接続先を決め、書き換えルールはリクエストのURLを変更したり、リダイレクトを返したりします。特定のドメインをプロキシ経由にするために書き換えルールを追加したり、通常のドメインルールをURL Rewriteに貼り付けたりしないでください。必要なのがアクセス経路の選択だけなら、まずRuleで指定します。URLの動作を変更する必要がある場合に限り、書き換えセクションを検討してください。

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

この例は、マッチパターン、置換先URL、リダイレクトのステータスコードで構成され、HTTPからHTTPSへの限定的なリダイレクトを示します。パターン中のピリオドはバックスラッシュでエスケープし、先頭の^でURLの先頭からのマッチを指定します。ドメインの後にスラッシュを置くことで、ホスト名との境界を明確にしています。この短い例から、任意の元のパスやクエリパラメーターが期待どおりに保持されると判断しないでください。これらの情報を引き継ぐ必要がある場合は、キャプチャと置換を明確に設計し、実際の結果を個別に検証してください。

HTTPSリクエストでは、URL内のパスなどの情報を常に同じ方法で確認できるとは限りません。通常のドメイン振り分けでは完全なURLを参照しませんが、パス単位の書き換えには該当するリクエスト情報を確認できる必要があります。そのため、「ドメインルールがマッチした」ことだけでは、書き換えパターンも実行される証拠にはなりません。例を試すために証明書設定や復号設定を安易に追加しないでください。まずリクエストの種類とアプリから確認できる情報を把握し、URL Rewriteが適切か判断します。確認できない場合は、元のリクエスト動作を保つほうがトラブルシューティングしやすくなります。

ルールの意図を分けて検証できる形にする

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

[Host]
lab.example.com = 192.168.1.20

この例では、LAN内の名前解決、特定ドメインの拒否、サフィックス全体のプロキシ経由、プライベートアドレスへの直接接続を組み合わせています。まず2つのドメイン例外を確認し、次にサフィックスの範囲、最後にアドレスとフォールバックを確認してください。lab.example.comは例示用のプライベートアドレスに対応付けられ、先行するDOMAINルールでDIRECTが指定されています。blocked.example.comは先に拒否されるため、後続のサフィックスルールでPROXYに変更されません。各項目を少ない変数で個別に確認できるよう、書き換えルールは加えていません。

実際に適用するときは、まず現在の設定をコピーし、必要最小限のルールを1つだけ追加してください。特定のAPIに異なるポリシーを適用するだけなら、まずDOMAINを追加します。Host、GEOIP、書き換えルールを同時に導入する必要はありません。完全一致ルールの検証後に、DOMAIN-SUFFIXへ範囲を広げる必要があるか検討します。設定の複雑さは、例に登場するキーワードの数ではなく、実際の要件に合わせてください。セクションを1つ増やすごとに、個別に説明・検証する処理が増えます。

ループや過度に広いパターンを避け、サブスクリプションと混同しない

リダイレクトのテストでは、最終的なURLとリダイレクトの回数を確認してください。新しいURLが再び元のパターンにマッチしたり、移動先のサイトから元のURLへ戻されたりすると、ループが発生することがあります。まず制御可能なパスを1つ選んで応答を確認してから、マッチ範囲を広げてください。正規表現ではピリオド、疑問符、括弧などに特別な意味があります。通常のURLを確認せずにパターンとして使わないでください。パターンが広すぎると、構文が正しくても、本来変更すべきでないリクエストが処理され、ログイン状態やリソースの読み込みに問題が起きることがあります。

サーバーのサブスクリプションと設定ファイルのURLも混同しないでください。既存のサブスクリプションはサーバー項目を追加するためのものであり、必ずしも.confのテキストを返すわけではありません。設定ファイルのURLは、アプリが認識できる設定内容を返す必要があります。例のhttps://example.com/sub?token=xxxxは、明らかなダミー値であり、利用できるサービスではありません。用途が不明なURLをConfigに追加して解析エラーが起きたら、Ruleのキーワードを追加して直そうとせず、まず返される内容の種類、アカウントの状態、URLの用途を確認してください。

設定を共有して確認を依頼するときは、問題を再現するために必要なルールとセクションだけを残し、個人のサブスクリプションURL、認証情報、その他の機密情報を削除してください。ファイル全体を送って相手に推測してもらうのではなく、「どのリクエストにどのポリシーを適用したいか」を説明します。画面で使われる用語やポリシー名は用語集で確認できます。組み合わせ設定の目的は、すべてのネットワーク変更を1つのファイルに詰め込むことではありません。各処理を説明できるようにすることです。

08 / 操作と検証の流れ

検証・メンテナンス・トラブルシューティング

決まった手順でテストする

テストを有効なものにするには、入力と環境を一定にします。まず現在のネットワーク、Global Routingのモード、選択中の設定、プロキシの選択を記録します。次にテストする完全なホスト名と想定するポリシーを記録してください。変更を保存したらConfigに戻ってファイルを確認し、Configモードに切り替えてから対象のリクエストを新たに送信します。テスト中にサブスクリプションの更新、サーバーの変更、ネットワークの切り替えを同時に行わないでください。リクエストが成功しても失敗しても、どの変数が影響したのか判断できなくなります。設定の問題を調べるには、ボタンを次々に押すより、再現できるテストが重要です。

アプリ内で利用できるリクエスト履歴や診断画面では、宛先ドメイン、宛先アドレス、マッチしたルール、ポリシーを確認してください。具体的な項目は現在の画面表示に従います。リクエストによってはすべての情報が表示されないため、欠けている項目はそのまま記録してください。Connectivity Testはテスト条件下での接続状況の把握に役立ちますが、実際のリクエストでルールを検証する代わりにはなりません。テストに成功しても、その対象と条件で特定の結果が得られたことを示すだけです。すべてのWebサイトやアプリのリクエストが同じ経路を使う保証にはなりません。

  1. ファイルを保存し、Configでそのファイルが選択されていることを確認する。
  2. Global RoutingがConfigであることと、現在のプロキシ選択を確認する。
  3. 既存のセッションを終了し、明確な新規リクエストを送信する。
  4. ページが開いたかどうかだけでなく、マッチ条件と実際のポリシーを確認する。
  5. 例外、一般的な範囲、フォールバック対象を再テストし、影響範囲を確認する。

現象から名前解決・マッチ・通信の問題を切り分ける

設定を正常に読み込めない場合は、まずテキスト構成を確認します。セクション名、半角の句読点、項目数、ポリシー名を見直してください。DOMAINルールは通常、種類、値、ポリシーの3項目です。FINALにはポリシーを続けて記述し、項目数を合わせるためにドメインを追加しないでください。コードのコピー時に説明文が混入していないか、特にWebページの見出し、行番号、自動改行を確認します。アプリがファイルを認識してから、リクエストの処理方法を調べてください。解析が完了していない段階でネットワークの動作を調べても、原因の切り分けにはなりません。

ファイルを読み込めても誤ったルールにマッチする場合は、現在のファイルが選択されているか、Configになっているか、実際のリクエスト名がルールと一致しているか、先行する広範なルールがあるか、FINALが早い位置にないか、順に確認します。ドメインルールが名前を利用できない場合は、リクエストに宛先アドレスしか含まれていないか確認してください。no-resolve付きのアドレスルールでは、利用できるアドレス情報がすでにあるか確認します。それぞれの可能性を示す証拠を見つけてください。マッチが観察できなかったことを、すべて「ルールが無効」とまとめないようにしましょう。

正しいルールにマッチしても接続に失敗する場合は、通信経路の問題を調べます。PROXYでは、ご自身のサーバー情報と認証を確認します。DIRECTでは、ローカルネットワークと宛先サービスを確認します。REJECTでは、拒否する意図が本当にあるか確認してください。DNSの失敗、接続タイムアウト、証明書エラーはそれぞれ異なる段階の問題です。同じルール変更で解決しようとしないでください。同じ宛先でProxyまたはDirectを一時的に比較できますが、テスト後は元のモードに戻し、Rule内の問題を修正してください。

変更後も以前のポリシーが表示される場合、まず何を確認しますか？

まず選択中のファイルとGlobal Routingを確認し、既存の接続を終了して新しいリクエストを送信します。履歴が新しいセッションのものだと確認してから、キャッシュ、先行ルール、リモート更新による上書きを調べてください。

PROXYにマッチした後もタイムアウトします。ドメインルールを追加する必要がありますか？

通常はまず、既存サーバーへの接続性、認証、宛先サービスを確認します。想定したポリシーにすでにマッチしているなら、同じドメイン条件を重複して追加しても、その後の接続失敗は直接解決しません。

元に戻せるメンテナンス記録を残す

設定のメンテナンスでは、変更前後の差分、変更理由、検証対象を記録してください。「特定のドメインをサフィックスルールより前に移動し、DIRECTの例外を維持」のように具体的に残し、「ルールを最適化」とだけ記録しないようにしましょう。重複項目、長期間使っていない例外、古くなったHostの対応付けは定期的に整理しますが、一度の作業で全階層を大きく変更しないでください。リモート設定の更新後は、ローカルの例外が残っているか、元の順序が変わっていないかを再確認してください。

原因を説明できない問題が起きたら、まず最後に動作を確認できた設定ファイルに戻し、基本的な接続が復旧するか確認します。その後、コピーしたファイルで変更を1つだけ再現してください。元に戻しても同じ問題が起きる場合は、変更したルールだけに原因を限定せず、ネットワーク、サービス、サブスクリプションの状態が変わっていないか検討します。初回接続の手順を確認するには使い方ガイドに戻り、アプリの入手元や購入済みアプリの復元については購入済みアプリの復元方法をご覧ください。問題の報告前に個人の認証情報を削除し、最小限のルール、リクエスト条件、実際の結果だけを残してください。

使い方ガイドに戻る →
App Storeでダウンロード