CONFIG / RULE / POLICY

Shadowrocketのルール・設定リファレンス完全ガイド

このページでは、Shadowrocket公式マニュアルのうち、設定構成、照合条件、トラブルの特定方法を体系的に解説します。サブスクリプションを初めて追加して接続する場合は、先に使い方ガイドをご覧ください。基本接続を確認したら、このページの目次に沿ってルールを調整できます。

すべての例は構文説明用で、ドメイン名とアドレスは例示用です。操作前に、ご自身のサブスクリプションまたはサーバー情報を用意し、現在使える設定を保存してください。

1. Configファイルの構成と設定の範囲

サーバー情報・サブスクリプション・Configファイルの違い

Shadowrocketでは、サーバー情報、サブスクリプション、Configファイルがそれぞれ異なる役割を担います。サーバー項目には、接続先のアドレス、ポート、認証情報、プロトコルパラメータを設定します。サブスクリプションは、登録済みのサーバー項目をまとめて管理するためのものです。Configファイルは、リクエストの解析・照合・処理に使うルールを構成します。これらは同じ利用手順の中で登場することがありますが、互いに置き換えられるものではありません。サーバーのサブスクリプションを追加しても、現在どのConfigを使っているかは別途確認が必要です。また、Configを選んだだけでは、利用可能なサーバーがあるとは限りません。トラブル時はこの2つを分けて確認すると、関係のない箇所を何度も変更せずに済みます。

Configは通常、セクションごとに分かれたテキストで構成されています。角括弧で囲まれた行がセクションの開始を示し、次のセクション見出しまでがその内容です。一般的な例では、[General]に共通設定、[Rule]に順序のある照合ルール、[Host]に指定ホスト名のアドレスマッピング、[URL Rewrite]に表示可能なリクエストアドレスの書き換えルールを記述します。セクション名は説明文ではないため、日本語に変更できません。ルール内のカンマ、等号、パラメータの位置も構文の一部です。編集時は半角英数字の記号を使ってください。

セクション主な役割確認ポイント
[General]共通動作と名前解決に関する設定パラメータ名、値、システムとの連携
[Rule]条件に応じた接続ポリシーの選択ルールの順序、条件、ポリシー名
[Host]指定ホスト名のアドレスマッピングマッピング先が現在も有効か
[URL Rewrite]式に基づく表示リクエストアドレスの書き換え照合範囲、対象、動作

短い例で見る各セクションの関係

以下の例では、共通設定とルールを分けて記述しています。dns-server = systemは、システムが提供する名前解決設定を使うという意味であり、すべてのネットワークで高速になることを保証するものではありません。2つのドメインルールは異なる接続先を指定し、最後のルールがそれまでに一致しなかったリクエストを処理します。これは構成を示す例であり、既存ファイルをそのまま置き換えるための完全な設定ではありません。特に、PROXYで実際に接続する先は、アプリ内で現在選択されているサーバーを確認してください。この数行だけから接続先を判断することはできません。

[General]
dns-server = system

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

長いConfigを読むときは、まずすべてのセクションを確認し、最後にあるデフォルトルールを見つけてから、ドメインルールとアドレスルールを確認するのがおすすめです。最初にファイル全体の範囲を把握し、その後で例外条件を確認できます。特定の大きなセクションを別のファイルへそのままコピーするのは避けてください。同じ名前のポリシー、既存ルール、共通設定が異なる場合があり、単独では正しい構文でも、統合後にリクエストの接続先が変わることがあります。用途がわからない設定は、目的を確認してから残すか削除するかを判断してください。

保存・選択・復元用コピーの確保

Configを編集する前に、現在のファイルを複製し、内容を判別できる名前で保存してください。編集後は保存状態を確認し、変更したファイルが実際に選択されているかも確認します。エディタで開いて内容を見ただけでは、使用中のConfigが切り替わったことにはなりません。さらに、Global Routingも確認してください。Configにルールがあることと、リクエストが実際にそのルールで処理されることは別の条件です。初めて操作する場合は基本の使い方を参考にConfigを選択してから、このページで構文を確認してください。

リモート管理されるConfigには、更新時の注意点もあります。リモートの内容で置き換えられるファイルに個人ルールを直接追加すると、次回の更新で変更が消える場合があります。元のファイルを保存し、個人用の作業コピーを別途作成して、変更内容と目的を記録しておくと安心です。サブスクリプションの更新、Configの更新、アプリの更新もそれぞれ別のものです。サブスクリプションは主に登録済みサーバー項目、Configの更新はルールテキストに関わります。アプリの入手と更新はApp Storeから行います。

2. Global Routingと接続ポリシー

まずモードを確認してから、ルールの結果を調べる

