Shadowrocket Features and Settings

Global Routing determines how requests are routed and is usually accessed from Home. It is separate from the currently selected server: selecting a server does not mean every request will use it. Whether a request takes the proxy route depends on the active mode and the matching rule. Use Config for everyday rule-based routing, Proxy temporarily to check the selected server's basic connectivity, and Direct to test direct access on the current network.

Before changing modes, note the current setting. Choose the mode you need, then return to Home to confirm the server selection and connection toggle. Restore the intended setting when testing is complete. A mode change applies to subsequent requests; existing connections may retain their previous state. To verify a change, make a new request and, if needed, reconnect. Don't rely on a page that has been open throughout the test.

Rules define what to match; policies define what to do when a rule matches. In Config, select the configuration you want to use, then review or edit its rules. Rules are generally evaluated from top to bottom, and the policy on the first matching rule is applied. FINAL determines how requests that match no earlier rule are handled. Put more specific rules before broader ones, and don't assume a domain is covered just because it appears somewhere in the file.

Common Rule Types

DOMAIN matches an exact domain; DOMAIN-SUFFIX matches a domain and its subdomains; DOMAIN-KEYWORD matches a keyword in the domain. IP-CIDR and IP-CIDR6 specify IPv4 and IPv6 address ranges, respectively. GEOIP matches based on the geographic location associated with an IP address. USER-AGENT relies on information available in the request and is not a universal match condition for all encrypted traffic.

PROXY, DIRECT, and REJECT

PROXY routes matching traffic through a proxy, DIRECT uses a direct connection, and REJECT blocks matching requests. A configuration may also refer to a named policy or policy group. Check that the target exists, its name matches, and the current selection is correct. Proxy in the interface is a mode name; PROXY in a rule is a policy keyword. Keep each in its original form when editing.

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

This is an example of rule order, not a complete configuration file for everyday use. The DOMAIN-KEYWORD,ads entry is only an example of keyword matching and may match domains you didn't intend. Check its scope before editing. Keep a copy of the original configuration, change one rule type at a time, and test with a new request. Avoid changing rules, DNS, and server settings all at once, or it will be harder to identify the cause of a problem.

Server entries store connection details such as address, port, protocol, and authentication. A subscription lets you manage a group of entries in one place. The steps below assume you already have your own subscription or server information. Use Home to view, select, and manage servers; Add Server to add an entry; and Scan QR Code to read supported QR code content. Before importing, identify whether the content is a subscription URL, a single-server URI, or a configuration file containing rules. These formats are not interchangeable just because their links look similar.

When adding a server manually, check Type first, then enter the address, port, and protocol-specific settings. For example, Shadowsocks, VMess, VLESS, and Trojan have different authentication and transport requirements. HTTP and SOCKS5 types must also match the server information you have. Don't guess settings from a name or remove TLS, transport, or certificate fields just to make the entry save.

Subscribe vs. Configuration Files

Subscribe on the Config page is for the relevant configuration subscription operation. To manage server subscriptions, use the server subscription import entry or another supported import method. Check the result after importing: server entries should appear in Home, while rule configurations should appear in Config and be enabled as needed. If parsing fails, first check the input type and make sure the URL is complete. Don't repeatedly import the same content into different places.

Refreshing a subscription updates the entries provided by its source; it does not necessarily change the rules in your current configuration. After refreshing, check that the selected server is still available, look for duplicate entries, and confirm you can still identify custom labels. Before deleting an old subscription, make sure you know which entries it contains so you don't remove a manually added server you still use. Treat subscription URLs containing authentication details, QR codes, and server information as sensitive. Don't post them in public discussions.

On Demand triggers connection behavior when specified conditions are met. It does not select a rule policy or replace checks for server availability. Find the On Demand options in Settings and review the network conditions available in your interface. First verify the server and rules with a manual connection, then add automatic triggers. This makes it easier to tell whether a problem is with the service itself or an unmet connection condition.

Specify the Wi-Fi or cellular network conditions under which you want a connection, then check each condition, its scope, and the saved result. Test again on both the target network and a different network, and confirm the system's connection status matches your expectations. Network options may differ between iPhone and iPad. Use the options available on each device rather than copying conditions from another device.

With On Demand enabled, disconnecting manually may not keep the connection off: it can reconnect when the conditions are met again. To pause automatic connections temporarily, check On Demand rather than repeatedly toggling the connection on Home. Battery use can't be attributed to this option alone; consider traffic, server reconnections, signal strength, and background activity. You can disable automatic triggers while changing rules or troubleshooting, then re-enable them after testing.

Data shows traffic recorded by the client. Open Data and first check the reporting period and how the figures are counted, then review sent and received traffic. These figures can help confirm that data is flowing after a connection, but they can't prove on their own that a specific request used the intended policy. To verify the route for a particular request, check rule-match information or available connection records.

