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

Shadowrocket
ルール・設定ガイド

まず設定が反映されているか確認し、次にルールの判定理由を調べます。このページでは、ファイル構成・判定条件・確認手順に沿って、各項目や振り分け結果を確認できます。

初めて設定する場合は、手持ちのサブスクリプションを読み込み、サーバーを選んで接続するまでのクイックスタートを先にお読みください。基本操作の後は、このページで Config とルールファイルを確認できます。チュートリアルでは一連の操作を、本ページでは設定同士の関係や適用範囲、変更後の確認方法を解説します。

01 設定ファイルの構成と適用範囲

設定ファイルは、まず正しく読み込めることが大切です。そのうえで、ルールが意図どおりに機能するかを確認します。Shadowrocketの設定ファイルは通常、セクションごとに構成されています。角括弧内の名前がセクションを示し、その下の内容は各セクションの構文に従って解釈されます。同じ行でも、記述するセクションによって意味が変わることがあります。例を参照・コピーするときは、セクション名、行の内容、適用先のポリシーをあわせて確認し、キーワードだけを切り取らないようにしてください。

General、Rule、Hostの役割

[General]には、名前解決やバイパスに関する設定など、全般的な項目を記述します。[Rule]には接続先を振り分けるルール、[Host]には指定したホスト名とIPアドレスの静的な対応を記述します。それぞれ「接続をどのような基本条件で処理するか」「接続先にどのポリシーを適用するか」「ホスト名にどのアドレスを対応させるか」を定めます。役割が異なるため、一方のセクションを変更しても、別のセクションの結果が変わるとは限りません。

セクション	主な用途	確認するポイント
`[General]`	接続と名前解決の共通設定	オプションの綴り・値・現在のネットワーク環境
`[Rule]`	条件に応じたポリシーの選択	ルールの順序、判定項目、ポリシー名
`[Host]`	ホスト名とアドレスの対応を指定	ドメインとアドレスが現在も同じサービスを指しているか
`[URL Rewrite]`	対象となるURLを判定して処理	正規表現の範囲、転送先、処理方法

最小構成のファイルで構文を確認する

以下の例は構成を説明するためのもので、あらゆるネットワークで使える完全な設定ではありません。例示のドメインやドキュメント用アドレスは、利用可能なサービスを示すものではありません。実際に使う際は、現在の設定に必要な項目を残し、手持ちのサーバーが利用できることを確認してください。PROXYはポリシーであり、ファイルに記述しただけでサーバーが追加されるわけではありません。また、ドメインルールを追加しても、そのドメインの名前解決やサービスの状態が自動的に修正されることはありません。

[General]
dns-server = system

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

[Host]
test.example.com = 192.0.2.10

セクション見出しには半角の角括弧を使い、ルールの項目は半角カンマで区切ります。通常のオプションは、名前と値を等号でつなぎます。全角カンマ、曲がった引用符、見えない空白が入力されると、見た目が同じでも正しく解析されないことがあります。コピーした後はエディターで一行ずつ確認し、行末に説明文が紛れ込んでいないかも確認してください。説明は本文か独立したコメント行に記載し、ポリシー項目の後ろに直接追加しないでください。

ファイルがあることと、現在使われていることは別

Configを開いたら、まず現在選択されている設定ファイルを確認してから編集します。選択されていないファイルを保存しても、実行中の設定が自動的に切り替わることはありません。同様に、手持ちのサブスクリプションを更新すると通常はサーバー一覧が更新されますが、ルールファイルも更新されたとは限りません。サーバーの取得元、設定の取得元、現在の選択状態をそれぞれ確認し、異なる項目を混同して編集しないようにしましょう。

作業前にローカルコピーを保存し、元のファイル名を記録してください。現在の設定が更新可能なURLから取得されている場合は、リモートの元データとローカルの変更を区別します。後で内容を再取得すると、ローカルの変更をあらためて確認する必要が生じることがあります。「保存済み」は「検証済み」を意味しません。テキストの保存後は、Global Routing、接続状態、実際に適用されたルールを確認して、反映されたか判断してください。

読み込みエラーが出た場合は、まず直近で変更したセクションを確認します。セクション名を重複して貼り付けていないか、ルールを誤った場所に記述していないかも確認してください。ファイルは開けるのに接続結果が異なる場合は、モード、ポリシー、判定順を調べます。構文の問題と実行結果の問題を分けて対処すれば、カンマの誤りを直すために名前解決やサーバー、ルール一式まで同時に変更して原因が分からなくなる事態を避けられます。