Global Routingは、ルールを処理に使うかどうかを判断する最初のポイントです。ConfigモードはConfig、プロキシモードはProxy、直接接続モードはDirectです。通常のルールトラブルシューティングでは、まずConfigに切り替えてからファイルの内容を確認します。別のモードでは、ドメインルールだけを変更しても期待した結果にならないことがあります。ここで説明するのは接続ルーティング全体の選択であり、アプリがシステムの制限を回避することや、すべてのシステム通信を同じように確認できることを意味するものではありません。

モード名とルール内のポリシーキーワードは、異なる階層にあります。Proxyは画面上のモード名、PROXYはルール内で指定するポリシー値です。DirectとDIRECTも同様です。表記は似ていますが、モードの変更は特定のルールのポリシー変更とは異なります。すべてのリクエストの接続先が一斉に変わった場合は、個々のドメインルールがすべて無効になったと考える前に、モードと現在選択中のConfigを確認してください。

モード画面上の表記使い方と確認のポイント
ConfigConfig現在のConfigを使って照合条件とポリシーを確認
プロキシProxyプロキシ経由でのサーバー接続を確認
直接接続Directローカルネットワークから直接接続した場合と比較

PROXY、DIRECT、REJECTの意味

PROXYは、プロキシ経由で処理することを示しますが、それ自体がサーバーアドレスを表すわけではありません。接続できるかどうかは、選択中のサーバー、プロトコルパラメータ、ネットワーク到達性によって決まります。ルールが正しくPROXYに一致した後にタイムアウトしても、ルールの誤りとは限りません。サーバーが有効か、リクエストに必要な転送方式に対応しているか、認証情報が一致しているかを確認してください。すべてのエラーをルールの問題とみなすと、接続確立時に起きている本当の問題を見落とすおそれがあります。

DIRECTは宛先へ直接接続することを示します。名前解決が省略されるわけではなく、宛先への接続が保証されるわけでもありません。ローカルネットワークのルーティング、ファイアウォール、名前解決結果、宛先側の状態も接続結果に影響します。REJECTは条件に一致した接続を拒否します。明確にブロックしたい範囲に使用します。拒否されたリクエストは通常完了しませんが、アプリ上ではルール名ではなく読み込み失敗として表示されることがあります。照合記録とあわせて判断してください。

[Rule]
DOMAIN,service.example.com,PROXY
DOMAIN,intranet.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
FINAL,PROXY

例では、ポリシーごとの範囲を把握しやすくするため、3つのホスト名を分けています。実際のConfigで、広い範囲を対象にする拒否ルールを先に置き、その後に特定ホスト名を許可するルールを追加するのは避けてください。前のルールが一致すると、後の例外は評価されません。また、REJECTをサーバー障害時の代替経路として扱わないでください。リクエストを拒否するためのもので、別の接続先を探す機能はありません。

サーバーを選んでも、すべてのリクエストがそのサーバーを経由するわけではない

Configモードでは、サーバーの選択とルールのポリシーが組み合わさって接続結果が決まります。リクエストがDIRECTに一致した場合、サーバーを選択していても直接接続されます。逆に、デフォルトポリシーがPROXYでも、それより前にある直接接続や拒否のルールが無視されるわけではありません。サーバー名からわかるのは「プロキシ経由の接続にどの接続先を使うか」であり、「このリクエストがなぜこの経路を通るのか」は、それだけでは判断できません。

プロキシ接続と直接接続を比較するときは、同じテスト対象を使い、モード、ネットワークの種類、テストした時間帯をそれぞれ記録してください。テスト後は元のConfigモードに戻します。サーバーの変更、DNSの変更、モードの切り替えを同時に行うと、改善した場合に何が有効だったか判断できません。プロキシ経由だけ失敗する場合は、接続タイムアウト・接続失敗時の確認手順をご覧ください。特定のドメインだけ失敗する場合は、照合条件と名前解決結果を確認してください。

3. DOMAIN系ルールとドメインの範囲

DOMAIN：特定のホスト名に一致

DOMAINは、完全一致するドメイン名を指定するルールです。条件には完全なウェブアドレスではなくホスト名を指定します。プロトコルの接頭辞、パス、クエリパラメータ、ポートは含めないでください。ウェブアドレスにはこれらの要素が含まれますが、ドメインルールが対象とするのはホスト名だけです。特定のページパスを処理したい場合は、別の適切な方法を検討してください。パスをドメインの後ろに加えても、ルールがアドレス全体を認識するわけではありません。

