FEATURES / SETTINGS
Shadowrocket
Features & Settings
Choose how requests are routed before adjusting connection and diagnostic settings. Change one type of setting at a time, and check the result using the same destination.
This page is a feature guide in the Shadowrocket manual, focused mainly on iPhone and iPad. Menu paths and available options may vary; refer to the English labels shown on your device.
01 / ROUTING
Global Routing: Config, Proxy, and Direct
Global Routing is the main entry for choosing how requests are handled, and is usually accessed from Home. Config, proxy, and direct routing correspond to Config, Proxy, and Direct. These modes determine traffic routing; they do not create servers or fix incorrect server settings. Before choosing a mode, make sure your existing server details have been imported and that the selected server is the one you intend to test.
| Mode and interface label | How it works | When to use it | What to check |
|---|---|---|---|
Config Config | Uses the active configuration file and its rules to determine the policy. | Everyday routing by domain or address. | Check that the configuration is enabled, rule order is correct, and the target policy exists. |
Proxy Proxy | Handles requests in proxy mode; exact behavior depends on related app settings. | Temporarily check whether the selected server can reach a destination. | Check server settings, network reachability, and the destination’s response. |
Direct Direct | Handles requests directly, without using the selected proxy server as the usual exit. | Establish a baseline on the current local network. | Check local network access, DNS, and whether the destination itself is reachable. |
- In
Home, openGlobal Routing. Note the current selection, then switch to the mode you want to check. - Test the same destination on the same network. Don’t change the server and DNS at the same time, or you won’t know what caused the difference.
- If
Proxyworks butConfigdoes not, check rule matches and policy references first. After testing, restore the mode you normally use.
02 / RULE ROUTING
Rules & Routing: Match Criteria and Policies
Each rule specifies both which requests it matches and how to handle them. Find the rules in the configuration file currently in use under Config. Select Config in Global Routing, then check how the rules behave. Rules are generally evaluated from top to bottom, so put more specific conditions before broader ones. Once a request matches an earlier rule, later rules of the same kind won’t change that decision.
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 describe IPv4 and IPv6 ranges, respectively. GEOIP checks an IP address against a geographic database. Domain rules and IP rules apply to different targets, so seeing a webpage’s domain doesn’t prove that an IP rule will match.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
This example illustrates syntax only: example.com and its subdomains use PROXY; all other requests fall through to FINAL,DIRECT. DIRECT means a direct connection, REJECT rejects the request, and PROXY uses the proxy policy. If you reference a custom policy group, make sure that name exists in the configuration. This is not a complete configuration for every network and does not provide connectivity services.
- Back up your current configuration before editing. Add or adjust only the rules you need to check; don’t replace the entire file.
- Put precise exceptions before broader rules, and keep
FINALat the end of the rule list as a fallback. - Save the file and confirm it is active, then check the request log for the destination, matched rule, and policy.
What to check: A rule matching correctly doesn’t mean the destination server is reachable. If the request uses the expected policy but still fails, check the server, name resolution, and network instead of repeatedly adding the same rule. For more on syntax and rule order, see Rule Keywords and Match Order.
03 / SERVER MANAGEMENT
Subscriptions & Servers: Lists vs. Individual Server Details
Server management assumes you already have your own subscription or server details. Use the SERVER section on Home to view and select servers. Add Server adds an individual entry of the appropriate type, while Subscribe is for subscription-related actions. A subscription is an updatable list of servers; an individual share link usually describes one server. They are not interchangeable just because both are links.
Before importing, identify whether you have a subscription URL, an individual share link, or details to enter manually. In Add Server, choose the type that matches the source, then check the address, port, authentication, and transport settings. To use a subscription, add it and run an update from the relevant Subscribe entry; the exact menu location depends on the current interface. You can import a QR code with Scan QR Code, but successful scanning only means the contents were read—it doesn’t confirm that the settings work.
Authentication and transport fields vary across protocols such as Shadowsocks, VMess, VLESS, Trojan, and Hysteria2. For example, VLESS credentials cannot simply be entered as a password for another type. Whether TLS, a transport path, or a server name is required depends on the original server details you already have; don’t fill in missing values by guessing common defaults.
- Before updating an existing subscription, note the selected server and its group. Save a backup of your configuration if needed.
- After the update, confirm the list has refreshed and check that the previously selected entry is still there. Reselect entries that were removed or renamed.
- Run
Connectivity Testfirst, then try an actual connection. Record the test result and webpage outcome separately.
04 / CONFIG FILE
Config: Manage Configuration Files Separately from Server Lists
Config manages rules and related configuration; it serves a different purpose from the server list. Server details specify where and how to connect, while a configuration file specifies how requests are routed and which related settings to use. Updating a subscription does not necessarily update the active configuration file, and importing a configuration does not mean all server details are ready to use.
In Config, first check which file is active, then open that file to view or edit it. Keep a recoverable copy before making changes, and note the current Global Routing mode. Before adding a configuration from a source you already have, review its rules, policy references, and resolution settings so you understand what enabling it will do. Saving a file does not guarantee that every policy name resolves correctly.
What to check: After saving, confirm which file is marked active, make the same request again, and check the rule it matches. To roll back, restore the configuration file and related settings—not just the server name. For complex rule issues, use the Troubleshooting Manual to continue based on the symptoms.
05 / ON DEMAND
On Demand: Connect Based on Network Conditions
On Demand triggers connection behavior based on preset conditions. It’s useful once manual connections work and you want connections handled automatically on specific networks. It doesn’t guarantee that a server is available or fix configuration errors. Open On Demand in the app and review the available network conditions and actions; the options shown on your device are what matter.
- Turn off On Demand triggers first, then use the manual switch to confirm the server, routing mode, and access results are all as expected.
- Open
On Demandand enable only one type of condition at a time. If the interface lets you specify a Wi-Fi network or network name, make sure it exactly matches the current network. - Switch networks to meet or clear the condition, then observe the system’s connection status and access to the destination. Return to the original network and confirm that the connection behaves as expected there too.
Note: With On Demand rules enabled, manually disconnecting may trigger another connection, making the switch turn back on. If you need to stop the connection reliably, first check whether On Demand is still active. This behavior alone doesn’t mean the app is malfunctioning. Temporarily disable automatic conditions before testing a manual connection to avoid repeated state changes.
06 / DATA
Data: Check Traffic Changes and Request Activity
Data provides client-side traffic statistics and related logs for observing request activity and data changes. Before comparing values, check the statistics and time ranges and the units shown in the interface. Client-side records may use different accounting methods from your existing connection service, so don’t treat these figures as remaining allowance or billing data.
Start by noting the baseline in Data, then perform one controlled action, such as loading a specific webpage, and check the change. To investigate routing, use available request logs to check the domain, destination address, and policy. To assess speed, keep the network, server, and test destination the same. An increase in total traffic only shows that data moved; it doesn’t prove a particular page loaded completely.
What to check: Background tasks, system requests, and other apps can all generate traffic at the same time. Reduce unrelated activity while troubleshooting and note the statistics range before testing. Clearing records may erase useful clues, so save any needed information first. When describing an issue to someone else, share only the relevant test details and hide personal usage information, including sensitive details beyond the domain.
07 / SETTINGS
Settings: DNS, Tests, and Utilities
Options in Settings affect different parts of the app; they’re not a set of switches you should all turn on. First identify whether the issue involves name resolution, connectivity testing, shortcuts, configuration sync, or diagnostics, then open the relevant item. Menu locations and available options may vary by device and app interface; follow the English labels currently shown.
DNS: Separate Name Resolution from Connectivity
DNS resolves domain names to addresses. Check DNS-related items in Settings, and look for resolution settings in the active Config. If a latency test succeeds but a webpage won’t load, the issue could involve name resolution, TLS, the destination service, or rules; that symptom alone doesn’t confirm a DNS problem. Record the current DNS settings and test the same domain. If a change is needed, adjust only one related setting and keep a way to roll it back.
What to check: Don’t substitute a proxy server address, subscription URL, or DNS address for one another. If only some domains work after a change, check the policy matched by the affected domain and its resolution result. For a detailed process, see the DNS Resolution Troubleshooting Checklist.
Test Method: Know What the Test Measures
Test Method determines how connectivity or latency tests are performed and can be checked in Settings. Different methods test different parts of the connection, so their results shouldn’t be ranked directly against each other. Review the selected method and its target before running Connectivity Test. If you change methods, retest the same set of servers rather than comparing new results with old ones.
What to check: A fast response doesn’t guarantee fast sustained transfers, and a test timeout doesn’t necessarily mean every request will fail. Verify with the actual destination and note the routing mode used.
Today Widget: Shortcuts Depend on Your Current Configuration
Today Widget is a utility entry point related to system widgets. If the app and system provide the relevant options, check what can be configured in Settings, then add or manage the widget using the methods supported by the system. For system requirements, refer to the App Store listing. Widget availability and display options depend on what your device provides.
Before adding a widget, check the selected server and connection status in the app. After adding it, confirm that the widget display matches the actual status. A shortcut doesn’t replace checking your configuration; if the display doesn’t update promptly, verify the app and system status instead of repeatedly triggering connections.
iCloud: Check Local Settings After Syncing
iCloud features can save or sync app data where supported; check the relevant options in Settings. Before using them, make sure you’re signed in to your own Apple Account and that the system allows the app to use iCloud. Keep a recoverable local copy before syncing or restoring through the available interface. Check the option details to see what will sync; don’t assume all data or system permissions will transfer.
What to check: On the other device, check the active configuration, selected server, and VPN configuration authorization. iCloud sync does not sync live connection status. Don’t run restore repeatedly without knowing which data will overwrite the other.
Diagnostics: Keep Reproducible Troubleshooting Details
Diagnostics helps collect diagnostic information; find the relevant entry in Settings. First note the network, routing mode, and steps involved when the issue occurs, then collect the relevant results once as directed by the interface. Keep the test destination consistent when reproducing the issue, and note what you changed after each attempt so the logs can be matched to the settings in use.
Note: Diagnostic data may include server addresses, request details, or authentication fields. Review and redact sensitive information before exporting or sharing it, and keep only the smallest excerpt that explains the issue. Diagnostics can help narrow down a problem; don’t reset every setting based on a single error message.
08 / VERIFICATION
Verify Your Settings: Trace One Request Step by Step
These features work together: server details provide the connection, Global Routing sets the routing mode, Config determines rule policies, and DNS handles resolution. Data and Diagnostics provide clues for troubleshooting. To check whether a setting works, trace the same request through each step rather than relying on whether a switch is on.
- Check the connection basics. Confirm that you’re using your own server with complete settings, that the current network works, and that the required system VPN configuration has been authorized.
- Check the routing mode. Make sure
Global Routingmatches the purpose of your test. If you’re usingConfig, also check the active file and the matched rule. - Check actual access. Run a test, then load a fixed destination. Record whether it succeeds, times out, or returns a specific error; don’t rely on latency alone.
- Check automatic behavior. Before restoring your usual settings, check whether
On Demandwill change the connection status again, and keep a record of the settings that worked.
If Shadowrocket isn’t installed yet, first read how to verify the App Store listing and purchase. Shadowrocket is available exclusively on the App Store; the developer is Shadow Launch Technology Limited, and the app ID is 932747118. Check the App Store listing for the current price, system requirements, and purchase availability. For your first import, continue with the setup guide. If an issue persists, troubleshoot it step by step using the Troubleshooting Manual.