Shadowrocket ルールガイド

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD

ドメインルールは、頻繁に変わるサーバーアドレスではなく、名前に基づいてアクセスの意図を表すのに適しています。まず照合したい対象が、完全なホスト名、ドメインの一群、特定の文字列を含む名前のどれかを決め、それに合ったキーワードを選びます。対象範囲が広いほど、誤って一致する可能性が高まります。個人用の設定を管理する場合は、完全一致から始め、リクエスト記録で共通の要件が確認できてから複数の完全一致ルールをサフィックスルールにまとめるのが基本です。

DOMAIN：指定したホスト名だけに一致

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

DOMAINは完全なドメイン名との一致に使います。最初の例はlogin.example.comを処理しますが、api.login.example.comやドメイン全体のexample.comまで処理するわけではありません。ルールのフィールドにはホスト名を記入し、プロトコル、ポート、URLのパスは含めません。ブラウザーのアドレス欄に表示される完全なURLからは、名前の部分を取り出す必要があります。特定のパスだけを処理したい場合、DOMAINだけでは条件を表現できません。

1つのページから、ログイン、画像、API、アクセス解析など、異なるホストへの接続が発生することがあります。ページのURLに完全一致ルールを追加しても、そのうち1つの名前しか対象にできません。ページの文字は表示されるのに画像が読み込まれない場合は、すべての名前にルールを拡大する前に、失敗したリクエストが実際にどのホストへ接続しているか確認してください。同じページを開いたときの接続を1つずつ確認すると、追加が必要なリソースのドメインを見つけやすくなり、ほかの通信のポリシーを不必要に変更するのも防げます。

DOMAIN-SUFFIX：ドメインとサブドメインに一致

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

DOMAIN-SUFFIXは、指定したドメインとそのサブドメインに一致します。例では、まずlocal.example.comをDIRECTの例外として設定し、それ以外のexample.comに属する名前をPROXYに振り分けています。ここに記入するのはexample.comで、先頭にアスタリスクを付ける必要はありません。また、*.example.comを同じ書き方とみなさないでください。ドメインの境界は重要です。後方一致は、文字列のどこかに同じ文字が含まれる名前との一致ではありません。

例外は広い範囲のルールより前に置きます。例の最初の2行を入れ替えると、先にサフィックスルールに一致し、その後の完全一致によるDIRECTルールは結果を変更できません。これはDOMAINの優先順位が低いからではなく、Ruleが記載順に処理されるためです。条件がより具体的であっても、自動的に優先されるわけではありません。意図した順序はファイルの作成者が記述位置で表します。例外を追加するときは、それより先に適用される可能性のある広いルールをすべて確認してから、挿入位置を決めてください。

DOMAIN-KEYWORD：範囲が広いため、条件をよく確認

[Rule]
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

DOMAIN-KEYWORDは、ドメイン名に指定したキーワードが含まれているかを調べます。特定のドメイン群に範囲が限定されません。例は構文の説明用であり、確認せず日常的に使うルールとして適切ではありません。名前にexampleが含まれるからといって、同じ組織や業務に属するとは限らないためです。キーワードが短く、よく使われる言葉であるほど誤って一致しやすくなります。完全一致やサフィックスで要件を表現できる場合は、範囲の明確な条件を優先してください。

ドメインルールを検証するときは、一致するはずの名前と、一致しないはずの名前を少なくとも1つずつ用意します。サフィックスルールではルートドメインとサブドメインの両方、キーワードルールでは同じ文字を含むものの対象範囲外である名前も確認してください。こうした逆方向のテストで、ルールの範囲が広すぎる問題を見つけられます。「対象にアクセスできた」ことだけでは、本来DIRECTにすべき別のリクエストまでプロキシ経路に送っていないか判断できません。

ドメイン名に国際化文字が含まれる場合は、リクエスト記録に実際に表示される名前の形式を確認し、クライアントが受け付ける形式で記入してください。空白を含む表示用のタイトルをそのまま使ったり、ブラウザーが読みやすく表示している文字列を最終的な照合値だと考えたりしないでください。もう1つよくある誤りは、ルールを変更した後、同じページを繰り返し再読み込みすることです。アプリが既存の接続を再利用する場合があるため、新しいリクエストを発生させ、変更後のポリシーが新しい接続に適用されていることを確認しましょう。

