この記事は、利用中のサービスとサブスクリプションがあり、手動で接続できる方を対象にしています。まずOn Demandと通信の振り分けの違いを確認し、指定Wi-Fiとモバイル通信の接続条件を設定します。最後に、ドメインによるトリガーの制限、ルールの順序、自動再接続の原因を確認します。テストでは一度に条件を一つだけ変更し、システムのVPN状態と実際のリクエスト記録をそれぞれ確認してください。
On Demandは接続を制御し、Global Routingとは別の機能
ShadowrocketのOn Demandは、AppleのオンデマンドVPN機能を利用し、ネットワーク条件がルールに一致すると接続を要求したり、ルールに従って切断したりします。制御するのは「いつトンネルを確立するか」であり、「特定のWebサイトにどの経路を使うか」ではありません。アプリのSettings → On Demandで条件を設定したら、現在のシステムVPN構成でオンデマンド接続が許可されていることも確認してください。
Global Routingは、接続確立後の通信経路を制御します。Proxy、Direct、Config、Sceneはこの段階のモードです。Configでは現在の設定にあるルールに従って通信を振り分け、Sceneでは選択中のシーン設定に従って動作します。Global RoutingをDirectにしても、システムVPNやOn Demandが無効になるわけではありません。
そのため、「VPNの状態は表示されているが、通信はDirectになる」という状況が、必ずしも障害とは限りません。前者はトンネルの状態、後者はリクエストに適用された送信ポリシーを示します。トラブルシューティングでは、この2つを別々に記録してください。ステータスバーのアイコンだけを見て、すべての通信がProxy経由だと判断することはできません。
有効化の前に手動接続とシステムの許可を確認
On Demandで、無効なサブスクリプションや誤った接続パラメーター、利用できないネットワークを修復することはできません。まずHomeで利用可能な既存の接続を選び、手動で接続スイッチをオンにして、通常アクセスできるページを開いてください。手動接続が機能することを確認してから、自動トリガーのテスト結果を判断します。
- 既存の設定を確認。Homeで現在選択されている接続を確認します。ルールに基づいて通信を振り分ける場合は、Configで想定した設定が選択されていることも確認し、テスト中に設定が切り替わらないようにしてください。
- システムの許可を完了。VPN構成を初めて追加するときは、システムの案内に従って許可します。許可しなかった場合やシステム構成を削除した場合、アプリ内の条件だけではトンネルを確立できません。
- オンデマンド設定を開く。ShadowrocketのSettings → On Demandを開き、現在の有効状態と保存済みの条件を確認します。具体的な項目や選択できるアクションは、現在の画面に表示される内容に従ってください。
- システム構成を確認。iPhoneまたはiPadのシステム「設定」で「一般」→「VPNとデバイス管理」→「VPN」の順に開き、該当する構成の情報画面でConnect On Demandを確認します。システムの言語設定によっては「オンデマンド接続」と表示されます。
- 基準状態を記録。現在のWi-Fi名、モバイルデータ通信の有効状態、接続状態、Global Routingのモードを記録します。以降のテストでは、毎回一つの項目だけを変更してください。
指定Wi-Fiの設定：例外を先に、一般条件を後に
指定Wi-Fi名による条件では、照合対象はSSIDです。SSIDはルーターの管理アドレスやデバイスの名前とは異なります。まずシステムのWi-Fi画面で接続中のネットワーク名を確認し、そのまま入力してください。空白、記号、大文字・小文字にも注意し、システムが部分一致すると決めつけないでください。
たとえば、必要なリソースに直接アクセスできると確認済みの自宅ネットワークではトンネルを切断し、それ以外のWi-Fiでは接続を要求したい場合があります。これは「指定ネットワークを例外にし、一般的なネットワーク条件を設定する」方法であり、すべての家庭用ネットワークで切断すべきという意味ではありません。以下のSSIDは例です。設定時は実際のネットワーク名を入力してください。
指定Wi-Fiの例外
- 設定場所
- Settings → On Demand
- ネットワーク条件
- Wi-Fi
- SSIDの例
- Home-WiFi-Example
- 実行するアクション
- Disconnect
- 配置順
- 一般的なWi-Fi条件より前
この例外は、そのネットワークでトンネルが不要だと確認できている場合にのみ使用してください。SSIDだけではネットワークの信頼性を判断できません。
その他のWi-Fi条件
- 設定場所
- Settings → On Demand
- ネットワーク条件
- Wi-Fi
- 対象範囲
- 前段の例外に該当しないWi-Fi
- 実行するアクション
- Connect
- 配置順
- 指定SSIDの例外より後
画面に別の例外リストがある場合は、そのリストで対象範囲を指定してください。意味が明記されていない空欄をワイルドカードとして扱わないでください。
システムはオンデマンドルールを順番に評価するため、先に一致した一般条件が後の個別条件に影響する場合があります。現在の画面でリストの順序を変更できる場合は、対象範囲の狭い例外を広い条件より前に置いてください。分類からルールが作成される画面では、例外の選択肢を使って設定します。Configのテキストルールを貼り付けないでください。
- 同じSSID：別の場所でも同じネットワーク名が使われている場合があり、名前だけでは同じルーターかどうかを確認できません。
- デュアルバンドWi-Fi：SSIDが同じ2つの周波数帯は、通常SSIDだけでは区別できません。SSIDが異なる場合は、それぞれ確認してください。
- 認証が必要なネットワーク：Web認証が必要なWi-Fiでは、先に認証を完了してから接続をテストしてください。ネットワークに未接続の状態を、条件が機能していないと誤認するのを防げます。
- ネットワーク名の取得：アプリが現在のSSIDを認識できない場合は、システムの案内に従って関連する権限や制限を確認してください。問題を隠すために自動接続の範囲を広げないでください。
モバイル通信：Wi-Fiを切るだけで済ませず、切り替えを個別にテスト
モバイル通信の条件が対象とするのは実際に使用中のネットワークインターフェースであり、SIMカードが挿入されているかどうかではありません。モバイルデータ通信に対応するiPhoneまたはiPadで通信可能なことを確認し、条件にConnectまたはDisconnectのアクションを設定してください。Wi-Fiのみ対応するiPadでは、モバイル通信経由のテストはできません。
- まずWi-Fiの基準状態を確認。指定したWi-Fiに接続し、ネットワークが安定するまで待ってから、例外条件で想定したVPN状態になることを確認してください。
- モバイル通信に切り替え。システム設定でWi-Fiをオフにし、ネットワークに接続できない状態ではなく、モバイルデータ通信で通常のページにアクセスできることを確認してください。
- 実際のリクエストを発生させる。ページを開くかリクエストを再送信し、モバイル通信の条件に従ってVPNが接続または切断されるか確認してください。ステータスバーのアイコンが変わるのを待つだけでは不十分です。
- 元のWi-Fiに戻す。同じSSIDに再接続し、ネットワークの切り替えが完了するまで待ってからリクエストを送信します。例外条件に対応する状態に戻ることを確認してください。
- 2つの結果を記録。VPNの状態とページへのアクセス結果を別々に記録してください。トンネルが確立しているのにページを開けない場合は、ネットワークのトリガー条件ではなく、接続パラメーターや通信振り分けルールを確認します。
ネットワークの切り替え中は、既存の長時間接続が切断されて再試行される場合があります。また、DNSキャッシュが残ることもあります。一度だけ短時間失敗しても、ルールの競合とは限りません。ネットワークが安定してから新しいリクエストを送信し、同じテストを繰り返してください。On Demandを設定しても、すべてのアプリが常に通信するわけではありません。アイドル時に一定秒数以内に必ず接続するといった保証はできません。
ドメインによるトリガー：オンデマンド評価とDOMAIN-SUFFIXを区別
「特定のドメインにアクセスしたら自動接続する」と「特定のドメインへの通信をProxy経由にする」は別の要件です。後者はConfigのDOMAIN-SUFFIXなどのルールで処理できますが、対象のリクエストがすでにトンネルに入っていることが前提です。[Rule]にドメインルールを追加しただけでは、システムのドメイン別オンデマンド接続条件は作成されません。
Appleのオンデマンド機能では、ドメインに関する動作にEvaluateConnectionやConnectIfNeededが関わる場合があります。システムは条件に合うドメインの名前解決や接続評価時にVPNが必要かを判断するもので、ブラウザーのアドレスバーを監視してアクセスのたびに無条件で接続するわけではありません。設定できるかどうか、入力方法は、Shadowrocketの現在のオプションによって異なります。システムが対応するすべての項目が、アプリ内に設定項目として用意されているとは限りません。
| 設定場所・仕組み | 解決する問題 | ここからは判断できないこと |
|---|---|---|
| Settings → On Demand | システムがトンネルの確立または切断を要求するタイミングを定義 | ドメインへの通信が必ずProxy経由になるとは限らない |
| EvaluateConnection / ConnectIfNeeded | ドメインと接続評価の条件に基づき、接続が必要か判断 | 同じドメインを開くたびに、必ず接続が再確立されるわけではない |
DOMAIN-SUFFIX,example.com,PROXY | Configの振り分けで、ドメインに一致した通信に対応するポリシーを適用 | 未確立のトンネルを単独で起動することはできない |
ドメインのテストは特にキャッシュの影響を受けやすい点に注意してください。既存のDNS結果、アプリ独自の暗号化DNS、IPアドレスへの直接アクセスなどによって、想定したシステムのドメイン名前解決経路を通らない場合があります。現在のネットワークでドメインを正常に名前解決できても、「接続が必要」と評価されるとは限りません。そのため、「Webページは開けるのに自動接続されない」という状況だけで、設定の失敗とは判断できません。
- 現在のOn Demand画面にドメイン関連の条件があることを確認してから、項目の説明に従って入力してください。完全なURLをドメインとして入力しないようにします。
- ドメイン欄には通常、
https://、ページのパス、:443は入力しません。サフィックスの一致範囲は項目の説明に従って確認し、ワイルドカードの書式を推測しないでください。 - ネットワークに応じて安定してトンネルを確立し、その後Webサイトごとに通信を振り分けたい場合は、Wi-Fi／モバイル通信の条件とConfigを組み合わせてください。動作を検証できていないドメインによるトリガーには頼らないでください。
ルールの競合：トリガーの順序と通信振り分けの順序を個別に確認
2つのルール層にはそれぞれ順序があり、まとめて比較することはできません。On Demandが接続アクションを決定し、接続確立後にGlobal RoutingがConfigのルールを使うかどうかを決定します。ProxyまたはDirectが選択されている場合、その状態での動作を確認するために[Rule]を編集するのは、通常適切な方法ではありません。
以下は通信振り分けの構文例であり、On Demandの設定ではありません。また、接続可能なサービスも含まれていません。PROXYは、現在の設定内で利用できるポリシーに対応している必要があります。実際の設定にルールを適用する前に、元の設定をバックアップし、ポリシー名を確認してください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- 1行目：
DOMAIN-SUFFIXは例示したドメインのサフィックスに一致します。一致すると、その行のポリシーが適用され、後続のルールは評価されません。 - 2行目：
IP-CIDRは例示したプライベートアドレス範囲に一致します。no-resolveは、このIPルールのために追加のドメイン名前解決を行わないことを示し、すべてのDNS動作を無効にする意味ではありません。 - 3行目：
GEOIPはIP地理情報データベースの結果に基づいて一致を判定します。Webページの言語やドメイン名の文字列から地域を判定するものではありません。 - 最終行：
FINALはそれまでのルールに一致しなかった通信を処理するため、フォールバックとして末尾に配置します。システムのオンデマンド接続アクションを代替するものではありません。
実際の確認は、現在のネットワーク条件、オンデマンドルールの対象範囲、システムVPNの確立状態、Global Routingとリクエストに一致したルールの順で進めます。最後の段階に問題がある場合に限り、通信振り分けルールの順序を変更してください。サブスクリプションの更新で利用可能な接続が変わった場合も、On Demandと設定ファイルを同時に変更せず、まず手動接続を再確認してください。
よくある症状：自動再接続、例外が効かない、テストを止める方法
Homeで接続を切ったのに、なぜ再接続される？
まずSettings → On Demandでオンデマンドトリガーを無効にし、システムVPNの情報画面でConnect On Demandの状態を確認してください。条件が有効なままだと、新しいネットワークリクエストで再接続される場合があります。Homeのスイッチをオフにするだけでは、オンデマンド条件は削除されません。
自宅のWi-FiをDisconnectに設定したのに、なぜ接続される？
まず実際のSSIDが完全に一致しているかを確認し、一般的なWi-FiのConnect条件が例外より前に配置されていないか確認してください。想定したネットワークに接続されていることを確かめたら、いったん切断して再接続し、新しいリクエストを送信してから、該当するシステムVPN構成の状態を確認します。
モバイル通信でVPNの状態は表示されるのに、ページが開けない場合は？
まずOn Demandを無効にし、同じモバイル通信ネットワークで手動接続をテストしてください。それでも失敗する場合は、Homeで選択中の接続、その接続が現在も有効か、Global Routingの設定を確認します。手動接続が正常なら、モバイル通信の条件を再度有効にして、トリガーの動作だけを個別に確認してください。
ドメインルールを追加したのに、アクセスしても自動接続されないのはなぜ？
設定を変更した場所を確認してください。ConfigのDOMAIN-SUFFIXだけを変更した場合、それは通信振り分けルールです。Settings → On Demandに戻り、ドメインによるトリガーの選択肢があるか確認してください。該当する選択肢がない場合は、通信振り分けの構文でシステムのトリガー条件を代用しようとしないでください。
完全に手動接続へ戻すには？
まずアプリ内のOn Demandを無効にし、該当するシステム構成でConnect On Demandがオフになっていることを確認してから、Homeで接続を切断します。Wi-Fiに再接続してリクエストを送信し、以前の条件で再接続されないことを確認してください。必要になったときに、手動で接続をオンにします。
テストが終わったら、用途を説明できる条件だけを残してください。指定SSIDの例外、その他のWi-Fi、モバイル通信をそれぞれ個別に確認します。ドメイン関連の条件で想定した動作を安定して再現できない場合は、いったん無効にして、検証済みのネットワーク条件だけを残してください。これにより、「接続がトリガーされたか」と「接続後に通信できるか」を切り分けられます。