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

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

まず、現在使用中のConfigを確認し、ルールの順序と適用されるポリシーをチェックします。このページではファイル構成に沿って設定の動作を説明します。ルール数を増やすこと自体を目標にはしません。

  • 上から順にマッチ
  • PROXY / DIRECT / REJECT
  • FINALで補完

初めて接続する場合は、まずはじめにに沿って、インポート、接続、検証まで進めてください。接続できていて、例外ルールや設定の管理方法を確認したい場合は、このページの目次から該当箇所を参照してください。本ページは、ご自身で用意したサブスクリプションまたはサーバー情報があることを前提としています。

01 / ファイルの構成

設定ファイルの構成：4つのセクションの役割

Shadowrocketの設定ファイルは、セクションごとに設定を記述するテキスト形式です。角括弧内のセクション名が役割を分け、各セクションにパラメーター、ルール、マッピングなどを記述します。ファイルを読むときは、まず[General]、[Rule]、[Host]、[URL Rewrite]を見つけ、その後で各セクションの内容を確認してください。設定ファイルはサーバー一覧と同じものではありません。サーバーは接続を確立し、設定ファイルはリクエストごとの処理方法を定めます。両者を現在の動作状況と合わせて理解する必要があります。

セクション名で内容の解釈が決まる

[General]には設定全体に関わるパラメーターを記述し、通常はキーと値の形式で指定します。[Rule]には順番に評価する振り分け条件、[Host]には指定したホスト名とローカルアドレスの対応、[URL Rewrite]には式に一致するリクエストURLの処理を記述します。正しいルールを誤ったセクションに置いても、有効な振り分けルールにはなりません。トラブル時は、まず記述先のセクションを確認してから、ルールの条件が適切かを検討してください。

# セクション構成の例。接続設定の完全版ではありません
[General]
dns-server = system

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

[Host]
test.example.com = 192.0.2.10

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

上記の4セクションはそれぞれ異なる構文を示すもので、すべての設定に必須という意味ではありません。ローカルマッピングが不要ならHostの項目は追加しなくて構いません。明確なURLの書き換え先がなければ、URL Rewriteも不要です。最小限の設定にすることで、各項目の役割を把握しやすくなります。ファイルを充実して見せるために、用途の不明なパラメーターを追加するのではなく、各設定を実際の要件に対応させてください。

設定ファイル・サーバー情報・サブスクリプションは別々に管理

ご自身で用意したサーバー情報には、通常、アドレス、ポート、プロトコル、認証パラメーターが含まれます。サブスクリプションはサーバー情報をまとめてインポートまたは更新するためのものです。一方、設定ファイルには振り分けの動作を記述します。インポートが成功しても、読み込んだデータがアプリに反映されたことしか確認できず、サーバーへの接続、設定の選択、ルールの想定どおりの動作まで保証されるわけではありません。「サブスクリプションを更新した」ことを「正しい設定を使用中」と見なさず、3つを個別に確認してください。

アプリのConfigで現在の設定を開き、名前と内容を確認してから、Homeに戻ってGlobal Routingをチェックします。ローカルファイルを保存しただけでは、実行中の設定として使われているとは限りません。リモート設定とローカルコピーの名前が似ている場合もあるため、編集前に対象を確認してください。ご自身で管理する提供元の設定を使っている場合は、更新によってローカルの変更が上書きされる可能性も確認しましょう。試験用の変更を残す場合は、判別しやすい名前を付けて別のコピーに保存してください。

セクション役割混同しないこと
General設定全体に関わる動作パラメーター順にマッチさせるルール一覧ではない
Rule条件の照合とポリシーの選択サーバーの認証パラメーターは保存しない
Hostホスト名とアドレスのローカルマッピングPROXYやDIRECTを直接指定しない
URL Rewrite式に基づくリクエストURLの処理ドメイン振り分けとは異なる

編集前に元に戻せる状態を保存

長い設定ファイルを初めて編集する場合は、まず正常にアクセスできる宛先、選択中のサーバー、Global Routingを記録し、元のファイルを保存してください。一度にDNSの変更、全ルールの並べ替え、書き換えルールの追加を行わないでください。変更を一つずつ試せば、結果が変わったときに原因を特定しやすくなります。コメントを付けるときは、ルールの内容を繰り返すより「なぜこの例外が必要か」を説明しましょう。たとえば、特定の内部ホストへのアクセスにローカルネットワークが必要な理由を記載します。

構文については、半角カンマ、セクション名のつづり、意図しない改行、コピー時に混入した全角記号も確認してください。コメントは説明がフィールドとして解釈されないよう、独立した行に記述するのがおすすめです。ルールは少しずつ追加し、保存後にアプリの表示を確認してから、検証する接続を新たに開始してください。各セクションの概要は設定ファイルの各セクションの役割で確認できます。このページの以降の章では、マッチ条件の境界や検証方法を詳しく説明します。

