What each of the three On Demand triggers matches, how to add rules under Settings → On Demand, whether to choose Connect or Disconnect as the Action, and the order to troubleshoot in when a rule doesn't fire. For readers who can already connect manually in Shadowrocket and want it to switch on and off automatically as they move between networks.
What On Demand Is: One Master Switch Plus a Set of Rules
On Demand in Shadowrocket does exactly that: when a condition is met, the system brings the tunnel up on its own, and when the condition goes away it disconnects — no need to return to the Home page and tap the connect switch every time. You'll find it under Settings → On Demand, and the screen has just two parts: the master switch at the top decides whether the whole mechanism is active, and the rule list below decides when to connect and when to disconnect.
These rules end up in the iOS VPN configuration and are executed by the system whenever network state changes. That means Shadowrocket doesn't have to stay in the foreground — the rules still work after the process is reclaimed by the system. The flip side is worth noting too: once a configuration has been written into the system, uninstalling the app won't remove it. An entry may still be sitting in Settings → General → VPN & Device Management → VPN, and you'll have to delete it there by hand.
Between a condition being met and traffic leaving the device there are four steps. The first three happen automatically, handled by the system and Shadowrocket; which route the fourth step takes, and which domains go direct, is still decided by Global Routing on the Home page and the rules in your Config. On Demand only controls whether to connect — not how traffic is routed. Keep the two apart when troubleshooting.
On Demand only decides when to connect; it doesn't provide a route. Get your subscription link and servers from your provider — a one-time client purchase is not a server plan.
Wi-Fi Triggers: Using SSID to Decide Connect or Disconnect
A Wi-Fi trigger matches the name of the network you're currently on — the SSID. The path is fixed: Settings → On Demand → turn on the master switch → tap + in the top-right corner of the rule list → set Type to Wi-Fi → enter the SSID → pick an Action. Each of the three fields does one job: Type decides what to look at, Value decides what to match, and Action decides what happens when it matches.
Action takes only two values: Connect and Disconnect. Home Wi-Fi is usually set to Disconnect — at home you're on broadband and don't need the tunnel; office, hotel and café Wi-Fi get Connect. The low-maintenance approach is to write Connect rules only for the networks that need a proxy and leave the rest alone, keeping manual control.
Wi-Fi Trigger Rule
- Path
- Settings → On Demand → +
- Type
- Wi-Fi
- Value
- SSID, matching the system display character for character
- Action
- Connect / Disconnect
- Tip
- Set home Wi-Fi to Disconnect
If you rename the router or swap the hardware, the SSID in the rule has to be updated to match.
Cellular and Domain Trigger Rules
- Path
- Settings → On Demand → +
- Type
- Cellular
- Type
- Domain
- Value
- example.com — host name only
- Action
- Connect
A domain trigger brings the tunnel up when the system is about to reach that domain.
SSID matching is character by character: a different case, a trailing space, or a full-width character sneaking in, and the rule simply won't fire — with no error shown anywhere in the interface. Checking is straightforward: look at the current network name in iOS Settings → Wi-Fi and line it up with the Value in the rule.
Takeaway: Check the String Before You Blame the Mechanism
When a Wi-Fi rule doesn't fire, first compare the SSID against the string shown in the system, character by character. A mismatch is the most common cause of this kind of failure; correct the value, save, and it takes effect again — no need to reinstall the app or restart the device.
Cellular and Domain Triggers: Two Conditions That Don't Depend on the Current SSID
A Cellular trigger looks at the network type currently carrying traffic: it fires when Wi-Fi isn't connected and cellular data is providing the network. The classic pairing is a Wi-Fi rule that disconnects at home and a cellular rule that connects when you leave — the moment you step out the door, the tunnel comes up on its own, with no manual switching.
A Domain trigger looks at the request target: it brings the tunnel up when the system is about to reach a given domain. Enter just the host name, for example example.com — no https://, no path or port, and not an IP address. It suits cases where you only need a proxy for one service, such as an intranet domain at work, or a route you use on one specific site.
There's one behaviour to expect with domain triggers: the rule takes effect when the system resolves the domain and is about to open the connection, so the very first request sometimes goes out before the tunnel is up — the page fails to load once and works after a refresh. That's a timing issue, not a mistake in the rule.
The Three Trigger Types Compared, and Common Misconfigurations
All three condition types can exist at once; the system evaluates each against the actual network state and request target. What really goes wrong isn't usually the rule itself but rules fighting each other, or rules that don't line up with the Global Routing mode on the Home page.
| Trigger type | What it matches | Typical use and common pitfalls |
|---|---|---|
| Wi-Fi | The SSID you're currently connected to | Disconnect at home, Connect at the office; SSID matching is character by character, so old rules stop working after a router rename |
| Cellular | Whether cellular data is currently carrying traffic | Connects automatically once you leave Wi-Fi; mutually exclusive with Wi-Fi — only one network carries traffic at a time |
| Domain | The host name being requested | Connects automatically when example.com is requested; host name only, and the first request may go out direct |
Takeaway: Prove the Mechanism With One Rule, Then Add the Rest
Write a single Disconnect rule for your home Wi-Fi, then move back and forth between Wi-Fi and cellular and watch whether the VPN badge in the status bar appears and disappears as expected. Once the mechanism works, add the cellular and domain rules: going from one rule to three doesn't triple your troubleshooting effort, but writing five at once means bisecting them one by one when something breaks.
Turned On Demand on and now your home Wi-Fi has no internet?
First check whether the rule for your home Wi-Fi is set to Connect. At home you only need a direct connection; if the tunnel comes up and the route itself isn't usable, pages simply won't load. Change the Action to Disconnect and reconnect to the Wi-Fi.
Swapped the router and the old Wi-Fi rule no longer fires?
The SSID changed. Go back to Settings → On Demand, open that rule and set Value to the new network name — case and spaces must match exactly. The old value will never match, so delete the rule and create a new one rather than keeping it around.
Frequent disconnects and reconnects on cellular?
It's usually because Connect and Disconnect rules both exist for the same situation, or because the network type keeps changing as you move. First reduce the rules to one action per network and see whether the flapping stops, then decide whether to keep the cellular rule at all.
Do domain rules need a full URL?
No. Enter the host name only, for example example.com — no https://, path, port or query parameters. A value with a path will never match, because the trigger is evaluated at the point where the target host name is resolved.
Does On Demand still work if Shadowrocket isn't running in the background?
Yes. The rules live in the system VPN configuration, and the system brings the tunnel up when network state changes — provided that configuration has been created successfully at least once, was authorised in the system prompt, and hasn't been deleted in system settings.
Verification and Troubleshooting: What to Do When On Demand Doesn't Behave as Expected
Working through a fixed order beats reinstalling the app over and over. The five steps below cover the vast majority of cases, and each one gives you something you can see on the device.
-
Check the master switchThe switch at the top of Settings → On Demand is on, and the rule list holds at least one rule.
-
Check the three fields of each ruleConfirm Type, Value and Action one by one; the SSID must match the string shown in iOS Settings → Wi-Fi.
-
Check the system VPN configurationThe configuration should be visible in iOS Settings → General → VPN & Device Management → VPN; a VPN badge in the status bar means the tunnel is up.
-
Check the routing modeGlobal Routing on the Home page should be on Config so traffic follows your rules; on Direct, the tunnel may be up but traffic won't go through the proxy as expected.
-
Rebuild the configurationToggle the connection switch off and on again on the Home page so Shadowrocket rewrites the VPN configuration; if it still misbehaves, delete the old configuration in the system VPN list and connect once more.
If all five steps are done and it still doesn't work, the rules are usually interfering with each other. Trim the On Demand list down to the two or three you actually need and add them back one at a time — that's far easier to debug than ten rules written in one go. The rules themselves only describe when to connect; whether traffic actually gets through afterwards depends on things like whether your subscription is up to date and whether the servers are reachable.