Shadowrocket
ルール・設定リファレンス
設定セクション、マッチ条件、実行ポリシーから確認できます。使用中のファイルを確かめ、項目を一つ変更したら、リクエストログで結果を確認してください。
サブスクリプションの追加、VPN構成の許可、接続の開始については、クイックスタートガイドを参照してください。このページでは設定が反映される仕組みと、ルールがマッチする・しない理由を説明します。初回接続後の項目別確認にお役立てください。
01 · 設定ファイルの構成と編集時の注意
Configを開き、一覧で最後に読み込んだファイルではなく、現在選択されている設定を確認します。そのファイルの編集画面に進み、設定セクションと既存のルールが表示されることを確かめてから変更してください。保存後に一覧へ戻り、選択中のマークが同じファイルを指しているか確認します。別のコピーを編集した場合、内容が正しくても現在の接続には反映されません。Configで管理するルーティング設定と、Homeのサーバー一覧は役割が異なります。同じデータとして扱わないでください。
設定セクションの役割
Shadowrocketのテキスト設定は、角括弧で囲んだセクション名を使って構成されます。セクション名は独立した行に記述し、次のセクションが始まるまで、後続の内容はそのセクションに属します。Generalには基本動作のパラメーター、Ruleには順番に評価する条件、Hostにはホスト名とアドレスの対応、URL RewriteにはリクエストURLの書き換えやリダイレクトに関するルールを記述します。ドメイン名に見える行でも、すぐにHostへ入れないでください。経路を決めるのか、名前解決の結果を指定するのか、リクエストURLを変更するのかを先に判断します。
| セクション | 主な役割 | 主な内容 |
|---|---|---|
[General] | 基本設定パラメーター | dns-server = system |
[Rule] | 条件のマッチとポリシーの選択 | DOMAIN,example.com,PROXY |
[Host] | ホスト名とアドレスの対応付け | lab.example.com = 192.168.1.20 |
[URL Rewrite] | リクエストURLのマッチと処理 | 正規表現、転送先、アクション |
構成の読み方を示す最小限の例です。基本パラメーターとRuleのみを示しており、サーバー定義は含みません。完全な設定の代わりにはなりません。PROXYに利用可能な接続先があるかは、Homeで確認してください。例のドメインは説明用です。実際に検証するときは、テストする権限があり、アクセス結果を把握できる接続先に置き換えてください。サーバーの状態を確認するために、例示アドレスへ何度もアクセスするのは避けてください。
[General]
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY元のファイルを残し、検証用のコピーを作成する
編集前に、現在使えている設定をエクスポートまたはコピーし、用途が分かる名前を付けてください。バックアップからGeneral、Rule、カスタムHostの内容を復元できることを確認し、サーバー一覧も別途保存されているか確かめます。エクスポートした内容にはサブスクリプションURLや認証情報が含まれる場合があります。ファイル全体を公開の掲示板に投稿しないでください。相談する際は、該当するルール、マスキングした接続先情報、実際に起きているエラーだけを共有します。
項目が受け付けられたかどうかは、保存結果、アプリ内エディターの説明、リクエストログを合わせて確認します。半角のカンマ、等号、セクション名はそのまま使用してください。全角の句読点、見えない空白、文書アプリからコピーした特殊な引用符などは、行が意図どおりに解析されない原因になることがあります。保存直後にエラーが出た場合は、最後の変更を戻し、一行ずつ修正してください。複数のセクションを同時に書き換えて解決を試みないでください。
サブスクリプションの更新と設定の更新を区別する
既存のサブスクリプションは通常、サーバー項目の更新に使います。リモート設定ではルーティングルールや基本パラメーターが更新される場合があり、両者は別のものです。サーバーを更新してもRuleが変わるとは限りません。リモート設定を再取得した場合は、ローカルで編集した内容を確認し直す必要があることもあります。操作する前に、更新項目の場所、リモートコンテンツの種類、保存先を確認してください。サブスクリプションURLはご利用のサービス提供元から入手してください。このページではURLを提供せず、サービスの品質評価も行いません。
アプリ内の編集画面とこの記事の例に違いがある場合は、現在の項目説明を優先し、既存の動作するパラメーターを維持してください。システム要件はApp Storeの掲載内容をご確認ください。アプリのアップデートはApp Storeから行います。アップデートのために設定ファイル全体を置き換える必要はありません。設定はネットワーク動作を、App Storeはアプリの入手とアップデートを担います。それぞれ別の手順として確認してください。
02 · Global Routingとマッチの優先順位
ルールを確認する前に、HomeでGlobal Routingを開き、現在どのモードになっているか確かめてください。設定に応じて振り分ける場合はConfig、プロキシ経由の場合はProxy、直接接続の場合はDirectです。Ruleによる振り分けを確認するにはConfigを選び、新しいリクエストを発生させてログを確認します。Configでルールを編集しても、Proxyモードのまま全リクエストがプロキシ経由になっていることを見ただけでは、Ruleの構文に問題があるとは判断できません。モードによって、現在の判定にルールが使われるかどうかが決まります。
| 画面上の選択肢 | 確認する内容 | 結果を読む際の注意 |
|---|---|---|
| Config | 現在の設定に従って通信を振り分ける | 選択中の設定とRuleの順序も確認する |
| Proxy | プロキシ経由の接続が機能するか確認する | カスタムRuleの順序は検証できない |
| Direct | 直接接続した場合の結果と比較する | 現在のネットワークやシステムの名前解決条件にも左右される |
最初にマッチしたルールが優先され、「最長のルール」が優先されるわけではない
Ruleは上から順に確認し、最初に条件を満たしたルールが今回のポリシーを決定します。後ろにあるルールがより具体的でも、先にマッチしたルールを自動で上書きすることはありません。完全一致のドメインルールを広範囲なサフィックスルールより前に置くのは、優先順位を手動で設定するためです。アプリが自動で並べ替えるわけではありません。変更時はセクション全体の前後関係を確認し、使いたいルールがファイルに書かれていることだけで判断しないでください。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXYこの例では、api.example.comは最初の行にマッチし、example.comのほかのサブドメインは次の行に進みます。先頭の2行を入れ替えると、api.example.comは先にサフィックス条件を満たし、完全一致の行は判定に使われません。このような問題を調べるときは、対象ホスト名、最初にマッチした条件、最終的なポリシーを記録し、対象範囲の広いルールが上にないか順に確認してください。
FINALは残りのリクエストを処理する
FINALにはドメインやアドレスのパラメーターを追加する必要はありません。それ以前のルールにマッチしなかったリクエストを処理するため、Ruleの末尾に配置します。「失敗したら自動で切り替える」指示ではなく、プロキシへの接続可否を確認する機能もありません。FINAL,PROXYは残りのリクエストをPROXYに渡すという意味です。PROXYに対応するサーバーが利用できなければ、リクエストは失敗する可能性があり、FINALが自動で接続障害を修復することはありません。
途中にFINALを置き、その後ろに例外ルールを追加しないでください。途中にフォールバックを置くと、残りのリクエストを先に処理してしまうため、後続の項目を保存できても想定した例外を適用できません。予備経路を示すために、矛盾するFINALを複数残すことも避けてください。まず残りのリクエストに使う経路を決め、その方針を末尾のルール一つで明確に表します。
ログのアドレスが最初にアクセスしたドメインとは限らない
ページを開くと、メインページ、画像、API、リソースファイルなど、複数の接続が発生することがあります。IPアドレス宛てのリクエストが一つPROXY経由になっただけで、メインドメインのルールが機能していないとは判断できません。Dataのリクエストまたは接続ログから、テストした時刻と対象ホスト名に対応する項目を探し、マッチ情報を確認してください。ログに接続先IPしか表示されない場合は、リクエストにドメイン情報が含まれているか、既存の長時間接続によるものかも確認します。
ルールの保存後も、すでに確立されている接続では以前選択した経路が使われ続けることがあります。設定を保存し、選択中であることを確認してから、接続を確立し直し、対象へのリクエストを発生させてください。必要に応じて関連アプリを終了して再度開きます。同じページを続けて更新するだけでは、キャッシュによってページが更新されたように見えても、確認したい新しい接続が発生していない場合があります。検証結果は、識別できる新しいリクエストに基づいて判断してください。
03 · DOMAIN系ルールの書き方
まずリクエストログから実際のホスト名をコピーし、マッチ方法を選びます。ドメインルールの条件には完全なURLを記述せず、https://、パス、クエリパラメーター、ポートも付けません。たとえば対象がhttps://api.example.com/statusなら、DOMAINの条件にはURL全体ではなくapi.example.comと記述します。パス単位で条件を分ける場合は別の要件となり、DOMAINの後ろにパスを追加しても実現できません。
DOMAIN：指定したホスト名だけにマッチ
DOMAINは、特定のホスト名だけを個別に処理する場合に適しています。DOMAIN,example.com,DIRECTは、文字列が同じだからといってapi.example.comを自動的に含むわけではありません。名前にexampleを含む別のドメインも対象外です。ログインAPI、アップデート先、社内サービスなどに例外を設定する場合は、実際のホスト名を確認してから完全一致で指定します。サービスが複数のホスト名を使っている場合は、1回のアクセスで接続先が一つだけだと思い込まず、それぞれ記録してください。
[Rule]
DOMAIN,login.example.com,PROXY
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXYこの例では2つのホスト名を明示し、ほかのサフィックスに対する処理を設定しています。login.example.comの完全一致ルールとサフィックスルールはどちらもPROXYを指定しており、一見重複していますが、個別に確認する対象であることをメンテナンス時に示せます。その必要がなければ、同じポリシーの重複項目を削除すると設定を読みやすくできます。整理する前に、ルールの順序に依存するほかの例外がないか確認してください。
DOMAIN-SUFFIX：ドメイン階層に基づいてマッチ
DOMAIN-SUFFIX,example.com,PROXYは、example.comとそのサブドメインにマッチします。任意の文字列を含むかどうかではなく、ドメインの境界に基づいて判定されます。api.example.comは対象ですが、notexample.comは対象外です。条件には通常example.comをそのまま指定します。アスタリスクを加えたり、正規表現として扱ったりしないでください。範囲を狭めるにはapi.example.comのようにサフィックスを指定し、その下のホスト名も含めるかを明確にします。
サフィックスルールを使うと、サービスのドメイン配下にある複数の接続先をまとめて扱えます。ただし、ページのリソースがすべて同じドメインにあるとは限りません。ログインはできるのに画像が表示されない場合は、メインドメインのルールを広げ続けるのではなく、画像リクエストの実際のドメインを確認してください。観測したドメインを広すぎるキーワード一つにまとめると、関係のないリクエストにも影響することがあります。まず失敗した項目を集め、完全一致ルールを追加するか、別のサフィックスを指定するか判断します。
| キーワード | 条件の例 | マッチする範囲 |
|---|---|---|
| DOMAIN | api.example.com | 指定したホスト名のみ |
| DOMAIN-SUFFIX | example.com | 指定したドメインとそのサブドメイン |
| DOMAIN-KEYWORD | example | ホスト名に指定文字列を含むもの |
DOMAIN-KEYWORD：想定より広い範囲にマッチすることがある
DOMAIN-KEYWORDはドメイン文字列に対してキーワードでマッチします。キーワードが完全なドメインラベルと一致する必要はありません。DOMAIN-KEYWORD,example,PROXYは、文字列を含む複数の無関係なドメインにもマッチすることがあります。この広い範囲を意図している場合には適していますが、すべてのDOMAIN-SUFFIXの代用にはなりません。トラブルの切り分けでは、広いキーワードを実際に確認できたホスト名に絞ると、誤マッチの影響を減らせます。
ルール条件に日本語のコメント、末尾の余計なカンマ、ブラウザーからコピーした句読点を含めないでください。ポリシーはルールの所定の末尾位置に記述し、説明は別の行に書いてフィールドと混同しないようにします。設定エディターで種類、条件、ポリシーを個別に入力できる場合は、長い行を貼り付けるより欄ごとに入力した方がミスに気付きやすくなります。保存後、テキスト表示に戻って結果を確認してください。
マッチ範囲とポリシーの変更を分けて検証する
ドメインルールをテストするときは、まずポリシーを変えずに、対象がそのルールにマッチするかだけを確認します。条件が正しいと確認できたら、PROXYまたはDIRECTを変更してください。これにより、「条件にマッチしていない」のか「マッチしたが経路で失敗した」のかを区別できます。条件、サーバー、DNSを同時に変更すると、成功しても失敗しても原因を特定できず、元に戻す判断もしにくくなります。
04 · IP、GEOIP、USER-AGENT
ドメイン条件だけですべてのリクエストを処理できるわけではありません。アプリがIPアドレスへ直接接続する場合や、接続ログにルールで使えるホスト名がない場合は、IP-CIDR、IP-CIDR6、GEOIPを使って判定することがあります。まず実際の接続先アドレスとアドレスファミリーを確認し、条件を選んでください。ブラウザーのアドレスバーに表示される文字列だけから、接続時に必ずドメインが使われると判断しないでください。また、アドレスルールをWebサイトの恒久的な識別方法と考えないでください。
IP-CIDR：アドレスとプレフィックス長
IP-CIDRの条件は、ネットワークアドレスとスラッシュの後ろに続くプレフィックス長で構成されます。192.168.0.0/16はアドレス範囲を表し、192.168.1.20/32はIPv4アドレス一つだけを対象とします。一般にプレフィックスの数値が大きいほど範囲は狭くなります。ルールの対象は接続先アドレスであり、現在使っているiPhoneのローカルアドレスではありません。特定の社内機器をDIRECTにする場合は、その機器が属する接続先範囲を指定し、機器自身のアドレスをそのままコピーしないでください。
[Rule]
IP-CIDR,192.168.1.20/32,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR6,fd00::/8,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYこの例では、先に内部の単一アドレスを指定し、その後に広いプライベートアドレス範囲を記述して、後から例外を追加しやすくしています。実際の環境では別の内部ネットワークが使われる場合があります。ネットワーク設定や管理者から提供された情報を確認してください。プライベートアドレスをDIRECTに指定するのはルーティング上で直接接続を選ぶだけで、アクセス権限が自動で付与されるわけではありません。そのネットワークに到達できる環境に接続し、対象サービスが該当ポートで待ち受け、アクセスを許可している必要があります。
IP-CIDR6とIPv6の確認
IP-CIDR6はIPv6のアドレス範囲に使います。例にあるfd00::/8はローカルアドレス範囲の書き方を示すだけで、すべてのIPv6アドレスをDIRECTにするという意味ではありません。同じホスト名から2種類のアドレスが返される場合、IPv4のルールだけでは実際に使われるIPv6接続をカバーできないことがあります。ログで接続に使われたアドレスの種類を確認してからルールを追加してください。アドレスファミリー全体を無効にする方法を通常の修復手段にしないでください。
一部のIP系ルールではno-resolveパラメーターを使用し、そのルールの確認だけを目的とするドメインの名前解決を避けられます。これはマッチ処理によって名前解決が起きるのを抑えるもので、リクエストに必要なすべてのDNS処理を無効にするものではありません。リクエストがドメイン名だけで、利用可能な接続先IPがない場合、想定どおりにマッチしないことがあります。使用する前に現在のエディターが対応しているか確認し、パラメーターの有無による違いをそれぞれ検証してください。
IP-CIDR,192.168.0.0/16,DIRECT,no-resolveGEOIPは言語ではなくIPアドレスのデータベースに基づく
GEOIP,CN,DIRECTは、対象IPの地理的な分類に基づいてDIRECTを選択するという意味です。ページの言語、ドメインの末尾、ユーザーの現在地による分類ではありません。ドメインが分散したアドレスを使うことがあり、データベース上の地域判定に差が生じることもあります。そのため、サービスの運営地を推測したり、接続速度を保証したりする用途には使えません。少数の特定サービスを例外にする場合は、検証済みのDOMAINルールを前に置く方が、広範なGEOIP条件を追加するより管理しやすいことがあります。
ドメインルールとGEOIPが同時にある場合も、順序が重要です。前方のドメイン条件にマッチしたリクエストを、後方のアドレス分類が自動的に別のポリシーへ変更することはありません。ログでリクエストがGEOIPにマッチしている場合は、先行するドメイン条件が実際のホスト名を対象としているか確認し、現在の接続にドメイン情報が残っているかも調べてください。リクエストの対象を確認せずにアドレスデータベースだけを更新しても、問題が解決しないことがあります。
USER-AGENTはアプリの識別方法の代わりにはならない
USER-AGENTは、取得できるリクエストヘッダーのフィールドに基づいてマッチします。たとえば USER-AGENT,ExampleClient*,PROXY は、ワイルドカードパターンを含む条件の書き方を示しています。アプリ名を基準に振り分ける機能ではなく、すべての接続で確認できるとは限りません。暗号化されたリクエストでは、多くの場合ヘッダーを直接取得できません。このルールのためだけに、安易に復号を有効にしないでください。マッチ可能なフィールドがログにない場合は、明確なドメイン条件を探し、残りのリクエストにはFINALを使用してください。
05 · PROXY、DIRECT、REJECTとプロトコルのパラメーター
ルールの前半は「どのリクエストか」を、末尾のポリシーは「どう処理するか」を示します。PROXY、DIRECT、REJECTはよく使われるポリシーキーワードです。大文字・小文字とスペルを正確に保ってください。ポリシー名とサーバーのプロトコルを混同しないでください。Shadowsocks、VMess、Hysteria2はサーバー接続に使うプロトコルを示すもので、RuleでPROXYの代わりに使える汎用アクションではありません。まず条件がマッチしたことを確認し、ポリシーが指す接続先を調べます。
PROXYとDIRECTの使い分け
PROXYは通常、現在選択されているプロキシにリクエストを渡します。実際の接続先はHomeでの選択内容や、設定内にポリシーグループがあるかどうかによって変わります。DIRECTは直接接続する経路を使いますが、ネットワーク環境、システム権限、名前解決を介さなくなるわけではありません。ある接続先にDIRECTで接続できても、プロキシの設定が正しいとは限りません。プロキシで接続できても、すべての内部アドレスをプロキシ経由にすべきとは限りません。サービスの設置場所と利用目的に応じて選択してください。
現在の設定に名前付きポリシーグループがある場合は、ルール末尾でグループ名を指定できることもあります。その場合は、グループが実在するか、名前が完全に一致しているか、利用可能なメンバーが含まれているか確認してください。別のファイルにあるグループ名を貼り付けても、自動で作成されるわけではありません。この記事の例では単独で読みやすいよう基本ポリシーを使っています。グループを使用している設定では、既存の構成を保ちながら例外ルールを配置してください。
REJECTはリクエストを明示的に拒否する
REJECTは、マッチしたリクエストを明示的に拒否するために使用します。「テストに失敗したら別のサーバーに切り替える」機能ではありません。対象を確実にブロックしたい場合にのみ使用してください。ログインに必要なドメインに誤ってREJECTを設定すると、アプリが待ち続ける、ボタンが反応しない、一部のリソースが読み込まれないといった状態になることがあります。明確な拒否メッセージが表示されるとは限りません。確認する際は拒否された項目を探し、条件が広すぎないか確認してから、削除または範囲を限定します。
[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,internal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXYこのルール例では、3つの異なるホスト範囲に対するアクションを示しています。実際のログインドメインを拒否リストに加えることを推奨するものではありません。blocked.example.comは拒否し、internal.example.comは直接接続、その他のexample.comサブドメインはプロキシ経由に設定しています。順序を変えるだけで結果が変わる場合があります。それぞれの例外について、必要な理由を短く記録してください。説明できない拒否ルールを増やすより、長期的に管理しやすくなります。
使用中のサーバーのプロトコルと設定項目だけを確認する
サーバーを読み込んだら、まずプロトコルの種類を確認し、次にアドレス、ポート、認証項目を確認してください。Shadowsocksの暗号化方式とパスワード、VMessやVLESSの識別情報、TrojanのパスワードとTLS設定は、それぞれ意味が異なります。項目の位置が似ていても相互に置き換えないでください。インターネット上の断片的な例より、ご利用のサービス提供元から受け取った完全な情報を優先します。不足している項目は情報の提供元に確認し、推測で補わないでください。
| プロトコル | 主な確認項目 | 追加の確認事項 |
|---|---|---|
| Shadowsocks | アドレス、ポート、暗号化方式、パスワード | 追加オプションがサーバー側の設定と一致しているか |
| VMess / VLESS | 識別情報、通信方式 | TLS、SNI、パスなどを実際の情報に合わせる |
| Trojan | パスワード、TLS、サーバー名 | 証明書名と接続パラメーターの一致 |
| Hysteria2 | 認証、TLS、UDPの到達性 | 現在のネットワークで必要な通信が許可されているか |
| WireGuard | 鍵、エンドポイント、アドレス、ルーティング範囲 | 既存の設定と照合し、鍵を公開しない |
TLS関連の失敗では、サーバー名、証明書の条件、システム時刻を確認してください。証明書の検証を省略する方法を通常のトラブル対処として使わないでください。Hysteria2を利用する場合は、UDPが実際に到達可能かも確認します。あるテストで応答があっても、すべての通信方式が正常とは限りません。プロトコルごとに成功条件を確認し、あるサーバーでの結果から別のサーバー設定の正しさを判断しないでください。
PROXY経由のリクエストは失敗する一方、DIRECTでは成功する場合、選択中のサーバー、プロトコルの種類、失敗した段階を記録し、Homeで該当項目を確認してください。同じサーバー経由ですべての接続先にアクセスできない場合は、サイトごとにルールを追加するのではなく、サーバーとネットワークを優先して確認します。一つの接続先だけ失敗する場合は、追加のドメイン、特殊なポート、サーバー側のアクセス制限が関係していないか調べてください。
06 · General、DNS、Hostの対応付け
DNSはホスト名を接続可能なアドレスに変換し、Ruleはリクエストの処理ポリシーを決定します。相互に関係しますが、同じ機能ではありません。ページが開かないときは、まずアドレスを取得できたか、次にどこへ接続したか、最後にどのポリシーが使われたかを確認します。DNSを変更してもパスワードの誤りは直せず、PROXYを変更しても存在しないドメインの名前解決は保証されません。障害の段階を分けて記録すると、関係のない項目を繰り返し変更せずに済みます。
dns-serverとシステムの名前解決環境
Generalの dns-server = system は、システムが提供するDNS設定を使うことを意味します。項目の役割を理解するための基本例であり、すべてのネットワークに適した設定とは限りません。システムの名前解決環境は、Wi-Fi、モバイル通信、ネットワーク管理設定によって変わります。まず現在のネットワークと既存のDNS設定を記録してから、設定内の名前解決オプションを変更してください。ネットワークを切り替えた際に違いが出ても、比較できる元の条件が残ります。
[General]
dns-server = system
[Host]
lab.example.com = 192.168.1.20
[Rule]
DOMAIN,lab.example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXYこの例では、lab.example.comを内部機器に割り当て、そのドメインを直接接続するよう設定しています。対象の名前と機器を自分で管理しているテスト環境に限って使用してください。Hostはアドレスの対応付けを行い、DOMAINはポリシーを選択します。後者がなければ、リクエストは別のRuleに従ってプロキシ経由になることがあります。反対に、DIRECTだけを指定して正しく名前解決されなければ、ホスト名が対象機器を指すとは限りません。
Hostは証明書やサービスの識別情報を変更しない
ホスト名を特定のIPに対応付けても、アクセス時に使われる名前は通常そのままです。HTTPSサービスにはその名前に一致する証明書が必要で、サーバー側もホスト名に基づいてサイトを選ぶことがあります。IPアドレスでページが開いたからといって、任意のHostを追加すれば正常にアクセスできるとは限りません。アドレスへの到達、証明書の一致、サイトの設定は別の条件です。それぞれ確認してください。
Hostは、アドレスが動的に変わる公共サービスを長期間固定する用途には適しません。サービスが接続先を変更した後も古い対応付けが残ると、無効になった接続先へリクエストが送られ、「ほかの端末では正常なのに、この端末だけ失敗する」ことがあります。問題を調べる際は古い対応付けが残っていないか確認し、一時的に削除してから接続し直して比較してください。内部機器に使う場合も、ネットワークから再割り当てされたことでアドレスが変わっていないか確認します。
DNSキャッシュと接続の再利用を区別する
対応付けを変更しても、古い名前解決結果や既存の接続が観察結果に影響する場合があります。ファイルを保存し、設定が選択されていることを確認してから、再接続して新しいリクエストを発生させてください。必要であれば、アプリに用意された操作から関連キャッシュを消去します。「ページに古い内容が表示される」だけでHostが反映されていないと判断しないでください。ページ、サーバーのキャッシュ、接続の再利用が古い結果を残すことがあります。新しいログに記録された接続先アドレスを優先して判断してください。
ログにドメイン名に対応するアドレスが表示されない場合は、まず現在のネットワークでその名前を解決できるか確認します。スペルミス、内部DNSへの依存、アプリ独自の名前解決方法も調べてください。アプリによっては一般的な方法ではリクエストを十分に確認できないことがあり、その結果だけでDNS設定がすべて無視されているとは判断できません。複数のページを同時に試すより、再現可能な対象を一つに絞ると原因を特定しやすくなります。
Generalのパラメーターを個別に確認する
Generalには、システムトラフィックの処理、例外範囲、アドレスファミリーに関するパラメーターが含まれる場合があります。これらを「最適化スイッチ」としてまとめて貼り付けないでください。既存ファイルを基準に項目の意味を調べ、Ruleとの関係を確認します。接続の取り込み範囲に影響するパラメーターの場合、Ruleを追加するだけではその効果を補えないことがあります。一度に変更するのは一項目にし、変更前の値とそのときの状況を記録してから次に進みます。
暗号化DNSなどの名前解決方式を使う場合は、名前解決のリクエストが接続先にどのように届くか、接続の依存関係が生じないかも確認してください。プロキシサーバーのアドレスを解決する必要があるのに、DNSサーバーへの接続がそのプロキシに依存していると、起動時に相互待ちが発生する場合があります。このようなときは、まず動作が確認できている基本設定に戻し、名前解決と接続を順番に確立します。根本的な依存関係を見えなくするために、DNSアドレスをむやみに追加しないでください。
07 · URL Rewriteの用途と制約
変更したいのがアクセス経路なのか、リクエストURLなのかを最初に明確にします。example.comをPROXYに送るのはRuleの役割です。古い接続先から別のURLへ転送する場合は、URL Rewriteが関係することがあります。両者は設定セクションを置き換えて使うものではありません。また、URL RewriteをRuleより前に置いても、ルーティングの優先順位が上がるわけではありません。それぞれ別の問題を扱うため、検証では経路の結果とURLの変化を分けて確認してください。
制御できるHTTPの接続先から始める
URL Rewriteは通常、マッチ条件、転送先、処理アクションで構成されます。以下では、HTTPからHTTPSへのリダイレクト例を使って構造を説明します。テスト前に対象の接続先を自分で管理していることを確認し、現在のエディターが対応するアクションと構文を使用してください。式中のバックスラッシュはドットを通常の文字として扱うために使い、括弧はパス部分をキャプチャします。転送先の$1は、最初のキャプチャグループを参照します。
[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302この行はURLの先頭からhttp://example.com/にマッチし、その後ろの文字列を転送先に引き継ぎます。302は一時的なリダイレクトを表します。転送先のサーバーでHTTPSが自動的に有効になるわけではなく、証明書の問題も解決しません。転送先にアクセスできなければ、リクエストは別の失敗先へ移るだけです。まず転送先URLへ直接アクセスできることを確認し、その後、元のURLが転送されるかをテストしてください。
正規表現ではマッチ範囲を限定する
正規表現ではドットが既定でほかの文字にもマッチするため、エスケープを省くと範囲が広がることがあります。先頭アンカーを付けると、文字列の途中で意図せずマッチするのを防げます。短いキーワードだけの条件では、どのURLを対象にするのか明確にできません。まずプロトコル、ホスト名、必要なパスを具体的に指定し、結果を確かめてから拡張してください。最初に広い条件を作り、誤マッチを後から一つずつ除外する方法は避けます。
URLにはクエリパラメーター、エンコード文字、異なるパス形式が含まれることがあります。例のキャプチャグループはスラッシュ以降を保持しますが、複雑なアドレスを常に単純な連結で扱えるわけではありません。ログイン後のコールバック、署名付きリクエスト、正確なパラメーター順に依存するAPIでは、一部を変更しただけで検証に失敗することがあります。このような接続先を扱う場合は、まずプロトコルの仕様を確認してください。一般的なページを開ける式を、認証処理にそのまま適用しないでください。
リダイレクトループとリクエストの意味の変化を避ける
ルールを追加した後、転送先URLが同じルールに再びマッチするか、別のルールで元のURLに戻されないか確認します。ページが何度も転送される、アドレスが繰り返し変わる、リクエスト数が増え続ける場合は、追加したルールを無効にしてログを保存してください。複数の接続先を相互に書き換えると、簡単にループが発生します。保守しやすいよう、元の条件、転送先、想定する最終URLを記録し、一行の記述だけで正しさを判断しないでください。
リダイレクトによって、リクエストメソッド、リクエストボディ、認証ヘッダーの扱いが変わる場合もあります。実際の挙動はアクションとリクエストを送るアプリによって異なります。ブラウザーでGETリクエストが成功しても、APIのPOSTリクエストが同じように動くとは限りません。フォーム送信、決済、認証などに関わるリクエストは、サービスの仕様を理解していない限り、元のままにして汎用ルールで一括書き換えしないでください。
HTTPSで確認できる範囲と証明書の条件
通常の暗号化接続では、完全なURLパスは一般的なルーティング判定から直接見えません。HTTPSの内容を読み取る機能には、追加の復号処理と信頼設定が必要です。URL Rewriteを記述しただけで、その条件も満たされていると考えないでください。このページの例は暗号化されていないHTTPから始まり、ルールを確認するために証明書を信頼対象に追加する必要はありません。ドメインに基づく振り分けだけなら、Ruleを使用してください。
証明書を信頼する手順を、あらゆる書き換え失敗の解決策として使わないでください。まずテストリクエストが実際に確認できるか、式がマッチするか、アクションに対応しているか、転送先へ到達できるかを確認し、この機能が現在の要件に適しているか判断します。アプリによっては証明書を独自に検証したり、接続先を固定したりすることがあります。失敗した場合は、検証条件を緩め続けるのではなく、書き換え範囲を広げるのをやめてください。
検証が終わったら、必要最小限のルールだけを残し、それぞれの目的とテスト先を記録します。Webサイト側ですでにリダイレクトしている場合、ローカルで同じ書き換えを追加すると管理する箇所が増えるだけです。ルールを削除してもアクセス結果が変わらない場合は、サーバー側またはブラウザーのキャッシュによって転送されていないか確認してください。処理の担当を特定してからルールを残すか決めると、後で設定を移行する際の隠れた依存を減らせます。
08 · 設定の検証、On Demand、メンテナンス手順
検証前に、「api.example.comへの新しいリクエストがDOMAINにマッチし、DIRECT経由になる」のように、確認可能な目標を一文で決めます。現在のネットワーク、Global Routing、選択中の設定、サーバーを記録してからアクセスしてください。成功の判断はスイッチの色が変わったかではなく、リクエストが想定どおりにマッチし、接続先サービスから妥当な応答が返ったかで行います。ルーティング判定が正しくてもサーバー側で失敗した場合は、ルールがマッチしない問題とは別に対処します。
失敗した段階を確認し、変更を重ねない
最初にシステムネットワークが正常に使えるか確認します。次に接続スイッチとVPN構成の許可、続いてサーバー、最後にルールを確認してください。VPN構成の追加を拒否したことがある、または関連する構成を削除した場合は、Ruleを先に変更せず、初回接続の手順に戻ってください。システムの確認画面については、VPN構成の追加とシステム権限についてをご覧ください。
Connectivity Testはサーバーの応答を確認する補助機能ですが、実際の通信リクエストの代わりにはなりません。テストに失敗した場合は、アドレス、ポート、プロトコル、現在のネットワークを確認します。応答があるのにWebページを開けない場合は、DNS、TLS、ルール、対象の接続先を確認してください。テスト方法によって確認できる段階が異なるため、一度の表示結果を通信経路全体の保証と見なさないでください。詳しくは接続タイムアウトの確認手順をご覧ください。
On Demandは接続の開始条件を制御し、ルールの意味は変えない
SettingsでOn Demandの実際の条件を確認し、「いつ接続を開始するか」と「接続後にどう振り分けるか」を区別してください。On Demandは設定した条件に基づいて接続を開始する機能です。パスワードの誤りを修正したり、Ruleの順番を変更したりするものではありません。ルールの検証中は手動接続で安定した状態を作り、振り分けが正常と確認できてから、必要なOn Demand条件を有効にします。自動再接続による検証結果への影響を抑えられます。
手動で切断した後に接続が再開される場合は、設定ファイルが保存されていないと判断する前に、On Demandとシステムの接続条件を確認してください。バックグラウンドのバッテリー消費が気になる場合は、似たネットワーク、同程度の利用時間、同じサーバーで比較します。一度のバッテリー残量の変化だけで設定の問題と判断しないでください。常時接続とオンデマンド接続の使い分けについては、On Demandとバックグラウンドのバッテリー消費についてをご覧ください。
元に戻せる検証記録を作成する
変更するたびに、元のルール、変更後のルール、テスト対象、実際のマッチ結果の4項目を記録します。想定と違う結果になったら、今回の変更をすぐに戻してから次の対応を決めてください。失敗した状態のまま例外ルールを重ねると、最終的に接続できても、どの行が有効だったのか説明しにくくなります。重複条件を大量に残すより、目的を説明できる少数のルールで段階的に要件を満たす方が適切です。
| 確認された現象 | 優先して確認する項目 | 検証方法 |
|---|---|---|
| 新しいルールがまったく適用されない | Configモードと選択中のファイル | 接続を確立し直し、新しいリクエストを確認する |
| ルールにはマッチするが接続に失敗する | 選択中のサーバーまたはDIRECT経路の到達性 | ルールを変えずに、該当する経路だけを確認する |
| ページの一部のリソースだけ読み込めない | リソースのドメインと既存のREJECTルール | 失敗したリクエストのホスト名を一つずつ確認する |
| 更新後にローカルの例外が変わった | リモート設定とローカルコピー | バックアップと照らし合わせ、置き換わった設定セクションを確認する |
トラブルの記録を共有する際は、サブスクリプションURL、パスワード、識別情報、鍵、公開すべきでない内部アドレスを隠してください。通常必要なのは、該当するRuleの抜粋、マスキングした接続先名、マッチしたポリシー、エラーが発生した段階だけです。設定全体を共有する必要はありません。スクリーンショットに認証情報が写っていないかも確認してください。このページではファイルのアップロードや完全なサブスクリプションの提供を求めていません。問題の説明に必要な最小限の情報だけを共有してください。
アップデート後の定期確認
App Storeからアプリをアップデートしたら、現在の設定が選択されていることを確認し、使用中の重要なルールを確認してください。サブスクリプションの更新後はサーバーの選択が有効か、リモート設定の更新後はローカルの例外が想定した位置に残っているかを確認します。機種変更や再インストールでは、アプリの復元と設定の復元を別々に行ってください。購入履歴だけで、すべてのカスタムデータが自動的に復元されるとは限りません。手順は購入済みアプリの復元についてをご覧ください。
続けて確認する場合は、このページの目次から該当する設定セクションへ戻ってください。サーバーの追加から一通りの手順を確認する場合は、Shadowrocketの使い方ガイドをご覧ください。購入、読み込みエラー、システム権限など個別の問題は、FAQからカテゴリ別に確認できます。各ルールの範囲を明確にし、変更をいつでも元に戻せるようにし、再現可能な新しいリクエストに基づいて判断することが大切です。設定ファイルをむやみに長くしないようにしましょう。