This guide is for users who have imported their own subscription into Shadowrocket and confirmed that a manual connection works. First, distinguish On Demand connection triggers from traffic routing in Config, then configure conditions for specific Wi-Fi networks, Cellular, and domains. To verify the setup, change one condition at a time and check rule matches, tunnel status, and request policies separately. This helps distinguish automatic connection issues from routing errors.
On Demand vs. Global Routing
Shadowrocket’s On Demand feature uses Apple’s VPN On Demand mechanism to evaluate whether to establish a connection when the network changes or a qualifying network request occurs. It controls when to connect—not which policy each request uses. Once connected, requests are still governed by the current Global Routing mode on Home and the relevant configuration.
For routine checks, look at three areas: Home for the selected connection and Global Routing, Config for the active configuration, and Settings → On Demand for trigger conditions. Don’t use On Demand to fix an incorrect server address, port, or authentication detail; verify those by connecting manually first.
Config
RecommendedOnce connected, the active configuration determines request policies. When checking DOMAIN-SUFFIX, IP-CIDR, GEOIP, and FINAL, make sure the expected Config is enabled.
Best for: everyday use when you want automatic connections while keeping explicit routing rules.
Proxy
This proxy mode routes requests handled by the app and can help temporarily rule out Config routing as the cause. It does not mean On Demand is enabled, nor does it guarantee that all system traffic is handled.
Best for: briefly checking whether the connection and configuration rules work independently.
Direct
This direct mode is used. Even if On Demand triggers and establishes a tunnel, requests do not automatically switch to the proxy. A connection indicator alone doesn’t show where requests are routed.
Best for: checking direct connections or troubleshooting when you’re connected but the routing policy isn’t what you expected.
Bottom line: Set the routing mode first
Before testing, set Global Routing to Config and note the active configuration. Don’t change the routing mode, configuration, and connection at the same time while testing a set of triggers.
Before enabling On Demand: Verify a manual connection
These steps assume you already have your own service provider and subscription. This guide does not provide, sell, or recommend nodes or subscriptions. Subscription updates and On Demand are separate: the former refreshes existing connection details, while the latter controls when the system uses a connection. Automatic connections can’t fix expired subscription data.
-
Check your existing setup
Go to Home, confirm that your subscription has been imported and updated as needed, and select a connection you know works. Check the address, port, protocol, and authentication details. Don’t change several settings at once.
-
Connect manually
Start a connection manually from Home. The first time you connect, follow the system prompt to allow a VPN configuration. If the manual connection fails, fix the connection details or network issue before setting up automatic triggers.
-
Check routing
On Home → Global Routing, check the routing mode, then go to Config and verify the active configuration. Test with a request whose expected policy is clear, and note when it was made and which rule matched.
-
Open settings
Open Settings → On Demand and review the existing conditions and their order. If automation rules are already configured, note their current values. Keep only the conditions needed for this test to prevent an earlier rule from matching first.
-
Enable one condition at a time
Set one network condition in Settings → On Demand and enable On Demand. Return to Home to check the status, then switch networks to test it. Verify basic Wi-Fi and Cellular triggers before adding a domain condition.
The actions Connect, Disconnect, EvaluateConnection, and Ignore below describe Apple On Demand rule behavior; they are not a one-to-one reproduction of every Shadowrocket interface control. The available fields and action combinations depend on the current interface. Don’t substitute Config rules for conditions that the interface doesn’t offer.
Wi-Fi SSIDs: Put specific networks before general conditions
An SSID is a Wi-Fi network name, not a router address or the hardware address of a wireless access point. To set a condition for a specific network, check its full name in the device’s current Wi-Fi details—for example, Home-WiFi. Watch for capitalization, spaces, and punctuation. Don’t assume Home-* works as a wildcard.
In the Wi-Fi conditions under Settings → On Demand, enter or select the target SSID and set the connection behavior for that network. For example, if you want to disconnect on a home network you’ve confirmed meets your needs and connect on other Wi-Fi networks, place the disconnect condition for that specific SSID before the general Wi-Fi connection condition. An SSID is only a matching value; it doesn’t prove a network’s identity or trustworthiness.
| Order | Match condition | Action | How to verify |
|---|---|---|---|
| 1 | Wi-Fi, SSID is Home-WiFi | Disconnect | Connect to this SSID and check that the tunnel disconnects as configured. |
| 2 | Other Wi-Fi networks | Connect | Switch to another Wi-Fi network with a known name and check whether it triggers a connection. |
| 3 | Other networks | Set a separate condition | Set a separate condition for Cellular; don’t infer it from the Wi-Fi condition. |
This table illustrates the intent of the rules; it is not configuration text you can import. If the system or app prompts you for permission to access network information, check the prompt. If the SSID can’t be retrieved, a condition for a specific SSID may not match as expected. If a public Wi-Fi network requires a login, complete the sign-in first, then test On Demand. Otherwise, lack of internet access could be mistaken for a connection settings issue.
Cellular: Test it separately with Wi-Fi turned off
Cellular conditions apply to the cellular data network the device is actually using. Before setting one, make sure the device supports cellular and cellular data is enabled. An iPad with Wi-Fi only won’t gain cellular capability just because you added this condition. Similar network names don’t mean the connection types are the same: another device connected to a phone’s hotspot is usually still using its own Wi-Fi interface.
Set the desired action for Cellular in Settings → On Demand, then turn off Wi-Fi and confirm that the device has switched to cellular data. Simply leaving an SSID’s coverage area may not provide a clean test, since the device could immediately connect to another saved Wi-Fi network.
- To connect automatically on cellular: Set the Cellular condition to connect, then check whether an earlier, more general condition matches first.
- To stay disconnected on cellular: Set the corresponding disconnect behavior and check whether a general connection condition at the end of the list overrides the intended setup.
- For dual-SIM devices: Note which line is currently used for cellular data. Test again after switching data lines, and don’t confuse a carrier network change with a rule-order issue.
- To keep an eye on data usage: On Demand controls connection triggers; it isn’t a data quota tool. Subscription updates, app syncing, and other requests may still use cellular data.
Domain triggers: Don’t copy DOMAIN-SUFFIX rules into settings
Domain-based On Demand connections use the system’s connection evaluation mechanism. Apple’s EvaluateConnection can use domain matching along with DNS, reachability, and other connection requirements to determine whether to establish a connection. It is not a filter that continually checks every webpage URL, nor does it mean “always connect immediately when this domain is visited.” Configure domain conditions only if the current interface provides the relevant evaluation fields.
In Settings → On Demand, check whether domain evaluation options are available. If the fields are editable, enter a domain as required—for example, example.com. Don’t paste a full URL such as https://example.com/path, or use DOMAIN-SUFFIX,example.com,PROXY as a domain value. Check the field’s actual matching behavior to see whether subdomains are included; don’t assume it works like Config rule syntax.
| Item | On Demand domain evaluation | Config domain rules |
|---|---|---|
| Purpose | Evaluate whether a connection is needed. | Choose the policy for requests handled by the app. |
| Where to configure | The domain fields actually available in Settings → On Demand. | The rules section of the active Config. |
| What to enter | Enter domains and evaluation conditions as specified by the fields. | DOMAIN-SUFFIX,example.com,PROXY |
| Common factors that affect results | DNS cache, existing connections, how the app resolves domains, and earlier On Demand rules. | An earlier rule matching first, an incorrect policy name, or the wrong configuration being active. |
The Config rule in the table above also requires an available PROXY policy in the active configuration. It explains routing syntax; it does not create an On Demand condition. When testing a domain trigger, make sure an earlier network-level Connect condition hasn’t already established a tunnel unconditionally. Otherwise, you’ve only confirmed that the network condition works—not the domain evaluation.
Bottom line: Isolate conditions when testing domains
To test domain evaluation, temporarily disable broad network connection conditions that could match first, then close existing sessions in the relevant app and make a new request. If the interface has no domain evaluation option, use network triggers instead; don’t use Config rules as a substitute.
Multiple rules: Match connection conditions first, then request policies
On Demand rules are evaluated in order, and the first matching rule takes precedence. In general, put specific exceptions such as an SSID first, followed by broader interface conditions or fallback conditions. When a rule has multiple conditions, distinguish between multiple alternative values in one field and conditions that require both an interface and an SSID. Don’t assume every condition means “match any.”
Connect establishes a connection when its conditions are met. Disconnect prevents that connection from staying active when its conditions are met. Ignore leaves the current connection state unchanged, so it isn’t interchangeable with Disconnect. EvaluateConnection requires further evaluation of the connection conditions; it shouldn’t be treated as an unconditional Connect. Use only actions supported by the interface, and note their order.
- Define the expected behavior first: For example, “disconnect on Home-WiFi, connect on other Wi-Fi networks, connect on Cellular.” Specify one clear outcome for each network state.
- Put specific conditions before broad ones: Place an SSID-specific condition before a general Wi-Fi condition. Don’t put a general condition ahead of an exception it would override.
- Check where domain evaluation appears: If a network-level Connect condition has already matched, a later domain evaluation usually won’t determine that connection.
- Check Config last: After the connection is established, check request rules such as DOMAIN-SUFFIX, IP-CIDR, and GEOIP, along with the final FINAL rule. This is a separate matching layer.
Don’t confuse a fallback action in On Demand rules with FINAL. FINAL is the final request policy in Config and belongs at the end of the request rules. It doesn’t select a Wi-Fi network or enable On Demand for the system.
Testing and troubleshooting: Change one variable at a time
Your test notes should include at least the current network type, SSID, On Demand condition order, Home connection status, Global Routing mode, and request match result. Don’t expect a fixed connection time: network transitions, system scheduling, and server response times all affect what you see. A specific number of seconds is not a reliable pass/fail criterion.
Why does it reconnect after I disconnect manually?
Go to Settings → On Demand and temporarily turn off On Demand, then return to Home and disconnect manually. If the current network continues to match a Connect condition, the system may establish the connection again during a later evaluation. To keep it off, change the condition or turn off the feature.
Why doesn’t it disconnect when I get home?
Check that the currently connected SSID exactly matches the one in the condition, then make sure the specific SSID condition comes before the general Wi-Fi condition. If the interface asks for permission to access network information, grant it and switch networks again to retest.
It connects on cellular, but webpages won’t load. Why?
Turn off On Demand, then connect manually and test on the same cellular network. If the manual connection also fails, check the existing connection details and network reachability. If it works manually, check the condition order, Home → Global Routing, and the rules in the active Config.
Why doesn’t visiting the domain trigger a connection?
First, confirm that domain connection evaluation is configured in the interface—not just a Config rule. Close existing sessions in the app and try again. Check the DNS cache and how the app resolves domains. If the feature triggers only under conditions such as a resolution failure, no connection during successful resolution may be expected.
Do I need to set it up again after updating my subscription?
After the update, return to Home and check that the selected connection is still available, then test it manually. Subscription changes may affect the connection being used, but they don’t necessarily mean all On Demand conditions need to be recreated. Confirm the manual connection works before resuming On Demand testing.
For a complete check, switch back and forth through “specific Wi-Fi → other Wi-Fi → Cellular → specific Wi-Fi,” noting the expected action and observed status at each step. To undo these settings, turn off On Demand in Settings → On Demand first, then restore the original conditions and order. Don’t delete only one condition and leave a broader automatic connection rule behind.