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

Check On Demand and Global Routing separately

Start by separating two functions: On Demand determines when the system tries to establish or disconnect a VPN connection; Global Routing determines how traffic is handled while connected. Enabling On Demand does not fix server addresses, ports, authentication, or TLS settings in an existing service, nor does it change DIRECT rules in Config to PROXY.

The main areas in Shadowrocket are Home, Config, and Settings. First, verify that your existing configuration connects manually from Home, then go to Settings → On Demand to set up automatic triggers. This guide focuses on iPhone and iPad. Check the App Store listing for system requirements.

For troubleshooting, you can temporarily use Global Routing → Config and keep a copy of a configuration you've already verified. Proxy and Direct can help with comparisons, but they are not automatic connection conditions. Scene is not the same as matching a Wi-Fi name in On Demand. Change one type of setting at a time to tell whether a result comes from the connection or routing layer.

Establish a manual connection baseline first

If the destination is unreachable even with a manual connection, troubleshoot the underlying connection first. On Demand automates connection behavior; it does not fix connection failures. This guide assumes you already have your own service provider and subscription. It covers local settings only and does not provide service access details.

1. In Home, check which connection configuration is selected. If you recently updated an existing subscription, verify the selected entry again so your test uses the intended configuration.
2. Turn off On Demand temporarily, connect manually, and note the current Wi-Fi or cellular network, Global Routing mode, and whether the destination page loads.
3. In Config, confirm which configuration is currently enabled. While testing, avoid editing DOMAIN-SUFFIX, GEOIP, IP-CIDR, or FINAL at the same time.
4. Complete the VPN configuration authorization required by the system. If your device is managed by an organization, first confirm that its policies allow this VPN configuration.
5. Once manual connection and access both work, go to Settings → On Demand, add or adjust the conditions, and save your changes.

Set conditions for Wi-Fi names and cellular networks

A common setup is to avoid automatic connections on a specific Wi-Fi network while connecting automatically on cellular. Add the narrower Wi-Fi exception first, then the broader network rule. A Wi-Fi name is its SSID—not the router's admin address or the title of a web-based network sign-in page.

The two cards below are test plans, not importable configuration text. The action labels distinguish connection from disconnection. The fields you can edit depend on the current Settings → On Demand screen. Do not use the example names as your own SSIDs.

1. Start with one condition to test. Save it, reopen the page, and confirm that the condition and action were retained.
2. When testing Wi-Fi, check the exact name of the current network in iOS Settings. Match spaces, hyphens, and capitalization exactly; name fragments are not wildcards.
3. To test cellular, turn off Wi-Fi in Settings and confirm the network has switched before making a new web request.
4. Add a second condition only after the first passes, then add any other Wi-Fi conditions. Avoid broad rules covering every network unless you have a specific need.

Different bands on the same router may use different SSIDs or share one. Conditions match the actual network name; they do not depend on how close the device is to the router. If a public Wi-Fi network requires web sign-in, complete that step before testing automatic connections so a lack of internet access isn't mistaken for an On Demand failure.

Domain triggers are not the same as DOMAIN-SUFFIX routing

Domain evaluation in On Demand and domain rules in Config operate at different stages. System-level On Demand domain evaluation checks whether a connection is needed for a specific domain. DOMAIN-SUFFIX selects a policy after traffic enters rule processing. Adding a domain rule to Config does not create a system-level On Demand condition.

If the current On Demand editor offers domain evaluation, use the domain and connection-evaluation options available there. Evaluate Connection works differently from Connect: it evaluates further based on domain demand rather than connecting immediately when a network matches. Enter a hostname, such as example.com, not a full URL like https://example.com/path.

• Check whether domain evaluation is available.If the current screen only offers network conditions, don't enter a domain in the SSID field. You can connect based on a network condition first, then use Config for domain-based routing.
• Check for earlier rules that take precedence.If an earlier matching network rule executes Disconnect, a later domain evaluation won't override it.
• Test with a fresh lookup and connection.An already-open page, cached result, or reused connection may not trigger a new evaluation. Close the test page, make a new request, and check the system connection status.
• Check the DNS path.An app's own encrypted DNS, cached results, or direct use of an IP address may bypass the expected system domain-lookup path. Don't assume every app will trigger the same result.

This example shows Config routing syntax only. It is not an On Demand configuration and should not replace an existing configuration. The domain is for illustration; the actual outbound connection for PROXY depends on your existing configuration.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

Resolve conflicts by checking rule order

On Demand evaluates rules in order and performs the action for the applicable rule it matches. It does not combine all matching results, and Connect does not always take precedence over Disconnect. Place specific exceptions before broader conditions. Conditions within one rule also do not necessarily work as an “any condition” match. For example, a rule specifying a Wi-Fi interface and an SSID requires both to match; a list of names can contain multiple possible SSIDs.

If no condition matches, don't assume the connection will always disconnect. An existing connection, the system's current state, and other configurations can all affect what you observe. If you need a defined default behavior, set a clear final rule if the interface supports one, then test separately from both connected and disconnected starting states.

Also distinguish Disconnect, Ignore, and the DIRECT traffic policy. Disconnect is an On Demand action; Ignore does not force a disconnection; DIRECT is a routing policy. Treating them as interchangeable is a common reason users think “DIRECT is set, so why does the VPN still show as connected?”

Verify automatic connections with a consistent test plan

Don't rely on the Home switch alone. Record the system VPN status, current network, and destination request result together. After each change, save it before triggering a new network condition. A single successful test confirms only that scenario, not every possible one.

1. Specific Wi-Fi:Starting with the VPN disconnected, join the exception SSID and make a new request. Record whether the VPN stays disconnected, then repeat from a connected state.
2. Other Wi-Fi networks:Switch to another available SSID and check that it follows the general Wi-Fi condition you set rather than the previous network's result.
3. Cellular:Turn off Wi-Fi in Settings, confirm cellular data is available, then open the destination. Record whether the VPN connects automatically and whether the page loads.
4. Domain evaluation:When no earlier rule has already determined the action, visit the test domain and a comparison domain separately. Avoid reusing a connection from an already-open page.
5. Retest after a network change:Test again after the system reevaluates the network, for example by rejoining Wi-Fi. Record what actually happens; don't assume the process always completes within a fixed number of seconds.

Common questions and restoring manual control

The final setup should make each trigger clear: which network starts a connection, which SSID is an exception, whether the system evaluates domains, and which Config handles routing after the connection is established. After updating an existing subscription or changing an outbound configuration, verify manual connection first, then retest these scenarios. This keeps changes to service settings separate from troubleshooting automatic connection conditions.