Shadowrocket 設定ガイド ルールと優先順位

General と DNS：名前解決と接続経路は別

General の設定は、リクエストがルールで判定される前後の基本動作に影響するため、1つのドメインルールより広い範囲に作用することがあります。DNS はドメイン名をアドレスに変換し、Rule はリクエストの処理方法を決め、サーバー情報はプロキシ接続を確立します。この3つは関連していますが、互いの代わりにはなりません。ドメインが名前解決できても接続先のサービスにアクセスできるとは限らず、プロキシサーバーに接続できても、すべてのドメインを適切に解決できるとは限りません。

原因を説明できる基準をまず作る

[General]
bypass-system = true
dns-server = system

ここでの dns-server = system は、システムのDNSを基準として使用する設定です。現在のネットワークでの基本的な名前解決を確認しやすくなりますが、すべてのネットワークで適切に動作することを保証するものではありません。bypass-system はシステム通信を迂回させる共通設定であり、「すべてのプライベートアドレスを直接接続する」ための代替設定ではありません。個別のアドレスルールが必要かどうかは、対象アドレス、現在のネットワーク、リクエストの記録をもとに判断してください。設定名だけから適用範囲を推測しないようにしましょう。

最初のトラブルシューティングでは、General のオプションを必要最小限にして、変更ごとの影響を説明できる状態にします。DNSの変更、ルールの追加、サーバーの切り替えを一度に行い、その後ページが表示されたとしても、どの変更が有効だったのか分かりません。サーバーと Global Routing を固定して、変更する変数を1つに絞り、同じ対象へ再度リクエストして結果を記録する方法が確実です。動作が戻ったら、その変更を残すか判断してください。

ドメインルールとアドレスルールで必要な情報は異なる

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD はリクエストから識別できるドメイン名を使い、IP-CIDR と GEOIP はアドレス情報を使います。先行するドメインルールでポリシーが決まる場合、後続のアドレスルールのためだけに追加の照合を行う必要はありません。アドレスルールまで判定が進んだ場合、クライアントが有効な接続先アドレスを取得している必要があることがあります。ここでの名前解決と、最終的な接続に使われる名前解決の経路は、単純に同じものとして扱えません。特にプロキシプロトコルやリモート側での処理方法によって異なります。

アドレスで開始されたリクエストや、クライアントがドメイン情報を十分に取得できないリクエストには、ドメインルールで照合する対象がありません。ブラウザーのアドレスバーにサイト名が表示されていても、すべての個別リクエストが同じドメインを含むとは限りません。接続記録を確認し、ドメイン、接続先アドレス、ヒットしたルールタイプ、適用されたポリシーをそれぞれ確かめてください。1つのページが複数のドメインを使う場合は、トップページのドメインだけでなく、失敗したリクエストを個別に調べます。

DNS設定変更後に確認する範囲

ネットワークを切り替えた後に問題が起きた場合は、まず現在のネットワークで同じドメインを解決できるか確認し、次に新しいリクエストが意図したポリシーで処理されているかを確認します。キャッシュがテスト結果に影響する場合があり、既存の接続では再解決が行われないこともあります。対象のページを閉じて開き直し、必要に応じてアプリ内の操作で接続を再確立してから、新しい記録を確認してください。一度の再読み込みで成功したからといって、継続的に解決できるとは限りません。アドレスが変わっただけで名前解決の異常と判断しないようにしましょう。

ローカルネットワークのリソースでは、システムDNSが内部名の解決を担うことがあります。DNSの参照先をむやみに変更すると、それらの名前を解決できなくなる可能性があります。パブリックドメインでも、ネットワークによって異なるサービスアドレスが返されることがあり、その違いだけで障害とは言えません。まず返されたアドレスに到達できるか、適切なプロトコルでリクエストしているか、サーバー証明書がドメイン名に対応しているかを確認してから、DNSの変更を検討してください。HTTPSサイトにアドレスを直接入力してアクセスしても、通常のドメイン名を使うリクエストを正確に再現できるとは限りません。

