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

Understand the Difference Between On Demand and Global Routing

Shadowrocket’s On Demand settings control when a connection is triggered. Once saved to the system VPN configuration, the system can attempt to connect when the network changes or domain-evaluation conditions are met. You do not need to open the app and tap the switch at the top of Home every time. On Demand is not a timer and cannot fix a server that will not connect.

Global Routing handles a different question: how requests are handled after the connection is established. Proxy, Direct, Config, and Scene are the options in this section. Config routes traffic according to the selected configuration’s rules, while Scene applies the configured scene. Even when On Demand triggers a connection, a request may still use DIRECT. A VPN status of Connected does not mean every request goes through a proxy server.

Domain evaluation may also be triggered by a new name-resolution request. The sequence above explains the roles of each stage; it does not mean every trigger must follow a network change. When troubleshooting, check “Was the connection triggered?” separately from “How was traffic routed after connecting?”

Before You Configure: Establish a Reproducible Manual Connection

This guide assumes you already have your own service provider and subscription. On Demand does not include server details, and purchasing the client does not come with server access. If you cannot connect manually yet, resolve server, authentication, and network-reachability issues before adding automatic triggers.

1. Temporarily turn off On Demand in Settings → On Demand so automatic reconnections do not affect your tests.
2. Go to Home, select the imported server you intend to use, and confirm the selection indicator appears beside the expected entry.
3. Turn on the connection switch. The first time, follow the system prompt to allow adding a VPN configuration. System authorization is required.
4. Run Connectivity Test, then visit a page that is normally accessible. The test only shows how the specific test target performed; it does not verify every request your apps may make.
5. Note the current Global Routing option and enabled Config, then disconnect before testing automatic triggers.

Wi-Fi and Cellular: Set the Conditions, Then Choose an Action

Go to Settings → On Demand and check the available network conditions and actions. Depending on the layout, a condition and its action may appear on one row or be edited separately; use the fields shown in your version of the app. The approach is the same: specify the network first, then choose whether to connect or disconnect when it matches. Do not use a note intended to describe a rule as the Wi-Fi name.

Enter the Actual Wi-Fi Name

For a Wi-Fi condition, enter the full name of the network your device is connected to—the SSID. In the example below, Home-WiFi is illustrative; replace it with the name shown on your system’s Wi-Fi screen. Do not enter the router’s admin address, Wi-Fi password, or a URL beginning with https://. Do not add quotation marks or wildcards.

1. Check the current network name on the system Wi-Fi screen. Verify each character, including capitalization, spaces, and suffixes.
2. Return to Settings → On Demand, enter the name under the Wi-Fi condition, choose the action you want, and save.
3. Enable On Demand, then disconnect from and reconnect to that Wi-Fi network. Check whether the connection state changes as expected.
4. Repeat the test on another Wi-Fi network to make sure the rule does not unexpectedly apply to every wireless network.

Different bands on the same router may use different names, and the same SSID can appear in different locations. Matching a name does not authenticate a trusted network. A familiar-looking network name is not proof that the network has been verified as safe.

Cellular Conditions Refer to the Interface, Not the Carrier

A cellular condition refers to the cellular interface currently in use by the system. It is not a field for a phone number, carrier name, or mobile-network APN. If you want to connect automatically after leaving a specific Wi-Fi network, also consider what should happen on other Wi-Fi networks: a cellular rule does not automatically mean “all networks except home Wi-Fi.”

Connect means the system will attempt to connect; it does not guarantee success. Disconnect ends the connection when the condition matches. If the interface offers an action that ignores the condition or leaves the current state unchanged, do not interpret it as “ensure disconnection.” To reliably exclude a network, verify what the selected action actually does rather than relying on the rule name.

Domain Conditions: Enter a Domain, Not a Full URL

Domain conditions are not quite the same as Wi-Fi or cellular-interface conditions. The system VPN’s On Demand mechanism can evaluate domains and decide whether to connect based on the matching domain, its resolution results, and the rule’s requirements. This often involves the semantics of EvaluateConnection and ConnectIfNeeded; it is not a simple match against the text in a web browser’s address bar.

In Settings → On Demand, check whether the current interface offers domain-related evaluation conditions; configure them only if they are available. Enter domain names such as example.com in the domain list. Do not paste the routing syntax below into a domain field, and do not mistake a DNS server field for a destination-domain field.

If you need to cover multiple specific hosts, check the domain-matching documentation for that field. Do not assume *.example.com works everywhere. Domain-related fields may use different suffix-matching conventions; test with one specific host first, then expand the scope gradually.

If your goal is to keep the VPN connected but proxy only specified domains, check Global Routing → Config and its rules instead of relying on domain-based On Demand for traffic routing. The example below illustrates the distinction between these functions. Use it only if it matches your configuration goals; it affects requests to matching domains.

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

DOMAIN-SUFFIX determines the outbound policy for requests here, while FINAL catches requests not matched by earlier rules. GEOIP and IP-CIDR are also routing rules; adding them to Config does not make them On Demand connection triggers.

When Multiple Rules Apply: Follow the Order, Don’t Guess Based on Specificity

The system evaluates On Demand rules in list order and uses the first matching top-level rule. Do not assume that a longer domain or more specific SSID automatically gets higher priority. Different conditions within a single top-level rule generally all need to be met, while multiple candidates in the same name list match if any one of them does. Domain evaluation can also involve internal actions, so not every condition can be treated as a simple flat list.

If the current interface lets you reorder rules, put explicit exceptions before broad conditions. If it only offers fixed options, do not assume you can drag them into any order; verify how they interact by testing the saved configuration. In particular, do not enable a broad connection condition and expect a later exclusion to necessarily take effect.

1. Define the goal first: For example, “Disconnect on a specific Wi-Fi, connect on cellular, and leave other Wi-Fi networks unchanged.”
2. Check for overlap: A rule that connects on every Wi-Fi network overlaps with a disconnect rule for a specific SSID.
3. Handle exceptions: In a sortable rule list, evaluate the exception for a specific SSID before broadening the Wi-Fi condition.
4. Test domain conditions separately: If a top-level network rule has already matched Disconnect, do not expect a later domain evaluation to override it.
5. Save and test again: Changes in the app must be saved to the active VPN configuration. Editing a screen without saving does not mean the system is using the new conditions.

The order described here is the On Demand rule order. Config’s top-to-bottom rule matching is a separate mechanism. Even if both use a “first match” approach, do not combine their lists when determining priority.

Test and Troubleshoot: Check the Trigger, Then the Connection, Then Routing

After configuring the rules, test at least the specified Wi-Fi network, another Wi-Fi network, and cellular data separately. Test domain conditions on their own, and note whether DNS caching or background requests may be involved. The checks below describe what to observe; they do not guarantee success on every network.

• Specified Wi-Fi: Reconnect to the target SSID and check whether the configured connect or disconnect action occurs.
• Another Wi-Fi: Join a network with a different name and make sure the specified-SSID condition was not entered as a rule for every Wi-Fi network.
• Cellular: Turn off Wi-Fi, confirm cellular data is available, then check whether the system attempts to connect.
• Domain evaluation: Make a new request to the domain when no other condition takes priority, then check the resolution and connection states.

To roll back, turn off On Demand in Settings → On Demand and save, then control the connection switch on Home manually. Once the manual baseline is restored, re-enable one type of condition at a time. Updating a subscription changes your existing server list and related configuration; it does not prove that On Demand rules are correct. After an update, check the selected server and verify the actual connection result.