Shadowrocket Features & Settings

Global Routing determines how Shadowrocket handles traffic routed through the app. Open Global Routing on Home, check the current selection, then decide whether to change it. The available modes are Config, Proxy, and Direct; use these English labels to identify them in the interface. Switching modes does not change the server or fix incorrect server details.

Separate Everyday Use from Troubleshooting

When your routing configuration is ready, use Config and check request records to confirm how rules behave. If you suspect a rule is causing a problem, note the original mode, then compare the same destination once in Proxy or Direct. Restore the original mode after testing so a temporary setting does not become your everyday setup. If a destination opens in one mode, that narrows down the issue but does not prove that DNS, the server, or a rule is at fault.

Direct does not turn off the system VPN configuration. To check whether the connection has stopped completely, check both the connection toggle on Home and the system VPN status. If the connection path matters, do not rely on the status bar icon alone.

A rule typically consists of a match type, match value, and policy. The rule type specifies what identifies a request; the policy specifies what happens when it matches. In Config, review the rules in the active configuration, checking specific entries before broad matches and FINAL. Rules are generally matched in order, so finding a rule in the file is not enough—you also need to check whether it can be reached.

Choose a Match Condition by Destination

DOMAIN matches an exact domain; DOMAIN-SUFFIX matches a domain suffix; DOMAIN-KEYWORD matches a keyword in the domain and may cover more than expected. For a suffix rule, enter the domain itself without a webpage path. To make an exception for a single domain, put the specific condition before any broader condition that could match it.

IP-CIDR and IP-CIDR6 match address ranges, while GEOIP relies on IP geolocation data. Domain rules and IP rules match different things: DNS results, IPv4, and IPv6 routing can all affect what you see. USER-AGENT depends on relevant information being identifiable in the request; it should not be treated as an app-level selector that works for every app.

Policy Names and FINAL

DIRECT means a direct connection, PROXY routes traffic through a proxy, and REJECT blocks matching requests. If a configuration uses custom policy names, make sure each name is defined and spelled consistently. FINAL handles requests that did not match earlier rules. Its selection determines the route for many destinations that are not listed individually, so be clear about the intended behavior before changing it.