Host マッピングで、動的ドメインの名前解決問題を長期的に覆い隠さないでください。マッピングするとアドレスが固定され、サービスが移転した後も古いアドレスを参照し続けることがあります。その結果、DNSを変更しても効果がないように見える場合があります。同じドメインに Host の項目とドメインルールの両方がある場合は、それぞれを分けて記録してください。前者はアドレスの参照元を変更し、後者はポリシーを決めます。マッピングを削除する前に、ローカルのサービスが引き続き依存していないかも確認し、トラブルシューティングを新たなアクセス問題に広げないようにしましょう。

プライバシーに配慮して診断する際は、必要な接続先情報だけを残してください。DNSの記録にはアクセス先のドメインが含まれる場合があります。スクリーンショットやテキストを共有する前に、個人の業務名、アカウント情報、サブスクリプションURLを削除してください。接続失敗をさらに調べる場合は、使い方ガイドのトラブルシューティングも参照し、権限、サーバー、ネットワークの状態を確認します。DNSは個別の確認項目として調べ、あらゆる障害の原因と決めつけないようにしましょう。

アドレスとリクエストの特徴：IP-CIDR、GEOIP、USER-AGENT

アドレスルールは、サービスのドメインが一定かどうかではなく、接続先アドレスやその地域情報をもとに判定します。プライベートネットワーク、既知のアドレス範囲、後続の広範な分類には適していますが、特定サイトのサービス全体を正確に表すものではありません。同じサービスが複数のアドレス範囲を使う場合があり、異なるサービスが同じインフラを共有することもあります。ある時点で確認したアドレスを特定サイトの恒久的な識別子とみなすと、実際の状態とルールが徐々にずれていきます。

IP-CIDR とプレフィックス長

