On Demand の3種類のトリガー条件がそれぞれ何にマッチするのか、Settings → On Demand でルールをどう追加するのか、Action を Connect と Disconnect のどちらにするのか、そしてルールが効かないときの確認順序をまとめます。Shadowrocket で手動接続はできるようになり、ネットワークの切り替えに合わせて自動でオン・オフさせたい読者向けの内容です。
On Demand とは:マスタースイッチ1つとルール群
Shadowrocket の On Demand は「必要なときに接続する」仕組みです。条件が満たされるとシステムが自動でトンネルを確立し、条件が消えると自動で切断するため、毎回 Home 画面に戻って接続スイッチを押す必要はありません。入口は Settings → On Demand にあり、画面の構成は2つだけです。上部のマスタースイッチがこの仕組み全体の有効・無効を決め、下のルールリストが「どんな条件で接続し、どんな条件で切断するか」を決めます。
これらのルールは最終的に iOS の VPN 構成に書き込まれ、ネットワーク状態が変化したときにシステムが実行します。そのため Shadowrocket を前面に置いておく必要はなく、プロセスがシステムに回収された後もルールは有効です。一方で注意も必要です。構成がシステムに書き込まれると、アプリを削除しても自動では消えません。「設定 → 一般 → VPN とデバイス管理 → VPN」に項目が残っていることがあるため、そこから手動で削除してください。
条件に一致してから通信が出ていくまでには4つのステップがあります。最初の3つはシステムと Shadowrocket が自動で処理します。4つ目のどの回線を通るか、どのドメインを直接接続するかは、Home 画面の Global Routing と Config 内のルールが決めます。On Demand が管理するのは「接続するかどうか」だけで、「どう振り分けるか」ではありません。切り分けの際はこの2つを混同しないでください。
On Demand は接続のタイミングを決めるだけで、回線を提供するものではありません。サブスクリプション URL とノードは、ご利用のサービス提供元から取得してください。アプリの買い切りと回線プランは別物です。
Wi-Fi トリガー:SSID で接続と切断を切り替える
Wi-Fi トリガーがマッチするのは、現在接続しているネットワーク名、つまり SSID です。追加の手順は決まっています。Settings → On Demand → マスタースイッチをオン → ルールリスト右上の + をタップ → Type で Wi-Fi を選択 → SSID を入力 → Action を選択。3つの項目がそれぞれ1つの役割を担います。Type は何を見るか、Value は何にマッチさせるか、Action は一致したときに何をするかを決めます。
Action に指定できる値は Connect と Disconnect の2つだけです。自宅の Wi-Fi は通常 Disconnect にします。家ではブロードバンドに直接接続するためトンネルは不要です。会社の Wi-Fi、ホテルやカフェの Wi-Fi は Connect にします。手間を減らすなら、「プロキシが必要なネットワーク」にだけ Connect ルールを書き、それ以外のネットワークには何も書かず、手動操作に任せるのがおすすめです。
Wi-Fi トリガーのルール
- 設定場所
- Settings → On Demand → +
- Type
- Wi-Fi
- Value
- SSID。システムの表示と1文字単位で一致させる
- Action
- Connect / Disconnect
- ヒント
- 自宅の Wi-Fi は Disconnect に設定
ルーターの名前を変えたり機器を交換したら、ルール内の SSID も合わせて変更する必要があります。
モバイル通信とドメインのトリガールール
- 設定場所
- Settings → On Demand → +
- Type
- Cellular
- Type
- Domain
- Value
- example.com。ホスト名だけを入力
- Action
- Connect
ドメイントリガーは、システムがそのドメインにアクセスしようとした時点でトンネルを確立します。
SSID のマッチは1文字単位です。大文字と小文字が違う、末尾に空白が1つ多い、全角文字が混ざっているといった場合でも、ルールは静かに一致せず、画面には何のエラーも表示されません。確認方法も単純です。システムの「設定 → Wi-Fi」で現在のネットワーク名を見て、ルール内の Value と突き合わせてください。
結論:まず文字列を照合し、それから仕組みを疑う
Wi-Fi ルールが効かないときは、まず SSID とシステムに表示される文字列を1文字ずつ突き合わせてください。文字列の不一致はこの種のトラブルで最も多い原因で、修正して保存すれば再び有効になります。アプリの再インストールやデバイスの再起動は必要ありません。
モバイル通信とドメインのトリガー:現在の SSID に依存しない2つの条件
Cellular(モバイル通信)トリガーは、現在通信を担っているネットワークの種類を見ます。Wi-Fi に接続しておらず、モバイルデータ通信がネットワークを提供しているときに一致します。典型的な組み合わせは「Wi-Fi ルールが自宅での切断を担当し、Cellular ルールが外出時の接続を担当する」形で、家を出た瞬間にトンネルが自動で確立され、手動で切り替える必要はありません。
Domain(ドメイン)トリガーは、リクエストの宛先を見ます。システムが特定のドメインにアクセスしようとしたときにトンネルを確立します。書き方としてはホスト名だけを入力します。たとえば example.com のように書き、https:// やパス、ポートを付けたり、IP アドレスで書いたりしないでください。「特定のサービスにアクセスするときだけプロキシが必要」という場面に向いており、たとえば社内ネットワークのドメインや、特定のサイトでだけ使う回線などが該当します。
ドメイントリガーには、あらかじめ想定しておきたい挙動があります。ルールはシステムがそのドメインを解決し、接続を開始しようとする時点で有効になりますが、最初のリクエストがすでに送信されてしまっていることがあり、初回だけページを開くのに失敗し、再読み込みすると正常になるという形で現れます。これはタイミングの問題であり、ルールの書き間違いではありません。
3種類のトリガー条件の比較とよくある設定ミス
3種類の条件は同時に存在できます。システムは実際のネットワーク状態とリクエストの宛先に応じてそれぞれ判断します。本当に間違えやすいのはルールそのものではなく、複数のルールが互いに衝突している場合や、ルールと Home 画面の Global Routing のモードが噛み合っていない場合です。
| トリガーの種類 | マッチ対象 | 典型的な使い方とつまずきやすい点 |
|---|---|---|
| Wi-Fi | 現在接続している SSID | 自宅は Disconnect、会社は Connect。SSID は1文字単位でマッチするため、ルーターの名前を変えると古いルールは効かなくなる |
| Cellular | 現在モバイルデータ通信が使われているか | Wi-Fi から離れると自動接続。Wi-Fi とは排他関係にあり、同時刻に通信を担うネットワークは1つだけ |
| Domain | アクセス先のホスト名 | example.com へのアクセス時に自動接続。ホスト名だけを書き、最初のリクエストは直接接続になることがある |
結論:まず1つのルールで仕組みを検証し、残りの条件は後から追加する
自宅の Wi-Fi に Disconnect ルールを1つだけ書き、Wi-Fi とモバイル通信の間を行き来して、ステータスバーの VPN マークが期待どおりに表示・消滅するか確認します。仕組みが動いたら Cellular と Domain のルールを追加します。1つから3つに増やすなら切り分けの手間は倍にはなりませんが、一度に5つ書いてしまうと、問題が出たときに1つずつ二分探索することになります。
On Demand を有効にしたら、自宅の Wi-Fi につないだのに逆にネットにつながらない?
まずルールリストで自宅 Wi-Fi 向けの項目が Connect になっていないか確認してください。自宅では直接接続だけで済むはずで、トンネルが確立された状態で回線自体が使えないと、ページが開けないという形で現れます。Action を Disconnect に変更し、Wi-Fi に接続し直してください。
ルーターを替えたら、以前の Wi-Fi ルールが反応しない?
SSID が変わっています。Settings → On Demand に戻り、そのルールを開いて Value を新しいネットワーク名に変更してください。大文字・小文字と空白も一致させる必要があります。古い値は一致しないので、残しておくより削除して作り直すほうが確実です。
モバイル通信で切断と再接続を繰り返す?
多くの場合、同じ場面に Connect と Disconnect の両方のルールが存在しているか、移動中にネットワークの種類が何度も変わっていることが原因です。まず「1つのネットワークに1つのアクション」になるようルールを整理し、それでも揺れるかどうかを観察してから、Cellular ルールを残すか判断してください。
ドメインルールには完全な URL を書く必要がある?
必要ありません。ホスト名だけを書きます。たとえば example.com のように書き、https://、パス、ポート、クエリパラメータは付けません。パス付きの書き方は一致しません。トリガーの判定は宛先ホスト名を解決する段階で行われるためです。
Shadowrocket をバックグラウンドから終了しても On Demand は有効?
有効です。ルールはシステムの VPN 構成に書き込まれ、ネットワーク状態が変化したときにシステムがトンネルを確立します。ただし、この構成が一度は正常に作成され、システムのダイアログで許可を得ており、システム設定で削除されていないことが前提です。
検証と切り分け:自動接続が期待どおり動かないときの対処
決まった順序で切り分けるほうが、アプリを何度も再インストールするより効果的です。以下の5つのステップでほとんどのケースをカバーでき、どのステップも端末上で結果を直接確認できます。
-
マスタースイッチを確認Settings → On Demand 上部のスイッチがオンになっており、ルールリストに少なくとも1件のルールがある。
-
ルールの3要素を照合Type、Value、Action を1つずつ確認する。SSID はシステムの「設定 → Wi-Fi」に表示される文字列と一致させる。
-
システムの VPN 構成を確認iOS の「設定 → 一般 → VPN とデバイス管理 → VPN」に対応する構成が見える。ステータスバーに VPN マークが出ていれば、トンネルが確立している。
-
振り分けモードを確認Home 画面の Global Routing が Config になっていればルールどおりに振り分けられる。Direct になっていると、トンネルが確立しても期待どおりプロキシ経由にならない。
-
構成を作り直すHome 画面で接続スイッチをオフにしてからオンにし、Shadowrocket に VPN 構成を書き直させる。それでも改善しない場合は、システムの VPN 一覧で古い構成を削除してからもう一度接続する。
5つのステップを試しても改善しない場合は、通常ルールどうしが干渉しています。On Demand のリストを現在本当に必要な2〜3件まで絞り、そこから1つずつ戻していくほうが、一度に10件書くより問題を特定しやすくなります。ルールが表すのは「いつ接続するか」だけです。接続後に通信できるかどうかは、サブスクリプションが更新されているか、回線が利用可能かといった部分を確認してください。