02 Global Routingとポリシーの選択

ルールを確認する前に、Global Routingを確認してください。Configモードでは現在の設定に従って接続先を決定します。Proxyモードでは通常そのモードで処理される接続をプロキシ経由にし、Directモードでは直接接続します。本ページで扱うドメイン、アドレス、最後のフォールバックルールは、主にConfigで検証します。モードを変えた後、同じルールが以前と異なる動作をしても、必ずしも設定ファイルに問題があるとは限りません。

モードごとに確認できる内容が異なる

モード	画面上の表示	確認できること
設定	`Config`	現在の設定による通信の振り分けを確認
プロキシ	`Proxy`	プロキシ経路とサーバーへの接続を確認
直接接続	`Direct`	現在のネットワークで直接接続できるか確認

トラブル対処では、異なるモードを一時的に比較できますが、同じネットワーク、同じ接続先、同じサーバーを使い、できるだけ新しい接続で試してください。Proxyでは接続できてConfigでは失敗する場合は、設定が接続先をどの経路に振り分けているかを優先して確認します。どちらでも失敗する場合は、サーバー情報、名前解決、接続先のサービスも確認が必要です。一度切り替えただけで、すべてのルールが正しいとは判断できません。

PROXY、DIRECT、REJECTの違い

PROXYはプロキシポリシーを使うことを示します。実際に利用できる経路は、選択中のサーバーや関連するポリシー設定にも左右されます。DIRECTは接続先への直接接続、REJECTは条件に一致する接続の拒否を示します。これらはルール内のポリシーキーワードで、画面上のモード名とは別の階層です。特に、全体のProxyモードと、個別ルール末尾のPROXYを同じ設定操作と考えないでください。

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

最初の行が示すのは、対象ドメインをプロキシ経由にすることだけです。サーバーのアドレス、認証方法、通信パラメーターは定義していません。手持ちのサーバー情報に不足があれば、ログにPROXYと表示されても接続に失敗することがあります。逆に、DIRECTに一致しても、現在のネットワークから接続先に到達できるとは限りません。ルールの選択と経路の到達性は別々に確認し、一方の結果で他方を判断しないでください。

REJECTは、対象範囲が明確で、実際に拒否したい接続だけに使用します。範囲が広すぎる拒否ルールは、ログイン、画像、プッシュ通知、アプリの初期化などに影響する可能性があります。同じアプリが複数のドメインにアクセスすることもあるためです。拒否ポリシーを試す際は、まず完全なドメイン名を指定し、影響を受けたリクエストを記録してから範囲を広げるか判断します。名前が統計や広告のように見えるだけで、拒否しても他の機能に影響しないと決めつけないでください。

ポリシー名も確認する

設定によっては、独自のポリシー名を参照していることがあります。その場合は設定内の定義を探し、名前が存在すること、綴りが一致すること、現在も有効な経路を選択できることを確認してください。既存のポリシーグループをサーバーのメモ名に置き換えたり、参照しているルールだけをコピーしたりしないでください。初めてファイルを整理する場合は、まず意味の分かる組み込みポリシーで最小限の検証を行い、その後に独自ポリシー同士の関係を調べると、原因を切り分けやすくなります。

アプリの接続スイッチとルーティングモードも分けて確認します。スイッチがオフなら、ファイルを編集しても通信は現在のルールを通りません。オンにして接続中と表示されても、Webサイトやアプリからのリクエストを確認したことにはなりません。初期設定の手順はチュートリアルの手順を参照してください。本ページでは、個別のルールが一致する理由を解説します。確認後は元のモードに戻し、一時的な調査用設定がそのまま残らないようにしてください。

03 DOMAIN系ドメインルール

接続先のドメイン名が分かっている場合は、まずドメインルールを確認します。ドメインルールが対象にするのはホスト名であり、ブラウザーのアドレス欄にある完全なURLではありません。api.example.comを記述する場合、プロトコル、パス、クエリーパラメーター、ページタイトルは付けません。URLではホスト名の後に続くスラッシュ以降が別の情報になるため、DOMAINの判定項目にはそのまま使えません。

完全一致とサフィックス一致

DOMAINはドメイン名全体との一致に使います。example.comと記述しても、www.example.comまで含むわけではありません。DOMAIN-SUFFIXは、ドメイン本体とそのサブドメインを対象にする場合に適しています。条件をexample.comとすると、ドメイン本体とその配下のサブドメインに適用できます。この違いによって、一つのホストだけに適用するのか、同じドメイン配下の複数サービスに適用するのかが変わります。

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

