Official Manual · Features & Settings
Shadowrocket Settings
Routing modes, rules, and connection checks
Check Global Routing first, then review Config and your server. Change one setting at a time and test with the same request to see whether it affects the connection.
Browse by setting
First, distinguish modes, configurations, and connections
The interface paths below primarily refer to iPhone and iPad. Layouts and available options may differ on other platforms. Follow what you see in your version of the app rather than assuming the same paths apply on every device.
Global Routing: Config, Proxy, and Direct
The mode determines how traffic is handled. Check it before troubleshooting rules.
What it is: Global Routing sets the overall connection handling mode. Config uses the rules in the current configuration file to choose a policy; Proxy routes requests handled by the app through a proxy; Direct routes those requests directly. “All” means traffic handled by the app, not necessarily every type of system traffic on the device.
Where to find it and how to set it: Open Global Routing from Home, choose Config, Proxy, or Direct, then return and check the selected server. Use Config for everyday routing by domain or IP. If you suspect a rule is selecting the wrong policy, temporarily switch to Proxy or Direct for comparison. Keep the destination, network, and server unchanged during the comparison so you can tell whether the result came from the mode or a network change.
| Mode | How it works | When to use it | What to check first |
|---|---|---|---|
| Config | Applies the matching policy from the current Config rules. | Everyday rule-based routing; checking the route for a specific domain or IP range. | The selected configuration file, rule order, and policy target. |
| Proxy | Routes handled requests through a proxy. | Temporarily bypassing rule-based routing to check an existing server connection. | Whether the selected server is valid and its authentication and transport settings match. |
| Direct | Routes handled requests directly. | Comparing access over your local network to see whether the proxy route is involved. | Whether the local network, destination service, and DNS are working. |
Note: Proxy will not fix incorrect server settings, and Direct does not mean the app is disconnected. After switching modes, make a new request before checking the logs; existing long-lived connections may continue on their original route. Restore your usual mode after the comparison rather than leaving a troubleshooting setting in place. Config mode in Global Routing and the Config page have the same name, but the former is a routing mode and the latter manages configuration files.
Rule-based routing: check match conditions and policies separately
What it is and where to find it: Rules combine a match condition with a policy. In Config, review the currently selected configuration file. 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; GEOIP matches using the IP geolocation database. USER-AGENT depends on whether the relevant request information is available, so it should not be treated as a reliable match condition for every encrypted request.
How to configure it: Decide which destination needs a different route, then choose the most specific matching condition. Rules are generally checked from top to bottom, and the first match determines the request’s policy. Place specific domain rules before broader rules that could override them, and put FINAL at the end to handle requests that do not match earlier rules. After editing, confirm the configuration file is still selected and test with a new request; do not stop at confirming the text was saved.
Rule examples and policy meanings
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYPROXY routes traffic through a proxy, DIRECT uses a direct connection, and REJECT denies matching requests. Any custom policy name in the configuration must have a corresponding definition.
Note: These examples illustrate rule order and are not suitable for every network. IP-based matching may involve DNS resolution, and a change in a domain’s resolved address can change its route. REJECT denies matching requests; it cannot remove content based on its visual position on a page or guarantee that every unwanted resource is blocked. If a rule matches correctly but access still fails, check the server assigned to that policy instead of adding more rules of the same type.
Manage subscriptions and servers: know where they come from
What they are and where to find them: A server entry stores connection details such as protocol, address, port, and authentication. Subscribe retrieves and updates entries from a subscription URL you already have. View the server list on Home, use Add Server to enter details manually, or import an existing QR code with Scan QR Code. Subscription management and Config file management are separate: updating the server list does not update the active rules file.
How to configure it: Get the complete connection details from your own provider, then select the protocol they specify, such as Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, or Hysteria2. Check authentication, TLS, transport, and any related options as well as the address and port. Two entries with the same address do not necessarily use the same settings. After importing, check the entry count and names, run Connectivity Test on an entry, then verify with a request to an actual destination.
To update a subscription, manually refresh it from Home and check the result. A failed update and an update that leaves the list empty are different issues: first check whether the URL can be reached; if the list is empty, also check whether the response is valid and in a format the app can read. A truncated URL, spaces added during copying, or a response that leads to a login page can all prevent import. Keep existing working entries until the import is confirmed so you have something to compare against.
Note: Changes made manually to subscription entries may be overwritten at the next update. To keep changes long-term, first understand how local entries relate to subscription entries. Subscription URLs may contain personal access credentials; do not post them in public comments, screenshots, or diagnostic logs. The same protocol name does not guarantee identical settings, and Connectivity Test does not replace checking authentication or access to the destination.
On Demand: trigger connections based on conditions
What it is and where to find it: On Demand triggers connection behavior based on configured network conditions. In Settings, open On Demand and check whether it is enabled and which conditions are set. It controls when a connection starts, not which policy a request uses; Global Routing and Config determine routing by domain and IP.
How to configure it: Connect manually first and confirm the configuration works, then set triggers using the conditions available in the app. For Wi-Fi conditions, check the network identifier and the order of conditions carefully. After saving, test on networks that do and do not meet the conditions, and check whether the connection state matches your expectations. Change only one network condition at a time; avoid editing rules and server settings at the same time.
Note: On Demand does not guarantee that the app will run continuously in the background. Network changes, system permissions, and system policies can all affect connections. If enabling it increases connection attempts or changes battery use, note which network changes occurred, remove unnecessary triggers first, and then decide whether other settings need adjustment. Available conditions vary by platform; follow the options shown in the app.
Data: use traffic changes to help troubleshoot
What it is and where to find it: Data displays traffic statistics for activity handled by the app. Categories, time ranges, and available details depend on the current interface. Use it to check whether requests and traffic changed during a test; it is not a provider’s billing statement and does not show that every network activity on the device was counted.
How to use it: Open Data and note the statistics range and current values. Return to the target app and make a repeatable request, then check for changes. If the app also provides request or connection logs, compare the destination domain, timestamp, and policy to understand the route. Do not rely on the total alone: background system activity may also generate traffic, so a noticeable increase may not come from the page you just tested.
Note: The app’s statistics may differ from a provider’s figures because of protocol overhead, billing periods, or how uploads and downloads are counted. The numbers do not need to match exactly. Before clearing logs or resetting statistics, save any information needed for troubleshooting. Logs may contain domains, addresses, and access times, so remove sensitive details before sharing them. Traffic in Data only confirms that data was transferred; it does not show that the destination returned the right content or guarantee a particular speed.
DNS: check the resolution path before changing addresses
What it is and where to find it: DNS resolves domain names to IP addresses. The results affect subsequent connections and may also be used for IP-based rule matching. Check DNS-related options in Settings and see whether the current Config includes DNS settings. A configuration file may also affect actual behavior, so changing one page does not mean every request will use the new setting.
How to configure it: First confirm that the problem is actually at the resolution stage: check that the domain is spelled correctly, whether multiple domains fail, and whether the local network works. Record the current DNS settings, then change one resolution option at a time while keeping the server and routing mode unchanged. Enter an address in the format required by that field. If it requires an address for a specific protocol, do not mix a plain IP address with a full protocol URL.
After making a change, repeat the test with a new request and account for existing caches and long-lived connections. If the domain resolves but the connection still times out, check the server, rules, and destination service. If only a few domains fail, compare the policies they match and their resolution results. IPv4 and IPv6 may have different reachability; for intermittent issues, note which address type was used rather than immediately disabling support for either one.
Note: DNS is not proxy transport; changing DNS cannot fix an incorrect password or port. Encrypted DNS describes one way DNS requests are transported and does not establish the privacy properties of all app traffic. Avoid changing multiple DNS options, the routing mode, and the server at once; even if things work again, you will not know which change made the difference.
Test Method, Today Widget, and iCloud
These settings affect testing, quick actions, and data sync respectively; they are not connection-quality switches.
Test Method: know what the test measures
What it is and where to find it: Check Test Method in Settings; it affects the method used by Connectivity Test. Different methods test different stages of a connection, so their results are not directly comparable. Passing one type of test does not confirm that authentication, the destination website, and sustained data transfer have all been verified.
How to set it and what to watch for: Choose from the methods shown in the current interface and use the same method when comparing servers. If you can configure the test target, keep that the same too. If a result looks unusual, first check whether the test target itself is reachable, then review the server settings. To confirm real-world behavior, make a request in the target app; a single test result does not establish sustained speed or long-term stability.
Today Widget: confirm the connection in the app after a quick action
What it is and where to find it: Today Widget settings provide quick access through a system widget. Check the relevant option in Settings, then add it using the method provided by the system. Widget placement and available interactions may vary by system version.
How to set it and what to watch for: After adding the widget, try an action and return to Home to confirm the connection and selected server. The displayed status may depend on when the system refreshes the widget, so do not rely on an outdated status to determine whether a connection is still active. If the widget does not appear or update, first check that the system allows it and that you have opened the app at least once; there is no need to rewrite the rules file.
iCloud: distinguish sync, backup, and current selections
What it is and where to find it: iCloud options support the data sync or import operations available in the app. Check the relevant item in Settings, and confirm that you are signed in to iCloud and have allowed the app to use it. If the interface offers Import from Cloud JSON, import a file in the format that entry accepts; arbitrary subscription text is not the same type of file.
How to set it and what to watch for: Confirm that the data arrived on the target device, then check the currently selected Config and server. Do not assume that selections, system connection permissions, or all local settings will be synchronized as well. Keep a usable copy of the configuration before and after syncing, and identify which version to keep if a conflict occurs. Server credentials and subscription URLs are sensitive, so also review access to your cloud account. Cross-platform data sharing depends on the features actually available.
Diagnostics: turn symptoms into verifiable steps
What it is and where to find it: Diagnostics is the entry point for collecting or viewing network check information provided by the app. Find Diagnostics in Settings and choose an available option in the current interface. Diagnostic logs reflect the conditions at the time of a test; old logs do not describe the current network.
How to use it: Describe the symptom clearly: does the switch fail to connect, does every destination fail, does only one domain fail, or does a subscription fail to update? Record the network, Global Routing mode, selected server, and Config, then reproduce the issue once. Review the logs by time and distinguish DNS resolution failures, connection timeouts, authentication failures, and policy mismatches. Do not change several settings before collecting logs, or they will no longer reflect the original issue.
- Check the basic network first. Under controlled conditions, compare access over your local network to rule out a disconnected network or a connection that requires authentication.
- Then check the connection details. Verify the server address, port, protocol, and authentication settings. If needed, compare them with another existing entry.
- Then check the mode and rules. Confirm that the current Config is selected and check which policy the request actually uses, rather than looking only at the rule text.
- Finally, restore and retest. Revert temporary changes that have not been verified, repeat the request to the same destination, and note the difference before and after restoring the settings.
Note: Before sharing logs, remove subscription URLs, authentication fields, and other personal information. Keep only the error type, sequence of events, and necessary details about the environment. If the issue began after an update or configuration change, compare with your original configuration copy before clearing all data. For more symptom-specific steps, see the troubleshooting guide; for a step-by-step first connection, see the getting started guide.