Shadowrocket On Demand Setup: Automate Connections by Wi-Fi, Cellular, and Domain

First, distinguish On Demand from Global Routing

Find On Demand under Settings → On Demand. It uses the system VPN mechanism to apply connection conditions, which can include network interfaces, Wi-Fi names, and domain evaluation. It is not a timer, and it does not rely solely on whether Shadowrocket is in the foreground. Automatic connections still require a valid VPN configuration, system permission, and an available network.

Global Routing controls how requests are handled after the tunnel is established. In Home, Global Routing offers options such as Proxy, Direct, Config, and Scene; Config routes traffic according to the rules in the selected configuration. Connect in On Demand does not switch Global Routing to Proxy, and Disconnect does not switch it to Direct. Check these two layers separately when troubleshooting.

For example, after a cellular rule triggers Connect, requests matching DIRECT still connect directly if Global Routing is set to Config; only requests matching a proxy policy use the corresponding outbound. Conversely, a DOMAIN-SUFFIX rule in the configuration does not mean the tunnel will connect automatically when that domain is accessed.

Before enabling automation: establish a manual-connection baseline

Automation rules cannot fix an invalid connection configuration. Before you begin, select an existing configuration in Home, connect manually, confirm that the system allows a VPN configuration to be added, and access a destination you actually need. A subscription provides and updates existing connection details; it does not determine Wi-Fi conditions or domain triggers for you.

1. Record the current setup: Note the selection in Home, the Global Routing option, and the configuration currently in use under Config. Also record the order and actions of any existing On Demand rules.
2. Verify connectivity: Connect manually on the Wi-Fi and cellular networks you plan to test. If the connection does not work on either network, resolve the network or existing configuration issue first.
3. Open the settings: Go to Settings → On Demand and review the network conditions, actions, and rule order. Controls and available conditions may vary; use what appears in the current app rather than relying on an old guide to locate a specific button.
4. Check system settings: In iPhone or iPad Settings, find the VPN configuration and check the one associated with Shadowrocket, including its Connect On Demand status. The exact system path and labels may vary by device.
5. Test one condition at a time: Enable only the network-condition rules first, without adding domain evaluation. Once network switching behaves as expected, add another type of condition.

Set actions for Wi-Fi names and cellular networks

Define the intended behavior first. For example, disconnect the tunnel when connected to a Wi-Fi network named Home-WiFi, and connect it when switching to cellular. Home-WiFi is only an example of a custom network name. Replace it with the SSID of a network your device actually uses; do not copy a name that does not exist.

Check the SSID against the actual network name, including capitalization, spaces, and punctuation. Multiple access points with the same name may match the same condition, and an SSID alone cannot establish that a network is trusted. If your work and home networks share a name, the SSID cannot distinguish between them.

1. Add an SSID condition for the specified Wi-Fi network and select Disconnect. After saving, verify that the condition is tied to Wi-Fi rather than being a general rule with no interface restriction.
2. Add a Connect condition for Cellular. Make sure cellular data is available; turning off Wi-Fi without cellular data does not provide a valid connectivity test.
3. To connect automatically on other Wi-Fi networks too, add a Connect condition for those networks and place it after the specific-SSID exception.
4. Reconnect to the target Wi-Fi, then switch to cellular and make one new request on each network. Record the network name, expected action, and actual VPN status shown by the system.

When switching networks, an existing connection, the interface being switched to, and system timing can affect what you observe. Do not treat the icon immediately after a switch as the final result. Wait until the network is available, then check VPN status and make a new request. Avoid testing rules by switching rapidly back and forth.

Triggering connections by domain: don’t move DOMAIN-SUFFIX into On Demand

Domain-based On Demand and ordinary domain routing serve different purposes. The system uses domain-related connection evaluation to decide whether a tunnel is needed; routing rules choose a policy for requests while the tunnel is active. Apple’s On Demand mechanism can handle this with EvaluateConnection and its domain evaluation actions. ConnectIfNeeded evaluates whether a connection is needed; it does not connect unconditionally every time a particular website is opened.

In Settings → On Demand, check whether the current interface offers domain evaluation and a corresponding action. If available, enter a domain, such as internal.example.com, not https://internal.example.com/path. This example only demonstrates the input format; it is not a working internal service. For testing, use a domain you are authorized to access and whose DNS behavior you understand.

• Check the outer conditions first: Domain evaluation rules may also be limited by interface conditions. If an earlier network rule matches Connect or Disconnect, later domain evaluation rules will not be considered as additional matches in the same evaluation.
• Then check name resolution: ConnectIfNeeded can use DNS results, a specified DNS server, or probe conditions to decide whether to connect. If the direct network already satisfies the resolution condition, accessing the domain may not trigger the tunnel.
• Do not substitute an IP address for a domain: Connecting directly to an IP address, reusing an existing connection, or having the app handle name resolution itself may prevent the system from evaluating the domain as expected.
• Do not assume the tunnel disconnects when you finish browsing: A domain trigger determines whether to connect; closing a webpage is not a general Disconnect condition. The resulting state still depends on the system and other On Demand rules.

“Connect on any Wi-Fi” and “connect only when a particular domain is needed” are different goals. The first establishes a tunnel as soon as the network condition matches, so a later domain condition cannot narrow it down. To connect by domain, check whether a general network rule matches first and prevents domain evaluation.

Domain rules in Config handle traffic after connection

The following example uses Config rule syntax; it is not On Demand configuration text. It specifies a policy for matching requests, not a system trigger for automatic connection.

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

With Global Routing set to Config, the first rule sends requests matching the relevant domain to PROXY, while other requests fall through to FINAL and DIRECT. Make sure PROXY maps to a working outbound in the actual configuration. Saving this rule to Config does not set up domain-based On Demand connections.

When multiple conditions match: check rule order first

The system evaluates On Demand rules in order. The first matching rule determines the action for that evaluation; actions are not all applied together. More specific exceptions generally belong before broader network conditions. Check conditions within domain evaluation rules separately, and do not confuse their order with the rules in Config.

This table shows a network-priority setup and does not include domain evaluation. If you move the general Wi-Fi Connect rule to the top, Home-WiFi will match it too, preventing the later Disconnect rule from working as an exception. If you add a general condition with no interface restriction, check that it does not prevent all subsequent network rules from being evaluated.

1. When the result is unexpected, start with the first rule and note for each one: “Does the current interface match? Does the SSID match? What is the action?”
2. Temporarily disable newly added rules and keep the smallest set that worked before. Check whether the issue disappears when the new conditions are removed.
3. Change the position or action of just one rule at a time. Save, then test network switching and make a new request again.

Config’s FINAL rule cannot fix On Demand rule order. FINAL is a fallback for request routing; it is not a fallback connection action for system On Demand and cannot correct an incorrect SSID condition.

Troubleshooting: no automatic connection, reconnects after disconnect, or no domain trigger

Start by recording a reproducible sequence: the networks you switched between, the selected configuration, the first matching condition, and the system VPN status. Use the checks below for the symptom you see; there is no need to reset everything at once.

To roll back, turn off On Demand first, return to manual connections, and confirm the baseline still works before restoring rules one at a time. For everyday use, keep the smallest set of rules that explains each result. Avoid masking problems with overlapping, duplicate conditions.