この記事の要点

自分のサービス設定を読み込み済みで、Shadowrocketの振り分けルールを編集する方向けの記事です。まずHome → Global RoutingでConfigを選び、「具体的な例外を先に、範囲の広いルールを後に、FINALを最後に」の順で現在の設定を編集します。ルールの一致と接続可否を切り分け、ドメインがDIRECTに振り分けられる、REJECTが適用されない、FINALが早く処理を終えてしまうといった問題を確認できます。

まずGlobal Routingを確認：ルールを適用するための前提

ShadowrocketのHomeでは接続とルーティング方法を選択し、Configではルール設定ファイルを管理し、Settingsでは動作設定を行います。ルールをファイルに記述しただけでは、そのファイルが使われているとは限りません。現在選択中の設定と、Home → Global Routingの状態をどちらも確認してください。この記事では、自分のサービス事業者とサブスクリプションがあり、接続情報が利用可能な状態を前提とします。接続先の入手方法は扱いません。

Global RoutingでConfigを選ぶと、現在の設定に基づいて通信が振り分けられます。ProxyとDirectは通信全体の経路を切り替え、Sceneは設定した条件に応じて動作を選択します。画面上のProxyと、ルールのポリシーキーワードPROXYは混同しないでください。前者はルーティング方法、後者はルールに一致した後の処理を表します。

Config

おすすめ

現在の設定にあるルールに従って接続を処理します。この記事のルール順序の調整とFINALの例は、このモードで確認します。

適した用途：ドメイン、接続先IP、地域に基づいて通信を振り分ける場合。

Proxy

通信全体をプロキシ経由で処理するため、カスタムのDIRECTやREJECTルールが適用されるか確認する用途には向きません。

適した用途：一時的にプロキシ経由の動作と比較し、ルールの問題を切り分ける場合。

Direct

通信全体を直接接続で処理します。この状態でウェブサイトにアクセスできても、設定内のPROXYルールが正しいとは判断できません。

適した用途：ローカルネットワークでの直接接続の状態を比較する場合。

Scene

設定済みのシーン条件に基づいて動作します。ルールを調べるときは、現在のシーンで実際に選択されているルーティング方法を先に確認してください。

適した用途：ネットワーク環境に応じて切り替える条件を設定済みの場合。

判断のポイント：ルールを調整する前にモードを固定する

テスト中はHome → Global RoutingをConfigに設定し、同じ設定ファイルを選択したままにしてください。一度に変更するのは1項目だけにし、シーンの切り替えや通信全体のプロキシ化による結果を、ルールの優先順位が変わった結果と取り違えないようにします。

優先順位は行の順番で決まり、ルール名やドメインの長さでは決まらない

ルールは上から順に確認され、最初に一致したルールのポリシーが適用されると、それ以降のルールは照合されません。「より具体的な」後続ルールが優先されることもありません。そのため、範囲の広いDOMAIN-SUFFIXが、その下にある特定ドメイン向けルールより先に一致する場合があります。REJECTも、拒否を表すという理由で自動的に最優先になるわけではありません。

1件
最初に一致したルールが、その通信に適用するポリシーを決定
3種類
この記事で扱うポリシー：PROXY / DIRECT / REJECT
4種類
この記事で扱うルール：DOMAIN-SUFFIX / IP-CIDR / GEOIP / FINAL

たとえば、次の2行はどちらもads.example.comに一致します。先にある1行目が一致し、DIRECTが適用されます。より具体的な2行目は実行されません。これは順序の問題であり、REJECTが機能していないわけではありません。

DOMAIN-SUFFIX,example.com,DIRECT
DOMAIN-SUFFIX,ads.example.com,REJECT

具体的な例外を先に移動すると、ads.example.comとそのサブドメインには最初にREJECTが適用され、ほかのexample.comドメインは続けてDIRECTに一致します。DOMAIN-SUFFIXは対象ドメイン自体とそのサブドメインに一致するルールで、任意の文字列を部分一致で検索するものではありません。

DOMAIN-SUFFIX,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT

「上から順に」とは、現在実際に使われているルール列を指します。設定で外部ルールセットを参照している場合は、そのルールが設定内のどこにあるかも確認してください。追加した2行だけを見て、それより前にある一致ルールを見落とさないようにします。

DOMAIN-SUFFIX、IP-CIDR、GEOIPが照合する情報

