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

On Demand Controls Connections; It Does Not Replace Global Routing

Shadowrocket's On Demand feature uses Apple's VPN On Demand mechanism to request a connection or disconnect when network conditions match your rules. It controls when a tunnel is established—not which route a website uses. After configuring conditions in Settings → On Demand, make sure the current system VPN configuration allows On Demand connections.

Global Routing determines where traffic goes after a connection is established. Proxy, Direct, Config, and Scene are options at this layer. Config routes traffic according to the active configuration's rules, while Scene uses the selected scene's settings. Setting Global Routing to Direct does not turn off the system VPN or disable On Demand.

So, seeing a VPN status while a request uses Direct does not necessarily indicate a problem. The VPN status reflects the tunnel state; Direct reflects the request's outbound policy. Record these results separately when troubleshooting. The status bar icon alone does not show that all traffic is going through a proxy.

Before Enabling On Demand: Verify Manual Connections and System Authorization

On Demand cannot fix an invalid subscription, incorrect connection settings, or an unavailable network. In Home, select an existing, working connection, turn it on manually, and visit a page that normally loads. Automatic trigger tests are meaningful only after a manual connection works.

1. Check your configuration. In Home, confirm the selected connection. If you need rule-based routing, also go to Config and make sure the intended configuration is selected. Avoid switching configurations during testing.
2. Authorize the system VPN. When adding a VPN configuration for the first time, follow the system prompts. If you deny authorization or remove the system configuration, the app's conditions cannot establish a tunnel on their own.
3. Open the On Demand settings. In Shadowrocket, go to Settings → On Demand and check whether the feature is enabled and which conditions are saved. Available fields and actions depend on the current interface.
4. Check the system configuration. On your iPhone or iPad, open Settings → General → VPN & Device Management → VPN, then view the relevant configuration and check Connect On Demand. The label may appear as “On Demand” in some system languages.
5. Record a baseline. Note the current Wi-Fi name, whether cellular data is enabled, the connection status, and the Global Routing mode. Change only one item in each test.

Specific Wi-Fi Networks: Add Exceptions Before General Conditions

When you set a rule for a specific Wi-Fi network, it matches the SSID. The SSID is not the router's management address or the device's nickname. Check the network name on your device's Wi-Fi screen and enter it exactly as shown. Pay attention to spaces, symbols, and capitalization; don't assume the system performs fuzzy matching.

For example, a user may want the tunnel to disconnect on a home network they've confirmed can access the resources they need directly, while requesting a connection on other Wi-Fi networks. This setup combines a specific network exception with a general network condition; it does not mean that every home network should disconnect. The SSID below is an example—use the actual network name when configuring your rule.

The system evaluates On Demand rules in order. A general condition earlier in the list may match before a more specific one. If the interface lets you reorder rules, put narrow exceptions before broader conditions. If rules are generated from category options, use the exception option provided; don't paste text rules from Config into On Demand settings.

• Duplicate SSIDs: Different locations may use the same network name. Matching by name alone cannot confirm that the router is the same.
• Dual-band Wi-Fi: Two bands with the same name generally can't be distinguished by SSID alone. If they have different names, check each one separately.
• Captive portals: Complete the web-based sign-in for a Wi-Fi network before testing. Otherwise, a network that isn't online yet may look like a condition that isn't working.
• SSID detection: If the app can't identify the current SSID, follow the system prompts to check relevant permissions and restrictions. Don't broaden the auto-connect scope just to mask the issue.

Cellular Networks: Test the Switch Separately; Turning Off Wi-Fi Is Not a Complete Test

A cellular condition applies to the network interface actually in use, not simply to a device with a SIM card. On an iPhone or iPad that supports cellular data, first confirm that cellular service works, then set the condition's Connect or Disconnect action. A Wi-Fi-only iPad cannot be used to test the cellular path.