02 / 動作条件

General：動作パラメーターとDNSの範囲

Generalは設定全体の動作条件を指定するもので、宛先ごとの出口をRuleの代わりに決めるものではありません。「同じルールなのに動作が異なる」場合は、ドメインの名前解決、宛先アドレス、現在のネットワーク、実際に選択されている設定を併せて確認する必要があります。特にIP-CIDRやGEOIPでは、宛先アドレスを取得できるかどうかが後続の判定に影響します。名前解決の過程を確認せずルールの1行だけを見ても、結果を十分に説明できないことがあります。

まず必要最小限のパラメーターを確認

Generalのパラメーターはキーと値の組み合わせで指定します。別の場所で見かけた長いパラメーター一覧を、既存ファイルにまとめて追加しないでください。設定によっては、名前解決、ネットワークの取り込み、アドレス処理の方法が変わることがあります。見慣れないパラメーターは、まずアプリ内の説明を確認し、現在の問題に関係するかを判断してください。明確な目的のない設定は、動作条件を一度に変えて「最適化」するのではなく、現在の状態を維持しましょう。

[General]
# システムのDNS設定を使用
dns-server = system

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

この例は、DNS設定とRuleセクションが独立していることを示しています。dns-server = systemはシステムの名前解決設定を使用する指定であり、すべてのドメインが常に同じアドレスに解決されることや、どのネットワーク環境でも同じ結果になることを意味しません。ネットワークの切り替え、名前解決のキャッシュ、宛先側のアドレス振り分けによって、返される内容が変わることがあります。個別のリクエストを判断する際は、その時点で確認できる情報を基準にしてください。

ドメインルールとIPルールでは必要な情報が異なる

DOMAIN系のルールには識別できる宛先ホスト名が必要です。一方、IP-CIDRやGEOIPにはアドレス情報が必要です。ドメイン名で開始したリクエストは、ドメインルールでポリシーが決まる場合もあれば、続けて評価される過程でアドレス解決が関わる場合もあります。「ドメインが特定の地域で登録されているから、必ずGEOIPに一致する」とは限りません。GEOIPが判定するのはアドレスとデータベース上の帰属であり、サイト名や登録情報ではありません。

名前解決で使われる経路と、その後の通信接続で使われる経路は別の問題です。DNSリクエストを確認できても、後続のWeb接続が同じ出口を使うとは限りません。通信がPROXYに一致しても、すべての名前解決が同じサーバーを経由するとは断定できません。トラブル時は「アドレスの取得」と「宛先への接続」を別々の段階として記録し、どこで問題が起きたかを確認してください。タイムアウトをすべてルールの問題と決めつけないようにしましょう。

IPv4、IPv6、キャッシュをそれぞれ確認

IPv4のネットワークルールしかない場合、IPv6の宛先にも適用されると考えないでください。実際の接続先がIPv6の場合は、IP-CIDR6と対応するポリシーを確認し、IPv4の範囲をむやみに広げないようにしてください。同じドメインでも、リクエストごとに異なるアドレスファミリーが使われる場合があります。設定を検証するために、先に特定のアドレスファミリーを無効にする必要はありません。まず実際の宛先アドレスを記録し、そのアドレスに適用されるルールを確認してください。

キャッシュや既存の接続が残っていると、設定変更の効果がすぐに観察結果へ反映されないことがあります。アプリ、ブラウザー、ネットワーク層がそれぞれ情報を保持している可能性があり、設定を保存しても長時間接続が再確立されるとは限りません。変更後は、設定が引き続き選択されていることを確認し、テスト対象の古いセッションを終了するか、新しいリクエストを開始してください。再接続が必要かどうかは、変更内容やアプリの案内によって異なります。接続の切り替えを繰り返すだけで解決しようとしないでください。

システムのネットワーク条件はルールとは別

ローカルネットワークでログインが必要、Wi-Fiから宛先へ接続できない、サーバーのホスト名を解決できないといった状況では、構文が正しい設定でも利用できないことがあります。このような場合、DOMAIN-SUFFIXを追加しても根本的な接続問題は解消しません。まずデバイスが利用可能なネットワークに接続されていることを確認し、次にご自身で用意したサーバーの接続性と認証情報を調べ、最後に通信の振り分けを検証します。この順番で確認すると、ルールの問題とネットワークの問題を切り分けやすくなります。

Generalを管理する際は、変更前後のネットワーク種別、名前解決設定、テスト対象を記録し、実際の認証情報は記録しないようにしてください。特定のネットワークだけで問題が起きる場合は、別のネットワークを比較用に残し、項目ごとに確認します。権限や初回起動の手順ははじめに、Global Routingのモード選択はルーティングモードの説明を参照してください。サーバーや権限の問題が未確認のまま、動作パラメーターで補おうとしないでください。