ルールごとに参照する情報は異なります。ドメインルールはホスト名を確認し、IP-CIDRは接続先IPが指定範囲に含まれるかを確認し、GEOIPはIPを地理データベースに基づいて分類します。ドメインにアクセスできるからといって、必ずドメインルールに一致するとは限りません。また、IPが特定の地域に分類されても、サイトの運営者やドメインの末尾がその地域に属するとは限りません。

ルールの例 照合対象 設定時の注意
DOMAIN-SUFFIX,example.com,DIRECT 接続先のホスト名 example.comとそのサブドメインに一致します。個別の例外はこの行より上に配置してください。
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve 接続先IPv4アドレスの属するネットワーク範囲 ここではプライベートアドレスの範囲を例示しています。このネットワークにアクセスするには、ローカルネットワークに対応するルーティングが必要です。
GEOIP,CN,DIRECT 接続先IPの地理データベース上の分類 IPを取得するためにドメイン名の解決が必要になる場合があります。分類結果はデータベースと実際の名前解決結果に左右されます。
FINAL,PROXY それより前のルールに一致しなかった接続 ドメイン名やネットワーク範囲を指定せず、ルール列の末尾に配置します。

no-resolveは、このIPルールとの照合のために追加のドメイン名解決を行わないことを示します。「DNSを無効にする」という意味ではなく、通常のドメイン名解決に代わるものでもありません。リクエストにホスト名しかなく、その時点で利用できる接続先IPがない場合、このルールには一致せず、処理が次のルールへ進むことがあります。

FINALによるフォールバック：例外、範囲ルール、最後にFINAL

FINALには照合条件がなく、それ以前のルールに一致しなかった接続を受け取ります。有効なFINALは1つだけにして、ルール一覧の末尾に配置することをおすすめします。後ろにルールを追加しても、通常どおり照合されません。設定ファイル全体では、ルールの記述は[Rule]セクションに置きます。サーバーアドレス、サブスクリプションURL、プロトコルパラメーターの欄に貼り付けないでください。

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

この例では、指定したドメインを最初に拒否し、明示したドメインとプライベートネットワークを許可した後、CNのIPをGEOIPで処理し、それ以外をPROXYに送ります。example.comはルールの書き方を示すための例示用ドメインであり、サーバーアドレスや利用可能な接続先ではありません。実際に使う前に、自分の対象に合わせてルールを置き換え、必要な通信を妨げないことを確認してください。

  1. ads.example.comにアクセスすると、1行目のドメインルールに一致し、REJECTが適用されます。後続のDIRECTには進みません。
  2. www.example.comにアクセスすると、1行目には一致せず、2行目に一致してDIRECTが適用されます。
  3. 192.168.1.10に直接アクセスすると、最初の2つのドメインルールには一致せず、プライベートネットワークのルールに一致してDIRECTが適用されます。
  4. GEOIPでCNと判定されたほかの接続にはDIRECTが適用されます。それにも一致しない場合は、FINALによってPROXYが適用されます。

FINAL,DIRECTも有効なフォールバック設定です。「明示的に一致したプロキシルールだけをプロキシ経由にし、それ以外は直接接続する」という意味です。FINAL,PROXYとどちらが優れているかは、利用目的によって異なります。ここでのPROXYは通信をプロキシ経由にする指定であり、サーバーを自動作成するものではありません。現在選択中のプロキシが利用可能で、設定が参照するポリシーも定義されている必要があります。

既存設定のルールをすべて上書きしないでください。元のファイルとポリシーグループの定義を残し、コピー上でルールセクションを調整します。既存ルールがカスタムのポリシーグループ名を使っている場合は、その意味を維持し、すべてを機械的にPROXYへ置き換えないでください。

Configで編集し、新しい接続で確認する

