Shadowrocket On Demand Rules: Automatically Connect by Wi-Fi, Cellular, and Domain

Learn how On Demand works and set up automatic connections or disconnections by Wi-Fi name, cellular network, and domain—with a clear explanation of rule order.

At a glance

Shadowrocket’s On Demand feature determines when the system starts or disconnects a VPN connection; it does not replace traffic rules applied after connecting. For users with a working connection and configuration, this guide shows how to set actions for specific Wi-Fi networks and cellular data, explains why a domain condition does not mean the VPN will always connect when you open a webpage, and walks through checking rule order and automatic reconnection.

1. On Demand vs. post-connection routing rules

Before configuring anything, keep this distinction in mind: to connect automatically based on network conditions, check Settings → On Demand. If the VPN is connected but a website is routed incorrectly, check Home → Global Routing and the active configuration in Config. These work at different stages. Adding domain routing rules to a configuration does not create a system-level On Demand trigger.

Network conditions change System evaluates conditions Connection action runs Tunnel is established Traffic rules are matched

On Demand relies on Apple’s system VPN on-demand mechanism. The system evaluates whether to connect based on the current network and saved conditions. Once connected, Shadowrocket handles traffic according to the selected routing mode. Events such as network changes and name-resolution requests may factor into this evaluation, but On Demand does not continuously scan foreground webpages or start and stop based on whether an app is open.

For example, DOMAIN-SUFFIX,example.com,DIRECT in a configuration sends matching domain suffixes direct, while FINAL,DIRECT sets the fallback when no earlier rule matches. These rules do not start the system VPN. GEOIP (matching by IP geolocation) and IP-CIDR (matching by IP range) also operate at the traffic-handling stage; neither replaces Wi-Fi or cellular conditions.

2. Check access, connection, and recovery before you begin

First confirm that a manual connection works, then enable automation. These steps focus on iPhone and iPad. For system requirements, refer to the App Store listing. Available fields may vary by system and app interface; use the options currently shown in Settings → On Demand. Do not assume a system action will appear as a button in every interface.

2 layers
Settings path: Settings → On Demand
2 types
Network conditions in this example: Wi-Fi and Cellular
3 items
Verification notes: current network, connection status, request result
  1. In Home, select an available connection you already have and turn it on manually. If the system prompts you to add a VPN configuration for the first time, verify the app and follow the system prompts to approve it.
  2. Open a page that normally works and confirm the network itself is available. If a manual connection fails, troubleshoot the connection details, network reachability, or configuration first.
  3. Note the current Global Routing mode and the active configuration in Config, so you can restore them if you change either while testing.
  4. Go to Settings → On Demand and note the existing conditions and their order. Change only the item you need to test; do not update a subscription or switch connections at the same time.
  5. Remember where to find the corresponding VPN configuration in Settings → General → VPN & Device Management → VPN. If the system shows an option related to On Demand, check its status too.

In short: establish a working manual baseline first

Connect manually on the same network, then change only the On Demand conditions. If something goes wrong, you can tell whether the trigger failed to fire or the connection failed after it was triggered.

3. Connect or disconnect based on Wi-Fi name

A Wi-Fi name condition usually refers to the SSID (the wireless network name). It matches the network name—not the router brand or a website domain. This example uses the fictional name Home-WiFi to illustrate the goal of disconnecting on a specific Wi-Fi network and connecting on cellular. Whether to disconnect on a particular network depends on your needs; a network name like “home” does not automatically make it trustworthy.

  1. In your system Wi-Fi settings, check the full name of the connected network. Preserve its spaces, symbols, and capitalization; do not substitute a note such as “home network” for the actual SSID.
  2. Go to Settings → On Demand, edit the Wi-Fi condition, and enter the actual SSID to match. Home-WiFi is only an example.
  3. To disconnect this VPN on the matching network, set the action to Disconnect. To connect on that network, use Connect. Save using the options shown in the current interface.
  4. Check for broad conditions that apply to all Wi-Fi networks. A specific SSID exception should come before any general condition that might override it.
  5. Disconnect from the Wi-Fi network and join it again to check the VPN status. Do not save the setting and immediately judge it based on a single page load on the same network.

Example: target settings for a specific Wi-Fi network

Settings path
Settings → On Demand
Network type
Wi-Fi
SSID
Home-WiFi (fictional example)
Action
Disconnect: disconnect on this network

This describes the intended settings; it is not configuration text you can import. Replace the example with the current network’s SSID.

Example: target settings for cellular

Settings path
Settings → On Demand
Network type
Cellular: cellular network
SSID
Not applicable; SSID is a Wi-Fi condition
Action
Connect: connect on this network

Test only on a device that supports cellular data and has it enabled. A successful connection still depends on whether your existing connection works.

Disconnect disconnects this VPN; it does not turn off the device’s Wi-Fi or block all network traffic. If you only want a particular domain to go direct at home, keep the VPN connected and set up routing in Config instead of disconnecting on the entire home Wi-Fi network. These approaches have different effects.

4. Automatic connection on cellular and rule order

On a device that supports cellular data, you can set the Cellular condition to Connect. After you leave a specified Wi-Fi network, the system switches to cellular data and evaluates the relevant conditions. The transition still depends on network availability, VPN setup, and subsequent requests; do not assume On Demand will keep every existing connection uninterrupted.

Evaluation orderConditionActionWhat to check
Specific exception firstWi-Fi, SSID is Home-WiFiDisconnectThe name matches the network actually in use
Network typeCellularConnectThe device is currently using cellular data
General condition at the endOther networks that need a connectionConnectAdd only if supported by the interface and needed