ルールが増えてきたら、「完全一致の例外」「業務ごとのサフィックス」「慎重に使うキーワード」を連続する小グループに分けると管理しやすくなります。ただし、キーワード順に機械的に並べるのではなく、例外との関係に合わせてください。特定のウェブサイトだけをプロキシに通す場合は、指定したウェブサイトだけを振り分ける方法を参考に、対象を絞ったリストから始め、実際に使われるリソースのリクエストに合わせて追加しましょう。関係のない名前を一度に大量に含める必要はありません。

HostとURL Rewriteの用途と範囲

HostとURL Rewriteはいずれも、ユーザーに見えるアクセス結果を変えることがありますが、解決する問題は異なります。Hostは主に名前とアドレスの対応を定義し、URL Rewriteは参照可能なURLを条件に処理します。Hostはプロキシポリシーではなく、URL Rewriteもドメイン振り分けの代わりにはなりません。必要な機能を判断するときは、まず目的を「名前解決先を指定する」「接続経路を選択する」「ある形式のURLを別の形式に変える」のどれかに整理してください。

Host：アドレスを固定しても出口は固定されない

[Host]
printer.example.com = 192.0.2.20

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

例では、1つの名前を説明用のアドレスに対応付け、Ruleでその名前の接続経路をDIRECTにしています。この2行はそれぞれ名前解決と経路選択を担い、互いに置き換えられません。実際に使うアドレスは、自分が利用する権限を持ち、現在のネットワークから到達可能なものにしてください。ドメインをアドレスに割り当てても、到達できなかったネットワークに接続できるようになったり、認証、ポート転送、サーバー側の仮想ホスト設定が自動で用意されたりするわけではありません。

アドレスを固定すると、既存の動的な名前解決が機能しなくなる場合があります。接続先のアドレス変更、近接サーバーへの振り分け、障害時の切り替えに依存するサービスでは、古い対応付けを長期間残すと接続がタイムアウトする可能性があります。追加前に本当にアドレスの固定が必要か確認し、解除方法を記録してください。テストでは名前が想定どおりのアドレスに解決されるかだけでなく、サービス、ポート、証明書の識別情報も正しいか確認します。アドレスから応答があっただけで、サービスが正常だと判断しないでください。

Hostはブラウザーがアクセスしているホストの識別情報を置き換えません。HTTPSの名前に接続するとき、サーバー証明書は引き続きその名前の検証条件を満たす必要があります。必要なサービスを提供しないアドレスに名前を割り当てると、証明書エラーや別のサイトが表示されることがあります。検証を無視して解決しようとしないでください。対象サービスがその名前に対応しているか、許可されたテスト環境での割り当てかを確認しましょう。通常の名前解決に戻した後は、関連するキャッシュも更新されたことを確認してください。

URL Rewrite：正規表現、転送先、アクション

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

この例では、正規表現で古いURLに一致させ、キャプチャしたパスを新しいURLに引き継ぎ、302リダイレクトを返します。ピリオドの前のバックスラッシュは、実際のピリオドに一致させるためのものです。先頭と末尾のアンカーで一致範囲を限定し、括弧でキャプチャした部分を$1で参照します。2つのドメインは例示用です。自分の設定で使う場合は、テストする権限のある接続先に置き換え、クエリパラメータとエンコードが要件どおり保持されるか確認してください。

正規表現のピリオドには既定で特別な意味があるため、エスケープし忘れると対象外の名前にも一致することがあります。ホストの境界を省略すると、似た別のURLまで範囲に含める可能性があります。URL Rewriteを管理する際は、一致する例、似ているが一致すべきでない例、パスとクエリパラメータを含む例を少なくとも1つずつ用意してください。ホームページだけでテストしないでください。パスのないURLで成功しても、より長いURLが正しく処理されるとは限りません。

