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

First, distinguish auto-connect from request routing

On Demand determines whether the system establishes a VPN tunnel under specific conditions. Global Routing determines how requests are handled after the connection is established. These are separate layers. A successful auto-connect does not mean every request uses a proxy; a request matching DIRECT does not mean the system should disconnect the VPN.

Check Global Routing in Home: Proxy routes traffic through the proxy by default, Direct connects directly by default, Config applies the rules in the selected configuration, and Scene switches related settings according to the configured scene. To test rule-based routing, select Config and confirm that the intended configuration is enabled. Scene is not another name for On Demand; scene switching and automatic system connections are separate features.

Settings → On Demand: Set up a baseline you can verify

Save your current configuration before you begin, and note the existing On Demand conditions. Use Home to check the current connection and server, Config to review the configuration file, and Settings → On Demand to manage connections on demand. Condition editors may be arranged differently across system versions and interface languages. Check each condition type and action rather than relying on the position of a particular switch.

1. Record the baseline. In Home, note the current server, Global Routing mode, and manual connection result. If Scene is enabled, rule out automatic scene changes during testing.
2. Open the condition settings. Go to Settings → On Demand and check whether it is enabled, along with the existing network conditions and actions. Keep only the condition you want to test for now to avoid changing several conditions at once.
3. Allow the system to save the VPN configuration. During initial setup, if the system asks to add a VPN configuration, review the prompt and grant permission. The name and location of the VPN entry in system settings vary by system version; use what appears on your device.
4. Save, then change the network conditions. After editing and returning, switch Wi-Fi or cellular networks once. Don’t just wait on the editing screen, and don’t assume unsaved changes have taken effect.
5. Record connection status and access results separately. Note the current network, whether the VPN is connected, and whether the website loads. Keeping these results separate helps distinguish a trigger failure from a routing failure after connection.

On Demand is handled by the system’s network services, so Shadowrocket does not need to stay in the foreground. Background triggers still depend on the system detecting a matching network change or connection request. Force-quitting the app repeatedly is not necessary to test auto-connect.

Set actions for Wi-Fi names and cellular networks

The name in a Wi-Fi condition is the SSID, not the router’s admin address or the Wi-Fi password. Preserve the original capitalization, spaces, and symbols; don’t add quotation marks around the name. If dual-band networks use separate names, include each SSID you want to match. If they share one name, the SSID condition cannot distinguish between bands.

The cards below show example condition designs; they are not configuration text you can import. HomeNet and OfficeNet are sample names. Replace them with the actual SSIDs shown in your device’s Wi-Fi list. Connect means to request a connection; Disconnect means to disconnect under that condition. Available actions depend on what the app interface shows.

To disconnect on HomeNet and connect on other Wi-Fi networks, you must also set up conditions for those other Wi-Fi networks. Adding a cellular Connect condition alone does not cover them. Put more specific SSID conditions before broader network conditions. Check the saved order to make sure a broad match does not prevent a later, more specific condition from taking effect.

• Test HomeNet and cellular network behavior first. Add an “Other Wi-Fi” condition afterward so you’re not introducing three variables at once.
• The same Wi-Fi name can be used in different locations. Automatically disconnecting based only on an SSID is not a network security measure.
• For Wi-Fi with a captive portal, complete the sign-in first, then check whether the server is reachable. Being connected to Wi-Fi does not necessarily mean you have internet access.

Domain-based triggers: Understand the limits of EvaluateConnection

Domain-based system VPN behavior is part of connection evaluation; it is not a command that toggles the VPN whenever you open a URL in a browser. Network-level Connect or Disconnect actions can directly determine what happens under a network condition. Domain evaluation typically uses EvaluateConnection and its domain actions to decide whether a DNS lookup should establish a connection. Configure this only if the current interface offers the relevant domain evaluation options. Don’t enter a domain in the Wi-Fi name field.

ConnectIfNeeded means “connect if needed.” It can evaluate whether to establish a VPN based on DNS lookup failures, specified DNS servers, or probe results. If the domain resolves successfully on the current network, don’t assume it will trigger a connection. NeverConnect means that the domain won’t trigger a connection; it does not immediately disconnect an established VPN when you visit that domain.

When testing domain conditions, use a test domain you control whose DNS behavior is known, and account for DNS caching. An already-open webpage, a reused connection, a direct IP address, or an app’s encrypted DNS may prevent the system from seeing the expected domain lookup. The example domain example.com illustrates rule syntax; it is not a suitable test target for reliably triggering a connection through a failed lookup.

After connecting, use Config rules to route domains

If you want a specific domain to use a proxy while other requests connect directly, let network conditions establish the connection and use Rules in Config to route requests. The snippet below is an example; PROXY must match a policy name available in your current configuration. Don’t replace your existing configuration without checking its policy definitions.

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

• DOMAIN-SUFFIX,example.com,PROXY matches example.com and its subdomains, selecting an outbound policy. It does not create an On Demand domain condition.
• IP-CIDR,192.168.0.0/16,DIRECT,no-resolve applies to the destination IP range; no-resolve means this IP rule won’t trigger an extra domain lookup.
• GEOIP,CN,DIRECT relies on the destination IP and its location in the local database. It cannot replace precise domain rules and does not classify traffic by webpage language.
• FINAL,PROXY is the fallback for requests that don’t match earlier rules and should go at the end of the rule list. This example sends unmatched requests through a proxy; it does not connect everything else directly. If you want that behavior, verify your requirements and change the fallback to DIRECT.

Verify the setup in two steps: first confirm that On Demand established a connection, then confirm that Global Routing is set to Config and check which rule matched the request. With Proxy mode selected, you can’t use the result to tell whether the routing rules above are working. With Direct mode selected, a webpage loading does not prove that the proxy connection is working.

Connection details for Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard, and other protocols belong to the server protocol layer. They are separate from the conditions that determine when to connect. If the address, port, or authentication details for your existing service are invalid, fix those first; adding On Demand conditions won’t make the protocol configuration valid.

Test four network states instead of checking the switch once

Change one setting per round. After saving, return to the relevant network state and make a new request. The results below are acceptance criteria for the example setup, not a promise of how every device will behave. Connections may take time to re-establish after a network switch, so don’t rely on the status icon at the instant of the switch.

If the VPN reconnects soon after you disconnect it manually, first check whether On Demand is still enabled and whether the current network continues to match a Connect condition. The system reconnecting when conditions match doesn’t mean the app ignored your action. To stay disconnected temporarily, turn off On Demand before disconnecting from Home. When you’re ready to resume, re-enable it using your saved settings.

FAQ: Auto-reconnect, domains that don’t trigger, and partial failures