[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

CIDR はネットワークアドレスとプレフィックス長で表します。IPv4 の /32 は単一のアドレスを示し、プレフィックスが短いほど対象となるアドレス範囲は広くなります。192.168.0.0/16 は「最後の2つの部分が0のアドレスだけ」ではなく、プレフィックス全体の範囲を表します。上の例は、一般的なプライベートIPv4アドレスの範囲と IPv6 のユニークローカルアドレスの範囲を示しています。構文の例であり、すべてを追加すべきという意味ではありません。実際の接続先と現在のネットワークに応じて判断してください。

プライベートアドレスへの直接接続はポリシーを決めるだけで、存在しないローカルルートを作ったり、異なるネットワークで同じプライベートアドレスを自動的に相互接続したりするものではありません。別のネットワーク内にある接続先には、引き続き適切なネットワーク到達性が必要です。複数のネットワークが同じプライベートアドレスを使う場合、アドレスの意味が衝突することもあります。DIRECT に一致しても接続できない場合は、CIDR の範囲をむやみに広げるのではなく、接続中のネットワーク、接続先デバイスの稼働状況、ポートの開放状態を確認してください。

no-resolve の適用範囲

no-resolve は、そのアドレスルールとの照合だけを目的としたドメイン解決を避けるための指定です。リクエスト全体でDNSを使わないという意味でも、対象を直接接続に強制する設定でもありません。リクエストに使用可能な接続先アドレスがすでに含まれていれば、アドレスルールに一致する場合があります。ドメイン名だけがあり、有効なアドレス情報がない場合、このルールが名前解決を実行してから判定すると期待しないでください。デバッグでは、その時点でリクエストがどの情報を持っていたかを確認する必要があります。

no-resolve を追加するかどうかは、そのルールの役割によって決めます。明確なプライベートアドレスへの接続では、すべてのパブリックドメインに対して余分なアドレス照合を試みないほうが動作を説明しやすい場合があります。解決後のアドレスで分類する必要があるリクエストでは、このパラメーターを省略した場合の名前解決への依存を理解してください。すべてのルールの末尾に機械的に追加しないでください。DOMAIN や FINAL にアドレスルールのフィールド構成を流用することもできません。

GEOIP はアドレスの分類であり、サイトの所属を示すものではない

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

GEOIP,CN,DIRECT は、利用可能な接続先アドレスと地理情報データベースに基づいて判定します。ページ内の文字、ドメインのサフィックス、ユーザーの所在地は判定基準ではありません。中国語のページでもアドレスが CN に分類されるとは限らず、ほかの言語のページでも CN に分類される場合があります。CDN、アドレスの移転、データベースの違いも結果に影響します。そのため GEOIP は広範な分類ルールとして使い、明示的に処理する必要があるドメインの例外より後に配置してください。サイトがどの組織に属するかを証明するためのものではありません。

USER-AGENT は汎用的なアプリ選択機能ではない

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

USER-AGENT は、識別可能なリクエストに含まれる User-Agent フィールドを照合します。上の ExampleClient は説明用の文字列で、実在のアプリを示すものではありません。アプリ単位の振り分けと同じ機能ではありません。複数のリクエストで同じフィールドが使われることもあれば、同じアプリが異なるフィールドを送信することもあります。また、ルールで読み取れる情報がまったくない通信もあります。特に暗号化されたリクエストでは、クライアントがリクエストヘッダーを当然に確認できると想定しないでください。

USER-AGENT ルールに一致しない場合は、まずフィールドが参照可能か、実際の内容がパターンに合っているかを確認し、その後でルールの位置を調べます。ルールを機能させるために、不要な通信まで確認対象に広げないでください。暗号化されたコンテンツの処理に関わる場合は、許可、証明書の信頼、プライバシーへの影響を別途検討してください。本ページのアドレスとポリシーの例では、追加の暗号化コンテンツ処理を有効にする必要はありません。要件を明確なドメインで表現できる場合は、まずドメインルールで確認するのが適切です。

ルールの優先順位と FINAL：最初に一致したルールで終了

Rule を読むときは、上から順に1行ずつ判定することが最も重要です。リクエストが適用可能なルールに一致すると、そのポリシーが使われ、それより「具体的な」ルールを探して下へ読み進むことはありません。DOMAIN が DOMAIN-SUFFIX より自動的に優先されたり、ルールタイプの名前だけでドメインルールがアドレスルールに優先されたりすることはありません。優先順位を決めるのは、まず設定ファイル内の位置です。この仕組みを理解するほうが、多くのルールキーワードを覚えるより設定ミスの防止に役立ちます。

例外は範囲の広いルールより前に置く

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

この例では、まず api.example.com に PROXY を適用する例外を設定し、次に同じドメイン配下のほかのリクエストを DIRECT に渡します。その後、プライベートアドレスと CN の分類を処理し、最後に PROXY を既定のルールとして適用します。各行にはそれぞれ役割があります。サフィックスルールを先頭に移動すると、api.example.com は先に DIRECT に一致し、後にある完全一致の例外は適用されません。行の間にコメントや空行を入れても、順序は変わりません。

「例外を先に置く」とは、すべての DOMAIN ルールをファイル全体の先頭に集めるという意味ではありません。同じ判定範囲では、対象の狭いルールを広いルールより前に置くということです。実際の設定では用途ごとにグループ分けできますが、グループをまたぐ重複も確認してください。前方にある DOMAIN-KEYWORD が、後続の複数のサービスドメインをすでに含んでいる場合があります。アドレス範囲のルールが、後で特別に処理したい接続先を含むこともあります。グループ見出しは人が読みやすくするためのもので、クライアントに新たな優先順位の階層を作るものではありません。

FINAL の構造と配置

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

FINAL は、それ以前のルールに一致しなかったリクエストに適用する最後のルールです。タイプとポリシーだけを記述し、ドメインやアドレスのフィールドは不要です。通常は Rule の末尾に配置します。FINAL を途中に置くと、後続の通常ルールで残りのリクエストを処理できなくなります。ファイル内に FINAL が複数ある場合も、段階的に使う予備の出口とは考えないでください。最終的なポリシーを1つに定め、具体的な例外は前のルールで指定します。

FINAL,PROXY と FINAL,DIRECT は既定の動作が異なるため、どちらかが常に正しいとは言えません。前者は分類されなかったリクエストをプロキシポリシーに渡し、後者は直接接続します。どちらを選ぶかは、既定の経路をどうしたいか、前に置いた例外が十分かどうかで決まります。設定をコピーする場合は特に最後の行を確認してください。前のルールがほとんど同じでも、既定のポリシーを変えると、ルールに記載されていない多くの接続先で出口が変わることがあります。

手作業で判定してルールの重なりを見つける

ルールを確認するときは、代表的な接続先をいくつか選び、上から順に判定してください。完全一致の例外が最初の行に一致するか、同じドメイン配下の別ホストがサフィックスルールに一致するか、プライベートアドレスがアドレスルールに進むか、残りのリクエストが最終的に FINAL に到達するかを確認します。想定するポリシーだけでなく、どの行で判定が止まったかも記録してください。競合を見つけやすくなるだけでなく、一見正しいルールに一致記録が出ない理由も説明できます。

アドレスルールを判定に使う場合は、接続先アドレスがすでにあるか、no-resolve により該当行が名前解決を行わないかも記録します。アドレス情報のないドメイン名だけを机上で確認しても、GEOIP の実際の結果を正確に予測できません。ログが手作業での判定と異なる場合は、クライアントが認識した接続先情報を優先して確認し、その後で現在有効なファイルを調べます。アドレスルールを一致させるために、すべてのドメインルールを削除しないでください。

2つの設定ファイルを統合するときは、Rule の内容をそのまま連結しないでください。1つ目の FINAL によって、2つ目のルールがすべて適用されなくなる場合があります。範囲の広いキーワードが、2つ目にある例外より先に一致することもあります。まずセクションを分け、FINAL を取り除き、用途別に具体的なルールを統合してから、FINAL を1つだけ追加します。同じ対象でポリシーが異なる競合は手動で選択し、意味が同じことを確認してから完全一致の重複行を整理してください。

長いファイルをメンテナンスする場合は、ルールの追加を小さな変更としてローカルコピーに反映し、挿入位置、対象範囲、想定するポリシー、テスト結果を記録してください。しばらく運用してから同種の項目をまとめるようにすると、トラブルのたびに新しいルールを先頭へ積み上げずに済みます。ルールの順序は、理由を説明できる構成に保ちましょう。なぜその行がそこにあるのかを覚えているのが管理者本人だけでは、後の更新や障害からの復旧が難しくなります。

確認とメンテナンス：1つのリクエストから変更箇所を特定

設定確認の目的は「ファイルが完全に見える」ことを証明するのではなく、想定する各動作を実際のリクエストから説明できるようにすることです。有効なテストでは、現在のネットワーク、Global Routing のモード、Config ファイル、選択中のサーバー、対象ドメイン、確認できた結果を最低限記録します。これらの前提がない場合、同じページの表示が前後で異なる原因は、編集したルールではなくキャッシュ、既存の接続、ネットワークの変化、出口の切り替えかもしれません。

4つの層に分けて問題を絞り込む

第1層では、リクエストが現在のクライアントの処理対象に入っているかを確認します。接続が有効か、システムの許可があるか、正しいファイルを使用しているかを確かめてください。第2層では、ドメイン名やアドレスなど、接続先の情報が利用できるか確認します。第3層では、一致したルールとポリシーが想定どおりかを確かめます。第4層で初めて、該当する経路で接続できるかを調べます。この順で確認すれば、サーバーは正常なのに誤って REJECT に一致している状況で、サーバー情報を何度も入力し直すような手戻りを防げます。

Connectivity Test は接続条件の確認に役立ちますが、テストが成功しても実際の通信に必要な条件がすべて満たされているとは限りません。テスト方法によって対象やプロトコルが異なる場合があり、1つのページが複数のドメインにリクエストを送ることもあります。サイトに問題がある場合は、失敗した具体的なリクエストを1つ選び、ドメイン、アドレス、一致したルール、失敗した段階を確認してから、ページ全体の動作を調べてください。Data の統計は利用状況の確認には役立ちますが、特定のルールに一致したことを単独で証明するものではありません。

元に戻せる最小限の変更を行う

一度に変更するのはルール1つ、または関連する設定1つに絞り、変更前後の内容を保存してください。テスト結果が変わらない場合は、リクエストが再確立されたか、より前のルールに一致していないかを確認してから、変更を戻すか調査を続けるか決めます。効果のなかった例外を残したまま次々に追加しないでください。次のテストで確認する変数が増えてしまいます。設定ファイルが長い場合は、コピー上に必要な General と少数の Rule だけを残し、問題を再現できる最小の状態を作ります。

[General]
bypass-system = true
dns-server = system

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

この診断用の例では、1つのサンプルドメインを PROXY に渡し、それ以外は DIRECT にすることで、確認対象を絞っています。長期利用向けの汎用設定ではありません。適用する前に、既定のポリシーを変更するとほかのリクエストにも影響することを理解してください。想定どおりの結果が得られたら、元の設定から関連するルールをグループごとに戻し、どのグループで一致結果が変わったか特定します。それでも失敗する場合は、照合範囲を広げるのではなく、ドメイン情報、プロキシ出口、接続先サービスを引き続き確認してください。

更新、バックアップ、機密情報の取り扱い

設定のバックアップとサーバーのサブスクリプション情報は、分けて保存してください。ファイルによっては、サーバー情報、認証情報、個人を特定できる情報を含むリンクが記載されています。主な内容がルールに見える場合でも、共有前に全体を確認しましょう。トラブルシューティング用の資料を共有する場合は、セクション名、ルールタイプ、フィールド構成、順序を保ち、必要に応じて実際のドメインを example.com に置き換えます。アカウント情報とサブスクリプション情報は削除してください。スクリーンショットの一部だけを隠し、ほかの識別可能な項目を見落とさないようにしましょう。

アプリのアップデートは App Store から行います。アプリの入手方法と正規版の確認は正規版の確認方法をご覧ください。設定ファイルの更新方法は、実際に利用しているファイルの配信元によって異なります。この2種類の更新を混同しないでください。アプリの更新後に初めてアクセスに失敗したからといって、ルール構文が変わったと判断するのも避けましょう。まずファイル、モード、サーバー、ネットワークを確認し、個々の設定項目がアプリ内の説明に沿っているかを調べてください。

サービス提供元のサブスクリプションを使用している場合は、更新の前後でサーバー項目の名前や設定値が変わっていないか、以前の選択が引き続き有効かを確認します。個別の共有リンクとサブスクリプションリンクは用途が異なります。読み込んだ項目がどちらか分からない場合は、共有リンクとサブスクリプションリンクの違いをご覧ください。本ページでは手元にある情報の使い方を説明しています。サーバー情報とサブスクリプションは、ご利用のサービス提供元から入手してください。

最後に回帰テストを行います。完全一致の例外、ドメインサフィックス、プライベートアドレス、FINAL から代表的な接続先を1つずつ選び、適用されるポリシーを確認してください。Host または URL Rewrite を使用している場合は、マッピングとリダイレクトの連鎖もそれぞれ確認します。テスト後は使用予定の Global Routing に戻し、元に戻せるコピーを保管してください。よくある接続の問題は使い方ガイド、通信量の読み方はData の通信量統計ガイドをご覧ください。再現可能なリクエストと明確な変更記録に基づくメンテナンスは、ルールを増やし続けるより効果的です。