サフィックスルールを選ぶ前に、ドメインの境界を確認してください。任意の文字列末尾との比較ではなく、似た文字が含まれているだけで一致するわけでもありません。見た目が似た名前でも、同じドメインの配下とは限りません。トラブル対処では、ログにある完全なホスト名とルールの値を一字ずつ照合します。余分なサブドメイン、トップレベルドメインの違い、アプリの遷移後に使われる別のサービスドメインにも注意してください。

DOMAIN-KEYWORDは広い範囲に一致する

DOMAIN-KEYWORDはドメイン名に含まれるキーワードで判定するため、文字列による範囲指定が必要な場合に使います。ブランド、サービスの運営元、用途を判別する機能はないため、同じ文字列が無関係なドメインに含まれていることもあります。キーワードが短いほど、意図しない一致を予測しにくくなります。完全なドメイン名を列挙できる場合は、通常、広範なキーワードよりも個別ルールの方が説明しやすく、後から確認しやすいでしょう。

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

この例では、範囲の広いルールより先に、対象を限定した例外を置いています。ads.example.comへの接続は、まず完全一致の拒否ルールに一致します。同じドメインの別のホストは、その後のサフィックスルールによってプロキシに振り分けられます。後続のキーワードルールが、すでに一致した接続を再処理することはありません。この例は順序を示すもので、汎用のブロックリストではありません。実際に拒否する範囲は、利用者自身の目的とログに基づいて決めてください。

Webページは複数のドメインを使うことがある

ページ本体、画像、スクリプト、ログイン用API、メディアが異なるホストから配信されることがあります。アドレス欄にあるドメインだけにポリシーを設定しても、すべてのリソースが同じ経路を使うとは限りません。「トップページは開くのに画像が表示されない」場合は、失敗したリソースの実際のホスト名を確認し、すぐにサフィックス全体のポリシーを変更しないでください。範囲を段階的に広げることで、正常な別サービスへの影響を防ぎやすくなります。

ドメインルールが一致するには、接続処理時に対象の名前を取得できる必要があります。アプリが数値のIPアドレスに直接接続する場合や、その時点で名前とアドレスの関連を取得できない場合、利用者がそのアドレスの所属サイトを知っていても、ドメインルールが一致するとは限りません。接続ログに表示された対象の種類を確認し、必要に応じてアドレスルールを追加してください。一つのリクエストに対処するために、すべての未識別接続を直接接続にしないでください。

ドメイン条件を変更した後は、新しいリクエストを発行してください。ブラウザーやアプリが既存の接続を再利用すると、新しいルールが同じセッションを処理する機会がありません。対象のページを閉じて開き直し、必要に応じて接続を再確立したうえで、新しいログを確認します。判断材料は新しいリクエストの接続先と判定結果です。画面に以前の内容が残っていても、どのルールで通信したかの証明にはなりません。キャッシュされたページだけでは、使用されたルールを確認できません。

保守しやすいように、ルールのグループごとに「完全一致の例外」「ドメイン全体」など、簡潔な用途メモを残してください。ドメインが使われなくなった場合も、先にサービスが別のホストを使うようになっていないか確認してからルールを削除します。用途の記録がないままルールを長期間追加すると、同じドメインに異なるポリシーを重複して設定しがちです。その場合、結果はルールの順序で決まり、自動で適切に統合されることはありません。

04 IP-CIDR、IPv6、GEOIP

アドレスルールが対象にするのは、ドメイン名の文字列ではなく接続先のIPアドレスです。IP-CIDRはIPv4のネットワーク範囲、IP-CIDR6はIPv6のネットワーク範囲、GEOIPはIPアドレスのデータベース上の地域情報を判定します。いずれも接続先アドレスに関係しますが、情報源と対象範囲は異なります。使う前に、特定のネットワーク範囲を指定するのか、地域情報に基づく分類が必要なのかを確認してください。

CIDRプレフィックスでアドレス範囲を指定する

CIDR表記は、アドレスとスラッシュ以降のプレフィックス長で構成されます。IPv4ではプレフィックスが長いほど範囲が狭くなり、単一のアドレスは32ビットのプレフィックスで指定できます。IPv6はアドレス長が異なるため、IPv4のプレフィックスの考え方をそのまま当てはめることはできません。手入力する際は、手持ちのネットワーク情報から範囲を確認してください。先頭の数文字が同じだからといって、同じネットワーク範囲に含めるべきとは限りません。

