ShadowrocketのOn Demand設定ガイド｜Wi-Fi・モバイル通信・ドメインで自動接続

1. 自動接続とルールによる振り分けを区別する

ShadowrocketのOn Demandは、システムがVPN接続を開始するタイミングを管理します。接続後にアクセス先をどう処理するかは、Global Routingと現在の設定によって決まります。ステータスバーにVPNアイコンが表示されても、すべての通信がプロキシ経由とは限りません。また、特定のサイトがDIRECTに一致しても、VPNが切断されるわけではありません。

入手方法は2種類です。iPhone / iPad版はApp Storeで2.99米ドルの買い切り、開発元はShadow Launch Technology Limitedです。システム要件はApp Storeの掲載内容をご確認ください。Mac（Appleシリコン / Intel）、Windows、Android、Linux版は無料です。各デバイスの入手先は全プラットフォームのダウンロードページをご覧ください。この記事では、利用者がすでに自身のサービスとサブスクリプションを用意していることを前提としています。アプリに接続サービスは含まれず、本サイトではノードやサブスクリプションの提供・販売・推奨は行っていません。

サイトごとに通信を振り分ける場合は、HomeでGlobal Routingを確認し、Configを選択して、想定した設定が実際に有効になっていることを確かめます。Proxy、Direct、Config、Sceneはそれぞれ異なるルーティングモードであり、On Demandの接続動作ではありません。特にGlobal RoutingのDirectを、システムのオンデマンドルールにおけるDisconnectと混同しないでください。前者はリクエストの転送方法、後者はトンネルの接続状態を制御します。

2. 有効化する前に手動接続を確認する

自動化しても、誤った接続情報は修正されません。まずHomeで使用する接続設定を選び、手動で接続して、正常にアクセスできることが分かっている宛先を開きます。ここで失敗する場合は、サーバーアドレス、ポート、認証情報、プロトコル設定を確認してからOn Demandを有効にしてください。サーバーの変更、DNSの修正、振り分けルールの調整を同時に行うと、どの変更が結果に影響したのか判断できなくなります。

1. Homeで現在選択されている接続設定を確認します。サブスクリプションから読み込んだ設定は、先に更新して、設定一覧が空でないことを確かめてください。
2. プロトコルが既存のサーバー設定と一致しているか確認します。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは、認証情報や通信パラメーターを互いに置き換えることはできません。
3. 手動で接続し、システムの案内に従ってVPN構成の追加を許可します。接続スイッチだけで判断せず、ブラウザーで実際にアクセスできるか確認してください。
4. Settings → On Demandを開き、現在のルールと並び順を記録してから、ネットワーク条件を追加します。
5. 条件は一度に1つだけ変更して保存します。Homeに戻って接続状態を確かめ、実際にネットワークを切り替えてテストしてください。

3. 特定のWi-Fi：例外を先に設定し、他のネットワークを指定する

「自宅のWi-Fiではトンネルを接続せず、その他のWi-Fiでは接続する」例では、まずシステムのSettings → Wi-Fiで現在のネットワーク名を確認します。SSIDはWi-Fiのネットワーク名であり、ルーターのブランド名、ゲートウェイアドレス、デバイス名ではありません。例のSSID Home-WiFiは、デバイスに実際に表示される名前に置き換えてください。空白や句読点など、名前に含まれる文字も一つずつ確認します。

ShadowrocketのSettings → On Demandを開き、編集可能なWi-Fi条件で対象のSSIDを指定して、対応するアクションをDisconnectにします。次に、その他のWi-Fiに対してConnectを設定します。編集できる項目はシステムやプラットフォームによって異なる場合があります。以下のカードは条件とアクションの対応を示すもので、貼り付けて読み込める設定ファイルではありません。現在の画面で指定できない条件を、Configのドメインルールで代用しないでください。

SSIDで分かるのはネットワーク名だけで、ネットワークの安全性は判断できません。家庭用ルーターの名前を変更した場合、2.4GHz帯と5GHz帯に別々の名前を付けた場合、ゲスト用ネットワークに異なる名前を付けた場合は、マッチする範囲を再確認してください。公共Wi-Fiで認証ページを開く必要がある場合は、先にログインを済ませます。ネットワーク自体がインターネットに接続できていなければ、Connectを実行してもサーバーへ自動的に到達できるようにはなりません。

4. モバイル通信：個別の条件で切り替えを確認する

Wi-Fi圏外で自動接続したい場合は、モバイル通信にConnectを設定できます。判定対象はデバイスが現在使用しているネットワークインターフェースであり、SIMカードに表示される名前や通信事業者ではありません。iPadでこの条件を直接テストできるのは、モバイル通信機能を備え、有効にしている場合に限られます。スマートフォンのテザリングに接続しているデバイスは通常Wi-Fi接続として扱われるため、接続先のSSIDで判定してください。

