Shadowrocket On Demand Setup: Automatic Connections for Wi-Fi, Cellular, and Domains

On Demand controls connections; Config controls routing after connection

Shadowrocket’s On Demand feature uses the system’s on-demand VPN mechanism to decide whether to start a connection based on network conditions and connection evaluation. It doesn’t periodically tap the connect switch in the background or create a separate VPN for each website. Go to Settings → On Demand. The conditions you can edit depend on the current app interface.

On Demand determines whether to establish a tunnel. Global Routing determines how traffic is handled once it’s established. Proxy routes all traffic through the proxy; Direct routes all traffic directly; Config matches traffic against the current configuration; and Scene applies the selected scene’s settings. To test rules such as DOMAIN-SUFFIX in a configuration, first make sure Global Routing is set to Config. Don’t troubleshoot these two layers as if they were one.

• Home: Make sure the selected connection profile is valid and that a manual connection works.
• Config: Check which configuration is active and confirm the rule order. Make sure you’re not editing a file that isn’t selected.
• Settings → On Demand: Choose when the system should attempt to connect. Proxy protocol credentials aren’t entered here.

This guide assumes you already have your own provider and subscription. On Demand can’t fix expired connection details or automatically update an invalid subscription URL. If a manual connection doesn’t work, resolve the underlying connection issue before enabling automation.

Before you begin: establish a manual connection and a fallback

When setting this up for the first time, leave automation off. Connect manually once and allow the system to add the VPN configuration, then return to Settings → On Demand. While testing, avoid changing the server, DNS, Global Routing, and On Demand conditions at the same time. Otherwise, a single failure could have several possible causes.

1. In Home, select a valid connection profile you already have and turn on the connection switch manually.
2. Choose Global Routing based on what you’re testing. To verify configuration-based routing, select Config.
3. Visit a page you use regularly and note the current network type and whether the connection works.
4. Go to Settings → On Demand, add just one set of network conditions, and then enable On Demand.
5. Switch between Wi-Fi and cellular once, then check the connection status in Home and the system VPN status.

Know how to stop automatic connections

To turn off automation, first disable On Demand in Settings → On Demand, then disconnect manually. Turning off the connection switch in Home alone may not be enough: the system could reevaluate the On Demand rules after a network change. Search for “VPN” in system settings to find the VPN controls. Managed devices may also be subject to organizational policies.

If your iPad doesn’t support cellular, you only need to test the Wi-Fi conditions. Check the App Store listing for system requirements. The absence of cellular network switching on a device doesn’t mean the cellular conditions are faulty.

Wi-Fi and cellular rules: specific conditions first, general conditions next

A network condition typically consists of an interface type, an optional Wi-Fi name, and an action. The example below keeps the tunnel off on your home Wi-Fi while connecting automatically on other Wi-Fi networks and cellular. Home-WiFi is an example SSID. Replace it with the name of the Wi-Fi network your device actually joins; it isn’t your router’s admin address.

The English keys above illustrate system On Demand conditions; they don’t necessarily appear verbatim in the app. Configure them using the Wi-Fi, cellular, and action options available in the current interface. Don’t paste these keys into ordinary traffic-routing rules in Config.

Check the SSID’s capitalization, spaces, and exact network name. Different bands on the same router may use different names, and a guest network may have its own SSID. Matching an SSID only checks its name, not whether the network is trusted, so a match to your home network name isn’t a security check.

Domain-based On Demand connections: not another way to write DOMAIN-SUFFIX

Domain-based On Demand is part of the system’s connection evaluation mechanism. At the system level, EvaluateConnection can be used with domain conditions and ConnectIfNeeded. This doesn’t mean the VPN must reconnect every time you visit that domain. If the current network can resolve the domain and satisfy the connection evaluation, the system may not start the VPN. Caching, existing connections, and how an app resolves domains can also affect what you observe.