03 / ホスト名のマッチ

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD

ドメインルールは「このホスト、またはこのホスト群にどのポリシーを適用するか」を表すのに適しています。よく使われる3つの書き方の違いは対象範囲であり、どれが上位ということではありません。特定ホストの例外にはDOMAIN、ルートドメインとサブドメインを含める場合はDOMAIN-SUFFIX、名称の一部で広くマッチさせる必要がある場合に限りDOMAIN-KEYWORDを検討します。対象範囲が広いほど、意図しないマッチがないか慎重に確認してください。

DOMAIN：単一ホストに明確な例外を設定

DOMAIN,api.example.com,PROXYは完全なホスト名を対象とし、exampleを含む他のホストまで自動的に対象にするものではありません。フィールドにはプロトコル、パス、クエリパラメーター、ポートを含めず、ホスト名だけを記述します。https://api.example.com/login全体をDOMAINに指定しても、「ログインページだけをプロキシにする」という意味にはなりません。パスの処理は別の要件です。URLの書き換えが本当に必要か、まず確認してください。

[Rule]
# 単一ホストへの正確な例外
DOMAIN,api.example.com,PROXY
DOMAIN,intranet.example.com,DIRECT
FINAL,DIRECT

この書き方は、小さな範囲でのテストに適しています。単一ホストのポリシーが正しいと確認してから、同じサービスの他のドメインへ対象を広げるか判断してください。1つのページからAPI、画像、認証など複数のホストへアクセスする場合があるため、「メインページがマッチした」ことは、関連するリクエストすべてがマッチしたことを意味しません。ページの一部だけ表示されない場合は、関連するドメイン全体をすぐに同じポリシーにせず、失敗したリソースの実際のホスト名を確認してください。

DOMAIN-SUFFIX：ドメイン階層を対象にする

DOMAIN-SUFFIX,example.com,PROXYは、example.comとapi.example.comのようなサブドメインを対象にします。これはドメインのサフィックス関係に基づくもので、任意の文字列の末尾を照合するものではありません。notexample.comはexample.comのサブドメインではありません。通常、フィールドの先頭にアスタリスクを追加する必要はありません。この違いを理解すると、ワイルドカードとルール自体のマッチ条件を混同せずに済みます。

サフィックスルールは対象範囲が広いため、追加前に、そのドメイン配下にDIRECTで接続すべき内部サービスがないか確認してください。たとえば内部管理用ホストと公開APIが同じルートドメインを使う場合は、ルートドメインのPROXYルールより先に、内部ホストへ正確なDIRECT例外を設定します。順序が逆だと、内部ホストが先にマッチし、後続の個別例外では結果を変更できません。

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

DOMAIN-KEYWORD：対象範囲は文字列次第

DOMAIN-KEYWORD,ads,REJECTはドメイン名に含まれるキーワードでマッチします。単語の意味を理解するわけではなく、リクエストが実際に広告かどうかも判別しません。ホスト名に指定した文字列が含まれていれば、対象になる可能性があります。そのため、短いキーワードは通常のサービスにも誤って適用されやすくなります。例は構文を説明するもので、あらゆるネットワーク環境に適したブロック設定を推奨するものではありません。実際の管理では、確認済みの正確なホスト名やサフィックスを優先してください。

ルールの種類フィールドの例マッチ範囲
DOMAINapi.example.com指定した完全なホスト名
DOMAIN-SUFFIXexample.comルートドメインとそのサブドメイン
DOMAIN-KEYWORDadsホスト名に含まれる文字列

キーワードを含む通常のホストを除外する場合は、キーワードルールより前に正確な例外を置いてください。ただし例外が増え続ける場合は、パッチを追加し続けるのではなく、キーワードの範囲が広すぎないか見直しましょう。ルール管理の目的は、条件と要件を一致させることです。広すぎるルールを大量の例外で無理に使い続けることではありません。読みやすさや検証にかかる手間も選択の基準にしてください。

ドメインを確認できないときは、推測でルールを追加しない

すべての接続で想定どおりのホスト名が取得できるとは限りません。アドレスを直接指定している場合、リクエストが別の処理を経由する場合、接続情報が不足している場合などは、想定したドメイン条件にマッチしないことがあります。まずアプリ内で確認できる宛先情報を調べ、必要に応じてIPルールを検討してください。ブラウザーのアドレスバーに表示された名前だけを見て、ページが生成するすべての接続に同じマッチ用ドメインが含まれると決めつけないでください。

ドメインフィールドとコード例では半角カンマを使います。複数のホストは別々のルールに記述し、1つのフィールドにまとめないでください。国際化ドメイン名や表記の違いがある場合は、実際のリクエストで確認できる形式を使ってテストします。DOMAINやFINALなどのキーワードの簡単な説明は用語集を参照してください。この章では対象範囲と例外の関係を説明します。