[Rule]
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR,198.51.100.8/32,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

上記のアドレスは文書用の例示範囲で、構文を示すためのものです。実際に接続できるサーバーを示すものではありません。2行目は単一のIPv4アドレス、3行目はIPv6のプレフィックスを表しています。実際の設定では、アドレス範囲を対象に合わせる必要があります。例をそのままコピーしても、実際のサービスの振り分けは解決せず、サーバーが使えるかどうかの判断にもなりません。

no-resolveは判定時の名前解決を制御する

接続先がドメイン名で示されている場合、アドレスルールの判定に名前解決が関係することがあります。ルール末尾のno-resolveは、そのアドレスルールのためだけにドメイン名の名前解決を積極的に行うことを避ける指定です。処理時に接続先アドレスがすでに分かっていれば、そのアドレスを使って判定できます。すべてのDNSを無効にする設定でも、接続時にドメイン名を使わなくする指定でもありません。これを全体の名前解決スイッチと誤解すると、結果を正しく予測できなくなります。

このオプションを追加するかどうかは、ルールの目的によって決めます。アドレスで接続された通信だけを対象にしたい場合や、ドメイン名の接続先に対してアドレスルールが追加の名前解決を行わないようにしたい場合に使えます。ドメイン名を名前解決して指定範囲に一致させたい場合は、実際の判定経路を確認してください。ルールによる名前解決を制限しながら、まだ取得できていないアドレスに必ず一致することを期待することはできません。結果は接続ログで確認してください。

GEOIPはサービスの提供地域を示すものではない

GEOIP,CN,DIRECTが判定するのは、接続先アドレスがデータベース上でどの地域に分類されているかです。サイトの言語、ドメインの末尾、企業の登記地、利用者の所在地を判定するものではありません。コンテンツ配信ネットワークを使うサービスでは、時間によって異なるアドレスに名前解決されることがあり、データベース上の地域情報が実際のサービスの認識と一致しない場合もあります。地域ルールは広い分類条件として使い、重要なサービスのドメインを明示する代わりにはしないでください。

ルール	判定対象	主な注意点
`IP-CIDR`	IPv4のアドレス範囲	ドメインの名前解決結果が変わると範囲外になることがある
`IP-CIDR6`	IPv6のアドレス範囲	IPv4ルールだけではIPv6接続をカバーできない
`GEOIP`	アドレスデータベース上の地域情報	ドメインやサービスの事業上の所在地は示さない

同じドメインからIPv4とIPv6の両方のアドレスが返されることがあります。どちらか一方だけにルールを設定すると、もう一方の接続は後続の地域ルールやFINALに一致する可能性があります。「同じURLなのに直接接続になったりプロキシ経由になったりする」場合は、アドレスの種類、実際の接続先アドレス、新しい接続の発生時刻を確認してください。URLの文字列だけを比較しても原因は分かりません。IPv6経路が実際に利用できるかも別途確認が必要です。

対象を明確にしたドメイン例外は、範囲の広いアドレスルールや地域ルールより前に置き、最後のフォールバックルールも残すことをおすすめします。特定のサービスに固定ポリシーを適用する必要がある場合は、どの地域のアドレスに解決されるかを推測するより、ドメインを直接指定する方が安定します。アドレス範囲が必要な場合は、取得元と用途を記録してください。サービスのアドレス変更後、古いルールが別の用途に割り当てられた接続へ影響するのを防げます。

05 判定順、USER-AGENT、FINAL

通常の[Rule]一覧では、設定の記述順にルールを確認し、一致したルールのポリシーを適用します。「最も具体的なルールを自動で選ぶ」仕組みではありません。条件が具体的でも、適切な位置になければ判定されないことがあります。先に広い条件が対象をカバーすると、後続の個別ルールで結果を変更することはできません。設定を整理するときは、条件そのものと同じくらい順序が重要です。

例外を先に、広い範囲のルールを後に置く

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

この例では、ログイン用ドメインを先に直接接続にします。同じドメインの他のホストは、サフィックスルールによってプロキシ経由になります。キーワードルールが対象にするのは、前のルールに一致しておらず、ドメインに指定の文字列を含む接続だけです。サフィックスルールを先頭に移すと、ログイン用ドメインも先にプロキシに一致します。ログイン用のルールが長く、より具体的に見えても、ファイルが自動的に優先することはありません。

