Shadowrocket Features
Routing, Connections, and Diagnostics
First choose how traffic is handled, then set when to connect, and finally verify the results with tests and logs. These instructions cover common tasks on iPhone and iPad.
Global Routing
Choosing a mode
Path: Home → Global Routing
Choose Config to route traffic by rules. Proxy and Direct are useful for specific global needs or temporary comparison tests. Global Routing controls how traffic is handled overall; it is not a server list and does not show whether a connection is active. After changing modes, check the selected server and connection toggle in Home, then test the destination.
| Mode | How it works | When to use it | What to check |
|---|---|---|---|
| Config | Uses the rules in the active configuration to choose a policy. | Different domains or addresses need separate PROXY, DIRECT, or REJECT handling. | The file selected in Config, rule order, and FINAL. |
| Proxy | Routes intercepted traffic through a proxy without applying Config's standard rules one by one. | Temporarily check whether the selected server can reach a destination. | Whether the server is available and the destination allows the connection. |
| Direct | Handles intercepted traffic by connecting directly. | Compare direct access on the current network to distinguish proxy-path issues from local network problems. | Local network, DNS, and destination availability. |
Setup and verification
Open Global Routing in Home, choose a mode, then return. Before using Config, confirm the intended configuration is selected in Config. Connect and test a known destination. If the same destination works in Proxy but fails in Config, first check the matched rule, policy target, and DNS. This can help narrow down the cause, but one comparison alone does not prove a rule is wrong.
Proxy is not a “fix configuration” button. After a temporary test, restore the intended mode; otherwise, LAN access and other traffic may be handled differently. Direct does not mean the connection toggle is off: it changes how traffic is handled, while the toggle and conditions such as On Demand determine whether the connection stays active.
Match the right traffic
then choose how to handle it
Path: Config → current configuration → [Rule]
A rule defines what to match and what to do when it matches. DOMAIN matches an exact domain; DOMAIN-SUFFIX matches a domain and its subdomains; DOMAIN-KEYWORD matches a keyword in a domain; IP-CIDR and IP-CIDR6 match IPv4 and IPv6 address ranges; GEOIP matches using an IP geolocation database. Each rule type uses different information, so domain rules cannot directly replace address rules.
PROXY, DIRECT, and REJECT are policies, not rule types: they send traffic through a proxy, connect directly, or reject the connection. Rules are typically checked from top to bottom, and the first match applies, so put specific rules before broader ones. FINAL handles traffic that did not match earlier rules and should go at the end.
[Rule]
DOMAIN-SUFFIX,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,DIRECT
In this example, ads.example.com matches REJECT before it can fall within the later example.com range. Other domains in that range use PROXY, the specified private address range uses DIRECT, and remaining traffic is handled by FINAL,DIRECT. This example explains syntax only; it does not indicate that these domains offer usable connection services, and it should not replace a complete configuration.
Change one matching condition at a time
Keep the original configuration, edit a copy of its [Rule] section in Config, save it, and confirm that the copy is selected. Then return to Home and test with Config. After making a change, send a new request to the destination so an existing connection is not mistaken for the result of the new rule. If the actual policy differs from what you expect, check request records for the domain and destination address the app used. A page may contact multiple domains, so a rule for only the domain in the address bar may not control every request.
Subscribe and
server management
Path: Home → Add Server / Subscribe
These steps assume you already have your own subscription or server details. A server entry stores connection details such as address, port, protocol, and authentication. Subscribe retrieves and updates a group of entries from an existing subscription URL. Config handles settings such as global parameters and traffic rules; importing server details does not also provide a rules file suited to your needs.
Add a server manually or import a subscription
If you have details for a single server, open Add Server in Home, choose the matching protocol, and enter the supplied values. Protocols such as Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, and Hysteria2 use different fields. Follow the protocol options shown in the app and your existing server details; do not swap passwords, identifiers, or transport parameters between protocols.
To use a subscription, choose Subscribe in Add Server, enter your complete subscription URL, save it, and update the subscription. After import, check that the group and entries appear, select an entry, run Connectivity Test, and then try the actual destination. A successful update only means the details were retrieved and parsed; it does not guarantee that every server is currently available.
Check entry sources before updating
Subscription entries may be regenerated during an update, so changes made directly to their fields may not persist. For local changes you need to keep, save the necessary details first and distinguish manually added entries from subscription entries. Before deleting a group, removing duplicates, or replacing a subscription, check which entry the current connection depends on so you do not remove details that are in use.
On Demand
Control when to connect
Path: Settings → On Demand
On Demand asks the system to establish a connection when specified conditions are met. It is useful when you want to connect automatically on particular networks. Its role differs from traffic rules: On Demand controls when a connection is triggered, while Global Routing and Config determine how traffic is handled after connection. Enabling On Demand does not add a subscription, select an available server, or fix rules.
Before setting this up for the first time, turn off automatic triggers and manually select a server, authorize the VPN configuration, and verify access. Once the basic connection works, open On Demand in Settings and configure behavior based on the network conditions actually shown. Available options may vary by device and app state; check the current interface rather than following steps that may not apply.
After setup, test on networks where a connection should and should not be triggered. Check whether it connects as expected, then test access to a destination. If it reconnects after you disconnect manually, first review the On Demand conditions and related VPN settings in the system. If the connection fails after switching networks, test the server manually on the new network before adding more trigger conditions.
Automatic connection does not guarantee that a server is always available. Network changes, expired authentication, or updated subscription details can affect the result. Temporarily turn off On Demand while troubleshooting to prevent automatic reconnections from interfering with comparisons, then restore the conditions you need when testing is complete.
Data usage
How to read and use it
Path: Data
Data shows traffic recorded by the client. Use it to check whether data was transferred during a connection or compare changes before and after an action, not as a billing statement for a connection service. The client and server may differ in what they record, when they record it, and how they measure usage. If the numbers do not match, first check which connections and time periods each one covers.
In Data, first check the time range and traffic categories currently shown. For a focused test, note the readings beforehand, pause other ongoing transfers, access a single destination, and then check the change. If the interface offers a reset or clear option, save any records you need first. Clearing local statistics does not change usage records on the server.
An increase in traffic does not prove that a destination opened successfully; background requests, connection retries, and other apps can also transfer data. Conversely, a failed page load can still coincide with increased usage. Consider the current mode, destination results, and Diagnostics together. A rise in Data alone does not prove that a rule is correct or a server is working.
Settings
Adjust options by issue
Use the options shown in the current app interface.
You do not need to change every option in Settings at once. Start with the defaults and establish a working baseline, then adjust settings to address a specific issue. Some features also depend on the active Config, system permissions, or device environment. If you cannot find an option, check the app interface rather than assuming menu locations are the same across devices.
DNS: The basis of domain resolution and rule matching
DNS resolves domain names to addresses. Its behavior may be affected by both Settings and the [General] section of the active configuration. When troubleshooting, first check the DNS parameters in the configuration that is actually in use, then confirm that the network can reach the specified resolver. Avoid combining parameters from multiple sources and changing only one of them; it makes it harder to tell which setting changed the result.
If only some domains fail, compare other domains and networks, then check DNS results and rule matches. Change one setting at a time, reconnect, and send a new request. Access to one address does not prove that domain resolution is working properly overall, and changing DNS at random will not fix authentication issues or an unreachable server.
Test Method: Understanding the Connectivity Test scope
Test Method determines how Connectivity Test runs. Find the option in Settings, review the available methods, and use the same method when comparing entries. If the interface lets you set a test destination, choose one that is known to be reachable and meets the test requirements, and keep conditions consistent throughout the comparison.
Different methods measure different stages, so their results may not be directly comparable. A successful test does not mean every website will work, and a timeout may be caused by the test destination or current network. Check the method and destination first, then review the server address, port, and authentication details. Do not repeatedly switch entries based on a single test result.
Today Widget: Quick actions and status
Today Widget is for widget scenarios supported by the system. Check the related setting in the app, then add the widget using the system’s editing controls. Where it appears and how it works depend on system support; follow what is shown on your device. For system requirements, refer to the App Store page.
Complete initial setup, server edits, and rule checks in the app. The widget is useful for a quick status check, but if its display seems out of date or the connection result is unexpected, open Home and check the selected server and connection toggle instead of repeatedly tapping the widget.
iCloud sync: Check what is included before using another device
iCloud features sync app data where supported. Check the sync toggle in Settings, then confirm the relevant iCloud permissions and available storage in system settings. The app interface specifies what is synced. Do not assume that app purchases, server details, connection status, and historical statistics are all part of the same sync.
Before enabling sync for the first time, keep a copy of important configurations. On another device, confirm that the expected data has arrived before making local changes. Seeing data in the cloud does not mean system VPN authorization is complete; verify the destination device separately. Servers and subscriptions may contain authentication details, so make sure you control the accounts and devices used before enabling sync.
Diagnostics: Gather clues from a single failure
Diagnostics lets you view or create information for troubleshooting. When a problem occurs, open the relevant option in Settings and record one reproduction using the method shown in the current interface. Note the network, Global Routing mode, selected server, and destination before repeating the action. This makes the record easier to assess than one that combines several changes.
Distinguish between a failure to establish a connection, a DNS resolution failure, and a failed request to the destination. Before sharing records, hide subscription URLs, server authentication details, and personal request data; keep only what is needed to locate the problem. Diagnostics provides supporting evidence, but it cannot replace correct server details or identify every cause from a single message.
Verify the basic connection
before testing automation
Keep a baseline and change one thing at a time.
- Check the details. In Home, verify the source, protocol, and required fields for the selected entry. If a subscription needs updating, update it first, then confirm the intended entry is still selected.
- Check the mode. Use Config for everyday rule-based routing and confirm the active file in Config. Use Proxy or Direct temporarily for comparison, then restore the intended mode.
- Check the destination. Run Connectivity Test first, then access the destination you actually need. Record the test method, test destination, and actual access result separately.
- Check automatic connection. Enable On Demand only after the manual connection is stable, then test both conditions that should trigger a connection and those that should not.
- Check the records. Use Data to observe changes and, if needed, Diagnostics to record one reproduction. If the cause remains unclear, revert the most recent change instead of rewriting every setting at once.
If the connection toggle still will not turn on, a subscription update fails, or a specific destination remains inaccessible after setup, continue with troubleshooting. To get the app again, see App Store purchase and authenticity details. The developer is Shadow Launch Technology Limited, and the app ID is 932747118. Compatibility and purchase availability are as listed on the App Store page.