暗号化による可視性の制限と処理段階

完全なHTTPS URLのパスは暗号化された内容に含まれるため、通常の接続振り分けでその中のすべての項目を読み取れるとは限りません。URL Rewriteを対象に適用できるかどうかは、リクエスト情報を参照できるか、また関連する処理条件が満たされているかによります。「正規表現を書いた」だけでパスを読み取れるようになったと考えないでください。リダイレクトルールの検証だけを目的に、復号の範囲をすぐに広げることも避けましょう。証明書や暗号化処理に関する設定は、許可、プライバシー、アプリの互換性を個別に評価してください。

Ruleの上から順に処理される原則を、「設定ファイル全体が記載順に一度だけ実行される」と単純に捉えてはいけません。各セクションには異なる機能があり、HostがRuleより前に記載されているからといって、必ず文字どおり先に実行されるとは限りません。書き換えの問題を調べるには、元のURL、リダイレクトの有無、転送先、その後の接続に適用されたポリシーをリクエストの流れに沿って確認します。これにより、書き換えが適用されなかったのか、転送先への接続に失敗したのか、その後の振り分けに問題があったのかを切り分けられます。

リダイレクトが繰り返される場合は、追加したルールをいったん無効にする

新しい転送先が再び古いルールに一致する場合や、サイトが元のURLへリクエストを戻す場合は、ループになることがあります。元の設定に戻して正常なことを確認し、正規表現の範囲を絞ってください。逆方向のリダイレクトを重ねて追加しないでください。

ブラウザーがリダイレクト結果をキャッシュしていたり、アプリが名前解決や接続をキャッシュしていたりする場合があります。ルールを削除した後も以前の挙動が続いても、ファイルが保存されていないとは限りません。現在の設定を確認し、新しいテストリクエストまたは独立したテストセッションで再確認してください。長期的に使う書き換えルールには、目的、対象ホスト、想定する動作、削除条件を記録しましょう。接続先がURL構成を変更したのに、古い処理をローカルルールで強制し続ける事態を防げます。

HostとURL Rewriteは、対象が狭く目的を説明できる場合に適しています。あらゆるアクセス異常を修復するための手段として使わないでください。特定のサイトをPROXYに通したいだけならドメインルールに戻ります。名前解決の結果に問題があるなら、DNSと既存の割り当てを確認します。サイトにリクエストを拒否されたなら、認証やサービス側の応答も確認してください。問題の層を特定してから設定セクションを選べば、ファイルを簡潔に保ち、障害も再現しやすくなります。

ルールの一致確認、トラブルの切り分け、設定の復元

ルール検証の目的は、たまたま一度アクセスできることではありません。指定したリクエストが意図した条件に一致し、予定したポリシーで処理され、維持すべき動作も損なわれていないことを確認します。テスト記録には、実施時刻、現在の設定名、Global Routing、対象の名前またはアドレス、実際の一致結果、接続の状況を含めます。時刻は今回のテストと比較するためのもので、アプリの更新情報を示すものではありません。具体的な証拠を残せば、次にネットワークが変化したときに以前の結果と比較できます。

ルールの数から原因を推測せず、層ごとに確認する

まず接続が確立しているか、使用中のファイルが選択されているかを確認し、次にリクエストが想定した処理対象に入っているか調べます。その後、名前解決と実際の接続先を確認し、最初に一致した条件を見て、最後にポリシーの出口が使えるかを確認します。前の段階で失敗していれば、後の段階の変更は通常意味がありません。たとえば、名前解決の失敗に対してドメインサフィックスを追加しても解決しないことがあります。PROXYに一致したもののサーバーに接続できない場合、FINALを移動しても直接的な解決にはなりません。

Connectivity Testは既存サーバーのテスト結果を確認する助けになりますが、すべてのサイト、プロトコル、業務リクエストが利用できることを証明するものではありません。テストに成功しても、実際のアクセスで名前解決、接続先からの拒否、業務上の認証に問題が生じる場合があります。テスト結果は証拠の一部として扱い、最終的な結論とはみなさないでください。同様に、ウェブページが開いたからといってPROXY経由だとは限りません。該当するリクエストのポリシー記録と合わせて判断してください。