04 / IPアドレスとリクエスト属性

IP-CIDR、GEOIP、USER-AGENT

宛先アドレス、ネットワーク範囲、リクエスト属性に直接対応する要件では、ドメインルールが最適とは限りません。IP-CIDRはIPv4アドレスの集合、IP-CIDR6はIPv6アドレスの集合を表し、GEOIPはアドレスのデータベース上の帰属に基づいて分類します。USER-AGENTは取得可能なリクエストヘッダー情報を参照します。それぞれ必要な情報が異なるため、ドメインルールの別表記として扱わないでください。

IP-CIDR：プレフィックスでアドレス範囲を指定

192.168.0.0/16はIPv4のネットワーク範囲を表します。スラッシュの後の数値はネットワークプレフィックス長であり、ポート番号ではありません。プレフィックス長が大きいほど対象範囲は狭くなり、単一のIPv4アドレスは/32で表せます。ルールを記述する前に、宛先が実際に使用しているアドレスを確認してください。特にサーバーのアドレス、デバイス自身のアドレス、通信先のアドレスを混同しないようにしましょう。通常の宛先振り分けルールが確認するのはリクエストの宛先です。

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

上記の例はプライベートアドレス範囲の書き方を示すもので、すべてのローカルサービスに接続できることを保証するものではありません。デバイス側のネットワーク経路、サーバーの待ち受けアドレス、ファイアウォール、アプリ内の除外設定などが結果に影響することがあります。ルール処理の前に除外された通信は、これらの項目を通らない場合があります。内部サービスの問題を調べる際は、デバイスから実際にそのアドレスへ到達できることも確認してください。

no-resolve：このルールのために名前解決を行わない

IPルール末尾のno-resolveは、このルールとの照合のためにドメインの名前解決を積極的に行わない指定です。設定全体のDNSを無効にする意味でも、すでに取得済みのアドレスを無視する意味でもありません。ホスト名しかなく、利用できるアドレスがまだないリクエストは、このオプション付きのIPルールではマッチできないことがあります。その場合は後続のルールで処理されるため、適切なドメインルールとFINALも必要です。

ローカルネットワーク向けルールでこの指定を使う目的として、プライベートネットワークの確認だけのために多くの通常ドメインを追加で名前解決することを避ける方法があります。ただし、既存の設定に適しているかはリクエスト情報や名前解決の仕組みを確認して判断してください。内部ドメインをDIRECTにする必要がある場合は、DOMAINルールを明示的に追加し、現在のネットワークで正しく名前解決できることを確認する方法もあります。IPルールが偶然必要な情報を取得することだけに頼らないでください。

GEOIP：データベース上の帰属はサービスの識別情報ではない

GEOIP,CN,DIRECTは、宛先アドレスのデータベース上の帰属に基づいてポリシーを選択する指定です。Webページの言語、ドメインのサフィックス、ユーザーの所在地で判定するものではなく、宛先をどの組織が運営しているかを示すものでもありません。アドレスの帰属データには更新や境界の差があり、同じサービスが複数地域のアドレスを使う場合もあります。そのため、GEOIPは広い分類条件として使い、身元確認の根拠にはしないでください。

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

この順序では、明示したホストに先にPROXYを適用し、それ以外のリクエストをGEOIPで判定します。広範なアドレス分類を先に置くと、条件に一致したリクエストの判定が先に終了し、後続のドメイン例外が適用されなくなることがあります。特定のサービスの接続先を安定して指定したい場合は、確認可能なホスト名で要件を明確にしてからGEOIPを補助条件として使うと、動作を説明しやすく管理もしやすくなります。

USER-AGENT：情報を取得できるか先に確認

USER-AGENTは、USER-AGENT,ExampleClient*,DIRECTのように、確認可能なリクエストヘッダーの内容に基づいてパターンマッチします。ExampleClientは例示用のクライアント識別子であり、実際のアプリを示すものではありません。アプリ名による振り分けとは異なり、デバイスに特定のアプリをインストールしただけで、そのアプリの通信すべてが同じヘッダーパターンにマッチするとは限りません。

HTTPSではリクエスト内容が暗号化されるため、ルール処理時にUser-Agentを読み取れるとは限りません。このフィールドを含まないリクエストや、アプリによって内容が異なるリクエストもあります。通常の振り分けを確認するために、復号に関わる操作まで範囲を広げないでください。宛先を既知のドメインで正確に指定できる場合は、ドメインルールを優先してください。USER-AGENTが本当に必要な場合は、アプリ内で該当情報を確認できることを先に確かめ、マッチしないリクエストに適用する明確なフォールバックも設定します。

05 / 通信の処理先

PROXY、DIRECT、REJECTとGlobal Routing