重複ルールも順序に沿って考えます。同じドメインにDIRECTを記述した後でPROXYを記述しても、選択可能な経路が2つ残るわけではありません。条件に一致した前のルールが先に結果を決めます。競合を調べる際は、完全に同じ行だけでなく、そのドメインを含むサフィックスやキーワードなど、範囲の広い条件も検索してください。文字列が異なっていても、同じリクエストに影響することがあります。

USER-AGENTは取得可能なリクエスト情報に基づく

USER-AGENTは、リクエストに含まれるUser-Agent情報を条件にします。アプリ名を検出する機能ではなく、ルールにアプリ名を記述しただけですべての接続を識別できるわけでもありません。処理時に該当するリクエスト情報を取得できる場合に限り、ルールの判定材料になります。暗号化された接続では、すべてのリクエストヘッダーが常に見えるとは限りません。すべての接続を対象にする唯一の条件として使わないでください。

[Rule]
USER-AGENT,ExampleClient*,PROXY
DOMAIN,api.example.com,PROXY
FINAL,DIRECT

例にあるクライアント識別子は、条件の書き方を示すためのもので、実際のアプリを指すものではありません。利用時は、確認できるリクエスト情報から実際の値を調べ、ルールが一致しているか確認してください。同じアプリでもコンポーネントによって識別子が異なる場合があり、システムサービスが代わりにリクエストを送ることもあります。対象をドメインで明確に指定できる場合は、推測したリクエストヘッダーの文字列に頼らず、説明可能なドメイン条件を残してください。

FINALは最後のフォールバックとして使う

FINALは、それ以前のルールに一致しない接続にポリシーを適用するもので、通常は一覧の末尾に置きます。優先度を上げる指定でも、ルールの誤りを直すスイッチでもありません。ルール一覧の途中に置くと、後続のルールが判定されないことがあります。FINAL,PROXYとFINAL,DIRECTのどちらを使うかは、分類されていない接続にどの経路を使いたいかで決めます。他の設定ファイルの書き方をそのままコピーしないでください。

プロキシをフォールバックにすると、明示的に分類されていないリクエストは、手持ちのプロキシ経路に依存します。直接接続をフォールバックにすると、まだ対象になっていない通信は現在のネットワークから接続を試みます。どちらも実際に動作を確認してください。結果の理由を説明できることが重要です。ある接続が最後のルールに一致した場合、前の条件で対象にならなかったことを示すのであり、FINALが本来一致するはずのルールを奪ったわけではありません。対象の名前、アドレス、ルール範囲を確認してください。

設定を統合する際は、まず残すFINALルールを決め、その前に個別条件を配置します。完全なファイルを2つ、単純につなげると、セクションの重複、ルールの重複、途中に置かれたフォールバックが残りがちです。動作するファイルを土台にし、用途ごとにルールを移して、グループを追加するたびに接続先への判定結果を確認してください。問題が起きても、追加したばかりの範囲に原因を絞りやすくなり、何百行もの設定を最初から調べ直す必要がありません。

06 General、DNS、Hostのマッピング

名前解決と通信の振り分けには関係がありますが、同じ処理ではありません。DNSは名前をアドレスに変換し、ルールは条件に一致する接続にどのポリシーを適用するかを決めます。ドメイン名がプロキシルールに一致していても、名前解決に失敗すれば接続できません。名前解決に成功しても、選択した経路から返されたアドレスに到達できないことがあります。したがって、遅延時間が表示されたからといって、Webページの名前解決、通信、アプリの応答がすべて完了したとは限りません。

まず内容を説明できる基本設定を残す

[General]のオプションは、現在の設定やアプリ内の説明に沿って確認してください。名前解決の問題を調べる際は、元のDNS設定を記録し、一度に一つの項目だけを変更します。例にあるdns-server = systemは、システムの名前解決を使う設定例であり、すべてのネットワークに適した固定の答えではありません。現在のネットワーク、DNSサービスへの到達性、設定内の他のオプションによって、結果が変わることがあります。

[General]
dns-server = system

[Host]
test.example.com = 192.0.2.10

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

この例では、静的マッピングとポリシーを別々に記述しています。[Host]はテスト用ドメインのアドレスを指定し、[Rule]はそのドメインを直接接続にします。アドレスのマッピングを変更してもポリシーは変わらず、ポリシーを変更してもアドレスが正しいとは限りません。例示のアドレスは文書用で、実際のWebサイトの確認には使えません。実際のサービスのマッピングには、利用者が確認できるネットワーク情報を使ってください。

