Shadowrocketに自分のサブスクリプションを追加し、手動接続が正常に動作している方を対象に、設定手順を解説します。まずOn Demandによる接続のトリガーと、Configによる通信の振り分けを区別し、指定Wi-Fi、Cellular、ドメインの条件を順に設定します。確認時は一度に変更する条件を一つに絞り、ルールの一致状況、トンネルの状態、リクエストのポリシーをそれぞれ確認しましょう。自動接続の失敗とルール振り分けの誤りを混同せずに原因を切り分けられます。
On DemandとGlobal Routingの違い
ShadowrocketのOn Demandは、AppleのVPNオンデマンド機能を利用し、ネットワークの変化や条件に合うネットワークリクエストを検知して、接続を確立するか判断します。これは「いつ接続するか」を決める機能であり、「各リクエストをどのポリシーで処理するか」を決めるものではありません。接続確立後のリクエストには、HomeのGlobal Routingで選択中のモードと、適用される設定が引き続き反映されます。
確認する項目は3つに分けられます。Homeで選択中の接続とGlobal Routing、Configで有効な設定ファイル、Settings → On Demandでトリガー条件を確認します。サーバーアドレス、ポート、認証情報の誤りをOn Demandの変更で直そうとしないでください。これらの設定は、まず手動接続で検証する必要があります。
Config
おすすめ接続後のリクエストは、現在の設定ファイルにあるルールに従って処理されます。DOMAIN-SUFFIX、IP-CIDR、GEOIP、FINALを確認するときは、想定したConfigが有効になっているか確かめてください。
おすすめの用途：明確な振り分けルールを維持しながら、自動接続を使いたい場合。
Proxy
プロキシモードで、アプリが処理するリクエストを扱います。一時的にConfigの振り分けによる影響を除いて確認できますが、On Demandが有効になるわけではなく、システム上のすべての通信が処理されるとも限りません。
おすすめの用途：接続自体と設定ルールがそれぞれ正常か、短時間で確認したい場合。
Direct
Directモードで接続します。On Demandが条件を検知してトンネルを確立しても、リクエストが自動的にプロキシ経由になるわけではありません。接続中の表示だけでは、リクエストの経路を判断できません。
おすすめの用途：Directでの動作確認や、「接続済みなのにポリシーが想定と違う」場合の切り分け。
要点：ルーティングモードを固定する
テストを始める前にGlobal RoutingをConfigに設定し、現在の設定名を記録します。一連のトリガーテストが終わるまで、モード、設定ファイル、接続先を同時に切り替えないでください。
有効にする前に手動接続を確認
以下の手順は、ご自身でサービスを契約し、サブスクリプションをお持ちであることを前提とします。本記事では接続先やサブスクリプションの提供・販売・推奨は行いません。サブスクリプションの更新とOn Demandは別の操作です。前者は既存の接続情報を更新し、後者はシステムがいつ接続を使うかを制御します。自動接続を設定しても、期限切れのサブスクリプション情報は修復されません。
-
既存の設定を確認
Homeを開き、自分のサブスクリプションが追加され、必要に応じて更新済みであることを確認します。利用可能と分かっている接続を選び、アドレス、ポート、プロトコル、認証情報を確認してください。この時点では複数の項目を同時に変更しないでください。
-
手動で接続
Homeで接続を手動でオンにします。初回は、システムの案内に従ってVPN構成の追加を許可してください。手動接続に失敗する場合は、接続設定または現在のネットワークの問題を先に解決してから、自動接続の条件を設定します。
-
振り分けを確認
Home → Global Routingでモードを確認し、Configで有効なファイルを確認します。適用されるポリシーが明確なリクエストを使って検証し、リクエストの時刻と一致したルールを記録してください。
-
設定を開く
Settings → On Demandを開き、現在の条件と優先順位を確認します。自動化ルールがすでにある場合は、設定値を記録してください。以前のルールが先に一致しないよう、今回検証する条件だけを残します。
-
条件を一つずつ有効にする
Settings → On Demandでネットワーク条件を一つ設定し、On Demandを有効にします。Homeに戻って状態を確認した後、実際にネットワークを切り替えてください。ドメイン条件を追加する前に、Wi-FiとCellularの基本的なトリガーを確認します。
ここでは、Appleのオンデマンドルールで使われるアクションの意味をConnect、Disconnect、EvaluateConnection、Ignoreで説明します。Shadowrocketの画面にある各ボタン名をそのまま再現したものではありません。編集可能な項目やアクションの組み合わせは、現在の画面に従ってください。画面にない条件をConfigのルールで代用しないでください。
Wi-Fi SSID：個別のネットワーク条件を一般条件より先に設定
SSIDはWi-Fiのネットワーク名であり、ルーターのアドレスやアクセスポイントのハードウェアアドレスではありません。特定のネットワークを条件にする場合は、デバイスが現在接続しているWi-Fiの情報を確認し、完全な名前（例：Home-WiFi）を指定してください。大文字・小文字、空白、記号に注意し、Home-*がワイルドカードとして一致すると決めつけないでください。
Settings → On DemandのWi-Fi条件で、対象のSSIDを入力または選択し、そのネットワークでの接続動作を設定します。たとえば、利用要件を満たすことを確認済みの自宅Wi-Fiでは切断し、それ以外のWi-Fiでは接続したい場合、個別SSIDの切断条件を一般的なWi-Fi接続条件より先に置きます。SSIDは照合に使う情報であり、ネットワークの身元や信頼性を証明するものではありません。
| 順序 | 一致条件 | アクションの意味 | 確認方法 |
|---|---|---|---|
| 1 | Wi-Fi、SSIDがHome-WiFi | Disconnect | このSSIDに接続し、設定どおりにトンネルが切断されるか確認します。 |
| 2 | その他のWi-Fi | Connect | 名前が分かっている別のWi-Fiに切り替え、接続がトリガーされるか確認します。 |
| 3 | その他のネットワーク | 別途条件を設定 | Cellularは個別に設定する必要があります。Wi-Fi条件から動作を推測することはできません。 |
この表はルールの意図を示すもので、直接読み込める設定テキストではありません。システムやアプリからネットワーク情報へのアクセス許可を求められた場合は、実際の案内を確認してください。SSIDを取得できないと、指定SSIDの条件が想定どおりに一致しない場合があります。ログイン認証が必要な公共Wi-Fiでは、先に認証を済ませてからOn Demandをテストしてください。インターネットに接続できる状態になる前の問題を、接続設定の誤りと誤認しないようにします。
Cellular：Wi-Fiをオフにして個別にテスト
Cellular条件は、デバイスが実際に使用しているモバイルデータ通信を対象とします。設定前に、デバイスがモバイル通信に対応し、モバイルデータ通信が有効になっていることを確認してください。Wi-Fiのみ対応のiPadにこの条件を追加しても、モバイル通信は利用できません。ネットワーク名が似ていても接続方式が同じとは限りません。スマートフォンのテザリングに接続した別のデバイスは、通常、自身のWi-Fiインターフェイスを使用しています。
Settings → On DemandでCellularのアクションを設定し、Wi-Fiをオフにして、デバイスが実際にモバイルデータ通信へ切り替わったことを確認します。SSIDの圏外に移動するだけでは、すぐに別の保存済みWi-Fiへ接続することがあり、明確なテスト条件にならない場合があります。
- モバイル通信で自動接続する場合：Cellular条件を接続するアクションに設定し、それより前にある一般条件が先に一致しないか確認します。
- モバイル通信で切断状態を保つ場合：対応する切断アクションを設定し、リスト末尾の一般的な接続条件が意図した動作を上書きしないか確認します。
- デュアルSIMのデバイスを使う場合：まず、モバイルデータ通信に使用している回線を記録します。データ回線を切り替えた後に再確認し、通信事業者のネットワーク変更とルールの優先順位の問題を混同しないでください。
- データ使用量に注意：On Demandは接続のトリガーを制御する機能であり、データ通信量を制限するものではありません。サブスクリプションの更新、アプリの同期、その他のリクエストでもモバイルデータ通信が使われる場合があります。
ドメインによるトリガー：DOMAIN-SUFFIXを設定に貼り付けない
ドメインに関連するオンデマンド接続は、システムの接続評価機能に属します。AppleのEvaluateConnectionでは、ドメインの照合に加えて、接続に必要なDNSや到達可能性などの条件を使い、接続を確立するか判断できます。各ウェブページのURLを常時確認するフィルターではなく、「あるドメインにアクセスすれば必ず直ちに接続する」という機能でもありません。現在の画面に該当するドメイン評価項目がある場合に限り、その項目の意味に沿って設定してください。
Settings → On Demandを開き、ドメイン評価の項目が利用できるか確認します。編集できる場合は、項目の指示に従ってドメインを入力します（例：example.com）。https://example.com/pathのような完全なURLや、DOMAIN-SUFFIX,example.com,PROXYをドメイン値として貼り付けないでください。サブドメインも対象になるかは、該当項目の照合仕様を確認します。Configのルール構文をそのまま適用しないでください。
| 項目 | On Demandのドメイン評価 | Configのドメインルール |
|---|---|---|
| 主な目的 | 接続を確立する必要があるかを評価する。 | 処理対象のリクエストに適用するポリシーを決める。 |
| 設定場所 | Settings → On Demandに実際に表示されるドメイン項目。 | Configの有効なファイルにあるルール部分。 |
| 設定内容 | 項目の指示に従って、ドメインと評価条件を入力する。 | DOMAIN-SUFFIX,example.com,PROXY |
| 主な影響要因 | DNSキャッシュ、既存の接続、アプリの名前解決方法、先行するオンデマンドルール。 | 先行ルールの一致、ポリシー名の誤り、有効なファイルの不一致。 |
上表のConfigルールを使うには、現在の設定に利用可能なPROXYポリシーが必要です。ここで説明しているのは通信振り分けの構文であり、On Demandの条件を作成するものではありません。ドメインによるトリガーをテストする際は、先にネットワークレベルのConnect条件が無条件でトンネルを確立していないことを確認してください。そうした条件があると、確認できるのはネットワーク条件の動作だけで、ドメイン評価が機能したことにはなりません。
要点：ドメインのテストでは条件を切り分ける
ドメイン評価を検証する際は、先に一致する範囲の広いネットワーク接続条件を一時的に無効にし、関連アプリの既存セッションを終了してからリクエストを再実行します。画面にドメイン評価の項目がない場合は、ネットワークトリガーを使い、Configのルールでその機能を代用しないでください。
複数ルール：接続条件の一致後にリクエストのポリシーを処理
オンデマンドルールは順番に評価され、最初に一致したルールが優先されます。通常は特定のSSIDなどの例外を先に置き、適用範囲の広いインターフェイス条件やフォールバック条件を後に置きます。一つのルールに複数の条件を設定する場合は、「一つの項目に複数の選択値を指定する」ケースと、「インターフェイスとSSIDの両方を条件にする」ケースを区別してください。すべての条件がどれか一つ一致すればよい、という意味とは限りません。
Connectは条件に一致したときに接続を確立し、Disconnectは条件に一致したときに接続を維持しません。Ignoreは既存の接続状態を変更しないため、Disconnectの代わりには使えません。EvaluateConnectionでは接続条件をさらに評価する必要があり、無条件のConnectとは異なります。実際の設定では画面でサポートされているアクションのみを使い、順序も記録してください。
- 最初に期待する動作を書く：たとえば「Home-WiFiでは切断、その他のWi-Fiでは接続、Cellularでは接続」のように、各ネットワーク状態での動作を一つずつ明確にします。
- 個別条件から一般条件の順にする：指定SSIDを一般的なWi-Fi条件より先に置きます。一般条件で例外が上書きされないようにしてください。
- ドメイン評価の順序を確認：ネットワークレベルのConnectが先に一致すると、後続のドメイン評価が今回の接続を決める要因にならない場合があります。
- 最後にConfigを確認：接続確立後に、DOMAIN-SUFFIX、IP-CIDR、GEOIPなどのリクエストルールと末尾のFINALを確認します。これは別の照合レイヤーです。
「オンデマンドルールのフォールバック動作」とFINALを混同しないでください。FINALはConfig内のリクエストルールにおける最終ポリシーで、リクエストルール一覧の末尾に置きます。Wi-Fiを選択する機能でも、システムのOn Demandを有効にする機能でもありません。
検証とトラブルシューティング：一度に変更する変数は一つ
テスト記録には、現在のネットワーク種別、SSID、On Demand条件の順序、Homeの接続状態、Global Routingのモード、リクエストの一致結果を含めてください。接続にかかる時間を固定値として想定する必要はありません。ネットワークの切り替え、システムのスケジュール、サーバーの応答によって観察結果は変わるため、特定の秒数を必ず成功する基準にしないでください。
手動で切断しても再接続するのはなぜ？
Settings → On Demandを開き、On Demandを一時的にオフにしてから、Homeで手動切断します。現在のネットワークがConnect条件を満たし続けると、システムが再評価した際に接続が再確立されることがあります。長期間停止する場合は、条件を変更するか機能をオフにしてください。
自宅に戻っても自動で切断されない
現在接続中のSSIDが設定と完全に一致しているか確認し、指定SSIDの条件が一般的なWi-Fi条件より先にあるか確認します。画面にネットワーク情報へのアクセス許可が表示される場合は、許可の問題を解決してからネットワークを切り替えて再検証してください。
モバイルデータ通信ではトリガーされるのに、ウェブページが開かない
まずOn Demandをオフにし、同じモバイルネットワークで手動接続してテストします。手動接続も失敗する場合は、既存の接続設定とネットワークへの到達性を確認してください。手動接続が正常なら、条件の順序、Home → Global Routing、Configで実際に有効なルールを確認します。
対象のドメインにアクセスしてもトリガーされないのはなぜ？
まず、Configルールを追加しただけではなく、画面でドメイン接続評価を設定していることを確認します。アプリの既存セッションを終了して再試行し、DNSキャッシュとアプリ独自の名前解決方法を確認してください。名前解決の失敗などを条件に機能する設定の場合、正常に名前解決できると接続しないのは想定どおりの可能性があります。
サブスクリプションの更新後、設定し直す必要はある？
更新後にHomeへ戻り、選択項目が引き続き存在することを確認して、手動接続を一度テストします。サブスクリプションの内容が変わると接続先に影響する場合がありますが、On Demandの条件をすべて作り直す必要があるとは限りません。手動接続が正常であることを確認してから、On Demandのテストを再開してください。
一連の動作確認では、「指定Wi-Fi → その他のWi-Fi → Cellular → 指定Wi-Fi」と切り替え、各状態で期待するアクションと実際の状態を記録します。今回の設定を取り消す場合は、Settings → On Demandを先にオフにしてから、元の条件と順序に戻してください。一つの条件だけ削除して、適用範囲の広い自動接続ルールが残らないようにします。