Shadowrocket Features and Settings

Global Routing: Choose How Traffic Is Handled

Once the connection is active, Global Routing determines whether traffic is evaluated against the rules in your configuration or sent primarily through a single Proxy or Direct route. It is separate from server selection and the connection toggle on Home. Find Global Routing on Home, check the current mode, then choose Config, Proxy, or Direct as needed.

For everyday rule-based routing, Config is usually the right choice. Before making changes, open Config and check which file is actually enabled—not just whether a file has been imported. A file can exist without being in use. Editing a disabled file will not automatically change how current connections are handled.

If a destination is unreachable, note your current settings, then briefly compare Proxy and Config. If it works in Proxy but not Config, check which rule matched the request and where its policy sends it. This is a troubleshooting clue, not a definitive diagnosis. Restore your intended mode when you finish so a temporary test setting does not become your everyday configuration.

Rules & Routing: Conditions, Order, and Policies

Rule-based routing compares request details, such as the domain or destination address, against rules and applies the corresponding policy. Open the active configuration in Config and review its rule list. When Global Routing is set to Config, this is the configuration used for routing decisions. Keep a copy of the original before editing so you have a baseline to compare against.

A rule typically consists of a type, a match value, and a policy. Rules are evaluated from top to bottom; evaluation stops at the first match. Put a specific exception for a domain before any broader rule that would cover it. FINAL usually goes last to handle requests that did not match earlier rules. A long rule list is not necessarily a well-ordered one.

PROXY sends traffic through a proxy route, DIRECT connects to the destination directly, and REJECT blocks the request. Rules may also reference policy group names defined in the configuration. If so, check which option is currently selected in the group; the policy name at the end of the rule may not tell the whole story. The snippet below illustrates ordering only. example.com is illustrative and should not replace your existing configuration wholesale.

DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT
FINAL,PROXY

This example puts an exact-match exception before a suffix rule; otherwise, the broader rule would match ads.example.com first. When troubleshooting, find the rule that actually matched before changing the order. Simply adding a rule at the end does not ensure it will take effect. See Rule Matching Order and FINAL for more.

Subscribe and Server Management

Server records store connection details. Subscribe uses a subscription you already have to manage a group of servers, while Config mainly holds rules and related settings. These are related but different types of content. Import an existing link according to what it is; a configuration URL and a subscription URL are not interchangeable just because both are web addresses.

On Home, open Add Server and select the appropriate Type for the information you already have. When adding a server manually, check Address, Port, and the authentication fields required by the protocol. For example, Trojan and Shadowsocks do not use exactly the same fields. The parameters must match the server; changing Type will not fix mismatched details. For an explanation of the fields, see the protocol reference.

To import an existing subscription, choose Subscribe under Type in Add Server and enter your subscription details in the appropriate field, such as URL. After saving, return to Home and check that the subscription’s server list appears, then select the record you need. If you use Scan QR Code, verify the content type and source first. Check the saved parameters afterward; a successful scan does not mean the connection works.

Updating a subscription fetches its server list again, which can help when the provider has changed addresses or parameters. After an update, check that the selected server is still listed, whether its name has changed, and whether existing policies still reference valid records. Temporary edits to subscription-generated records may be overwritten by a later update. Before making important changes, check how the configuration is saved.

Connectivity Test can help compare how server records respond under the current test conditions. Results depend on Test Method, the test target, the network, and server status. A response in the list does not mean every destination is reachable. If there is no response, first check whether the test method suits the service before changing server parameters.

On Demand: Trigger Connections by Condition

On Demand lets the system start a VPN connection when specified conditions are met. It controls when a connection starts, not which policy a domain should use. Once connected, traffic handling still depends on Global Routing and the active Config. On Demand is not a separate set of routing rules.

First, make a manual connection from Home to confirm that your server and configuration work. Then go to Settings and find On Demand. Set the conditions available in the current interface. If a condition uses a Wi-Fi network name, check the spelling and make sure the device is connected to that network. Avoid adding several automatic triggers before a manual connection works; otherwise, it is harder to tell where the problem lies.

After setup, switch between the network environments you actually use and check whether the system starts a connection as expected. Confirm the status on Home. Test both conditions that should trigger a connection and those that should not. A single test on your current Wi-Fi cannot verify that other network conditions are configured correctly.

If the connection starts again after you intended to stop it, check whether On Demand is still enabled and whether its conditions are being met. To pause automatic connections, first disable the relevant triggers, then check the connection toggle. The system’s handling of network changes and background activity can also affect what you observe, so trigger timing may vary between environments.

Data: Review Traffic and Request Details

Data displays traffic statistics and request information recorded by the app. It can help answer questions such as whether data passed through during a connection or how records changed during a test. It is not a provider’s billing statement or a complete speed test. Check the options on your device for the available statistics, time range, and retention period.

In Data, check the statistics range, time period, and available categories before testing access to a single destination. Comparing the results before and after a test is more useful than looking at a cumulative total alone. If connection details or request records are available, use domains, destination addresses, and policy information to check the route. If a field is not shown, do not assume which rule handled the request.

