Shadowrocket Features and Settings

01 / ROUTING

Global Routing: Config, Proxy, and Direct

Global Routing determines how requests are routed and is usually accessed from Home. It is separate from the connection toggle and the currently selected server: the toggle controls whether the system VPN tunnel is active, the server provides a connection endpoint, and the routing mode determines how traffic uses those endpoints. Turning on the toggle alone doesn’t confirm that rules are working or that the server is reachable.

Open Global Routing and check whether Config, Proxy, or Direct is selected. Then use the table below to see whether it fits your test. These are the three English interface options—not three separate configuration files.

If Proxy can reach a destination but Config can’t, check the matching rule and its referenced policy first. If both fail, check the server settings and underlying network. This comparison helps narrow down the cause, but one result alone doesn’t prove what’s wrong. When testing is done, switch back to your usual mode so temporary changes don’t continue to affect traffic.

02 / RULES

Rule-based routing: match conditions and policies

Rule-based routing sends different requests to different policies. In Config, confirm which configuration file is active, then review its [Rule] section. With Global Routing → Config, rules are checked in order and the matching policy is generally applied. Put more specific conditions before broader ones, and place the fallback FINAL rule last.

A rule typically consists of a match type, a match value, and a policy. 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 address ranges, while GEOIP uses an IP geolocation database. USER-AGENT depends on request information being available; don’t assume it can identify all encrypted traffic.

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

This snippet illustrates syntax and rule order; it isn’t a complete file to replace your current configuration with. The first rule is more specific than the second: a request to ads.example.com matches REJECT first and won’t reach the suffix rule below it. DIRECT means a direct connection, REJECT blocks the request, and PROXY uses the proxy path. If a rule refers to a custom policy name, make sure that policy exists and is currently available.

Keep a copy of the original file before adding a rule, then change one clearly defined test target. Send the request again and check the connection log for the rule and policy actually used—don’t rely only on whether the page loads. Caching, requests to multiple domains, or existing connections can affect the result. To test a new match, start a fresh request to the target. Don’t change DNS, routing mode, and server settings all at once to verify a single domain rule.

03 / SERVERS

Subscribe and server management

Server entries store connection endpoints and authentication settings. Subscribe imports and updates a server list you already have. These are separate from rule configuration: importing servers doesn’t mean the right Config is selected, and downloading a rule configuration doesn’t provide usable server details. Before you begin, identify whether you have a subscription URL, an individual server entry, or a configuration file.

Subscribe: import an existing subscription

If you already have a subscription, use the Subscribe option on the Config page, as shown in your current interface, to enter its address and import or update it. After importing, return to Home and check that the server list, groups, and names look right. Select an entry and test the connection. A successful update means the content was retrieved and processed; it doesn’t mean every server can connect.

If an update fails, check that the address is complete, the subscription is still valid, and the current network can reach it; then review the specific error. Avoid repeatedly deleting and re-adding it, which can remove existing groups and useful troubleshooting context. Updates may overwrite fields managed by the subscription. If you need to make local changes, note what you changed and consider how the next update may affect them.

Add Server: check each setting

If you have details for an individual server, use the add option on Home to open Add Server. Choose the protocol, then enter the address, port, and relevant authentication fields exactly as provided. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different fields; don’t copy one protocol’s settings into another protocol’s form. TLS, SNI, and the transport method must also match the server configuration.

If you already have a QR code or a supported link, use Scan QR Code or the clipboard import option shown in the interface. After importing, check the protocol, address, and key fields. Don’t share QR codes, subscription URLs, or complete server entries that contain authentication details. Connectivity Test can help identify entries to check, but a passing test doesn’t replace verifying access to the services you need.

04 / ON DEMAND

On Demand: connect when conditions are met

On Demand uses the system VPN’s on-demand connection mechanism to connect when configured conditions are met. It isn’t a general fix for server problems, nor does it guarantee that all app traffic will use the proxy. How requests are handled still depends on Global Routing, the rules, and the selected server.

Find On Demand in Settings, review the available network conditions, and decide whether to enable it. First test a manual connection: confirm that the system VPN configuration is authorized, the selected server is available, and the current Config is correct. Verifying the manual connection first makes automatic connection behavior easier to assess.

After enabling it, test the connection behavior while switching between the Wi-Fi and cellular networks you actually use. Note which conditions trigger a connection and which leave it unchanged. If the connection turns back on soon after you turn it off, check On Demand and the system’s VPN on-demand settings before assuming the toggle is faulty. To temporarily disconnect for an underlying network test, pause the relevant on-demand conditions too, then restore them afterward.

Available network conditions may differ between iPhone and iPad depending on device capabilities, the system, and the current interface. Don’t assume settings from one device will work the same way on another. A VPN indicator alone doesn’t confirm that the connection was triggered as intended; also check the connection state, access results, and policy in use.