たとえば、下の最初のルールはapi.example.comだけを対象とし、同じ組織のドメインだからといってwww.example.comにも自動で適用されることはありません。正確なルールは、対象範囲が明確な単一サービスの接続先や、広い範囲のルールに対する例外に適しています。編集時は、ページ名から推測するより、リクエスト記録からホスト名をコピーするほうが確実です。ページに表示されるブランド名と実際のリクエスト先ドメインは異なる場合があり、静的ファイルや認証リクエストが別のホスト名を使うこともあります。

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

DOMAIN-SUFFIX：ドメインの階層に基づいて一致

DOMAIN-SUFFIXは、ルートドメインとそのサブドメインに同じポリシーを適用する場合に使います。条件にexample.comを指定すると、ルートドメインと対応するサブドメインが対象になりますが、この文字列を含むすべての名前が一致するわけではありません。ドメイン階層には明確な区切りがあり、キーワード照合とは異なります。通常、条件の先頭にアスタリスクを付ける必要はありません。ブラウザや別の構文で使うワイルドカードの習慣を持ち込むと、意図したルールにならない場合があります。

サフィックスルールを使うとサブドメインごとの管理を減らせますが、影響範囲も広がります。同じサフィックス内に、プロキシ接続が必要なAPIと、ローカルネットワーク内でのみ使うサービスがある場合、同じポリシーを一律に指定すると、どちらかに影響することがあります。より狭い範囲の例外を先に記述し、その後にサフィックスルールを置くのが適切です。上の例では、ログイン用ホスト名が先にDIRECTに一致し、同じサフィックスの他のリクエストは後続ルールで処理されます。順序も設定意図の一部です。

DOMAIN-KEYWORD：文字列条件と誤一致

DOMAIN-KEYWORDは、ドメイン名に指定したキーワードが含まれるかどうかを判定します。完全なドメインサフィックスより広い範囲が対象です。キーワードの意味を理解したり、名前が広告・分析・更新サービスに属するかを判定したりする機能はありません。短すぎる条件は無関係なドメインまで一致させやすく、特に一般的な文字の組み合わせには注意が必要です。以下は構文例にすぎません。記載したキーワードを検証済みのブロックリストとして扱ったり、テストせずに日常使用するConfigへ追加したりしないでください。

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

例では、まず明確なホスト名の例外を設定し、その後にキーワードによる拒否を示しています。それでも、同じ文字列を含む別のドメインが拒否される可能性があります。一部の画像が表示されない、またはログインが中断される場合は、まず失敗したリクエストのホスト名を確認し、広い条件に一致していないか調べてください。既知のドメイン1つだけを処理したい場合は、完全一致またはサフィックスルールのほうが意図を説明しやすく、後から影響範囲を確認する際にも便利です。

ページ内の複数の接続を分けて確認する

ウェブページの読み込みは1つのリクエストだけで完結しません。メインページ、スクリプト、画像、認証、APIがそれぞれ異なるドメインへ接続する場合があります。アドレスバーのドメインにルールを設定しても、すべてのリソースが同じ経路を通るとは限りません。検証では「ページが開くこと」と「すべての機能が使えること」を分けて確認し、重要なドメインごとに新しいリクエストを発生させてください。画像が1つ読み込めないからといって、サイト全体を対象にキーワードの範囲を広げたり、一時的に表示された外部リソースのドメインをすべて同じサフィックスに追加したりしないでください。

ドメインルールが機能するには、照合時にドメイン情報を取得できる必要があります。リクエスト先がアドレス形式で指定されている場合や、既存の接続が再利用されている場合は、編集したルールと観察結果が一致しないことがあります。テストページを閉じて新しい接続を発生させ、記録に表示される実際の接続先を確認してください。安定して再現できるようになってから、ドメインルールの追加、アドレスルールの調整、DNSの確認のどれが必要か判断します。用語は用語集でも確認できます。

4. IP、GEOIP、USER-AGENTルール

IP-CIDRとIP-CIDR6のアドレス範囲

IP-CIDRはIPv4アドレス範囲に、IP-CIDR6はIPv6アドレス範囲に一致します。スラッシュの後ろの数字はネットワークプレフィックス長を示し、ポート番号やアドレス数ではありません。一般にプレフィックスが長いほど対象範囲は狭くなります。正しいネットワークアドレスとプレフィックスの組み合わせを指定してください。単一のIPv4アドレスだけに一致させたい場合は、ホストを示す完全なプレフィックスを使います。プレフィックスを省略しても同じ意味になると考え、任意に省略しないでください。

以下は、一般的なプライベートアドレス範囲とIPv6のローカルアドレス範囲を使った構文例です。これらのルールが必要かどうかは、実際のネットワークと既存の共通設定に応じて判断してください。一部のシステム通信や共通のバイパス設定は、通常のルール照合より前に処理されることがあります。そのため、アドレスルールが一致しない場合でも、構文が誤っているとは限りません。特にLAN内サービスを調べる際は、端末の実際のアドレス、ゲートウェイ、接続中のネットワークの種類をあわせて記録してください。