ルール内のポリシーは「マッチした後にどう処理するか」を示し、Global Routingは「現在どの全体ルーティング方式を使うか」を示します。両者は異なる階層です。Ruleが適用されない場合は、まずGlobal RoutingがConfigになっているか確認してください。ProxyまたはDirectを使用中なら、同じリクエストの結果をConfig内の通常のルール順序だけで説明することはできません。ポリシーを検討する前に、まずモードを確認します。

基本ポリシー3種の役割

PROXYは、対象となった通信をプロキシ経由で処理します。接続できるかどうかは、ご自身で用意したサーバーの稼働状況や関連設定に左右されます。DIRECTは、選択中のプロキシサーバーを経由せずに接続する指定ですが、宛先への到達を保証するものではありません。REJECTは、条件に一致したリクエストを拒否する指定であり、失敗時に自動で別の経路へ切り替えるものではありません。いずれも具体的な要件に合わせて使用してください。

ポリシー処理内容よくある誤解
PROXYプロキシ経由で処理マッチしてもサーバーが利用可能とは限らない
DIRECT直接接続で処理直接接続もネットワーク状況に左右される
REJECTマッチしたリクエストを拒否自動的にDIRECTへ切り替わるわけではない

設定ファイルでは基本ポリシーを大文字で表記し、画面上のConfig、Proxy、Directと区別しやすくしています。既存の設定でカスタムポリシー名を使っている場合は、その名前に対応する定義があるか、どのサーバーや選択ロジックを指すかも確認してください。このマニュアルの最小例では3つの基本ポリシーだけを使用します。独自のグループ設定があることを前提とせず、基本的な振り分けのために複雑な構成を追加する必要もありません。

Config、Proxy、Directの違い

Global RoutingのConfigは、選択中の設定ファイルにあるルールに従って通信を振り分けます。Proxyは、取り込み対象の通信をプロキシ経由にし、Directは直接接続にします。ここでいう「全体」を、あらゆるシステム上の制限を回避してデバイス上のすべての通信を処理するという意味に捉えないでください。実際の動作は、システム、アプリが取り込む通信の範囲、関連設定にも左右されます。Global Routingはアプリ内のルーティング選択であり、接続成功を保証するものではありません。

内部サービスへの直接接続と、特定の宛先へのプロキシ接続を両立する場合は、Configで振り分けるのが適しています。一時的にProxyへ切り替えるとプロキシ経路の状態を確認でき、Directへ切り替えると直接接続との比較に使えます。ただし、どちらも診断のための手段であり、ルールを修正したことにはなりません。テスト後は、設定の目的に合った元のモードに戻してください。

FINALで未マッチのリクエストを処理

FINAL,PROXYは、それ以前のルールに一致しなかったリクエストを最終的にPROXYで処理する指定です。FINAL,DIRECTではDIRECTを選択します。ドメインやネットワーク範囲を示すフィールドはないため、通常の条件ルールと同じ3フィールド形式にはしないでください。FINALに到達したリクエストはすべてここで処理されるため、後続の条件ルールが適用されません。FINALはルールの末尾に置いてください。

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

この例は、明示的に指定していない宛先をDIRECTにするもので、すべてのユーザーに適したフォールバックという意味ではありません。FINALを選ぶ際は、まず設定の既定の処理方針を決め、その後で例外ルールを追加します。フォールバックの変更は、個別のDOMAINルールを変更するより多くの宛先に影響します。そのため、検証範囲も広く設定してください。明示的にマッチするドメインを1つテストしただけで、新しいFINAL全体を検証済みと判断しないようにしましょう。

接続状態・ポリシーの適用・通信の成功を分けて確認

システム上で接続済みと表示されても、確認できるのは該当する接続状態だけであり、すべての宛先にアクセスできることを意味しません。ルールがPROXYにマッチしても、選択された処理方向が分かるだけです。その後に認証失敗、接続タイムアウト、宛先側からの拒否が起きる可能性があります。Connectivity Testは接続性を確認する参考になりますが、個別の通信に適用されたルールの確認に代わるものではありません。3つの段階を分けて記録し、テスト結果を相互に置き換えないでください。

アプリを入手する場合は、まずApp Store正規アプリの確認ページで開発者名とアプリIDを確認してください。ShadowrocketはAppleプラットフォーム向けの有料クライアントで、入手先はApp Storeのみです。システム要件はApp Storeのページに記載された内容をご確認ください。アプリの購入と、ご自身で用意するサーバーは別のものです。クライアントの買い切りと回線プランは別です。モードごとの詳しい説明はGlobal Routingの3つのモードの違いをご覧ください。

06 / 優先順位

マッチ順序：先に一致したルールで結果が決まる

ルールは記載された順に評価され、通常は最初に一致したルールのポリシーが適用されます。DOMAINがDOMAIN-SUFFIXより自動的に優先されるわけではありません。また、より細かいネットワーク範囲が前方の広い条件を自動的に上書きすることもありません。条件を具体的にすることは順序を考える際の手がかりですが、ファイルの記述順とは別の優先順位システムではありません。結果を予測するには、ルール一覧の先頭から1行ずつ確認してください。

