Subscription (Subscribe)
Import a subscription you already have. It updates server entries; it does not automatically replace a complete routing configuration.
Official Shadowrocket Guide Genuine App Store app
Shadowrocket User Guide
A rule-based proxy client for iPhone / iPad. Start by importing an existing configuration, then learn how routing rules work and how to verify a connection. The app is a one-time purchase on the App Store; connection services are managed separately.
Apple platform app
Available exclusively on the App Store
One-time purchase
Rule-based routing
See the App Store listing for system requirements
CONFIGURATION / MATCH / POLICY
How subscriptions, rules, and policies work together
Start with connection details, then decide how requests should be routed. Subscribe manages existing server details, Config stores routing settings, and Rule determines which policy a request uses. Each has a distinct role: a successful import does not confirm that a connection works.
Rule
Conditions are checked in order. Put more specific exceptions before broader rules that could match first.
Policy
PROXY routes a request through a proxy, DIRECT connects directly, and REJECT blocks a request. A policy cannot guarantee that a destination is reachable.
Distinguish server details from configuration files
Server details answer “which protocol, address, and authentication method should I use?” A configuration file answers “which requests should use a proxy or connect directly, and how should domains be resolved?” Existing subscriptions usually manage server entries in bulk. A filename alone does not tell you whether a file contains rules. After importing, check the selected server in Home and the active configuration in Config separately.
The rule workspace on the right is a text-matching illustration, not a ready-to-use configuration. For example, if a broad condition containing example appears first, a later exception for ad.example.com may never take effect. Before making changes, decide which policy you want, then check the scope and order of each condition. Avoid continually appending rules to the end of a file.
FUNCTION INDEX
Explore settings and their limitations
Select an item below to learn more. Code examples show partial syntax or fields for reference, using reserved domains and documentation addresses—not working connection details.
Global Routing: decide how requests are routed
Check Global Routing in Home. Config mode follows the active configuration and its routing rules. Proxy mode sends typical requests through the selected proxy, while Direct mode connects directly. For domain- or address-based routing, select Config first, then confirm which file is active in Config. Changing modes does not supply server authentication details or prove that a server is available. When troubleshooting, change one condition at a time and compare results for the same destination. Avoid changing the server, rules, and DNS all at once, or you may lose track of the cause. The snippet below illustrates routing intent when used in a compatible rule configuration.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTOn Demand: connect automatically under specified conditions
On Demand is in Settings. It lets the system request a connection when specified conditions are met; it does not make a server available. Before enabling it, connect manually, verify that a destination is reachable, and check which network conditions apply. If a connection reappears after you disconnect manually, check On Demand before repeatedly deleting the configuration. Trigger behavior can also depend on system state and does not mean every request will go through a proxy. To pause automatic connections, disable the relevant conditions before disconnecting. The steps below are for troubleshooting, not an importable configuration.
Settings → On Demand
Verify a manual connection → Check trigger conditions → Retest after switching networksSubscribe: manage existing server entries in one place
An existing subscription link can import and update server details in bulk; you can usually access it from the add action in Home. Before importing, make sure the full link is on your clipboard. Afterward, check the group and its entries, then test one entry. Updates may change addresses, authentication parameters, or entry names, so avoid mixing ongoing manual edits into entries managed by a subscription. Subscription links may contain credentials; redact the full link and authentication fields when asking for help. This guide covers importing and managing information you already have; it does not provide subscriptions. The example below uses a reserved domain and dummy values to show the link format.
https://example.com/sub?token=xxxxConfig: organize settings into sections
Configuration files in Config can contain sections such as General, Rule, Host, and URL Rewrite, each controlling different behavior. Seeing file contents in the editor only confirms that the file exists. To check whether it is in effect, verify that it is active and review the Global Routing mode. Keep a recoverable copy before editing, change one thing at a time, and test to make errors easier to locate. Updating a subscription and switching configurations are separate actions; a change in server entries does not prove that rules were updated. The example below shows two valid rule lines only and is not a complete configuration for any particular setup.
[Rule]
DOMAIN,example.com,DIRECT
FINAL,PROXYRule: the first match determines the policy
Rule checks conditions from top to bottom and applies the policy specified on the first matching line. DOMAIN matches an exact domain, DOMAIN-SUFFIX matches a domain suffix, and IP-CIDR matches an address range; do not treat keywords as interchangeable just because their names look similar. Put narrower exceptions before broader conditions that could override them. FINAL handles requests that did not match any earlier rule. For troubleshooting, check the actual destination, matching rule, and resulting policy—not just whether a domain appears somewhere in the file. The example keeps a specific domain exception before rejecting requests to other example domains.
[Rule]
DOMAIN,keep.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,PROXYDNS: distinguish resolution problems from connection failures
DNS resolves domain names to addresses as part of the connection process. If a domain fails to load but its address is reachable, that suggests checking name resolution; it does not prove that a particular resolver is at fault. Review the DNS settings in the active Config, then consider the actual resolution result, cache, and request routing. Avoid adding many addresses from unknown sources. Keep the configuration easy to understand and retest the same domain. After a change, make a fresh request to see whether the result differs. The snippet below shows partial General syntax using system for system DNS settings; it is not a fixed solution for every network.
[General]
dns-server = systemURL Rewrite: apply actions to matching URLs
URL Rewrite applies a specified action to URLs that match its conditions. Its role differs from Rule, which selects a proxy or direct connection. Before editing, define the requests you want to match and check that the expression is not too broad. What can be seen in encrypted requests depends on the connection and related settings; a rewrite rule cannot be assumed to cover all app content. If access problems occur, disable the new rewrite and test again before removing the entire configuration. The example below shows redirect syntax for a reserved domain. You do not need to install a certificate to read this page, and the example is not a general recommendation for rewriting real websites.
[URL Rewrite]
^http://example\.com/ https://example.com/ 302Host: understand the scope of domain mappings
Host sets a local mapping for a specified domain and can help investigate differences in name resolution when the target address is known. It is not a server subscription and cannot replace protocol authentication or change the target service itself. After adding a mapping, confirm that requests use the intended address and remember that the target service may require the domain to match its certificate. Old addresses can cause localized access problems, so each mapping should have a clear purpose and a way to undo it. The example uses a documentation address and cannot be used for real access. If you do not need a fixed mapping, there is no need to add this section.
[Host]
example.com = 192.0.2.10Proxy: protocol parameters must match the server
In Add Server, select Type, then enter Host, Port, and the authentication fields required by the existing server details. Parameters for Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard are not interchangeable. Some types also require checking the transport method, TLS, and server name. Protocol names alone do not determine speed or battery use; network quality, transport settings, and server capabilities matter too. Importing a share link can reduce manual entry errors, but check the parsed fields afterward. The checklist below is for reviewing fields; use values from server details you already have.
Type → Host → Port
Authentication fields → Transport settings → TLS (if applicable)Diagnostics: narrow down the connection stage
Connectivity Test in Home and Diagnostics in Settings can help assess connectivity, but a single test does not represent every destination or protocol behavior. Record the current network, server, and Global Routing mode, then retest the same destination to distinguish name resolution, server connectivity, authentication, and routing. A latency figure reflects the round trip or connection process for the selected test method; it is not a measure of sustained throughput. Before sharing diagnostic information, remove subscription links, authentication fields, and personal browsing records. The sequence below is a checklist, not a predetermined diagnosis.
Current network → DNS → Server reachability
Authentication and transport → Matching rule → Actual destination accessData: understand what traffic statistics cover
Traffic information in Data shows connection activity within the client's statistics scope. Before interpreting it, check the reporting period, whether the counters were reset, and which policy the current request uses. Upload and download figures should not be treated as equivalent to a provider's bill: protocol overhead, measurement methods, and time periods can all cause differences. If usage rises unexpectedly, check for background syncing or ongoing transfers, then review connection records rather than inferring the cause from a single cumulative figure. Compare before-and-after totals over the same test period; do not mix data from different periods. The items below are dimensions to review.
Data
Reporting period / Upload / Download / Current connection and policyiCloud: check syncing and recovery separately
Before using iCloud-related sync or import features, check the device's sign-in status, system permissions, and the available options in the client. App purchase history, server details, configuration files, and connection authorization are different kinds of data; reinstalling the app does not mean all settings will be restored automatically. Keep a recoverable copy of important configurations and protect any credentials they contain. After syncing to another device, check the active configuration and selected server, then connect as prompted by the system. The two recovery checks below cover separate areas; refer to the current client interface for the exact sync scope.
App Store → Check purchase history
iCloud / Client import → Check configuration and server detailsFIRST CONNECTION
First connection: import, choose a mode, and test
Before you begin, have an existing subscription link or server details ready. Purchasing the app provides the client; connecting also requires valid server parameters. For your first setup, make as few changes as possible. Confirm that one connection works before adding routing rules or automatic connection conditions.
Add an existing server or subscription
Open the add action in Home. If you have a share link, copy the complete link and check the import result. For manual entry, select Type first, then verify Host, Port, and the authentication fields. Use a QR code only if it comes from information you already have, and review the parsed details after importing.
After importing a subscription, check that its group appears and its entries are complete, then select a server. Avoid enabling several advanced settings before verifying the parameters. If the import fails, first check whether the link was cut off by a line break or is empty, then determine whether its format is supported.
Choose Config, Proxy, or Direct
For rule-based routing, select Config and confirm which file is active in Config. Proxy and Direct can help compare how requests are routed, but they do not fix connection problems automatically. After changing modes, make the same request again and compare the result.
If one website works and another does not, first check whether they use different policies. Troubleshooting DNS, authentication, or rules only makes sense after confirming the intended server and configuration are in use. An entry appearing in Home alone does not prove that a configuration is active.
Connect and verify real-world access
When starting a connection, follow the system prompts to review and allow adding a VPN configuration. This permission only establishes a system network connection; verify server authentication for your existing subscription separately. Once connected, run Connectivity Test, then open the destination you actually need and confirm that it works as expected.
A system status of connected only indicates that the connection configuration is active; it does not prove that every destination is reachable. If a test fails, note the current network and mode, check the server parameters first, then review request routing. Change one thing at a time and keep a reproducible before-and-after comparison.
A step-by-step verification beats changing everything at once
If the first connection does not work as expected, keep a copy of the original details and check that the subscription or server parameters were entered correctly. Then verify that the intended entry is selected, Global Routing is set as expected, and the right Config is active. Once these basics are confirmed, inspect name resolution and the specific request records. A test timeout alone is not enough to determine whether the rules or server are at fault.
When switching networks, retest the same destination and note whether only some requests fail. This helps distinguish a change in the environment from a configuration change. If you need help, share the mode, what happened, and the steps you have tried. Do not disclose a full subscription link, password, or other authentication details.
DEVICES & APP STORE
Getting Shadowrocket on iPhone and iPad
The App Store is the only place to get Shadowrocket. Purchase eligibility for both devices, system requirements, and compatibility are as shown on the App Store listing. On a device where the app is already purchased, still check the account and connection configuration in use.
iPhone
Verify the App Store listing before purchasing and installing. When setting up your first connection, follow the system prompts to authorize it, then return to Home and select an existing server. Retest access after changing networks or configurations.
If Shadowrocket does not appear in store search, check the country or region associated with your account and the details on the product page. Do not confuse a search visibility issue with a client connection problem.
See the iPhone setup steps →iPad
Use the same Apple ID to check your purchase history; purchase eligibility is determined by the store listing. On iPad, still verify the imported configuration, selected server, and Global Routing mode. A connection working on another device does not verify this device.
The larger display makes configuration files easier to read, but screen size does not change rule-matching logic. After restoring an existing configuration, check that its contents are complete, then connect and verify how requests are routed.
See the iPad setup steps →Shadowrocket is also available on Mac / Apple TV through the same App Store; see the listing for compatibility details.
See how to get the app →PRODUCT IDENTITY & PURCHASE
Verify the app and understand the one-time purchase
This is the official Shadowrocket website and guide. When purchasing, verify the product name Shadowrocket, developer, official icon, and app ID together. Do not rely on the search result title alone.
Shadowrocket
Shadow Launch Technology Limited
App ID 932747118
Closed-source commercial app
Compare the icon, developer, and ID in the product page URL; all three should match.
Verify three details on the product page
Open the App Store product page. Check the app name and icon, then confirm the developer is Shadow Launch Technology Limited. The id932747118 in the product page URL corresponds to the app ID. A similar icon is not enough to verify the app, and neither an identical nor a similar name replaces these two text checks.
If you arrived from a search result, verify the details again on the product page. The official icon shown here can help you compare the appearance, but the App Store listing is the source for current pricing, compatibility, and purchase information. App updates are also managed through the App Store; to see what changed, read the update notes there rather than guessing from how an app looks in a tutorial.
Pricing, the app purchase, and connection services are separate
Shadowrocket is a paid app. The US storefront reference price is $2.99 as a one-time purchase; other storefronts show local pricing, and the final price is displayed at checkout. Buying the app provides the client, not a guarantee of server connectivity, service duration, or access quality.
A one-time app purchase is not a service plan. This site does not provide, sell, or recommend servers or subscriptions. To use the connection features, prepare a subscription or server details you already have. The validity period, address changes, and authentication details for an existing service depend on your existing service arrangements; reinstalling the app will not restore or extend them automatically.
Store availability and account region
The App Store displays products based on the country or region associated with an account, so search results and purchase availability can vary. If Shadowrocket does not appear in search, check the current storefront in your account settings, then open the product page linked on this site. Missing search results do not mean the app name has changed or that an existing purchase is invalid.
When checking your account, distinguish the account signed in to the device from the account used for App Store purchases. Follow account settings and store prompts for any regional, payment, or purchase restrictions. Do not repeatedly change purchase settings to troubleshoot a client connection issue: getting the app from the store and connecting to a network are separate processes, and the former cannot fix authentication errors for an existing server.
Restore on a new device and use the purchase on both devices
When switching devices or reinstalling, use the original purchase account to check App Store purchase history, then verify the Shadowrocket product page. The purchase eligibility for iPhone and iPad, as well as compatibility with other devices and Family Sharing conditions, is determined by the App Store listing. If prompted to pay again, check the account and purchase history before buying again.
Restore the app and restore its configuration separately. Purchase history helps you retrieve the app; server details and configuration files must be restored from your own backup or existing synced data. After restoring, check the selected server, Config, and Global Routing, then connect as prompted by the system on this device. Authorization and test results from another device do not replace checks on this one.
Routine maintenance: keep a copy and make small changes
Once your setup is stable, manage server details, routing configuration, and automatic connection conditions separately. After updating a subscription, check what changed in its entries; after editing rules, verify which rule matches; after changing On Demand, test network switching. Keeping these operations separate makes it easier to identify the cause of a problem. Keep a recoverable copy of important configurations and protect any authentication details they contain.
When troubleshooting a Shadowrocket connection problem, record the current network, selected entry, Global Routing mode, and specific symptoms. This is more useful than a screenshot showing only that a switch is on. Before sharing logs, check for full subscription links, server passwords, or personal browsing records. The goal is to identify a reproducible failure point, not to keep changing every setting to chase a particular test result.
Frequently asked questions
Why do I still need to select a server after importing?
Importing only saves information in the client. You still need to select an entry in Home, check Global Routing and the active configuration, then connect. An entry being present, a test passing, and the intended destination being reachable are separate results; verify them in order. See the import and connection steps →
Why is access still unstable when latency is low?
A latency test measures connection or round-trip time using a particular method. It does not cover throughput, packet loss, sustained connections, or how quickly the destination responds. Keep the same server and mode, retest the actual destination, and then check whether the issue changes with the network. See verification and troubleshooting steps →
Why did adding a rule not change how a request is routed?
First check that Global Routing is set to Config and that the edited file is active. Then check rule order and the domain used by the actual request. A new rule cannot determine the policy if an earlier, broader condition matches first. After confirming these details, make the request again and compare. Read the routing rules guide →
Will reinstalling the app restore all server details?
Check purchase history and configuration data separately. Retrieve the purchased app from the App Store, then restore configuration from your own backup, an existing subscription, or sync data supported by the client. After restoring, check that the information is complete and test again. Read how to restore a previous purchase →
TECHNICAL NOTES
Technical notes: how it works and what to expect
Go beyond the setup steps with notes on specific questions. These articles explain the scope of rule-based blocking, how store listings relate to account regions, and what latency tests can tell you. First identify whether your issue concerns purchasing, configuration, or connectivity.
How Shadowrocket's REJECT policy works: what rule-based blocking can and cannot do
Learn how matching conditions and the reject policy handle domain-based requests, and why domain rules cannot distinguish all content on the same domain or every request embedded in an app.
Can't find Shadowrocket in the mainland China App Store? Apple ID region and App Store visibility explained
Follow the steps to check which storefront is associated with your account and distinguish search results, product page availability, and past purchases. For purchase issues, verify the store details first; do not confuse them with client connection problems.
How to choose a server for Shadowrocket: latency tests, location, and protocol—and why a low latency number does not guarantee a better experience
Using server entries you already have, learn how test methods, location, and protocol settings affect results. The article offers ways to compare results under consistent conditions and does not recommend services.