To check traffic, note the current figures, make a specific request, then return to see what changed. Background apps, system services, and existing connections can all generate traffic, so don't attribute every short-term increase to a page you just opened. Before clearing counters, save any records you need and check what the reset affects. Figures from different reporting periods aren't directly comparable by subtraction.

Data is not a server account balance or a carrier bill. Server-side figures may use different billing methods or time ranges, or include additional overhead. If the numbers don't match, first compare how each is calculated. If the connection appears active but traffic is not as expected, check the selected server, Global Routing mode, whether you made a new request, and whether a DIRECT rule bypassed the proxy route.

Settings brings together options for app behavior and tools. Before making a change, check whether the active configuration also defines the relevant parameters; a global setting may not be the only one in effect. The sections below explain each option by purpose. Menu locations and available values depend on the interface on your device. Save and verify each change, and keep the original value so you can revert it.

DNS: Domain Name Resolution

DNS translates domain names into addresses that can be reached. Review DNS options in Settings and check the DNS content in the active Config. When troubleshooting, distinguish a domain resolution failure from a connection failure after an address is returned. If the server uses a domain name, its resolution can also affect connection setup. Before entering a custom DNS address, check its format, reachability, and suitability for your use case. Changing DNS is not a fix for every issue.

For IPv6, local network domains, or different network environments, check whether the resolved addresses work on the current network. After changing DNS, make a new request and reconnect if needed, keeping cached results in mind. Don't disable certificate verification as a substitute for DNS troubleshooting. Certificate, domain, and routing errors need to be addressed separately.

Test Method: Connectivity Test Options

Test Method selects how connectivity is tested and can be found in Settings. After choosing a method, run Connectivity Test from Home and interpret the result in that context. Different methods check different parts of the connection, so their reported times shouldn't be compared directly. The test target, current network, and server status can all affect the result.

A successful test only confirms that the corresponding connection path worked under those test conditions. It doesn't prove that every site, DNS setting, or rule is correct. If a test fails, first check that the selected method suits the test target, then review the server parameters and network status. For a useful comparison, test on the same network with the same method. Don't change several settings in a row and rely only on the final result.

Today Widget: Quick Access and Controls

Today Widget settings control what a system widget can display or do. Check the relevant options in Settings, then add the widget where your system allows. Availability, appearance, and refresh behavior depend on what your system and device support. Widgets are useful for quick everyday actions; use the app for full configuration.

Widget updates may follow the system's refresh schedule, so an outdated status isn't proof of the current connection state. If the status looks wrong, open Home and check the connection and selected server. Choose what appears on the Lock Screen based on your privacy preferences.

iCloud: Sync and Moving to a New Device

Check the iCloud options in Settings and confirm in system settings that the app has permission to use the relevant features. Before syncing, review which items the interface explicitly lists. Don't assume servers, configurations, all settings, and usage records will all sync. Before switching devices, check that important content is actually available on the new device and save any necessary backups.

iCloud sync and restoring an App Store purchase are separate processes: the former concerns app content, while the latter restores your eligibility to get the app. After moving to a new device, check your server information, enabled configurations, and system connection permissions. For purchase records and the restore process, see how to restore a previous purchase.

Diagnostics offers tools to help narrow down issues and can be found in Settings. Before running a check, note the network, selected server, Global Routing mode, and configuration name. Use the checks available in your interface. Diagnostic output helps narrow the scope of a problem, but doesn't guarantee an automatic fix. Compare the results with what you actually observe rather than assuming one status message confirms every setting is correct.

Use the sequence below to build a minimal verification path. Change one factor at a time and keep a record of the results before and after each change. If access works temporarily in Proxy but fails in Config, check the rules, policy targets, and configuration first. If both fail, check the server information, DNS, and current network. Direct only reflects direct access conditions; it can't establish that the proxy server is working.

1. Check the basics. Confirm the current network can establish a connection, system permissions are set, and Home has the expected server selected.
2. Test the server. Run Connectivity Test using the same Test Method and check the address, port, authentication, and protocol settings.
3. Check routing. Confirm Global Routing, then check the enabled file in Config, rule order, and the FINAL target.
4. Check DNS. Distinguish a resolution failure from a connection failure, note the current DNS settings, and change one setting if needed.
5. Make a new request. Review Data and any available connection records, and rule out stale connections or cached results.

Before sharing diagnostic information, check for subscription URLs, authentication details, server information, or browsing records, and remove anything sensitive. When describing a problem, include the conditions, steps taken, actual result, and expected result. This is more useful for reproducing and diagnosing an issue than simply saying “can't connect.”