To review the data again, note any relevant details first, then use the reset or clear option provided in the interface. Clearing statistics does not change server parameters or fix incorrect rules. During testing, minimize background activity in other apps so updates, syncs, and other traffic do not skew the totals.

An increase in Data only shows that traffic was recorded within the selected range; it does not prove that the destination service worked. The app may still be retrying or loading other resources. Likewise, little or no change during a test could relate to connection status, the current mode, or the statistics range. Check Home, Global Routing, and the actual result of accessing the destination rather than drawing a conclusion from the numbers alone.

Settings: Know What Each Option Controls

Settings mainly contains app-level options, test preferences, sync settings, and utilities. Config may also hold settings related to resolution and connections. Before making a change, determine whether the option is app-level or configuration-level, note its current value, and keep a copy of the active file. If an option is not shown, do not assume it is elsewhere based on another guide; use the options available on your device.

DNS: Check Where the Setting Comes From

DNS translates domain names into addresses and is an important step before a connection is made. First, look for the relevant option in Settings, then check whether the active Config specifies DNS. Do not assume a change in one place overrides every configuration. Use a resolver you know works and a format supported by the app, then test the same domain again after saving. If you have just changed DNS, account for caching and clear it using the available interface option if needed before retesting.

Successful DNS resolution does not guarantee that the connection will work. If a domain fails but connecting by address behaves differently, DNS may be worth investigating. However, replacing a domain with an address can change TLS verification and request behavior, so do not treat that comparison as a permanent fix. Avoid changing DNS, Global Routing, and protocol fields all in the same test.

Test Method: Use the Same Method for Comparisons

Test Method determines how Connectivity Test checks a connection. Find the option in Settings, choose from the options shown, and check the relevant test target. Different methods test different stages of a connection, so their results are not directly comparable. After changing the method, retest the records you want to compare instead of ranking new results against older ones.

A test target responding only confirms that the part of the connection checked by the selected method responded. It does not guarantee that every app and website will work. When troubleshooting, note the method, target, and network conditions, then verify with the actual service. Do not treat a single response time as a guarantee of quality or reliability.

Today Widget: Quick Access and Controls

Today Widget provides quick access to the app’s system widget. First, check the related option in Settings, then open the system’s widget editor to see whether it can be added and which controls are available on your device. System version and widget support may affect what appears; check the interface on your device.

The widget can reduce the steps needed to open the app, but it does not replace checking your configuration. If the connection status seems wrong after using a widget control, return to Home to verify it and check whether On Demand is triggering the connection. Do not rely on the widget’s last displayed status as proof that a connection is active now.

iCloud: Keep a Copy of Your Config Before Syncing

iCloud options can sync content supported by the app between eligible devices. Open Settings to review the iCloud options and confirm that the system allows Shadowrocket to use iCloud. Before enabling sync for the first time, back up important Config files and note the selected server and mode. Check the interface for what is included; do not assume temporary state, statistics, or credentials are all synced.

After moving to a new device, wait for content to sync, then check files, servers, and policy references one by one. Sync is not a connection test and may not restore all history. If you edit the same configuration on two devices, check the saved results to avoid overwriting newer rules with an older copy. For migration steps, see Configuration Backup and Migration.

Diagnostics: Capture Evidence for a Specific Issue

Diagnostics provides information for troubleshooting. Find the option in Settings and choose a diagnostic method available in the interface. Note the network, Global Routing mode, selected server, and steps taken when the issue occurs, then reproduce it once. A focused record is usually easier to analyze than a long log containing unrelated activity.

Diagnostic results are clues for analysis, not an automatic fix. Before sharing, check for subscription URLs, server addresses, account details, or destinations, and redact sensitive information. Do not publish a complete record. Once troubleshooting is done, restore any temporary recording options and clear diagnostic data you no longer need.

Recommended Order for Checking Settings

When a configuration has many options, following a consistent checklist helps avoid repeated changes. First, keep a recoverable baseline, then change one variable at a time. After each save, test the same destination and record the result. This makes it easier to distinguish parameter issues from rule routing and automatic connection triggers.

1. Check the input. On Home, check the current server and confirm that any existing subscription has been updated. For manually entered servers, verify that Type, Address, Port, and authentication details match.
2. Check the routing mode. Review the current option in Global Routing. If using Config, open Config to confirm which file is actually enabled, then check policy references and FINAL.
3. Test manually. Start the connection and access a specific destination. Check the result using Data and any available records; do not treat Connectivity Test alone as proof that everything works.
4. Then review supporting settings. If needed, check DNS, Test Method, and Diagnostics one at a time. Note the original values and avoid changing multiple parts of the connection at once.
5. Enable automatic behavior last. After verifying a manual connection, configure On Demand, Today Widget, and iCloud, then test triggers, controls, and sync separately.

If you still cannot tell which part is causing the issue, start with troubleshooting. If you are new and have not finished importing and authorizing your setup, begin with Quick Start rather than changing advanced options. Keeping a verified working configuration is usually easier to maintain than layering on temporary changes.