正確な例外を先に、広い範囲のルールを後に

example.comとそのサブドメインをPROXYにしつつ、intranet.example.comはDIRECTにするケースを考えます。単に2つのルールを並べるのではなく、内部ホストの正確な条件を先に置いてください。intranet.example.comもexample.comのサブドメインです。サフィックスルールが前にあると先にマッチし、後続の個別条件を正しく記述しても結果を変更できません。

# 例外を先に配置
[Rule]
DOMAIN,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

順序を逆にしたリストは、2行を入れ替えただけに見えますが、動作は異なります。トラブル時に「そのルールがあるか」だけを検索しても不十分なのはこのためです。ルールが存在しても、実行されるとは限りません。対象のルールを見つけたら、その上にあるキーワード、ドメインサフィックス、アドレス分類、先に記述されたFINALなど、上書きする可能性のある条件も確認してください。前方のルールに一つでもマッチすれば、対象ルールは評価されません。

異なる種類のルールにも同じ順序が適用される

ドメインルールとIPルールは、それぞれ独立したリストではありません。同じRuleセクション内では、条件ごとに必要な情報は違っても、実際の記述順に沿って評価します。前方のドメイン条件にすでにマッチしていれば、後続のGEOIPで結果が変わるとは限りません。前方のIP条件にマッチすると、後方のドメイン例外が適用されない場合もあります。名前解決が関係する場合は、第2章で説明したアドレス情報の範囲も併せて確認してください。

ルールを具体的な条件から広い条件へ並べる方法は、整理の目安になります。たとえば、特定ホストの例外、ドメインの集合、必要なアドレス範囲、広域の分類条件、最後にFINALという順です。ただし、これは必ず従う固定テンプレートではありません。特定のホストへの接続を拒否する要件がある場合、正確なREJECTルールをドメインサフィックスの許可ルールより前に置くことがあります。順序はポリシーの色ではなく、要件間の優先関係で決めます。

重複・矛盾するルールの扱い

同じ条件と同じポリシーのルールが重複している場合、後の項目は読みづらさを増やすだけになりがちです。同じ条件に異なるポリシーが指定されている場合も、結果は先にマッチしたルールで決まります。管理時は、まず重複ルールの追加元を確認してから、どれを残すか判断してください。古そうに見える行をそのまま削除しないようにしましょう。更新によって追加されたルールもあり、追加元に対処しないと次回の更新で再び現れることがあります。

範囲の重複が必ずしも誤りとは限りません。正確な例外とサフィックスルールの重複は意図的な設計の場合もありますが、その優先関係を説明できる必要があります。用途を説明できない重複は、複数の設定を何度も結合した結果かもしれません。整理する際は、要件ごとにまとめ、それぞれの例外理由を記録してください。ドメイン名のアルファベット順に並べるだけでは、上下の順序に依存する動作が意図せず変わることがあります。

テストマトリクスで各分岐を確認

上記の例をテストするため、少なくとも3種類の宛先を用意します。正確な例外ホスト、同じドメイン配下の通常ホスト、そのドメインとは無関係のホストです。それぞれDIRECTの例外、PROXYの対象範囲、FINALを確認できます。さらに、そのサフィックスに属さない類似の名前もテストし、マッチ範囲を正しく理解しているか確認してください。例示用の名前が実際にサービスを提供している必要はありません。実際の接続テストには、ご自身で存在を確認した宛先を使用してください。

テストでは、宛先、想定するマッチ条件、予想するポリシー、観察結果、失敗した段階を記録します。想定したルールにマッチしない場合は、まず前方に上書きする条件がないか確認してください。ルールにマッチしてもリクエストに失敗する場合は、出口と宛先サービスを調べます。順序を変えたら、新しいテスト接続を開始して古いセッションの影響を避けてください。こうした記録を残すほうが、似たルールを次々に追加するより問題を再現しやすく、設定更新後の再検証にも役立ちます。

07 / マッピングと書き換え

HostとURL Rewrite：振り分けルールの代用にはしない

Hostは指定した名前に対応するアドレスを変更し、URL Rewriteは条件式に一致するリクエストURLを処理します。Ruleは適用するポリシーを決定します。3つは同じファイルに記述できますが、互いの代用にはなりません。特定のホストをDIRECTにする場合は、まず振り分け条件を明確にしてください。直接接続するためだけにホストを固定アドレスへマッピングしたり、関係のないサービスへアクセス先を変える書き換えを行ったりしないでください。

Hostマッピングで固定するのは名前解決の対応関係

