Shadowrocket Features and Settings

What it does: Global Routing determines how the app handles connections it intercepts. Config applies the active Config, Proxy routes traffic through Proxy, and Direct uses Direct. This is separate from choosing a server in Home: the routing mode determines how traffic is routed, while the server selection determines which connection details are used when traffic is proxied.

Where to find it and how to set it: Open Global Routing in Home. For routing traffic by domain, address, or other conditions, select Config and check which file is active in Config. To compare whether a request is affected by routing rules, temporarily switch to Proxy or Direct. Restore the original mode after testing so the troubleshooting setting does not become your long-term setup.

Keep in mind: Selecting Proxy will not fix an incorrect server password, and selecting Config will not create suitable rules for you. Direct is a routing choice within the app; it does not turn off the system VPN connection. For a useful comparison, record the mode, selected server, and destination, and start a new connection where possible. Existing connections may not switch routes immediately when you change modes.

What they do: Rules define matching conditions; policies define what happens when a rule matches. They are not interchangeable. DOMAIN matches an exact domain, DOMAIN-SUFFIX matches a domain suffix, and DOMAIN-KEYWORD matches a keyword in a domain. IP-CIDR and IP-CIDR6 match IPv4 and IPv6 address ranges, respectively; GEOIP relies on IP location data. USER-AGENT depends on request information being available and should not be treated as a reliable way to identify every app.

Where to find them and how to set them: Open Config, select the active file, and review its Rule section. Rules are generally evaluated from top to bottom, and the policy for the first matching rule is applied. Put specific exceptions before broad conditions, and define FINAL at the end. Adding rules to a file that isn’t active will not change how current connections behave.

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

This example illustrates rule order only: example.com matches DIRECT first; ad.example.com matches REJECT first; other domains matching the example.com suffix use PROXY. This is not a universal configuration. Check it against your actual destinations before applying it.

Keep in mind: PROXY uses the proxy route, DIRECT connects directly, and REJECT blocks matching requests. REJECT does not inspect page content, so a domain rule cannot distinguish different content hosted on the same domain. Address-based rules may also depend on DNS results. If traffic is routed incorrectly, first check which rule actually matched rather than adding more similar conditions. Save the configuration, confirm it is active, and then make a new test request.

For more on configuration sections and protocol settings, see the protocol reference and the .conf file structure guide.

What they do: A server entry stores connection details such as address, port, protocol, and authentication. Subscribe retrieves and updates a set of entries from a subscription source you already have. The server list and Config serve different purposes: the former supplies connection endpoints, while the latter defines routing and other behavior. Updating a subscription does not mean the rules file has also been updated.

Where to find them and how to set them up: Manage servers in Home. If you already have details for a single server, open Add Server, choose the matching server type, and enter the required fields. If you already have a subscription, choose Subscribe under Add Server, paste your complete subscription URL, and save it. You can also import your own details with Scan QR Code. After importing, open the entry and verify its details rather than relying on its name alone.

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard, and other types use different fields. Don’t put a Password from one type into an authentication field for another, and don’t infer the protocol from the port alone. TLS, server name, and transport fields should match the server’s requirements. If details are missing, confirm the original parameters instead of trying random combinations.

After updating Subscribe, check whether entries were added, removed, or renamed, then confirm that the server selected in Home is still the one you expect. Changes to subscription-generated entries may be overwritten by a later update. Before keeping your own edits, confirm who manages those entries and retain the original information so you can restore it if needed.

Keep in mind: Subscription URLs may contain access credentials, and QR codes may include complete authentication details. Don’t share them publicly or include them in screenshots. A failed subscription update is different from a failed server connection: for the former, check the subscription URL and whether it is accessible; for the latter, check the specific server settings. A successful latency test only confirms a result under those test conditions. It does not guarantee access to a destination, sustained throughput, or stable long-lived connections.

What it does: On Demand uses conditions supported by the system to trigger connection behavior, reducing the need to toggle the connection manually each time. It controls when a VPN connection is established or handled; Rule controls the route requests take after the connection is established. The two features can work together, but they are not the same switch.

Where to find it and how to set it up: Find the On Demand options in Settings. Review the existing conditions, then configure the options available in the interface, such as network type or network identifier. Before using it, confirm that manual connections, Global Routing, and the selected server all work. Then add one clear condition, save it, and check the result on the matching network.

For example, to treat a particular Wi-Fi network differently from others, verify its actual network identifier and check the order of the conditions. During testing, note the current network, expected action, and actual system state. If you keep manually disconnecting without changing the trigger condition, the system may reconnect while that condition remains true. That does not necessarily mean disconnecting failed.

Keep in mind: On Demand does not mean the app stays in the foreground, and it cannot ensure service will be restored if a server fails. Network changes, system policies, and server status can all affect the result. To temporarily stop automatic triggers, check both On Demand in the app and the system VPN settings so they do not conflict. Change only one trigger condition at a time while troubleshooting.