Hostのマッピングはサービス設定の代わりにならない

静的マッピングは、利用者自身のテスト環境など、ホスト名とアドレスの対応を固定する必要がある場合に使います。そのホスト名が本来使う動的な名前解決結果を迂回するため、使えなくなった古いアドレスが残ることもあります。コンテンツ配信、アドレスのローテーション、地域ごとに異なる応答を使うサービスでは、アドレスを手動で固定すると本来の選択を妨げる可能性があります。一度だけ接続できたアドレスを、汎用的な解決策として長期間使わないでください。

アドレスに接続できても、HTTPSではホスト名と証明書などの条件が一致している必要があります。ドメインを別のサーバーに割り当てても、そのサーバーに対象ドメインの証明書やサイトのコンテンツが自動で設定されるわけではありません。証明書の警告、別のサイトからの応答、接続拒否が発生した場合は、元のマッピングに戻してサーバー側の情報を確認してください。ルールの範囲を広げ続けないようにします。ドメイン、アドレス、サービスの識別情報がすべて一致している必要があります。

名前解決に失敗した場合の確認手順

まず、失敗が名前解決の段階で起きたのか、アドレス取得後に起きたのかを確認します。接続ログに名前解決エラーが表示されている場合は、DNS設定とその到達性を優先して調べてください。接続先アドレスが表示されている場合は、ポリシー、サーバー、接続先の応答を確認します。ブラウザーのエラーメッセージだけで判断しないでください。異なる原因でも似た画面が表示されることがあります。失敗したリクエストの時刻と接続先を記録すると、ログと照合しやすくなります。

次に、不要になった[Host]のマッピングが残っていないか確認します。同じドメインに静的マッピングがあると、DNSサーバーを変更してもテスト結果に変化が現れない場合があります。設定に古い固定アドレスがないことを確認してから、システムの名前解決結果と現在の設定による結果を比較してください。比較時はキャッシュも考慮し、古い記録を新しい設定の結果と取り違えないようにします。関連するリクエストを新たに発行し、必要に応じて再接続してから確認してください。

名前解決リクエストの経路と、実際の通信の経路も区別してください。通信ルールにPROXYを指定しても、名前解決に使う通信が必ず同じサーバーを通るとは限りません。名前解決に関する現在の設定が実際にどう動くか確認してください。DNSを調整するときに、サーバーの変更、最終ポリシーの変更、Hostマッピングの追加を同時に行わないでください。Webページが表示されるようになっても、どの変更が効いたのか分からなくなります。

ローカルネットワーク内のホスト名を使う場合は、そのネットワークの名前解決環境でしか解決できない名前かどうかも確認してください。元のネットワークを離れて名前解決できなくなっても、ルールファイルが壊れたとは限りません。一方、外部のネットワークで特定のローカルネットワークにしか使えない固定アドレスを残すと、接続に失敗し続ける場合があります。ネットワーク環境が変わったら、環境に依存する設定を見直してください。

より詳しいトラブル対処の手順は、遅延は正常なのにWebページが開かない場合のDNS確認方法をご覧ください。まず失敗した段階を特定し、その段階に関係する項目を変更します。名前解決の後にルーティングを確認し、ルーティングが正しければ接続先のサービスを調べます。すべての問題を「DNSを変える」だけで解決しようとしないでください。

07 URL Rewriteの適用範囲と注意点

[URL Rewrite]はURLの条件に基づいて処理するセクションで、接続のポリシーを振り分ける[Rule]とは役割が異なります。前者は取得可能なURL情報と対応する処理を扱い、後者は接続がどの経路を使うかを扱います。特定のドメインをプロキシ経由にする場合は、まずドメインルールを検討します。特定の古いページのURLを新しいURLへ転送する場合に、リライト条件と処理方法を確認してください。

対象のURLを明確にしてから正規表現を絞り込む

リライトルールには通常、マッチする式、転送先、処理方法を記述します。次の例では、特定の古いURLを一時的なリダイレクトで新しいURLへ転送します。構文と一致範囲を説明する例であり、利用者が実際に例示のドメインへアクセスする必要はありません。編集後は、アプリがその行を正しく読み込むことを確認し、新しいリクエストで結果を検証してください。ファイルを保存できたことだけでは、動作確認になりません。

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