[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.org,PROXY
FINAL,DIRECT

Use Home to view, select, and manage existing servers. Add a single server with Add Server and its protocol details; import an existing subscription link with Subscribe; or use Scan QR Code for an existing QR code. Choose an option based on the format of the information you have, not on whether it can change what the server supports. Before importing, confirm that the details come from a service you already use and keep the original information for reference.

Check Imported Details Before Connecting

1. Confirm that the expected entries appear in the server list. If the list is empty, check subscription retrieval and parsing first instead of changing rules.
2. Open an entry and check its protocol, address, port, and authentication fields. TLS and transport settings should match the information you already have; do not guess based on the server name.
3. Select the entry you plan to use, run Connectivity Test, then verify with an actual request. Test results mean different things depending on the method used.
4. Check Global Routing and the active Config, then turn on the connection. These settings need to be clear together to understand where traffic is going.

Updating a subscription reloads entries from its source. Names or entry counts may change, and a previously selected entry may no longer be available. Check the selected server again after an update rather than relying on the “update complete” message. Record any special parameters you need to keep before updating, and check whether the update will recreate the relevant entry.

A server name is a label for identification, not proof of connection quality. Use clear names to distinguish purposes, but do not put credentials in them. Subscription links, QR codes, and exported data may contain authentication details; include only necessary fields when sharing troubleshooting information. For a complete import walkthrough, follow the tutorial.

Data shows traffic and connection information recorded by the app. When troubleshooting, first check the displayed statistics range, time period, and whether the data has been reset. Then review uploads, downloads, or connection records. Traffic during a connection only shows that data was exchanged; handshakes, DNS lookups, and failed retries may also use data. An increase in the count does not by itself mean a request succeeded.

Compare Records Against a Reproducible Request

Before testing, note the selected server, Global Routing mode, and destination. Open a page, return to Data, and check new records. Compare the visible destination, policy, and time to see whether the request followed the expected path. If you need more detail about how it was handled, check Log as needed. Minimize background requests from other apps during testing so unrelated activity does not complicate the results.

Data statistics should not be treated as equivalent to server billing or the device’s cellular data usage. Different counting ranges, protocol overhead, reconnects, and time periods can cause discrepancies. To compare figures, use the same time window and keep a record of the data before resetting it. Records may include destinations and addresses; check for private information before taking screenshots or exporting them.

DNS: Distinguish Resolution Failures from Connection Failures

DNS resolves domain names to addresses. Check DNS-related options in Settings and the active Config, note the current values, and confirm what each setting is intended to do. A domain that cannot be resolved is a different problem from a connection failure after an address has been returned. Use diagnostic records to tell them apart before changing the relevant setting. Avoid changing several DNS options at once and guessing the cause based only on whether a page loads.

DNS requests also need a working network path. If the configured DNS method depends on the current proxy and the proxy connection is not established, the two may create a dependency problem. Check server reachability, rules, and both IPv4 and IPv6 results. DNS resolution involves handling query information, so understand the path a setting uses rather than comparing the time taken by a single test.

Test Method: How the Test Affects Results

Test Method controls how connection tests are run. Check the setting in Settings, then run Connectivity Test from Home. When comparing entries, keep the test method, destination, and network conditions the same. A timeout does not necessarily mean the server is completely unavailable; the test destination or method may not be suitable. Likewise, a passing test does not guarantee that every real-world request will succeed.

Do not reorder every server based on one test. Repeat the test, verify with a request to a real destination, and then review the logs. If you change a test-related setting, record its previous value so results from different conditions are not compared as if they were equivalent.

Today Widget: Quick Access and Controls

Today Widget is a Settings option for configuring related system widget displays or controls. Check the available options in Settings, then add the widget using the method provided by your device’s system. Displayed content, setup, and refresh behavior depend on the interface; a widget should not be treated as continuous real-time monitoring.

After using a shortcut, return to Home to check the connection toggle, selected server, and Global Routing. If the widget has not updated, open the app and check its current state. Do not keep toggling the connection based only on outdated widget text.

iCloud: Sync Scope and Conflict Checks

iCloud settings apply to sync features supported by the app. In Settings, check which items can sync and confirm that the system allows the relevant iCloud access. Keep a copy of important configurations before enabling sync. After switching devices, check the sync results before editing. Not every data category is necessarily synced; turning on iCloud does not mean all connection details have been restored.

When editing on multiple devices, first compare what each device shows, then decide which copy to keep. Sync may take time, so check local data before switching accounts or turning the feature off. iCloud sync and App Store purchase history are separate: restoring a purchase does not confirm that server details or configurations have synced.

Diagnostics and Log: Collect Evidence for One Issue

Diagnostics helps investigate connection issues; Log shows how requests are handled. Open the relevant options in Settings and run the checks available on your device. Before collecting data, note the failed destination, conditions, and current mode, then reproduce the problem once. Keep the records related to that request. This is usually more useful than logging continuously for a long time and guessing at the cause.

Logs may contain domains, addresses, subscription details, or other connection information. Remove or redact sensitive fields before sharing. Keep only the time, error details, and policy context needed to explain the issue. After collecting detailed records, restore settings suitable for everyday use. Do not infer that all connections have failed from a single error without enough context.

When many settings are involved, following a consistent order is easier to troubleshoot and undo than changing several options at once. First confirm the network is working, then check the server details and selected entry, followed by Global Routing, the active Config, DNS, and finally On Demand and any changes made through shortcuts. Record the original value at each step and restore temporary changes after testing.

1. Home: Check the selected server and connection toggle. Distinguish a successful subscription update, a passing test, and a successful real request.
2. Global Routing: Confirm whether the current mode is Config, Proxy, or Direct. Use the same destination for every mode comparison.
3. Config: Check the active file, matching rule, policy reference, and FINAL. Do not stop at searching for the destination domain.
4. Settings: Check DNS, Test Method, or On Demand based on the issue. Do not mistake a statistics display option for a routing control.
5. Data / Diagnostics: Compare the records against one reproducible request, save the necessary evidence, and restore everyday settings.