たとえばtest.example.com = 192.0.2.10は、ホスト名をアドレスに静的に対応させる例です。このアドレスは文書の例示用であり、実際にアクセスできるサービスではありません。Hostの項目にPROXY、DIRECT、REJECTのフィールドはありません。後続の接続にどのポリシーが使われるかは、Ruleと実際のリクエスト情報を併せて判断します。アドレスのマッピング成功と振り分けの成功を同じものと見なすと、問題の原因を見誤ることがあります。

[Host]
test.example.com = 192.0.2.10

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

静的マッピングは、ご自身で管理するテスト環境など、限られた用途に適しています。公開サービスでは、動的アドレス、負荷分散、障害時の切り替えを使う場合があります。アドレスを長期にわたり固定すると、接続できなくなったり、ネットワーク状況に応じた本来の振り分けを妨げたりすることがあります。アドレスの帰属、用途、管理責任を確認できる場合に限ってマッピングを追加し、解除する条件も記録してください。一度の名前解決で得たアドレスを、そのまま設定に固定しないでください。

マッピングをしても証明書やサービスの識別情報は変わらない

ホストを別のアドレスにマッピングしても、そのアドレス上のサービスが元のホスト名の正当な提供元になるわけではありません。HTTPSでは証明書やリクエストのホスト名なども確認されます。対象サービスがそのホスト名に対応していなければ、証明書の不一致やサービス側の拒否が発生することがあります。このようなエラーを、身元確認を無効にして「マッピングが有効」と証明しようとせず、アドレス、ホスト名、サービス設定が一致しているか再確認してください。

マッピングの想定どおりに動作しない場合は、アプリがその名前解決情報を実際に使用しているか、既存の接続に古いアドレスが残っていないか、別の方法でアドレスを取得していないかも確認してください。まずマッピングを1項目だけ解除して比較し、その後、再設定して新しい接続を開始します。Hostが原因だと確認できてから、IPルールとの相互作用を検討してください。マッピングと振り分けを同時に変更すると、原因を特定しにくくなります。

URL Rewriteを構成する3つの要素

よくあるリダイレクト設定は、マッチ式、置換先、ステータスコードで構成され、各フィールドを所定の構文で区切ります。次の例は特定のホストに対するHTTPのプレフィックスをHTTPSに置き換え、302を使用します。式中のピリオドはバックスラッシュでエスケープし、任意の文字として解釈されないようにしています。先頭の^はリクエストURLの先頭からマッチさせ、不要な一致を減らします。

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

この例は構文を説明するものであり、Webサイト側の正しいHTTPS設定に代わるものではありません。マッチ範囲にはスラッシュの位置も含まれるため、パス末尾のスラッシュがないURL、異なるポート、異なるホストへの入力が同じ条件になるとは限りません。トップページ、パス付きのリクエスト、クエリパラメーター付きのリクエストをそれぞれテストし、置換後のURLが想定どおりか確認してください。式の範囲を広げるほど、マッチさせてはいけない入力もテストする必要があります。

ループや確認範囲外の書き換えを避ける

ある書き換えの結果が別の書き換え条件に再び一致すると、リダイレクトが繰り返されたり、2つのURL間でループしたりすることがあります。ルールを追加する前に、元のURL、最初の置換結果、その後に一致する可能性のある条件を書き出してください。ブラウザーがリダイレクト結果をキャッシュする場合もあるため、デバッグ時はその影響を考慮し、キャッシュ内の遷移を現在の設定が有効な証拠と見なさないでください。ルールを解除した後も、新しいリクエストで改めて確認します。

暗号化されたリクエストの内容が、ルール処理時に自動的に確認できるとは限りません。URL Rewriteは、あらゆるHTTPSの内容を変更できることを保証する機能ではありません。通常の振り分け設定に、復号機能を追加する必要はありません。通信の出口を変えるだけならRuleを、名前に対応するアドレスを確認するならHostを、リクエストURLの変換を管理する必要がある場合に限りURL Rewriteを確認してください。この3つの役割を明確にすると、問題の箇所を見つけやすくなります。

08 / 継続的なメンテナンス

設定の検証：最小限の構成から安全に管理

設定を検証する目的は、一度アクセスに成功することではなく、想定した条件でルールが想定どおりに動作し、その結果を説明できることを確認することです。一連の手順には、元の設定の保存、動作モードの確認、項目を一つだけ変更、新しいリクエストの開始、マッチ結果と接続結果の確認、記録と復元手段の確保が含まれます。各段階を分けることで誤判定を減らし、サブスクリプションや設定を更新した後の再確認も容易になります。

手順1：現在実際に使われている設定を確認

まずHomeで接続状態、選択中のサーバー、Global Routingを確認し、次にConfigで使用中のファイルを確かめます。同じ名前や似た名前のファイルがある場合は、名前だけに頼らず内容も直接確認してください。ご自身で用意したサーバーのパラメーターは、入手元の情報と一致させます。ルールの検証と同時にプロトコル、ポート、認証フィールドも変更すると、接続結果の原因を特定できなくなるため、変更を分けてください。