05 / DATA

Data: review traffic records and changes

Data displays traffic and connection information recorded by the client. Open Data and check the reporting period, items included, and start and end conditions before reviewing upload and download changes. Totals on different screens may use different calculation methods. Don’t treat the client’s cumulative total as the server-side account balance or remaining allowance.

For troubleshooting, note the current figures, perform one specific action—such as opening a particular webpage—and return to check the new records and traffic changes. If a record shows a destination, policy, or connection status, compare it with the current Global Routing mode and rules. Avoid running large background transfers during the test, or it may be difficult to associate new traffic with your request.

If the current interface offers a clear or reset option for statistics, save any troubleshooting information you need before using it. Clearing local records doesn’t change server-side billing. Check whether statistics remain continuous after the app goes to the background, the connection is re-established, or the device changes networks. A single increase or decrease in traffic doesn’t by itself prove anything about speed, battery use, or server stability.

06 / SETTINGS

Settings: DNS, tests, and sync

DNS: distinguish lookup issues from connection issues

DNS resolves domain names to addresses, which can affect subsequent connections and some address-based rules. When reviewing DNS options in Settings, also check the active Config for DNS settings so you don’t change one source while overlooking another. Note the current values first, then determine whether the issue is limited to name resolution or whether the connection also fails after resolution.

Before making changes, check that the address and format are supported by the current interface, and that the resolver is reachable on your network. Don’t add multiple settings from unknown sources just to experiment, or treat DNS changes as a fix for every timeout. After changing a setting, send the same request to the same domain and compare the resolution result and connection log. Existing cache entries may hide the effect in a single test.

Test Method: keep tests comparable

Test Method determines how connection tests are performed. Check this setting in Settings, then use Connectivity Test. Different methods and targets may produce values with different meanings; a failed test doesn’t necessarily mean all real-world requests will fail. When comparing servers or networks, keep the test method, target, and network conditions as consistent as possible.

A connectivity test helps narrow down a problem; it isn’t a full throughput test. A lower test time doesn’t guarantee faster large-file transfers, and a timeout needs to be considered alongside actual access, protocol settings, and server status. If you change Test Method, note the old and new options so a change in test conditions isn’t mistaken for a change in server performance.

Today Widget: quick access and status checks

Today Widget provides quick access through the system widget interface. Check the related settings in Settings, then add an available widget using the method supported by your current system. Whether the system offers this entry point and which actions the widget supports depend on the device’s actual interface; don’t assume every system version behaves identically.

After starting an action from the widget, return to Home to check the connection result. The widget display, system VPN status, and in-app records may not update at the same time. If the display hasn’t changed, check the actual status in the app first, then review the widget settings. Avoid tapping repeatedly, which can trigger multiple connection changes.

iCloud: distinguish local data from cloud data before syncing

Review the iCloud sync or backup options in Settings and check which data they include in the current interface. Before using them, confirm that you’re signed in to iCloud, the app has permission to use it, and enough storage is available. Keep a copy of your local configuration before the first sync. If cloud and local data differ, identify which copy you want to keep before importing, restoring, or overwriting anything.

Don’t assume that all sensitive fields, system VPN authorization, or local records will transfer through sync. After moving to another device, check the server details, active Config, Global Routing mode, and initial VPN authorization. Restoring an App Store purchase to get the app again is separate from syncing configuration. See Restore Purchases for purchase details.

07 / DIAGNOSTICS

Diagnostics: keep troubleshooting reproducible

Diagnostics collects and displays diagnostic information. Find it in Settings and choose the available checks or logging options shown in your interface. Note the network, destination, time frame, and steps to reproduce the issue before running diagnostics; this gives the results useful context. Diagnostics don’t fix problems, and a single error line can’t rule out every other cause.

1. Keep test conditions consistent. Note the current server, Config, and Global Routing mode, then choose one request that reliably reproduces the issue.
2. Check the underlying network first. Confirm that Wi-Fi or cellular service is working, then check system VPN authorization and connection status.
3. Isolate one setting at a time. Check server details, rule matches, DNS, and connectivity tests separately; don’t change everything at once.
4. Retest and restore. After changing one setting, repeat the same request and record the result. Restore temporary routing modes and diagnostic settings when you’re done.

Before keeping or sharing diagnostic results, check for subscription URLs, authentication fields, server addresses, domain names, or other private information. Share only what’s needed to investigate the issue. No obvious errors in the log doesn’t mean every part of the connection has been verified; use the symptoms to find the relevant section in the Troubleshooting guide.

A reliable way to work with settings is to note the current value, change one thing at a time, and reproduce the result. If you only need to look up an English interface term, see the Glossary. For the full process from importing a configuration to the first connection, return to Getting Started—there’s no need to enable every feature on this page at once.