Shadowrocket Proxy Modes
and Essential Settings
Start by deciding how traffic should be handled, then adjust connection conditions. Begin with Global Routing and check rules, servers, On Demand, and diagnostic records in turn.
This page focuses on iPhone and iPad. Option locations may vary with the app interface; follow what you see in the current app. For system requirements, refer to the App Store listing.
Global Routing: Three Modes Compared
Global Routing determines how connections are handled after they enter the client. Open Global Routing from Home and choose Config, Proxy, or Direct. These modes are not speed settings, and they do not supply missing server credentials. Before switching modes, make sure a server is available and the intended configuration is selected.
| Option / Mode | How traffic is handled | When to use it | What to check |
|---|---|---|---|
ConfigConfiguration |
Handles connections according to the rules and policies in the selected configuration. | When connections need different routes based on domain, IP, or other conditions. | The selected configuration, rule order, final policy, and proxy target. |
ProxyProxy |
Handles traffic routed through the client using the proxy mode. | To briefly check whether an existing proxy server can handle connections. | The selected server and actual request results—not just the test score. |
DirectDirect |
Handles traffic routed through the client as direct connections. | To compare with your local network and check whether the proxy path is causing an issue. | Your local network and DNS; Direct does not disable system connection settings. |
Config: Use rules for everyday routing
Select the configuration you want under Config, then return to Global Routing and choose Config. Visit one site expected to use the proxy and another expected to connect directly, then check the connection records against the actual policies. If the configuration uses policy groups, check the selected options in those groups too. Correct rule text alone is not enough if the policy target is unavailable. Configurations with the same name may contain different rules, so review key rules after an update.
Proxy / Direct: Compare connection paths
When troubleshooting a site, temporarily compare the results using Proxy and Direct. If Proxy connects but Config does not, check which rule matches and which policy is selected. If both modes fail, check the server settings, local network, and DNS. Keep the target address and network conditions as consistent as possible. Changing the server, DNS, and network at the same time makes it hard to tell what affected the result.
Rules: Routing Rules
Routing rules define what traffic to match and how to handle it. Review or edit the rules in the active configuration under Config, and set Global Routing to Config to use them. Rules are generally evaluated in order, so put specific conditions before broader ones and leave FINAL at the end. Keep a copy of the original configuration before editing; test with a few targets before expanding the rules.
DOMAIN matches an exact domain; DOMAIN-SUFFIX matches a domain suffix and its subdomains; DOMAIN-KEYWORD matches a keyword in the domain and generally has a broader scope. IP-CIDR and IP-CIDR6 describe IPv4 and IPv6 ranges, respectively, while GEOIP uses a geographic IP condition. USER-AGENT depends on whether the client can access the relevant request information; it is not an app-identification condition that applies to every connection.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY
This teaching example shows how to match example.com and its subdomains first, then apply a GEOIP condition, with remaining connections handled by FINAL. PROXY sends traffic to a proxy policy, DIRECT connects directly, and REJECT blocks the connection. This example illustrates rule syntax; it is not a complete configuration for every network. Use the configuration and policy definitions you already have.
If a rule change has no effect, first make sure you edited the active file, then check whether an earlier rule already matched. Domain rules depend on domain information being available, and IP conditions may depend on resolution results. A website’s pages, images, and other resources may also connect to different domains. Find the specific request in the connection records instead of judging the entire ruleset by whether a page loads completely.
View the technical reference for protocols and settings →Subscribe and Server Management
Server entries store the address, port, protocol, and authentication details needed for a connection. Subscribe updates a server list from a subscription you already have. Servers and Config serve different purposes: servers provide connection targets, while the configuration determines how traffic uses them. Importing a subscription does not automatically make its rules, DNS, or other settings active; check each separately.
Add Server: Enter the details you already have
Open Add Server from the server list on Home. Choose the protocol that matches your existing details, then enter the address, port, and authentication fields. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different fields; do not choose a different protocol just to get the form to save. Additional settings such as TLS, SNI, transport, and path should also match the server details. If you are unsure, refer to the documentation for the service you already use.
Subscribe: Update and Keep Track
Use the Subscribe option to add a subscription address you already have, then check the entry name, type, and update result. Subscription addresses often contain access credentials. Do not share the full address in public screenshots, chats, or diagnostic materials. If an update fails, first check that the link is still valid and accessible on your current network, then review the error. Repeatedly adding the same subscription can create duplicate entries and make it harder to identify the active one.
Before manually changing servers created by a subscription, check whether a later update will overwrite your edits. Record any settings you need to keep, and distinguish manual entries from subscription entries. Before deleting an old subscription, check whether any policies in your configuration refer to it, so you do not leave selections pointing to a name that no longer exists.
On Demand: Connect on Demand
On Demand uses conditions supported by the system to determine when to trigger a connection. It does not replace routing rules or select an available server. Find On Demand in Settings and review the network conditions and behaviors shown in the current interface. Before enabling it, verify that the server, Global Routing mode, and configuration work together with a manual connection. This helps prevent automatic triggers from masking basic setup issues.
First decide what you want to achieve: connect on certain Wi-Fi networks, or use different connection behavior on cellular. Adjust only conditions supported by the current interface, save your changes, then test on the target networks and check what happens when the network changes. Verify network name conditions carefully; a similar name does not mean a condition has matched. Other system connection settings may also affect what you observe.
With On Demand enabled, a manual disconnect may trigger another connection when its conditions are met. If you need to stop temporarily, check On Demand as well rather than repeatedly switching off the connection. On Demand is not a power-saving mode: battery use depends on connection frequency, signal strength, protocol, data transfer, and server status. Check system battery usage and connection records for frequent reconnects instead of drawing conclusions from background activity time alone.
Data: Traffic Statistics
Data shows traffic recorded by the client. Open Data and first check what is being measured, the time range, and whether the statistics have been reset. Then review items such as uploads and downloads. Different views may report per-connection or cumulative totals, so check the labels before interpreting the numbers. Data from one connection is not the same as the device’s total network usage.
To compare traffic for a specific action, note the current reading and time, perform one clearly defined action, then check the change using the same measurement. If the interface supports resetting statistics, do so only after confirming you no longer need the earlier records. You can save a copy without sensitive information for comparison. Background sync, media loading, and system tasks may also use data, so not all increases can be attributed to a webpage you just opened.
Client statistics, system cellular data statistics, and server-side usage measurements may cover different scopes and use different accounting periods or connection overhead, so their readings may not match exactly. Data does not replace usage details from a service you already use, nor does it prove that a specific rule matched. Use connection records to check routing and the system battery page to check battery usage; choose evidence that fits the question.
Settings: Save Your Current Settings First
Settings groups options for connections, tests, display, and diagnostics. Some settings may also come from the active Config. Before changing anything, check its scope and whether the current interface offers that option. Change one setting at a time, noting its original value and what you plan to verify. Do not change a whole group of settings just because one option sounds relevant.
DNS: Separate Name Resolution from Connectivity
DNS resolves domain names to addresses used for connections. First check the DNS options in Settings, then review DNS entries in the active Config to identify which settings are actually in use. If a domain fails but connecting by address behaves differently, check resolution and connection records before concluding that the server is unavailable. Follow the existing configuration design, keep the original values, and test commonly used sites and local network resources. Do not enter an unfamiliar address in DNS settings.
Test Method: Know What the Test Measures
Find Test Method in Settings and check the current method, then return to Home and use Connectivity Test. Different methods produce results that cannot be directly compared. A test that returns no result does not necessarily mean an actual request will fail. Keep the method and network conditions consistent when comparing servers, and then try accessing the target service. Test results can help narrow down an issue, but they do not guarantee consistent speeds or continued availability.
Today Widget: Check the Target Before Using Quick Actions
Today Widget provides shortcuts or status information through system widgets; availability depends on the system and the current app interface. Check the related option in Settings, then look for the widget in the system’s widget management area. Before using a shortcut, select the intended server and mode in the app. A shortcut does not automatically check whether your configuration is appropriate. If the widget status differs from what you see in the app, return to Home and verify the actual connection rather than relying on the widget alone.
iCloud: Sync Is Not a Standalone Backup
Check iCloud sync options in Settings and confirm that the app is allowed to use iCloud in system settings. Decide what you want to sync, then verify the results on another device; do not assume that all settings, subscriptions, and records will sync. Before editing on multiple devices, keep a copy of important configurations and wait for syncing to finish. Sync may also propagate deletions or changes, so it should not be your only backup. Store configurations containing credentials as sensitive information.
Diagnostics: Keep Context When Troubleshooting
Open the Diagnostics options in Settings and use the tools available in the current interface to review diagnostic information. Note when the issue occurred, the network type, Global Routing mode, server type, and steps to reproduce it, then use the error message to identify the affected stage. Before sharing diagnostics, hide subscription addresses, authentication fields, personal domains, and unnecessary browsing records. Do not share a complete configuration to provide more logs, and do not disable security checks such as certificate verification without a clear reason.
How to Verify the Results
- Check the local network. First confirm that your current Wi-Fi or cellular network is working, and sign in to the network if required. Use one fixed test target; do not combine multiple issues in a single test.
- Check the connection details. Verify the selected server, protocol, and authentication settings. A successful subscription update only means the list was retrieved; it does not mean every server can connect.
- Check Global Routing. Use Config when you need routing rules, and verify the active file and policy target. After comparing Proxy and Direct, restore the mode you intend to use.
- Check records and trigger conditions. Match the time of the issue to the connection records. If needed, pause On Demand triggers and test again to distinguish automatic reconnections from manual actions.
- Keep only changes that work. Repeat the same action after each adjustment. If the result does not improve, restore the original setting and check the next layer instead of accumulating changes you cannot explain.
For an initial setup, follow the complete guide to import a configuration, choose a mode, connect, and verify the result. If an interface option is unfamiliar, check the glossary before deciding whether to change it. Every change should have a clear reason, a verifiable result, and a way to restore the previous setting.