以下ではHome、Config、Settingsの画面構成に沿って説明します。編集画面のボタン位置はプラットフォームによって異なる場合がありますが、編集対象は常にConfigで現在有効になっている設定ファイルです。サーバーサブスクリプションの更新とルールファイルの編集は別の操作です。サーバー一覧を更新しても、ルール設定を保存して選択する代わりにはなりません。

  1. ルーティング方法を確認

    Home → Global Routing → Configを開きます。現在選択中のサーバーまたはポリシーグループを控え、テスト中はプロキシの出口を切り替えないでください。

  2. コピーを保存

    Configを開き、現在選択中の設定を見つけます。先にコピーを保存するかバックアップをエクスポートしてから、その設定の編集画面を開いてください。有効になっていない別のファイルを編集していないことも確認します。

  3. ルールを整理

    ルール一覧を確認します。テキストで編集する場合は[Rule]を探してください。具体的な例外を範囲の広いルールより上に移動し、新しいルールはFINALの上に置き、参照先のポリシー定義を残します。

  4. 保存して有効化

    保存後にConfigへ戻り、編集した設定が選択されていることを確認します。Homeに戻って接続し直し、設定の解析エラーがないか確認してください。エラーが発生した場合は、まずコピーに戻します。

  5. 新しいリクエストで確認

    対象ページの既存の接続を閉じてから開き直し、接続ログに記録された宛先、適用ルール、ポリシーを照合します。古い接続を再利用したままのページを更新するだけでは確認になりません。

確認時は、「例外に一致するはずの宛先」「範囲ルールに一致するはずの宛先」「FINALに進むはずの宛先」をそれぞれ選びます。まず実際に一致したルールを確認し、その後で接続できるかを確認してください。PROXYに一致して失敗する場合は、プロキシ接続やリモートサービスに問題がある可能性があります。DIRECTに一致して失敗する場合は、ローカルネットワーク、DNS、接続先サービスの問題が考えられます。ウェブページが開かないという理由だけで、優先順位の誤りと判断しないでください。

よくある質問：ルールを設定したのに、想定した通信先にならない

REJECTを下に書いたのに、なぜ直接接続される？

まず、その上に範囲の広いDIRECTルールがないか確認してください。たとえば、example.comのDOMAIN-SUFFIXはすべてのサブドメインにも先に一致します。拒否したいドメインをその範囲ルールより上に移動し、保存して接続し直してから、実際に一致したルールを確認してください。

FINALの後にルールを追加しても、なぜ反映されない？

処理がFINALに到達すると、その時点でフォールバックが適用され、後続のルールは照合されません。追加したルールをFINALより前に移動し、その前に別のFINALがないか確認してください。末尾の行だけを別のポリシーに変更し、途中にある早すぎるフォールバックを残さないようにします。

Proxyにすると開くのに、Configでは開かない場合はどうする？

Home → Global Routing → Configに戻り、同じ宛先に再度アクセスして、DIRECTまたはREJECTに一致していないか確認します。設定どおりの経路だが要件に合わない場合は、そのルールを変更するか、より具体的な例外を追加してください。すでにPROXYに一致している場合は、ポリシーグループで実際に選択されている出口を確認します。

自分のサブスクリプションを更新した後、ルールを書き直す必要はある？

まず更新対象を確認してください。サーバーサブスクリプションの更新では、通常、接続先の項目が更新されます。リモートルール設定の更新では、ローカルファイルの内容が置き換わることがあります。更新前にローカルの変更を保存し、更新後は現在の設定とカスタムルールが残っているか確認してください。ルールが失われた場合や、参照先のポリシーが変わった場合に限り、該当部分を調整します。

ウェブページの一部が読み込めない場合、ドメイングループ全体を許可するべき？

まず、失敗したリクエストの実際のホスト名を確認してください。ページが複数のドメインを使う場合があり、メインのドキュメントがDIRECTに一致しても、画像やAPIも同じルールに一致するとは限りません。例外は必要だと確認できた宛先だけに追加し、範囲の広いREJECTやほかの範囲ルールより前に置いてください。

まとめ：画面の印象で推測せず、適用ルールの記録から特定する

失敗したリクエストについて、宛先、一致したルール、最終的なポリシーを記録し、毎回、該当ルールの位置か条件だけを変更してください。ルールが正しく適用されているなら、順序の変更は止めて、DNS、選択中のプロキシ、接続先サービスを調べます。

Shadowrocketの入手方法と設定手順

iPhone / iPad版はApp Storeから入手でき、価格は2.99ドルの買い切りです。開発元はShadow Launch Technology Limitedです。システム要件はApp Storeの記載をご確認ください。Mac（Appleシリコン / Intel）、Windows、Android、Linux版は無料です。デバイスに合ったダウンロードガイドを開き、クイックスタートに沿って自分の設定を読み込んでください。

アプリの買い切り購入と接続サービスのプランは別です。当サイトでは接続先やサブスクリプションを提供・販売・推奨していません。ルールの編集は、利用者自身のサービス設定があることを前提としています。

Shadowrocket をダウンロード 使い方を見る