一致・不一致・回帰のテストケースを用意する

一致テストは対象がルールに一致することを確認し、不一致テストは対象範囲が広がりすぎていないことを確認します。回帰テストでは、従来正常だった機能が引き続き使えるか確認します。たとえばDOMAIN-SUFFIXを追加した場合は、ルートドメインとサブドメインをテストし、次にそのサフィックスに属さない名前を確認してから、ログインとローカルネットワークへのアクセスもテストします。用途の分からない接続先にアクセスしてテストする必要はありません。自分がアクセスする権限を持ち、目的が明確なサービスを使ってください。例示用のドメインは構文の説明にのみ使います。

テスト中は、できるだけ変更する変数を1つに絞ります。サーバー、ネットワーク、動作モードを同じに保ち、ルールを1つだけ変更して結果を比較してから次に進みます。ネットワークを切り替える必要がある場合は別に記録し、その変化による名前解決の違いをルール変更の結果と取り違えないようにしてください。ページが接続を再利用する場合は、関連するテストセッションを終了して新しいリクエストを開始します。新しいルールは通常、新しい接続で確認する必要があります。既存接続が継続した結果だけで判断しないでください。

ログを共有する際の機密情報の取り扱い

トラブルの記録を共有する場合は、再現に必要な接続先、ルール、ポリシー、エラー情報だけを残します。サブスクリプションURLの認証情報、サーバーのパスワード、非公開のリクエストパス、アカウント識別情報、設定ファイル内の認証情報は、事前に削除してください。スクリーンショットにも同じ情報が含まれる場合があるため、画像だからといって確認を省略しないでください。機密情報を明確な例示値に置き換え、どの項目を置き換えたか説明すると、再現性と情報保護を両立できます。

問題の範囲を絞るには、最小限のテスト設定を作成します。必要なGeneral設定、対象のルール1つ、FINALを残し、自分がすでに持っているサーバーを使います。最小構成で正常に動作したら、元のルールをグループごとに戻し、結果に差が出る箇所を特定してください。戻すときはグループ内の元の順序を維持し、ファイル全体を同時に並べ替えないでください。これにより、特定条件、外部参照、複数の例外の順序関係のどれが問題か確認できます。

復元後も動作状態を改めて確認する

切り戻しは、設定の文字列を元に戻すだけではありません。元の設定を再度選択し、Global Routingと既存サーバーの選択を確認します。必要であれば接続を再確立し、以前正常だったテストケースと比較してください。元の設定に戻しても異常が続く場合、ネットワーク、サーバー、接続先のサービスが変化した可能性があります。すべての問題を今回の編集だけに結びつけないでください。変更前後のファイルと簡潔な記録を残すと、記憶を頼りに何度も復元する際、新たな差分を生むのを防げます。

変更を完了と判断する基準

対象が正しく一致し、例外が誤って影響を受けず、日常のリクエストが回帰テストに合格し、変更前の状態に戻せること。この4点すべてを確認してから、テスト用の複製を長期利用する設定にしてください。

機種変更後に復元する場合は、まずアプリがApp Storeから入手したものであることを確認し、自分で保存したサーバー情報と設定ファイルを復元してから、現在の設定とシステムの接続許可を再確認します。システム要件はApp Storeのページに記載された内容をご確認ください。購入済みアプリの復元や再入手については、購入済みアプリの復元ガイドと、同ページの購入に関するよくある質問をご覧ください。初回接続の手順は使い方ガイドに戻り、ルールの意味はこのページの目次から項目ごとに確認してください。

長期的な管理には、安定版とテスト版を1つずつ用意する方法があります。安定版には検証済みの変更だけを反映し、テスト版は新しい条件の追加や検証に使います。不要になった例外を定期的に整理し、固定アドレスが今も有効か確認し、リモート設定の更新後には個人ルールを再確認してください。ルールファイルの価値は長さではありません。各条件の目的を説明でき、結果を確認でき、変更をいつでも元に戻せることが大切です。