The example below shows the structure of system On Demand rules and how Action, Domains, and DomainAction relate to one another. It’s an illustrative property list snippet, not a Shadowrocket Config file or an importable configuration. Set it through the interface only if the current On Demand screen offers the corresponding domain evaluation options.

<dict>
  <key>Action</key>
  <string>EvaluateConnection</string>
  <key>ActionParameters</key>
  <array>
    <dict>
      <key>Domains</key>
      <array>
        <string>example.com</string>
      </array>
      <key>DomainAction</key>
      <string>ConnectIfNeeded</string>
    </dict>
  </array>
</dict>

• EvaluateConnection: Starts connection evaluation; it doesn’t unconditionally run Connect.
• Domains: Specify the domains to evaluate. Don’t enter a full URL, path, or port.
• ConnectIfNeeded: Attempts to connect when the system’s evaluation conditions are met. It doesn’t guarantee a connection every time you visit a domain.
• NeverConnect: Prevents a connection from starting as a result of evaluating the specified domain. It doesn’t disconnect an existing tunnel.

For example, example.com is a domain, while example.com:443 includes a port and shouldn’t be entered as the same domain condition. HTTPS commonly uses port 443, but On Demand domain matching doesn’t connect or disconnect based on that port. Visiting an IP address directly also won’t verify whether a domain condition matches.

Test network-based and domain-based rules separately

If an earlier rule applies Connect to all Wi-Fi networks, a later domain evaluation usually won’t get a chance to determine whether to start the VPN. Conversely, an earlier Disconnect could also prevent domain evaluation. Test domain evaluation on its own first, then add network restrictions. Don’t expect the system to combine multiple conflicting actions automatically.

After the tunnel connects: use Config to route traffic

If you want to keep the connection active but send only specific domains through the proxy, use Config to route traffic rather than repeatedly starting and disconnecting the entire tunnel. On Demand can connect automatically on cellular, while Config selects a route based on domain, IP, or region. These mechanisms can work together, but they aren’t interchangeable.

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

This snippet illustrates rule syntax; it isn’t a complete, ready-to-use connection configuration. DOMAIN-SUFFIX matches domain suffixes; IP-CIDR matches IP address ranges; GEOIP matches based on an IP geolocation database; and FINAL handles requests that didn’t match earlier rules. Apply these rules in the context of your existing configuration; don’t replace your entire Config with this example.

Troubleshoot one layer at a time. First check whether the system established a tunnel, then check whether Global Routing is set to Config, and finally inspect the specific routing rule that matched. If there’s no connection, changing FINAL won’t fix the On Demand trigger. If the VPN is connected but traffic takes the wrong route, check the configuration instead of repeatedly changing Wi-Fi conditions.

Testing and troubleshooting: change one condition at a time

Verify automatic connections by repeating the same network-switching steps. The steps below describe how to test and what to expect; they don’t guarantee connection times across all network environments. After switching networks, allow the system to finish evaluating the connection before checking its status. Don’t rapidly toggle the connection manually as soon as the network changes.

1. Test a specific Wi-Fi network: Join Home-WiFi and confirm that the Disconnect exception matches. If the VPN remains connected, check the SSID and rule order.
2. Test another Wi-Fi network: Switch to a Wi-Fi network with a different, known name and confirm that the general Wi-Fi Connect rule starts the connection.
3. Test cellular: Turn off Wi-Fi, confirm the device has a cellular data connection, and then check whether the VPN starts.
4. Test domain evaluation on its own: Temporarily remove any general action that would match first, disconnect an existing tunnel, and test the domain evaluation condition. Don’t draw conclusions just by repeatedly refreshing a cached page.
5. Test the fallback: Turn off On Demand, disconnect manually, and switch networks to confirm that no other automation or management policy starts the connection again.

When keeping the final working setup, note the actual SSID, rule order, Global Routing mode, and network type used for testing. Don’t share subscription URLs or credentials in troubleshooting notes. Before adding a new condition later, retest the current setup and add one rule at a time.