まだ接続に成功したことがない場合は、まずはじめにに沿って設定してください。多数のルールや書き換えを含む設定をすぐにインポートしないでください。アプリの入手や購入済みアプリの復元については、Ruleを変更するのではなく購入済みアプリの復元方法を確認します。App Storeで正規アプリを確認する際の開発者名はShadow Launch Technology Limited、アプリIDは932747118です。システム要件はApp Storeのページに記載された内容をご確認ください。

手順2：説明可能な範囲まで設定を絞り込む

問題が起きた場合は元のファイルを保存し、コピー側ではテスト対象に関係する条件と明確なFINALだけを残してください。まず正確なDOMAINを検証し、その後サフィックス、アドレス分類、Host、書き換えルールを少しずつ戻します。唯一使える設定を直接削除したり、テスト用コピーでリモートの設定を上書きしたりしないでください。設定を最小限にする目的は、影響する要素を切り分けることです。日常的に数個のルールだけを使うよう求めるものではありません。

[Rule]
# example.com をユーザー自身が存在を確認したテスト用ホストに置き換える
DOMAIN,example.com,PROXY
FINAL,DIRECT

この構成をテストする際は、DOMAINに明確にマッチする宛先と、マッチせずFINALを確認できる宛先を選びます。両方の結果が想定と異なる場合は、Global RoutingがConfigであることと、コピーした設定が選択されていることを確認してください。PROXY対象だけが失敗する場合はプロキシ経路を、DIRECT対象が失敗する場合は現在のネットワークから直接接続できるかを個別に調べます。一度の失敗だけで設定構文全体に問題があると判断しないでください。

手順3：よくある4種類の失敗を切り分ける

現象最初に確認すること次の手順
ルールにマッチしない設定の選択状態、モード、上方のルールによる上書き宛先情報を確認し、ルールを最小限に絞る
マッチしたがタイムアウトする選択中の出口、サーバー、宛先への到達性接続経路をそれぞれテストする
一部のリソースだけ失敗する失敗したリソースの実際のホスト名とポリシー関連するリクエストを一つずつ確認する
変更後も古い結果が表示される古い接続、キャッシュ、設定の選択状態新しいリクエストで再確認する

アプリ内で利用できる接続記録やログは、宛先、ポリシー、失敗した段階の確認に役立ちます。具体的な表示方法は現在のアプリ画面に従ってください。記録にアドレスしかない場合、推測でドメイン名を補わないでください。ドメイン名だけでアドレスがない場合も、特定のネットワーク範囲に属すると断定しないようにしましょう。Connectivity Testは接続性の判断を補助するものであり、特定のWebページやAPIへのリクエストは個別にテストする必要があります。

手順4：更新による上書きとルールの再検証

サブスクリプションの更新と設定の更新は分けて確認してください。サーバー情報の更新で、現在のRuleが必ず変わるわけではありません。一方、リモート設定の更新では、ローカルで変更した内容が並べ替えられたり置き換えられたりする可能性があります。更新後は、正確な例外、よく使う対象範囲、FINALの3種類を最低限再テストしてください。HostやURL Rewriteを使っている場合は、マッピング先とリダイレクトの境界も追加で確認します。メインページが開けることだけ確認して、メンテナンスを終えないようにしましょう。

メンテナンス記録には変更理由、変更前後のルール、予想結果、実際の結果を記載できます。サブスクリプションの完全なURL、認証情報、その他の機密情報は含めないでください。他の人に問題を説明する場合は、実際のホスト名や認証情報を置き換えたうえで、ルールの順序、フィールド構成、必要なエラー情報は維持します。パスワードだけを削除しても、認証パラメーターを含むサブスクリプションURLが残っていれば、アクセス権が漏れるおそれがあります。

ルールを保存したのに、なぜ変化が見えないのですか？

選択中の設定とGlobal Routingを確認し、次に古い接続やキャッシュを調べます。新しいテストリクエストを開始して、先にマッチするルールがないか確認してください。追加したルールが存在するかを見るだけでは不十分です。

PROXYにマッチすれば、設定全体が正しいといえますか？

そのリクエストで該当するポリシーが選択されたことだけが分かります。サーバー接続、認証、名前解決、宛先サービスが失敗する可能性は残ります。他のルール分岐と、どのルールにもマッチしないリクエストに適用されるFINALも確認してください。

最後に、検証済みで元に戻せる設定を1つ保存し、不要と確認できた試験用ルールを整理してください。ルールが多いほど安定するわけではありません。各条件の目的、順序、検証方法を説明できることが、長期的なメンテナンスに役立ちます。初回接続の手順を再確認する場合は、既定サーバーの選択とConnectivity Testによる確認をご覧ください。用語を確認する場合は用語集でキーワードを検索できます。