[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
IP-CIDR6,fe80::/10,DIRECT,no-resolve
FINAL,PROXY

no-resolveで制御すること

no-resolveは、アドレス条件の評価だけを目的としたドメイン名の名前解決を避けるための指定です。アプリ全体でDNSを使わなくなるわけではなく、ドメインに関係する接続にルールが一致しなくなるわけでもありません。リクエスト先が最初からアドレスで指定されている場合や、照合時に利用可能なアドレス情報がある場合は、アドレス条件に一致する可能性があります。この指定が制御するのは照合時の名前解決の動作であり、特定のアプリだけに使える特別なルールへ変更するものではありません。

大量のアドレス範囲を含むConfigで、不要な照合のたびに名前解決を行うと、待ち時間が増えたり、名前解決経路が結果に影響したりすることがあります。一方、すべてのルールに機械的にこの指定を追加すると、名前解決結果を前提とするルールが意図した段階で判定できなくなる場合があります。「このルールは機能するためにドメイン名をアドレスへ解決する必要があるか」を確認し、実際の記録を見て判断してください。汎用の高速化設定として扱わないでください。

GEOIPはデータベースによる判定で、サイトの所在地を示すものではない

GEOIPは、接続先アドレスと使用する地理情報データベースに基づいて判定します。一般的な構文は以下のとおりですが、国・地域コードが示すのはアドレスデータベース上の分類であり、サイトの運営主体、コンテンツの言語、ユーザーの所在地ではありません。ドメインが分散型サービスを利用していると、ネットワークや時間によって名前解決先が変わり、判定結果も異なる場合があります。そのため、GEOIPは広い範囲を対象とする後続ルールには使えますが、用途が明確なドメインの個別ルールの代わりにはなりません。

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

地理ルールの結果が想定と異なる場合は、まず実際の接続先アドレスを確認し、どのルールに一致したかを調べます。ページの言語だけからアドレスの分類を推測したり、1つの例外に合わせて地理ポリシー全体を反転したりしないでください。特定のサービスを常に決まった経路で接続したい場合は、より明確なドメインルールを前に置くほうが管理しやすくなります。データベースの分類、DNSの結果、サービスの要件は別々の情報として記録してください。

USER-AGENTを使う条件

USER-AGENTは、確認可能なリクエスト識別情報に一致するルールであり、端末にインストールされたアプリ名を判定するものではありません。以下は前方一致のワイルドカードを使った構文例ですが、実際に一致するかどうかは、リクエストに該当フィールドが含まれるか、処理段階でその値を確認できるかによります。暗号化されたリクエストの内容を、ルールを1つ追加するだけで自動的に読み取れるわけではありません。ルールが一致しない場合は、範囲を広げる前に情報を確認できる状態かどうかを調べてください。

USER-AGENT,ExampleClient*,DIRECT

同じアプリでも、システムコンポーネントや異なるネットワークモジュールを使い、別の識別情報でリクエストを送信することがあります。異なるアプリが同じ識別情報を使う場合もあるため、この種のルールを厳密なアプリ識別の境界として使うのは適切ではありません。通常のドメイン振り分けには、ドメイン条件のほうがわかりやすい場合が多いでしょう。リクエスト識別情報と対象範囲を確認し、安定して再テストできる場合に限って、該当ルールを使用してください。ルールを一致させるために、証明書の信頼設定を変更したり、コンテンツ処理の権限を広げたりしないでください。

5. 照合順序・例外・FINAL

最初に一致したルールが適用され、最も具体的なルールが自動で選ばれるわけではない

通常の[Rule]処理では、ルールを上から順に評価し、最初に条件を満たしたルールのポリシーが適用されます。ドメイン名がより具体的だからといって、完全一致ルールが自動的に優先されるわけではありません。広い範囲のサフィックスルールが先に一致すると、後ろの完全一致ルールは結果を変更できません。これが「ルールがあるのに反映されない」原因の1つです。確認時は対象ルールを探すだけでなく、その上にある条件が先に一致しないかも調べてください。

順序を読むときは、各行を1つの判定として考えるとわかりやすくなります。条件に一致すればその行のポリシーが適用され、照合はそこで終了します。一致しなければ次の行に進みます。コメント、グループ見出し、空行は読みやすさを高めますが、別の優先順位を作るものではありません。目立つ見出しの下に例外を置いても、前にある有効なルールを飛び越えられるわけではありません。長いファイルを管理するときは、例外の位置を記憶に頼るのではなく、一貫したグループ順で意図を表してください。

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

明確な例外から広い条件へ

上の例では、まず2つの特定ホスト名を処理し、次にサフィックス全体を対象にします。その後アドレス範囲と地理条件を確認し、最後にデフォルトポリシーを適用します。これは説明しやすい構成例であり、すべてのネットワークでそのまま使うべき順序ではありません。特定のサービスでアドレスルールを常に優先する必要がある場合は、順序を変更し、ドメイン条件への影響も理解する必要があります。重要なのは固定順を暗記することではなく、条件が重なるリクエストが最初にどのルールに一致するかを説明できることです。

office.example.comを例にすると、サフィックス条件にも一致する場合でも、最初のルールによって直接接続になります。サフィックスルールを先頭に移すと、結果は変わります。また、そのサフィックスに属さない別のドメインは、アドレス条件や地理条件を経てからデフォルトルールに到達する可能性があります。日常のブラウジングが「問題なさそう」かを見るだけでなく、このような最小限のテスト対象を用意すると、順序の問題を見つけやすくなります。編集によって何が変わったかも確認しやすくなります。

FINALは未照合リクエストの出口として配置する

FINALにはドメインやアドレスの条件がなく、それ以前のルールに一致しなかったリクエストを処理します。有効なルールの最後に配置してください。途中に置くと、後続のルールは通常実行されません。デフォルトルールを複数記述しても、複数のポリシーが順番に試されるわけではありません。以下の2つのデフォルト方向は、異なる基本方針を示しています。未処理のリクエストをプロキシ経由にするか、直接接続にするかは、接続先の要件と既存のConfigに合わせて選択してください。

FINAL,PROXY
FINAL,DIRECT

この2つはどちらか一方を使う例であり、「念のため」に両方を追加するものではありません。デフォルトポリシーの影響範囲は広いため、変更前にデフォルトの接続先に依存しているサービスも含め、代表的なリクエストをいくつか確認してください。すでに完全一致ルールに当たるドメインを1つテストしただけでは、新しいデフォルト方向が適切か判断できません。現在のConfigの意図がわからない場合は、デフォルトポリシーを維持し、明確な問題に対する例外だけを追加してください。小さな修正が全体の動作変更につながるのを防げます。

ルール統合時に重複と遮蔽を確認する

2つのルールを統合するときは、同じテキストがあるかどうかだけでなく、対象範囲が重なっていないかも確認します。同じ条件が複数ある場合、通常は先にあるルールが結果を決め、後の異なるポリシーは実行されないことがあります。広いキーワード、サフィックス、アドレス範囲が後続の例外を遮る場合もあります。整理する際は元のConfigを保存し、対象ドメインが最初に一致する位置を追跡してから、重複を削除してください。順序に意味のあるルールセクションを、ファイル全体のアルファベット順に並べ替えるのは避けてください。

遮蔽されたルールを見つけた場合は、不要な重複なのか、将来の用途変更に備えた記述なのかも判断します。実際に実行するルールはできるだけ明確にし、管理メモは処理に使われない場所に記録してください。変更後は新しい接続を開始し、既存の接続が引き続き使われている状態を、順序変更が反映されないと誤認しないようにします。関連するホスト名が複数ある場合は、それぞれを確認してください。1つのルールの優先順位が正しくても、関連するサービス全体がカバーされるとは限りません。

6. DNS、Host、接続先アドレスの関係

DNSはアドレスを返し、ルールはポリシーを決める

DNSはホスト名に対応するアドレスを返し、ルールはリクエストに適用するポリシーを決めます。両者は影響し合いますが、同じものではありません。名前解決に成功してもアドレスを取得できたことを示すだけで、対象ポートへの接続を保証するものではありません。プロキシルールに一致しても、想定どおりの経路で名前解決されるとは限りません。トラブルの記録には、ホスト名、名前解決結果、一致したルール、最終的な接続状態をそれぞれ記載してください。「開かない」だけで、すべての処理段階をまとめて判断しないようにします。

[General]の名前解決設定は、後続の判定に使われる情報に影響します。システムの名前解決を使う場合、結果は接続中のWi-Fiやモバイルネットワークによって変わることがあります。別の設定を指定する場合は、その名前解決サービス自体に接続できるかも確認してください。複数のDNS設定を同時に変更し、ページの表示速度だけで良し悪しを判断するのは避けましょう。ドメインのキャッシュや既存接続の再利用によって、実際の設定差より大きく、あるいは小さく見えることがあります。

[General]
dns-server = system

Hostマッピングはサーバー項目ではない

[Host]では、指定したホスト名にアドレスを割り当てられます。以下では説明用のドメイン名をドキュメント用アドレスに割り当てています。実際にアクセス可能なサービスが存在することを示すものではありません。等号の左側がホスト名、右側が接続先アドレスです。これはプロキシサーバーをAdd Serverに登録する設定ではなく、リモートサービスの認証情報も変更しません。サーバーを追加するために、サブスクリプション内のサーバーアドレスやパスワードをこのセクションへ記載しないでください。

[Host]
service.example.com = 192.0.2.10
assets.example.com = 198.51.100.20

固定マッピングは、アドレスを明確に指定する必要がある管理環境に適していますが、ドメイン本来の動的な接続先選択を回避します。サービスの移行、アドレスの無効化、ネットワーク環境の変化後も古いマッピングが残ると、不適切な接続先へリクエストを送ることがあります。特定のConfigを有効にしたときだけドメインに問題が起きる場合は、古いマッピングが残っていないか確認し、システムの名前解決結果とConfigの結果を比較してください。一時的に接続を復旧させるために、出所のわからない固定アドレスを長期間残さないようにします。

アドレスの変更は証明書上のIDの変更を意味しない

ホスト名で暗号化サービスにアクセスする場合、接続先アドレスとサーバーIDの検証には関連がありますが、互いに置き換えられるものではありません。ドメインを別のアドレスに割り当てても、そのアドレス上の任意のサービスに正しい証明書があるとは限らず、必要なホスト名が認識される保証もありません。証明書やハンドシェイクのエラーが発生した場合は、ドメイン、サービス設定、システム時刻を確認してください。検証要件を下げることを通常の解決策として扱わないでください。既存のTrojanサーバー設定を確認する場合は、パスワード、SNI、TLSパラメータの説明もご覧ください。

同様に、Hostマッピングとドメイン振り分けを、前者が常に後者に優先すると単純に考えることはできません。ドメイン条件がアドレス条件より先に一致する場合があります。アドレスマッピングは接続先に影響し、ポリシーは照合処理によって決まります。両者の関係を確認する場合は、説明用または管理下にある1つのホスト名だけにマッピングを設定し、実際の接続先アドレスを記録して、ドメインルールとアドレスルールの一致状況を別々に確認してください。最後に表示されたアドレスから、それ以前の処理をすべて推測しないようにします。

キャッシュ・デュアルスタック・ネットワーク切り替え

同じホスト名にIPv4とIPv6の両方の結果がある場合、どちらが使われるかはネットワークの到達性や接続処理によって変わります。IPv4用のルールだけでは、IPv6も自動的に対象になるわけではありません。反対に、IPv6で一度失敗したからといって、アドレスファミリー全体の設定変更が必要とは限りません。まず実際のリクエストでどちらのアドレスが使われたかを確認し、対応するルールとネットワーク条件を調べてください。2つのアドレスファミリーを分けて記録すれば、一方が成功しもう一方が失敗した場合にも、矛盾する結論を避けられます。

ネットワークを切り替えた後も、名前解決キャッシュ、アプリの接続プール、既存接続がしばらく影響することがあります。新しい設定を検証する場合は、古いテスト接続を終了し、固定した接続先に再度アクセスしてください。必要に応じて、アプリに用意された機能で関連キャッシュを消去します。ブラウザのページキャッシュだけを消去しても、すべてのネットワーク接続が再作成されるとは限りません。特定のネットワークだけで問題が発生する場合は、Configを変えずに比較すると、ローカルネットワークの違いとConfigの問題を切り分けやすくなります。

最終的には、名前解決設定の内容を説明できる状態にしておきます。どの情報源を使うのか、固定マッピングを設定した理由は何か、どのアドレスルールが名前解決に依存するのかを把握してください。過去の設定や用途不明のマッピングが増えるほど、トラブル時に確認すべき分岐も増えます。作業用Configに用途不明の設定を重ねず、まず動作に必要な最小構成に戻し、必要な設定を1つずつ復元してください。

7. URL Rewriteの構文と処理範囲

リクエストアドレスの書き換えと接続ポリシーの選択は別

[URL Rewrite]は条件に一致する表示可能なリクエストアドレスを処理し、[Rule]は接続ポリシーを処理します。互いに置き換えることはできません。アドレスを別のホスト名へ書き換えても、プロキシ経由になるとは限りません。新しい接続先は、関連設定と実際の処理段階に基づいて確認する必要があります。逆に、ドメインルールが決めるのは接続経路であり、特定のパスを別のパスに自動変換することはできません。まず問題がアドレス変換なのか接続先の選択なのかを明確にし、適切なセクションを使ってください。

書き換えルールは通常、照合式、変換先、アクションで構成されます。式に特殊文字が含まれる場合は、通常の文字列として読むのではなく、正規表現としての意味を確認してください。ピリオドは正規表現で特別な意味を持つため、ドメイン名の実際のピリオドに一致させるには適切なエスケープが必要です。先頭のアンカーは照合開始位置を、末尾のアンカーは文字列の終端を制限します。境界指定が不足すると、想定より広い範囲に一致することがあります。

[URL Rewrite]
^http://example\.com/(.*) https://example.com/$1 302

例を項目ごとに確認する

この例では、アドレスの先頭にある指定のプロトコルとホスト名に一致させ、スラッシュ以降をグループとして取得し、$1を使って変換先アドレスに挿入します。アクションの302は一時的なリダイレクトを表します。ここでは説明用に予約されたドメインを使っており、個人のConfigに追加する必要があるという意味ではありません。実際に使う前に、変換先サービスが指定されたプロトコルとパスに対応していることを確認してください。リダイレクトはリクエスト元に別のアドレスへアクセスするよう伝えるだけで、存在しないサービスを利用可能にするものではありません。

式と変換先の間の空白は区切りとして使われるため、式の中に未処理の空白を入れないでください。ルールをコピーするときは、テキストエディタが引用符、バックスラッシュ、句読点を置き換えていないかも確認します。単純なドメインルールに比べ、正規表現による書き換えでは「構文として読み込めるが、範囲が意図と異なる」という問題が起きやすくなります。成功するアドレスを1つ確認するだけでなく、一致してはいけない類似アドレスでもテストし、境界が適切か確かめてください。

書き換えにはリクエストが見えることが前提

暗号化された接続の完全なパスやクエリパラメータは、ドメインルーティングだけで読み取れるとは限りません。アプリが必要なリクエスト情報を取得でき、リクエストが処理可能な条件にある場合にのみ、書き換えが実行される可能性があります。接続先ドメインが見えても完全なアドレスが見えるとは限らず、1つのアドレスを確認できても、すべてのアプリのリクエストが同じ形式で処理されるとは限りません。ルールが実行されない場合は、アクションや変換先を変更する前に、リクエストが確認可能か、式に一致するかを調べてください。

通常の書き換えルールを検証するために、すべてのドメインを対象とするコンテンツ処理を有効にしたり、証明書の信頼設定を変更したりしないでください。暗号化された内容の処理には独立したセキュリティ上の制約があり、アプリ独自の検証にも影響されます。これらを通常のルール振り分けに必要な手順として扱わないでください。ドメインごとにプロキシ、直接接続、拒否を選ぶだけなら、[Rule]を使えばよく、同じ目的のためにアドレス書き換えを追加する必要はありません。

ループ・パスの欠落・機密情報の転送を防ぐ

リダイレクト先が再び元の式に一致すると、ループが発生することがあります。プロトコルだけを変更する場合でも、変換先サービスが元のアドレスへ再リダイレクトしないか確認してください。パスやクエリパラメータを引き継ぐかどうかも明確にします。取得範囲が狭すぎると必要なパラメータが失われ、広すぎると新しい接続先へ渡すべきでない情報まで含まれる可能性があります。特に認証関連のリクエストは、パラメータの用途を理解せずに別のホスト名へ書き換えないでください。

複数の書き換えルールがある場合は、照合範囲を1つずつ確認し、まず単独でテストしてから組み合わせを戻してください。同じ初期アドレスで何度もテストするときは、リクエスト元がリダイレクト結果をキャッシュしている可能性も考慮します。ページが新しいアドレスに直接移動しても、現在のルールが実行されたとは限りません。以前の結果が再利用された可能性があります。混乱を避けるため、最初に入力したアドレス、最終アドレス、一致したルールを記録し、必要に応じて新しいセッションで再確認してください。

既知のホスト名への接続を拒否するだけなら、複雑な書き換えより、明確なREJECTルールのほうが管理しやすい場合がほとんどです。ポリシーだけを変更したい場合も、ルールセクションを使ってください。アドレス変換が本当に必要で、照合条件と変換先の関係を説明でき、安定したテスト方法がある場合に限り、書き換えルールを残します。一時的に試したルールを削除しておくことも重要です。後日アクセスした際に古いルールが再び実行されるのを防げます。

8. Configの検証・トラブルシューティング・管理手順

再現できるテスト条件を整える

変更を始める前に、現在のネットワークで基本的なアクセスができることを確認し、使用中のネットワーク、現在のConfig、Global Routingのモード、選択中のサーバーを記録します。テスト対象を固定し、完全一致ルールの対象、サフィックスルールの対象、デフォルトルールに依存する対象をそれぞれ用意してください。条件を1つだけ変更し、保存後に新しい接続を開始します。こうした基準を整えておくと、ルールを次々と追加するよりも有用です。結果が変わったとき、どの編集が影響したのか明確にできるためです。

テストの成功条件も明確に定義してください。ページが表示されても、一部のリクエストが成功しただけかもしれません。ログイン、API、リソースの読み込みには別の問題が残っていることがあります。まず対象リクエストが想定したポリシーに一致するか、次に接続が確立するか、最後にサービスの機能が使えるかを確認します。この3つを分けて記録すると、「ルールの方向は正しいがサーバーに到達できない」場合と「接続は正常だがサービスのAPIがエラーを返す」場合を切り分けられ、誤った段階を何度も調整せずに済みます。

条件・照合・接続・サービスの順に確認する

  1. 条件：アプリが接続中で、正しいConfigが選択され、Configモードになっていることを確認します。
  2. 照合：実際のホスト名またはアドレスを確認し、ルールの先頭から最初に一致する箇所を探します。
  3. 接続：名前解決、接続先への到達性、サーバー認証、転送パラメータを確認します。
  4. サービス：接続先サービスの応答、アカウントの状態、依存する複数のリクエストが正常に完了するかを確認します。

想定したルールに一致しない場合は、広い範囲のルールによる遮蔽、デフォルトルールより後ろへの配置、別のファイルの保存、古い接続の再利用をまず確認してください。想定したポリシーに一致しているのに接続できない場合は、ルールの編集を中断し、その接続経路の到達性を調べます。Connectivity Testは、登録済みサーバーの接続状態を比較するのに役立ちます。ただし、テストに成功してもすべてのサービスを利用できるとは限らず、失敗しても原因となるプロトコルパラメータを特定できるわけではありません。

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

この短い例は検証の考え方を示しています。特定の対象は最初にプロキシへ、同じサフィックスの他のホスト名は直接接続へ、それ以外はデフォルトポリシーで処理されます。実際に試すときは、ご自身がテストする権限を持ち、実在する接続先を説明用ドメイン名と置き換えてください。説明用アドレスにアクセスできるかどうかでConfigの正しさを判断しないでください。ドメイン名とドキュメント用アドレスは構文説明のためのものであり、ネットワーク接続を確認するサービスではありません。

ルールの問題と速度の問題を切り分ける

接続経路が正しくても速度が遅い場合は、プロキシ対象をむやみに広げず、ローカルネットワークの品質、接続先サービス、サーバー負荷、プロトコルパラメータを比較してください。遅延テストと実際の転送速度も同じ指標ではありません。接続確立が一度速くても、長時間の通信が安定するとは限りません。Configを変えずに同じ接続先を複数のネットワークで確認すると、Configとサーバーを同時に変更するより原因を特定しやすくなります。具体的な方法は速度低下の段階別トラブルシューティングをご覧ください。

ネットワークを切り替えた後だけ問題が発生する場合は、接続が再確立されたか、名前解決結果が変わったか、On Demandが接続のタイミングに影響したかを確認してください。オンデマンド接続は接続を開始するタイミングを制御するもので、ドメインルールのポリシーを決める機能ではありません。自動接続のタイミングとルール照合を同じ設定として扱わないでください。この項目の調整については、On Demandとバックグラウンドのバッテリー消費の確認を参考にし、同じテスト対象で再検証してください。

変更内容を記録し、復元用コピーを保管する

安定したConfigには、明確な復元用コピーを用意しておきます。記録にサブスクリプションURL全体を含める必要はありません。変更の目的、関係するセクション、影響範囲、検証結果を記載してください。リモートConfigの更新後は、デフォルトポリシー、共通設定、個人用の例外が変わっていないか比較してから、通常使用するConfigに切り替えます。用途不明のルールを一度に大量に統合すると、内容の説明が難しくなり、重複条件や古いマッピングが混入する可能性があります。実際の必要に応じて1つずつ追加すれば、後から必要性を判断しやすくなります。

トラブルシューティング情報を共有する前に、ご自身のサブスクリプション認証情報、サーバーのパスワード、個人用アドレス、業務上機密のパスを削除してください。スクリーンショットやテキストには、問題の特定に必要なモード、ルールの種類、加工済みの接続先情報だけを残します。本サイトはShadowrocketの公式サイト・公式マニュアルです。アプリはクローズドソースの商用アプリです。iPhoneおよびiPadのシステム要件はApp Storeの掲載内容をご確認ください。正規品の確認方法は正規購入確認の3つのポイントをご覧ください。初回接続でよくある問題は、使い方ガイドに戻って順に確認できます。

最終的な目標はルールの数を増やすことではありません。各ルールの用途を説明でき、例外の範囲を検証でき、更新後に元へ戻せる状態にすることです。新しい問題が発生したら、まず再現し、想定から外れた最初の段階を特定してから、最小限の変更を行います。リクエスト先からポリシー、接続結果まで順を追って説明できれば、Configの検証は完了です。