1. Settings → On Demandでモバイル通信の条件を確認し、想定するアクションをConnectに設定して保存します。
2. 特定のWi-Fiに対するDisconnectの例外は残し、すべての状況に適用される無条件のConnectで上書きしないでください。
3. システムのSettings → Wi-FiでWi-Fiをオフにし、コントロールセンターで一時的に現在のネットワークを切断しただけではなく、デバイスが実際にモバイルデータ通信を使用していることを確認します。
4. 新しいウェブページを開き、Homeの接続状態とアクセス結果を確認します。システムの判定はネットワークの利用可否や新しいリクエストに左右される場合があるため、切り替えた瞬間のアイコンだけで判断しないでください。
5. 指定したHome-WiFiに再接続してサイトへアクセスし、Disconnectの例外どおりに接続状態が変わるか確認します。

5. ドメイン条件：特定のページを開いたときの全体的な接続切り替えとは異なる

システムのVPNオンデマンド機能では、EvaluateConnectionなどのアクションを使い、ドメインの名前解決や到達可能性に基づいて接続の要否を判断できます。ネットワークの種類を条件にConnectする設定とは異なり、ブラウザーのアドレスバーを読み取る仕組みでもありません。現在の編集画面にドメイン評価条件が実際に用意されている場合に限り、対応する動作を設定できます。すべてのプラットフォームで同じドメイン編集機能が使えるとは限りません。

ドメインには example.comのようなホスト名を指定します。https://example.com/pathやページタイトルは入力しません。どの範囲に一致するかは該当フィールドの仕様によって決まるため、DOMAIN-SUFFIXの意味をそのまま当てはめることはできません。「名前解決に失敗した場合に接続」「プローブに失敗した場合に接続」などの条件がある場合は、実際に選べる項目に従って設定し、使用するDNSやプローブ先が想定するネットワークで利用可能か確認してください。

• ドメイン評価は、システムが対象のリクエストを処理する過程で行われます。DNSキャッシュやアプリによる既存接続の再利用により、ページを再度開いても初回の動作を再現できないことがあります。
• ウェブページでは画像、スクリプトなど、別のドメインからもコンテンツを読み込む場合があります。メインページのドメイン条件が、すべての第三者リクエストに自動で適用されるわけではありません。
• ブラウザーのタブを閉じても、トンネル切断の確実な合図にはなりません。アクセス終了後にすぐDisconnectされるとは限りません。
• アプリが独自にDNSを処理する場合、暗号化された名前解決を使う場合、またはIPアドレスへ直接アクセスする場合は、トリガーの経路が異なることがあります。テストではシステムの名前解決とアプリの動作を分けて記録してください。

目的が「指定したサイトだけをプロキシ経由にし、それ以外は直接接続する」ことであれば、通常は接続を維持したままConfigで通信を振り分けます。ドメイン条件でトンネルを頻繁に切り替える方法に頼る必要はありません。以下は振り分け構文の例であり、On Demandの設定ではありません。PROXYは現在の設定で実際に利用できるポリシーを指定してください。

DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

この2行では、example.comとそのサブドメインにPROXYを適用し、その他のリクエストをDIRECTにします。対象サイトを離れたときにシステムへVPNを切断させるものではなく、サイトが必要とする他のドメインを自動で追加するものでもありません。テストではリクエスト記録を確認し、実際の宛先と適用されたポリシーを照合してから、ルールの追加を検討してください。

6. 条件の競合：オンデマンド条件とConfigを別々に確認する

オンデマンド接続とリクエストの振り分けは別々の判定です。それぞれ個別に確認してください。システムのオンデマンドルールは順番に評価され、最初に一致した適用条件のアクションが実行されます。接続後のConfigルールも順序が重要ですが、両者でいう「一致」は同じ意味ではありません。Configの先頭にDOMAIN-SUFFIXを移動しても、システムのオンデマンド一覧でWi-Fi例外の順序が誤っている問題は解決しません。

FINALをOn Demandの補完アクションとして使わないでください。FINALが処理するのは、先行する振り分けルールに一致しなかったリクエストです。「その他のWi-Fiで自動接続する」という意味ではありません。同様に、GEOIPとIP-CIDRはリクエストの宛先アドレスに関する条件であり、デバイスが自宅のWi-Fiとモバイル通信のどちらを使っているかを判定するものではありません。

7. テスト表で問題を切り分け、自動接続を無効にする

有効なテストでは、切り替え前後のネットワーク、接続状態、アクセス結果を確認します。同じアクセス可能な宛先を使い、ネットワーク条件は一度に1つだけ変更してください。ネットワーク切り替え時に一時的に以前の接続が残っていても、それだけでルールが動作していないと判断しないでください。接続状態と対象リクエストの記録をあわせて確認します。

切り分けが終わったら、「特定のWi-Fiを例外にする、その他のWi-Fi、モバイル通信、残りの補完条件」のうち、実際に必要なものを順に戻します。使用しないドメイン評価条件は残す必要がありません。項目を追加するたびに対応するテストを行い、接続アクションとリクエストのポリシーがそれぞれ想定どおりであることを確認してから設定を完了します。