Official Manual · Features and Settings

Shadowrocket Proxy Modes
and Settings

First decide how requests should be handled, then adjust rules, connection options, and diagnostics. Global Routing sets the overall handling mode, Config defines the rule details, and server information determines the actual connection destination.

Shadowrocket is a paid, closed-source app available exclusively on Apple platforms through the App Store. This page focuses on using it on iPhone and iPad; see the App Store listing for system requirements.

First connection setup → Subscription management guide →

01 · How requests are handled

Global Routing：Config / Proxy / Direct

Choose an overall mode first, then examine individual requests. Don’t confuse the routing mode with the connection toggle.

What it is and where to set it

Global Routing is where you choose the overall routing mode, usually from Home. This guide describes the three common modes as config-based routing, proxy routing, and direct routing; the interface labels remain Config, Proxy, and Direct. Changing this setting won’t enter a server address or restore invalid credentials. It determines how requests are handled, not where connection details come from.

Config in the options is related to the Config tab at the bottom, but they serve different purposes. The former means handling traffic according to the active configuration; the latter is where you manage and edit configuration files. Saving a rules file does not prove that the current connection is routing traffic through it. Check both the selected file and the Global Routing mode.

Interface option	How it handles traffic	When to use it	What to check
Config	Handles requests according to the rules and policies in the active configuration.	For everyday routing by domain, address, or other criteria.	The active configuration, rule order, policy targets, and final fallback rule.
Proxy	Routes traffic through a proxy; actual behavior also depends on app and system network boundaries.	To temporarily check whether the selected server can handle a target request.	Server availability and its connection to the target service.
Direct	Handles traffic using a direct connection.	To compare the local network path and troubleshoot issues related to the proxy path.	Whether the target is accessible over the local network and whether custom DNS settings are still in effect.

Switching modes and comparing results

First confirm the selected server on Home, then choose a mode in Global Routing. For a meaningful comparison, use the same target and type of request, and reconnect if needed to avoid reusing an existing connection. If a request works with Proxy but fails with Config, check which rule matches and which policy is selected. If both fail, check the server details, local network, and DNS rather than repeatedly changing rules.

Direct is useful for comparing network paths, but it doesn’t mean every network-related setting is disabled. DNS, existing connections, and system behavior can still affect the result. When testing is complete, restore your intended mode and check the connection toggle. Don’t leave a temporary test setup in place for everyday use.

02 · Match criteria and policies

Rule-based routing: match first, then choose how to handle the request

Rule types specify what to match; policies specify what happens after a match.

Check the active configuration in Config

Rule-based routing lets different requests use different handling methods. Open Config, confirm which file is active, then review its rules and policies. Rules are generally evaluated in order, and the first match determines how a request is handled. A broad rule placed too early can prevent more specific rules from taking effect. Save the original configuration before making changes, then move or edit only the few rules relevant to the issue.

DOMAIN matches a specific domain; DOMAIN-SUFFIX matches a domain suffix and its subdomains; DOMAIN-KEYWORD matches a keyword in the domain and may cover more than expected. IP-CIDR and IP-CIDR6 describe address ranges. GEOIP uses an IP geolocation database; it does not indicate where a service is registered or which language it uses. When domains are resolved to addresses, DNS results also matter.

DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

These are syntax examples, not a complete configuration. PROXY sends traffic through a proxy, DIRECT connects directly, and REJECT blocks the request. If a rule refers to a custom policy name, that policy must exist in the active configuration. FINAL is the fallback for requests that match no earlier rule; check both its position and target policy.

Check the scope of each match criterion

USER-AGENT relies on information available in a request; don’t assume every request exposes the same fields. A rule’s name alone doesn’t prove that it will match. If a request behaves unexpectedly, review the available connection logs and check the target domain, address, and policy used. Confirm Global Routing is set to Config, then check rule order and references. Rules determine routing; they don’t fix errors on the destination service.

Remote rules and server subscriptions are separate types of content. Updating a server list doesn’t necessarily update rules, and changing the configuration file can change policy names. To organize how configurations relate to each other, see the subscription and server management guide. Record each source and its purpose before making bulk changes.

03 · Connection details

Subscribe and Add Server