What it does: Data shows traffic statistics provided by the app. Use it to help determine whether a test generated traffic and whether upload and download changes match your expectations. These figures are not a service provider’s billing records, and a cumulative total alone cannot show that every request went through the proxy.

Where to find it and how to use it: Open Data and check what is being counted, the time range, and the counting method. Record the values before testing. Then visit one specific destination and return to the same view to check for changes. If the interface offers a reset option, save any figures you need before deciding whether to reset. Resetting local counters does not reset records kept by a service provider.

Keep in mind: Background tasks, media preloading, retries, and protocol overhead can all affect the results. Figures from different views may cover different scopes and should not be added together or treated as interchangeable. To determine the route taken by a particular request, check connection logs and the matched policy instead of relying on an increase in Data alone. For service usage, refer to the metering details for the service you already use.

DNS: how resolution interacts with routing

What it does and where to find it: DNS translates domain names into addresses needed for connections. Related options may appear in Settings and under General in the active Config. DNS is separate from Global Routing and cannot replace correct rules or server details.

How to set it and what to watch for: Record the current DNS settings first. Check that the address or resolver format is valid and reachable, then change one setting and test the same domain again. Don’t combine multiple settings from unknown sources. DNS caching, differences between IPv4 and IPv6 results, and address-based rules can all affect the route. A destination opening in a browser does not, by itself, prove that the app used the expected DNS. If a domain fails while connecting to its address works, consider DNS as one possible cause rather than assuming the server is unavailable.

Test Method: interpreting test results

What it does and where to find it: Check Test Method and its related parameters in Settings. These options determine how connection tests are performed. Connectivity Test in Home checks how a server responds under the selected test method.

How to set it and what to watch for: Choose a method as described in the interface, then compare results using the same test destination and similar network conditions. Different methods test different layers, so their numbers cannot be ranked directly. A successful connection to a port does not mean authentication, TLS, and the destination request all succeeded; lower test latency does not mean faster downloads. If the test destination itself is unreachable, check the destination before deleting server entries in bulk.

Today Widget: access and system limitations

What it does and where to find it: Today Widget is an entry point for widget-related features, such as shortcuts or information currently supported by the app. Check the available options in Settings, then see whether the widget can be added from the system’s widget management screen.

How to set it up and what to watch for: Choose what to display from the options available in your system and app, then return to the app to check that the status matches. Widget types, refresh frequency, and interactions depend on system support, so layouts may differ across devices. Widgets may take time to refresh; when troubleshooting a connection, rely on the actual status shown in the app and system settings.

iCloud: sync scope and recovery limits

What it does and where to find it: Check iCloud sync or backup options in Settings, and confirm in system settings that the app is allowed to use iCloud. These options cover data explicitly supported by the app; they do not restore an App Store purchase.

How to set it up and what to watch for: Read the description of the current options and check what will sync before enabling them. Wait for syncing to finish. Before switching devices, keep a separate backup of anything important. After restoring, verify your servers, active Config, and toggle states one by one; don’t assume everything transferred completely. Deleting or replacing data may affect synced content, so check the direction and scope first. Server passwords, subscription URLs, and configuration files may contain sensitive information, so limit access when exporting or syncing them too.

What it does: Diagnostics provides information or tools to help break “can’t connect” into more specific stages: whether the current network works, whether a domain resolves, whether a server accepts a connection, and which policy a request matches. Diagnostic records are clues for troubleshooting, not a button that automatically fixes every setting.

Where to find it and how to use it: Look for Diagnostics in Settings and use the tools and logging options available there. Note the time the problem occurred, network type, Global Routing mode, active Config, and selected server, then reproduce the issue once. If you need additional logging, collect only what is necessary and restore the previous logging settings when you’re done.

Check one layer at a time: first confirm that the current network can reach a known working destination; next test the server connection; then check domain resolution; finally review rules and policies. If the destination works in Proxy mode but fails in Config mode, start by checking the matched rule and its policy. Make sure the server and network stayed the same during both tests before drawing a conclusion from the mode difference alone.

Keep in mind: Diagnostic data may include visited domains, addresses, subscription details, or authentication fields. Remove sensitive information before sharing and keep only what is needed to explain the issue. Don’t publish a complete configuration, subscription URL, or QR code. If a failure occurs intermittently, repeat the test under the same conditions; a single timeout does not establish long-term reliability.

1. Check your inputs. Verify the server type, address, port, and authentication fields. Confirm that Subscribe updated the expected entries.
2. Check routing. Review Global Routing in Home. If you use Config, also check the active file, rule order, and FINAL.
3. Check the connection. Review the connection status in the app and system, then make a new request to the same destination to avoid misreading a reused connection.
4. Check the results. Compare connection logs, Diagnostics, and Data. Change one variable at a time and keep a way to revert each change.

Start by testing a manual connection; it’s easier to isolate problems than to enable automatic triggers, change DNS, and rewrite rules all at once. For the full first-time setup process, read the Shadowrocket getting started guide. To understand latency results, read latency tests and real-world performance.