Shadowrocket Settings and Features

In Config, select the file currently in use and inspect its Rule section. Rules are generally evaluated from top to bottom, and the first match determines how a request is handled. Put narrow exceptions first, followed by broader rules, and place FINAL last as the fallback policy when no earlier condition matches. After editing and saving, make sure the file is active.

Understand rule order with a minimal example

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

This example illustrates syntax only. For account.example.com, the first rule matches and applies DIRECT. The second rule matches other domains under example.com; all remaining requests fall through to FINAL. If the second rule comes first, it will match earlier and override the exact-domain exception. This example is not a complete configuration for every network.

If traffic is routed unexpectedly, first check that Global Routing is set to Config, then inspect the matching rule and its policy. Don’t change DNS, servers, and rule order all at once before confirming which rule matched. For more on configuration structure, address ranges, and rule priority, see the configuration field reference.

In Settings, open On Demand and review the listed triggers and exceptions before enabling or changing them for your use case. Available network conditions depend on the options shown in the app. For your first setup, start with a simple condition and test it, then add network exceptions one at a time. This makes it easier to identify which condition affects unexpected connection behavior.

For example, if you want a connection to start automatically on certain networks, first make sure a regular manual connection works. Then enable the relevant On Demand condition. Switch to a network that meets the condition and check the system and in-app connection status. On Demand won’t fix an unavailable server or supply a missing password, certificate, or rule.

If the connection starts again after you disconnect manually, check whether On Demand is still enabled and whether the current network meets its trigger conditions. To pause automatic connections, adjust On Demand first, then check the connection switch. Changing Global Routing to Direct does not disable automatic connection conditions.

DNS: check resolution and the connection route together

DNS resolves domain names to addresses used for connections. Check DNS in the relevant Settings options and the active Config. First see whether the configuration specifies a resolver, then decide where to make a change. Don’t cycle through multiple DNS addresses just because one domain won’t open. Verify the server connection first, then check whether resolution succeeds and returns the expected result.

Use a resolver you have confirmed is reachable and suitable for your needs, and keep a record of the original value. The route used for DNS requests is not the same as the final connection policy; successful name resolution does not guarantee a successful connection. After making a change, test with a new request and reconnect if needed to avoid interference from cached results or existing connections. For parameter details, see the configuration fields.

Test Method: keep test conditions consistent

Test Method selects how server tests are run. Open the corresponding option in Settings and choose from the options currently shown. When comparing servers, use the same method and test target; results from different methods are not directly comparable. A test reflects performance under specific conditions, not a complete measure of connection quality.

If test results don’t match actual access, note the method, test target, and current Global Routing mode, then verify with a real request. Don’t keep changing conditions just to get a lower test value; doing so makes troubleshooting less reliable. Testing is only one diagnostic step—check authentication, rules, and DNS separately.

Today Widget: quick access

Today Widget provides quick actions or a status view. Check the related options in Settings, then use the system’s editing controls to add an available widget. Its appearance and availability depend on the current system and the options described in the app. After adding it, confirm that it points to the Config or server you’re using; the widget’s display alone doesn’t prove the destination is reachable.

If the status doesn’t update promptly after you start a connection from the widget, return to the app and check the actual state. On Demand may still reconnect when its conditions are met, so disconnecting once from the widget may not disable automatic connections. Use the app’s status and an actual request to verify network behavior.

iCloud: sync and separate backups

iCloud syncs data supported by the app when the account and system conditions allow it. Check the iCloud options and in-app guidance in Settings, and confirm that iCloud is available in system settings. Organize your current configuration before enabling sync, then check what appears on another device. Don’t assume every server, subscription, rule, and local statistic will sync in the same way.

Sync does not preserve version history. Deletions or unwanted changes may also propagate to other devices, so export important Config files separately and store them safely. Backup files need protection too if they contain subscription URLs or authentication details. When moving to another device, confirm that app access, sync, and configuration recovery are each complete before connecting; don’t overwrite an existing configuration without checking its contents.

Diagnostics: test one hypothesis at a time

Diagnostics helps collect or review information related to connection issues. Open the relevant option in Settings and use the tools currently available to check the network, name resolution, or connection. First write down the conditions needed to reproduce the issue, such as “same server, Config mode, request to one domain fails,” then run the relevant test. Changing the server, DNS, and rules all at once makes the results hard to compare.

If you need to save diagnostic results, keep only the parts relevant to the issue and check for subscription credentials, authentication details, browsing records, or personal addresses. When describing the issue to someone else, use domain names and field names to explain what happened; don’t share sensitive details in full. After troubleshooting, restore temporary changes and verify everyday access again.