Use Subscribe to manage your existing server details in one place, or add a server manually to check each field.

Subscribe: import an existing subscription

On Home, open Add Server and choose Subscribe, then paste your existing subscription link. Save it and update the subscription. Check that server entries appear, then select the one you want to use. A subscription link and a single-server share link are different types of content. If the import doesn’t work, first confirm that you used the right input option for the content, then check that the link is complete.

Give each subscription a descriptive name so you can identify it without relying on its position in the list. An update replaces entries with the content returned by the remote source, so later updates may overwrite manually changed names or parameters. Note the currently selected server before updating, then confirm your selection afterward. An update completing successfully does not prove that every server can connect.

Add Server: check each field manually

If you already have details for an individual server, choose the matching Type in Add Server, then enter its address, port, and the authentication fields required by that protocol. Shadowsocks, VMess, VLESS, Trojan, WireGuard, Hysteria2, and other protocols use different parameters. Fill in each field using your existing details; don’t just change Type and reuse the previous settings.

If your details include TLS, a server name, or transport-related fields, make sure they match the server-side configuration. Saving successfully only means the local entry was created; it doesn’t confirm that authentication or the connection works. Run Connectivity Test, then try accessing the target. If something goes wrong, compare against the original details instead of changing several fields at once.

QR code, clipboard, and managing multiple subscriptions

Before importing with Scan QR Code or the clipboard, make sure the content comes from your own server details. After importing, check the protocol, address, port, and name. A successful QR code scan doesn’t guarantee that every parameter is present. Subscription links, share content, and configuration backups may contain credentials. Don’t include them in public screenshots or diagnostic reports; show only the field names needed to explain the issue.

When organizing multiple subscriptions, group them by purpose before testing or sorting. Before deleting a subscription, check which related entries will be affected and save any personal configuration you want to keep. Subscription updates change server details; App Store app updates update the client. They serve different purposes and are not interchangeable.

04 · Trigger connections automatically

On Demand connections

First establish a reliable manual connection, then set up automatic triggers.

What it does and how to set it up

On Demand triggers a VPN connection when configured conditions are met. It controls when a connection starts; Global Routing and Config control how requests are handled after it connects. Look for On Demand settings in Settings. Available conditions depend on the current app interface. Decide which network situations should trigger a connection, then enable the relevant conditions. Don’t turn on every option just to automate connections.

Before setting this up, select a server manually, choose a Global Routing mode, and verify that a request works. Then configure On Demand and check the system and in-app connection status after switching between Wi-Fi and cellular networks. Note the network conditions during testing so you don’t mistake a temporarily unavailable server for a trigger that isn’t working.

Understand what happens after disconnecting

With On Demand enabled, manually disconnecting may not keep the connection off. The system may reconnect when the conditions are met again. If the connection comes back after you disconnect, check On Demand before deleting configurations. To pause automatic connections, turn off the relevant conditions first, then observe a complete network transition.

On Demand doesn’t determine whether every website is accessible or guarantee that a server stays online. It depends on system scheduling, network conditions, and a valid configuration. When adjusting rules or server details, you can temporarily disable automatic triggers to prevent reconnections from interfering with comparisons. Restore the original conditions after testing.

05 · Monitor data usage

Data usage statistics

Statistics show traffic recorded by the app; they are not an external billing measure.

Where to find the stats and how to interpret changes

Open Data to view the traffic statistics available in the current interface. First check what is being measured, the time range, and whether the stats have been reset, then compare changes. Different statistics may use different measurement methods. Data for one connection or server is not necessarily the same as the device’s overall network usage. System networking, transfer overhead, and external service measurements can also cause differences.

To check whether an action generated traffic, note the starting values, perform one specific request, then return to Data and check for changes. Minimize background activity from other apps during the test. Cumulative usage is not a speed test: an increase means data was transferred within the recorded scope, but it doesn’t reveal bandwidth, response quality, or whether every request was routed as expected.

Resetting statistics and troubleshooting

If the interface offers a reset option, save any readings you want to compare before resetting. Clearing statistics doesn’t fix network problems. If traffic keeps increasing but a page won’t load, check whether the request matches the right policy, DNS resolution succeeds, and the server can reach the target. Conversely, little change in the stats may be due to the measurement scope or an existing cache; it alone doesn’t prove the connection has failed.