式の先頭にある^は文字列の開始位置、末尾の$は終了位置を指定します。ドメイン内のドットを表す\.は、ドットそのものを意味します。エスケープしない場合、正規表現のドットは通常、任意の1文字を表すため、意図しないURLまで一致する可能性があります。長い式から文字を削ったり変えたりするより、各記号の意味を理解してから変更すると、対象範囲を管理しやすくなります。

この例はサブドメイン、追加のパス、クエリーパラメーターを対象にしません。URL末尾にクエリー文字列が付くと、末尾を指定する条件が意図どおりに一致しない場合があります。パラメーターも処理する必要がある場合は、パラメーターを保持するのか、破棄するのか、並べ替えるのかを決めてから式を設計してください。すべてに一致する広い式を安易に追加すると、ログイン後の戻り先、リソースのパス、後続のページまで対象になる可能性があります。

リダイレクトと接続ポリシーは別々に検証する

リダイレクト後のリクエストは、新しい接続先へ進みます。新しい接続先でも名前解決が必要で、適用されるルーティング条件に従って接続します。元のURLのドメインが直接接続でも、転送先の別ドメインが直接接続になるとは限りません。トラブル対処では、最初のURLと最終的なURLの両方を記録してください。最初のリクエストだけを確認すると、実際には後続の接続先で失敗しているのに、ポリシーが効いていないと誤解することがあります。

サーバーの認証エラー、プロトコル項目の不足、DNSサービスへの接続不能をURL Rewriteで解決しようとしないでください。これらは異なる階層の問題で、URLの文字列を変更しても基盤となる情報は補えません。接続確立前にタイムアウトする場合は、まずサーバー、名前解決、ポリシーを確認します。リクエストが処理可能な段階まで進んでいることを確認してから、正規表現とリダイレクトの動作を調べてください。

HTTPSで取得できる情報の範囲に注意する

HTTPSではURLの完全なパスやリクエストヘッダーが暗号化された接続内にあるため、リライト行を追加すればすべての内容を読み取って変更できるとは限りません。具体的なルールが適用されるかどうかは、プロトコル、アプリの動作、関連する設定条件によります。証明書の信頼に関する設定はセキュリティ上の境界を変えるため、ルールを有効にするための標準手順として扱わないでください。通常のドメイン振り分けに、暗号化された内容の読み取りは必要ありません。

リライトが反映されない場合は、式が実際のURLを対象にしていない、既存の接続が再利用されている、結果がキャッシュされている、といった原因を先に確認してください。すぐに対象範囲を広げたり、すべてのドメインを追加処理の対象にしたりしないでください。用途を確認できない証明書や設定がある場合は、変更を止め、現在の動作する状態を保ったうえで、入手元と必要性を一つずつ確認します。ルールの範囲を広げるほど、検証の手間と影響範囲も大きくなります。

リダイレクトループにも注意してください。転送先のURLが元の条件に再び一致すると、同じ処理が繰り返されることがあります。テスト時はURLが何度も変化していないか、リダイレクト回数の上限を超えたという表示がないか、ログに同じ接続先が繰り返し出ていないかを確認します。対処するには古いURLの条件を明確にし、転送先が同じ条件に一致しないようにします。プロキシサーバーの変更でループを隠さないでください。

設定を保守する際は、接続ルールとURLの処理を別々のグループとして記録してください。リライトを削除または無効にして基本的なアクセスが戻った場合は、そのセクション内で原因を絞り込みます。振り分け全体をすぐに変更しないでください。ドメインに応じた経路選択だけが必要なら、リライトのセクションは空のままにするか、追加しなくてもかまいません。設定の完全性は実際の要件を満たすかどうかで決まり、利用可能な機能をすべて記述することではありません。

08 設定の変更・検証・トラブル対処

設定変更は、元に戻せる手順で進めます。元のファイルを保存し、目的を一つに絞り、関連する条件を一組だけ変更します。その後、新しいリクエストを発行し、実際に一致したルールと接続結果を確認してください。一度の検証で確認する内容は、「この完全なドメインがプロキシ経由になるか」のように一つに絞ります。名前解決、プロトコル、すべてのページリソース、ルール全体の正しさを同時に判断しないでください。目的が具体的なほど、結果を説明しやすくなります。

最小限の確認記録を残す