1. Establish a Wi-Fi baseline. Connect to the specified Wi-Fi network, wait for the connection to stabilize, and check the expected VPN status for the exception condition.
2. Switch to cellular. Turn off Wi-Fi in system settings and confirm that the device can load a regular webpage over cellular data, rather than being offline.
3. Send a real request. Open a page or retry a request, then check whether the VPN connects or disconnects according to the cellular condition. Don't rely only on a change to the status bar icon.
4. Reconnect to the original Wi-Fi. Rejoin the same SSID, wait for the network switch to complete, and send a new request. Check whether the VPN returns to the state expected for the exception.
5. Record both layers. Note the VPN status and the page's loading result separately. If the tunnel is established but the page fails, investigate the connection settings and routing rules rather than continuing to change network triggers.

During a network switch, existing long-lived connections may drop and retry, and DNS results may remain cached. One brief failure is not enough to prove a rule conflict. Wait for the network to stabilize, send a new request, and repeat the same test. On Demand also doesn't mean every app continuously generates network activity, so an idle device is not guaranteed to connect within a fixed number of seconds.

Domain Triggers: Don't Confuse On Demand Evaluation with DOMAIN-SUFFIX

“Connect automatically when a domain is accessed” and “route a domain through Proxy” are two different needs. The latter can be handled with rules such as DOMAIN-SUFFIX in Config, but only if the relevant request has already entered the tunnel. Adding a domain rule to [Rule] does not create a system-level domain trigger for On Demand.

In Apple's On Demand mechanism, domain-related behavior can involve EvaluateConnection and ConnectIfNeeded. The system evaluates whether a VPN connection is needed during qualifying domain resolution or connection checks; it does not watch the browser's address bar and connect unconditionally on every visit. Whether and how these options can be configured depends on the choices Shadowrocket currently provides. Not every system-supported field is necessarily an in-app setting.

Domain tests are especially prone to cache-related issues. Existing DNS results, an app's built-in encrypted DNS, or direct access to an IP address may bypass the expected system domain-resolution path. A domain resolving normally on the current network also may not meet the criteria for a connection. So, a page loading without an automatic connection does not by itself prove that the configuration is broken.

• First check that the current On Demand interface actually offers a domain-related condition, then follow the field's instructions. Don't enter a complete URL where a domain is expected.
• Domain fields typically don't take https://, a page path, or :443. Check the field's instructions to understand suffix matching; don't guess at wildcard syntax.
• For a reliable setup that establishes a tunnel based on the network and then routes traffic by website, combine Wi-Fi or cellular conditions with Config. Don't rely on unverified domain-trigger behavior.

Rule Conflicts: Check Trigger Order, Then Routing Order

These two rule layers have separate orders and should not be compared as if they were one list. On Demand decides whether to connect; after a connection is established, Global Routing decides whether to use Config rules. If the current mode is Proxy or Direct, changing [Rule] is generally not the right way to test behavior in that mode.

The following example shows traffic-routing syntax; it is not an On Demand configuration and does not include a working connection. PROXY must correspond to an available policy in the current configuration. Back up your configuration and confirm the policy names before using rules in it.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• Line 1: DOMAIN-SUFFIX matches the example domain suffix. When it matches, the policy on that line applies, and the system does not continue looking for a later rule that might better match your preference.
• Line 2: IP-CIDR matches the example private IP range. no-resolve means this IP rule won't trigger an additional domain lookup; it does not disable all DNS behavior.
• Line 3: GEOIP matches against an IP geolocation database. It does not determine location from a webpage's language or the domain name.
• Last line: FINAL handles traffic that didn't match an earlier rule and belongs at the end as a fallback. It cannot trigger a system On Demand connection.

A practical troubleshooting order is: check the current network conditions, confirm which On Demand rules match, see whether the system VPN connected, then check Global Routing and the rule matched by the request. Change routing rule order only if the last step is the problem. If a subscription update changes the available connections, first verify that you can connect manually. Don't change On Demand and the configuration file at the same time.

Common Issues: Automatic Reconnection, Exceptions Not Working, and How to Stop Testing

After testing, keep only conditions with a clear purpose. Test specific SSID exceptions, other Wi-Fi networks, and cellular service separately. If domain-related conditions don't reliably produce the expected behavior, disable them for now and keep the network conditions you've verified. This helps isolate whether a connection was triggered from whether it works once connected.