06 · Common Settings options

Settings: DNS, testing, and diagnostics

Adjust each item for its intended purpose. Available options and where to find them depend on the current app interface.

DNS: check the resolution path first

DNS resolves domain names to addresses. Review the DNS options in Settings, and check whether the active Config includes its own DNS settings so you don’t overlook the effect of changing only one location. Keep settings that already work. Change them only when you have a specific reason, such as failed resolution, unexpected addresses, or a need to use a particular resolution path.

Custom DNS and DNS over HTTPS both require an accessible resolver and aren’t automatically better than system DNS on every network. Change one variable at a time, reconnect, and access the same target again. Then review the resolution results to see whether anything improved. Using DoH doesn’t mean all requests automatically go through a proxy; check the DNS path and the connection path to the destination separately.

Test Method: use consistent testing conditions

Find Test Method in Settings, choose an option available in the current interface that suits your network, then return to Home and run Connectivity Test. Different methods check different things, so their timing results aren’t directly comparable. If the test requires a target address, first confirm that the target itself is accessible, then compare servers.

A successful test doesn’t mean every service is accessible, and a timeout doesn’t prove the entire connection is unusable. To compare servers, keep the test method, target, and local network the same, and verify results with actual requests. The order of the results reflects the test at that moment, not long-term performance.

Today Widget: quick access and status

Today Widget options configure the quick-view or action features provided by the system. First check which features the app supports in Settings, then add them where the system allows. Available formats depend on the system environment, so check what appears on your device rather than assuming every device has the same layout.

Quick access can reduce the steps needed to reopen the app, but after setting it up, return to Home to confirm the server, Global Routing mode, and connection status. If the widget and in-app status don’t match temporarily, open the app and check again before changing server details. Verify separately that the connection is active and that the target request works.

iCloud: sync scope and recovery order

Check the iCloud sync or backup options in Settings. Read which items are included in the current interface before deciding whether to enable them. Syncing configuration is not the same as restoring a purchase; app access and restoring purchases are handled through the App Store. Don’t assume system permissions or the current connection state will be fully copied between devices along with files.

Before enabling sync, save existing local configurations, especially if you’ve made changes on both devices. After restoring, check subscriptions, the selected server, and the active Config one by one, then test the connection manually. Treat content containing subscription links or authentication fields as sensitive. Sync convenience doesn’t replace checking what the backup contains and covers.

Diagnostics: gather information about a specific issue

Diagnostics lets you view or run the diagnostic checks available in the app. Look for the relevant options in Settings. First identify where the problem occurs: subscription update, connection setup, domain resolution, or a request to a particular destination. Note the current network, mode, and sequence of actions before running checks related to the issue.

Change one setting at a time, reproduce the issue, and compare the results. Diagnostic data may contain addresses, domains, request details, or authentication information. Review it and remove sensitive details before sharing. Diagnostics provide clues, not guaranteed fixes. If local settings match your existing details, continue checking the server-side configuration and the destination service’s availability.

07 · Recommended troubleshooting order

From connection details to rule matches

Check one layer at a time so you can identify the cause without changing several conditions at once.

Check the connection details. Review the Subscribe update results or verify the protocol, address, port, and authentication fields in Add Server. Keep the original details for comparison.
Confirm what’s selected. Check the active server and Global Routing mode on Home. Don’t rely on memory from your last session or assume the first item in the list is selected.
Test the connection, then the routing. Use Connectivity Test and an actual request to assess the connection. With Config selected, also check the configuration file, policy references, and rule order.
Check DNS and destination access separately. Successful resolution and a successful connection are separate steps. Change DNS settings only when the evidence points to a DNS issue; don’t use a DNS change to mask another problem.
Re-enable automation last. After verifying the manual setup, turn On Demand, sync, and quick-access features back on, then check what happens when the network changes.

For steps starting from the first launch, see the Getting Started guide. To organize multiple subscriptions and configuration files, see the subscription guide. For purchases and device compatibility, visit the App Store listing verification page. Check the developer, Shadow Launch Technology Limited, the official icon, and app ID 932747118. See the App Store listing for pricing, system requirements, and universal purchase details.