The system evaluates On Demand rules in order, and the first applicable matching rule determines the action. If a broad Connect condition at the top already covers every Wi-Fi network, a later Disconnect condition for a specific SSID may never take effect. Shadowrocket may organize conditions by network type, so check both the order shown in the interface and the scope of each condition—not just whether a switch is enabled.

An iPad without cellular capability cannot be used to test a cellular network transition. When connected to another device’s hotspot over Wi-Fi, your device is still using its Wi-Fi interface. Evaluate the network type seen by your device, not how the hotspot itself gets online.

5. Domain-based On Demand triggers are not DOMAIN-SUFFIX routing

The idea of “connect when visiting a domain” needs some clarification. Apple’s on-demand mechanism can use EvaluateConnection and domain or name-resolution conditions to decide whether to establish a VPN connection. This is different from matching DOMAIN-SUFFIX after connecting, and it should not be understood as monitoring the browser’s address bar.

In system domain evaluation, ConnectIfNeeded (connect when needed) is generally associated with conditions such as DNS resolution failure or an unavailable required DNS server. NeverConnect (do not start a connection for matching domains) is not a website-blocking rule. These are system mechanism names. Configure them only if the current Shadowrocket interface offers the relevant conditions; do not paste them into a configuration as if they were configuration keywords.

  1. First clarify what you need: “establish a connection when an internal domain is accessed while the tunnel is disconnected,” or “route a particular website a certain way while the tunnel is connected.” The latter is handled in Config.
  2. In Settings → On Demand, check whether domain-related conditions and actions are available. If the current interface only offers network-type conditions, configure only what it supports; do not make up fields.
  3. If the interface supports domain conditions, test with a domain you are authorized to access and that genuinely requires the relevant network environment for resolution. internal.example.com is only a syntax example and cannot be used to verify real connectivity.
  4. Enter a hostname or domain as required by the field, not a complete URL. In https://internal.example.com:443/path, the scheme, port, and path are not part of the domain itself.
  5. Record the DNS result while disconnected before enabling the condition. If the domain already resolves on a regular network, do not expect “connect when needed” to trigger every time.
Do not judge domain conditions by how many times you refresh

DNS caching, existing browser connections, and encrypted DNS used by an app can all affect whether the system detects a new resolution request. Refreshing an already-open page may not generate the evaluation event you expect. Check both the VPN status and the actual resolution result; a page opening successfully does not by itself prove that On Demand triggered.

If all you need is for example.com to go direct while other requests continue to follow the existing configuration, add the relevant domain rule to the active configuration and select Global Routing → Config. Domain routing controls where traffic goes; disconnecting the entire VPN affects requests from other apps and is not a substitute.

6. Verify the settings in three scenarios

Change one variable at a time: keep the same existing connection, active configuration, and test page. The observations below are items to record during verification, not fixed timings or performance guarantees. System evaluation and tunnel setup take time; wait for the status to stabilize before drawing conclusions.

Test scenarioActionWhat to checkCheck first if something goes wrong
Join a specified Wi-Fi networkRejoin an SSID configured as an exceptionDoes the VPN disconnect as set by Disconnect?SSID and coverage of general conditions
Switch to cellular dataTurn off Wi-Fi and confirm cellular data worksDoes the VPN start connecting and eventually connect?Cellular condition and availability of the existing connection
Access a domain that requires internal DNS resolutionMake a new resolution request under the applicable domain conditionWas the condition evaluated, and does the domain resolve after connecting?DNS cache, resolution path, and domain condition

If the status shows that the VPN is connected but the page still fails, the issue is now in post-connection handling. Check Global Routing, the active Config, DNS, and destination reachability instead of repeatedly changing the Wi-Fi name condition. If no connection action occurs at all, first check that On Demand is enabled, the current interface type, and rule priority.

7. Automatic reconnection, name matching, and battery questions

Why does the VPN reconnect after I turn it off manually?

Open Settings → On Demand and check whether a Connect condition still matches the current network. Then check the On Demand status in the system VPN settings. To pause automation, turn off On Demand before disconnecting; don’t keep toggling the connection switch on Home.

Why does the VPN stay connected at home even though I set home Wi-Fi to disconnect?

On the system Wi-Fi screen, check the full SSID again and confirm whether the device has joined a different band with a different network name. Then check whether a general Connect condition covering all Wi-Fi networks takes precedence. The same router does not necessarily mean the SSID is the same.

Why didn’t opening a specific domain trigger a connection? Is the domain rule wrong?

First, confirm that you set an On Demand domain condition, not a DOMAIN-SUFFIX rule in Config. Then check whether the domain is cached, whether it resolves on a regular network, and whether the request uses a DNS path the system can evaluate. A page loading successfully does not, by itself, prove that a new trigger occurred.

Does On Demand always use less battery than staying connected?

You cannot tell from the switch alone. Compare activity during similar usage periods in system Settings → Battery. If frequent network changes repeatedly establish the tunnel, reduce unnecessary condition changes. Configure On Demand for your actual connection needs, and avoid repeatedly disconnecting and reconnecting just for testing.

Keep the final checks in the same order: confirm network availability, check whether the system triggered the connection, then inspect routing and DNS after connecting. Recording what happens at each stage is more useful than changing On Demand, subscriptions, and configuration all at once. See more setup guides on this site for help with the basics.

Get Shadowrocket on the App StoreCheck the app details first →