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

First, distinguish On Demand, Global Routing, and Config

Shadowrocket’s On Demand settings configure the system’s on-demand connection behavior. When the network changes or a specific evaluation condition is met, the system decides whether to establish a connection. It is not a switch that asks whether to turn on the proxy for every request, nor does it require the app to stay in the foreground.

Global Routing on Home controls how traffic is handled after the connection is established. Proxy, Direct, Config, and Scene handle traffic routing; On Demand controls when the tunnel connects. When troubleshooting, record these separately. A connected VPN does not mean that every domain is routed through the proxy.

• Settings → On Demand: Set on-demand connection conditions and actions, then check the corresponding VPN configuration’s on-demand status in the system settings.
• Home → Global Routing: Check the current routing mode. To test Config rules, select Config rather than leaving Proxy or Direct selected.
• Config: Manages traffic-routing rules such as DOMAIN-SUFFIX, IP-CIDR, and FINAL.

Establish a reproducible connection baseline first

Make sure the same configuration works when connected manually before enabling automation. On Demand cannot fix an incorrect server address, authentication details, or an invalid configuration. If manual connection already fails, adding automatic reconnection only adds more variables and makes the original issue harder to isolate.

1. On Home, select a working configuration you already have and note the current Global Routing mode. Select Config when checking routing rules.
2. Temporarily turn off On Demand in Settings → On Demand. Connect manually and visit a page that normally loads to confirm the basic connection works.
3. Note the exact SSID of the Wi-Fi network you’ll use for testing. Use the name shown in the system’s Wi-Fi list, not the router model or a nickname you assigned to the network.
4. Go to Settings → On Demand and start with the fewest network conditions possible. Change one rule at a time, save, then switch networks to test it.
5. Check the corresponding configuration under Settings → General → VPN & Device Management → VPN. Labels may vary by system version; make sure you are viewing the configuration used by Shadowrocket.

Set conditions for Wi-Fi names and cellular networks

A common goal is to avoid automatic connections on one specific Wi-Fi network while connecting automatically on other networks. The key is not to list every Wi-Fi network individually, but to put precise exceptions before broader network conditions. Home-WiFi below is an example name; enter the SSID shown on your device.

An SSID condition matches a network name; it does not authenticate the router. Different locations can use the same Wi-Fi name, so a match is not proof that the network is trusted. Different frequency bands with the same name may match the same rule; networks with different names need to be handled separately.

• If you also have a rule to Connect on other Wi-Fi networks, place it after the Disconnect rule for the specific SSID.
• Add a fallback rule without a network-type restriction only if you actually need one. A broad Connect rule placed too early can take precedence over more specific conditions.
• Check that the system has permission to read Wi-Fi names. If the SSID can’t be read, don’t assume the exception for that name matched.
• Public Wi-Fi may require you to sign in to the network first. If the network is not yet online, Connect only means that a connection will be attempted, not that it will succeed.

When multiple rules match, check their outer order first

The system evaluates outer On Demand rules in list order and uses the action from the first matching rule; it does not combine the actions of every matching rule. A single outer rule that specifies both an interface type and an SSID requires both to match. Multiple names in an SSID list match any one of those names. Domain evaluation is a separate layer and should not be treated like an ordinary network condition.

Connect starts a connection when its conditions are met. Disconnect disconnects and prevents this mechanism from establishing a connection under those conditions. Ignore means that this evaluation does not change the connection state. It does not mean Disconnect, or “skip this rule and check the next one.” To keep a network explicitly disconnected, choose the action that matches your goal rather than relying on Ignore.

1. Place specific exceptions before broader conditions. Save, then reopen the page to check the rule order.
2. Trigger an evaluation by joining and leaving networks; don’t just refresh a webpage repeatedly on the same network.
3. Record whether a matching rule failed to start a connection or started one that then failed. The latter also calls for checking the underlying network and your existing configuration.

Automatic connection by domain: distinguish on-demand evaluation from routing rules

“Connect when I visit a domain” can describe two different needs: evaluating whether to connect based on a domain while the tunnel is down, or routing a specific domain through PROXY after the tunnel is up. The first uses the system’s On Demand EvaluateConnection mechanism; the second uses Config rules. Adding DOMAIN-SUFFIX alone does not enable the first behavior.

In the system’s rule semantics, EvaluateConnection can include domain evaluation items. ConnectIfNeeded uses domain resolution and reachability conditions to decide whether to establish a tunnel; it does not connect unconditionally whenever any webpage is opened. NeverConnect means that the domain evaluation item does not trigger a connection. It is not the same as DIRECT in a traffic rule and does not disconnect an existing connection.

• Check the settings first: In Settings → On Demand, see whether the current interface offers domain evaluation options. If it only shows network conditions such as Wi-Fi and Cellular, don’t enter a domain as an SSID or assume that pasting a routing rule will add a system feature.
• Enter a domain, not a URL: Use a name such as example.com. Don’t include https://, a path such as /account, or a port such as :443. Follow the field’s own description for the matching scope, and don’t add wildcards without a reason.
• Check which outer rule matches first: If an Any Wi-Fi Connect rule comes first, a later EvaluateConnection rule will never be selected. To evaluate domains on demand, redesign the actions for the relevant network conditions.
• Account for DNS caching: Existing DNS results, an app’s own resolution behavior, or direct IP access may prevent a new domain evaluation during testing. Refreshing the webpage alone cannot confirm that a rule failed.

If your goal is simply to route example.com through the proxy and send other traffic directly, set up routing in your existing Config using the policy names available there. The example below shows rule syntax only and assumes that the PROXY policy is already working. It is not an On Demand configuration and does not include a connection service.

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

Before using this rule, establish a working tunnel and select Config under Global Routing. If your existing configuration has other rules, don’t replace the entire file with this two-line example. Check for earlier matching conditions and keep any settings you still need.

Troubleshoot automatic connection issues with a consistent test procedure

During testing, keep the same existing configuration and change only one condition at a time. Record four things each time: the current network, the expected action, the actual VPN status, and the webpage result. A page loading only confirms that this visit succeeded; by itself, it does not prove that On Demand matched or that traffic used PROXY.

1. Test a specific Wi-Fi network: Join the configured SSID, wait for the network to finish connecting, then check the VPN status. If the intended action is Disconnect, make sure another automation is not reconnecting the VPN.
2. Test another Wi-Fi network: Switch to a network with a different name that can access the internet normally, then check whether the broad Connect rule starts a connection. Don’t mistake an incomplete network sign-in for a configuration problem.
3. Test Cellular: Turn off Wi-Fi, confirm that cellular data is available, and check the tunnel status. Keep the same Global Routing mode throughout the test.
4. Test a domain: Do this only if domain evaluation is actually configured. First confirm that the tunnel is disconnected, then make a new request to the domain and check the connection status and available logs. Don’t rely only on whether the page loads.
5. Restore the baseline: If the VPN keeps reconnecting, turn off On Demand and test manually. If manual connection also fails, troubleshoot the network or existing configuration first.