作業前に、現在選択中の設定、Global Routingのモード、選択中のサーバー、ネットワーク環境、テスト対象を記録してください。サブスクリプションのURLや認証情報を記録する必要はありません。トラブルについて他者に伝える際は、パスワード、完全なサブスクリプションURL、その他の個人情報を隠してください。ローカルログのクエリーパラメーターにも機密情報が含まれる場合があるため、サーバー名を隠すだけで十分だと考えないでください。

Configで現在のファイルを確認してコピーを保存し、変更するセクションを決めます。
半角の句読点、セクションの位置、ポリシーの綴り、FINALの位置を確認し、保存後にファイルを読み込めることを確かめます。
検証に使うConfigモードに戻し、接続スイッチが意図した状態であることを確認します。
対象ページを開き直すか、新しいリクエストを発行し、接続ログの対象、適用されたルール、ポリシーを照合します。
結果が想定と異なる場合は、直近の変更を元に戻して、失敗した段階から確認します。例外を次々と追加しないでください。

現象に応じて確認範囲を絞る

症状	優先して確認する項目	次の手順
設定ファイルを読み込めない	セクション名、半角の句読点、項目数	直近の変更を元に戻し、一行ずつ追加し直す
常にFINALに一致する	接続先の種類と、前にある条件の範囲	実際のドメイン、アドレス、取得可能なリクエスト情報を確認
想定したポリシーに一致するがタイムアウトする	名前解決、サーバー、接続先への到達性	選択した経路を個別に検証し、ルールを追加しない
一部のリソースだけ失敗する	サブリソースのドメインとリダイレクト先	失敗したリクエストを確認し、リスト全体を広げない
ネットワークを変更すると異常が起きる	ローカルネットワークのマッピング、名前解決条件、アドレスの種類	環境に依存する設定を見直し、同じ接続先で比較

すべてのリクエストがFINALに一致する場合は、まず編集したファイルが実際に使われているか確認します。次に、ドメイン欄に完全なURLを誤って記述していないか、前の条件が取得できない情報に依存していないかを調べてください。特定の接続先だけ結果が異なる場合は、その接続先を対象にする条件をすべて検索します。特に、前にあるサフィックスやキーワードを確認してください。FINALに一致するのは前の条件に一致しなかったためです。最初に何度も変更する対象ではありません。

ポリシーが正しいのに接続できない場合は、ルールの追加をいったん止めます。手持ちのサーバー情報と対応するプロトコルが一致しているか、アドレス、ポート、認証、通信関連の項目を確認してください。異なるプロトコルで似た項目名でも、互いに置き換えられるとは限りません。ルールの変更で認証エラーは解決できません。項目を確認するにはVMessとVLESSの項目の違いを参照し、手持ちのサービス情報と一つずつ照合してください。

サブスクリプション、設定、サーバーは分けて管理する

サブスクリプションの更新後に変化があった場合は、ルールファイルが変わったと思い込まず、まずサーバー一覧と現在の選択を比較してください。重複項目を削除する前に、どの既存サブスクリプションに属しているかを確認します。手動で追加した項目と更新後の項目が同時に残っている可能性があるためです。グループ分け、更新、重複の整理については複数のサブスクリプションの管理方法を、共有データの種類については単一サーバーのリンクとサブスクリプションURLの違いをご覧ください。

検証が終わったら、最終的に有効だった変更を記録し、目的、理由、確認結果を残してください。一時的な例外が不要になった場合は削除し、トラブル対処を重ねるうちに互いを上書きするルールが残らないようにします。リモート設定を再取得した場合も、ローカルの変更内容を確認してください。長期的な管理ではルールの数より、各条件の意味を説明できること、用途が明確であること、問題発生時に元に戻せることが重要です。

最後に、アプリの入手先と利用条件を確認してください。Shadowrocketは主にiPhone、iPadで利用されます。Mac、Apple TV、Apple Visionとの互換性や購入対象は、App Storeの製品ページに記載された内容をご確認ください。アプリのアップデートはApp Storeで管理します。本ページの設定例はシステム要件を変更するものではなく、ネットワークサービスも含みません。購入前に、デベロッパ名のShadow Launch Technology Limited、公式アイコン、App ID 932747118を確認してください。

基本操作がまだの場合は、チュートリアルに戻り、手順に沿って確認してください。具体的な問題が分かっている場合は、トラブル対処で該当する項目を探せます。結果を安定して再現できる最小構成を保存してから、他のルールを少しずつ戻す方法は、広い条件を次々に追加するより原因を特定しやすく、正常な接続への影響も抑えられます。