The Complete Shadowrocket User Guide

App Store access and verification: confirm the app before preparing connection details

Shadowrocket is a paid client for Apple platforms, primarily used on iPhone and iPad. The App Store is the only place to get it. Compatibility with Mac, Apple TV, and Apple Vision is also listed on the same product page; check the App Store listing for system requirements and general purchase terms. The rest of this manual focuses on iPhone and iPad, so don’t assume that layouts on other devices match the mobile interface. Before purchasing, make sure the product page opens in the relevant store, then review the compatibility and purchase information. This helps keep account issues separate from connection setup.

Check the developer, icon, and app ID

Follow the verification steps in the App Store guide. The app name should be Shadowrocket, the developer should be Shadow Launch Technology Limited, and the app ID is 932747118. The icon should match the official icon in this site’s header. The name is only a first check; similar names in search results are no substitute for verifying the developer and app ID. You can confirm the app ID from id932747118 at the end of the product URL. If the search results are unclear, return to the App Store guide and use its product-page link. Don’t purchase based on a similar name alone.

On the product page, distinguish product details from your account’s current status. The price button, redownload icon, and compatibility notice each mean something different: the price relates to purchasing, redownloading relates to an existing purchase, and compatibility indicates whether the current device meets the requirements. An issue with one doesn’t mean the other two are also affected. For example, if an existing purchase can’t be installed right now, check the device and account notices rather than searching for another app with the same name. Before purchasing, note the developer and app ID so you can verify the same details on another device.

You’re purchasing the client, not connection service

Shadowrocket is sold as a one-time purchase. The US storefront price is about $2.99, while other storefronts display local currency; check the App Store listing for the current price and purchase terms. Purchasing grants use of the app; it does not automatically provide server addresses, credentials, or subscription links. A one-time client purchase is not a service plan. Get subscriptions from your provider and confirm that they support importing into Shadowrocket. If you don’t have those details yet, you can install the app and explore its interface, but an empty server list doesn’t mean the purchase failed.

Check device and account requirements separately

On iPhone, check the system requirements before purchasing and installing from the App Store. On iPad, if you’re using the same account that made the purchase, check the App Store listing for redownload availability and purchase eligibility. Different layouts on the two devices don’t mean you need to create a new, unverified set of parameters. Store availability, payment methods, and purchase history depend on the current store account. If the product page is temporarily unavailable, read the system notice and check whether the current storefront and account support the purchase before proceeding. Repeatedly changing settings isn’t a general-purpose fix.

When switching devices or reinstalling, first find Shadowrocket in your App Store account’s purchase history and confirm which account was used to buy it. After downloading the app, separately verify whether your server details, subscriptions, and configuration were restored to the device. Don’t assume that seeing the app again means all connection details have returned. Open it and check the server list, active configuration, and routing mode before your first connection test. For purchase recovery, see Restore a previous purchase.

Before moving on, prepare a personal checklist of your subscription source, server protocol, authentication method, configuration source, and devices to set up. You don’t need to store full passwords; simply note where the details are kept. Leave uncertain parameters blank and check with the provider rather than guessing a common-looking value. Refer back to this checklist whenever you import, update, or troubleshoot. Installing the app completes the acquisition step; it doesn’t prove your connection details are valid.

First launch and permissions: VPN configuration and the Home screen

When you first open Shadowrocket, take a look at Home before switching the connection on. Home is the main place to manage connections. Connection status, Global Routing, Connectivity Test, and the SERVER list show status, routing mode, connectivity test results, and server choices respectively. These aren’t interchangeable: a server in the list isn’t necessarily selected, a selected server isn’t necessarily connected, and a VPN status in the system doesn’t guarantee that every destination is reachable. Understanding these states separately helps you avoid judging success by the top-level switch alone.

What allowing a VPN configuration means

When an action such as starting a connection requires a system configuration, you may be asked to allow a VPN configuration to be added. Confirm that the prompt was triggered by an action you just took in Shadowrocket, then authorize it as requested by the system. You may need to enter your device passcode or complete another identity check. This allows the app to process relevant traffic using the system’s network extension mechanism; it doesn’t automatically trust a server or fill in your credentials. You still need a valid server, routing mode, and configuration to communicate.

If you previously declined the prompt, try starting the connection again and follow the system prompt if it appears. If the expected prompt doesn’t appear, check the VPN configuration status in system settings to see whether a configuration already exists rather than repeatedly tapping the switch. Management policies may restrict configuration creation or network extensions on managed devices; check with the device administrator. Don’t delete system configurations used for other purposes without understanding what they do and how to restore them, especially on a work or school device.

Check four things on Home

1. Check SERVER for the server you intend to use, and confirm it’s selected.
2. Check Global Routing to see whether the current mode is Config, Proxy, or Direct.
3. Switch on the connection at the top and wait to see whether its status changes before leaving the app.
4. Run Connectivity Test, then verify a specific real-world request.

An unestablished connection may show Not Connected. This describes the current connection state but doesn’t identify the cause. An empty server list, authentication error, missing system authorization, or unavailable network each requires a check at a different layer. Likewise, a changed status at the top only means the connection mechanism is active; you still need to check whether the server can forward traffic, domains resolve, and rules select the expected policy. See First launch and the Home screen for a detailed interface guide.

Grant other permissions only when needed

When using Scan QR Code, the app needs camera access. If you denied it, check the relevant permission in system settings and then return to the scanner. You don’t need to enable camera access in advance if you only plan to enter details manually or import a link. When importing a configuration through the file picker, check the file’s source and contents. Before reading from the clipboard, make sure it contains the connection details you just copied. A permission prompt tells you which system resource the app is asking to access; it doesn’t verify where the data came from.

On first use, do one thing at a time: import a known set of details, check the resulting list, and then connect. Don’t switch networks, update a subscription, and change routing while a permission prompt is still pending; if something goes wrong, it will be harder to tell which action caused it. If the system asks you to authorize again, note the action and prompt text, then check whether the existing VPN configuration belongs to the current app. Deleting the app after one failed connection may erase local details that haven’t been backed up and create extra work to authorize and import everything again.

At this stage, also confirm that the device itself is online. Open a page that’s normally accessible and check whether you need to complete a sign-in or confirmation step for the current network. The app can’t provide an internet connection to a device that isn’t connected to one. On public Wi-Fi, complete the network’s sign-in page before testing Shadowrocket. If another feature on the device also manages network traffic, identify what each one does and compare them one at a time under controlled conditions. The import results in the next chapter will be easier to test once the network is ready.

Servers and subscriptions: single-server details, Subscribe, and Config

Before importing, identify what kind of information you have. A single server entry describes one connection endpoint and usually includes a protocol, address, port, and authentication fields. A subscription link retrieves and updates a group of servers. A Config file mainly contains rules and related settings, and may refer to policy names. Don’t treat these as interchangeable just because their links look similar. Get subscriptions from your provider. If you’re unsure about the format, confirm which import option to use before proceeding; don’t use the address of an information page as a subscription link.

Add a server manually with Add Server

In Add Server, first choose the protocol that matches your details, then fill in the fields it requires. Enter the actual server domain or address and the provided port. Authentication may use Password, UUID, or a key; these aren’t interchangeable. Check that your keyboard hasn’t added spaces, full-width punctuation, or line breaks, and remove any leading or trailing spaces copied with the details. A display name can help identify a server, but it isn’t a connection parameter. Changing the name won’t fix an incorrect address, authentication detail, or transport setting.

Even the same protocol can use different transport methods, so matching the protocol name is only one requirement. For a connection that requires TLS, for example, the connection address and certificate verification name may differ; Host and SNI also have distinct roles. Don’t set every domain field to the same value just to see what works. If your details don’t specify a field, leave its default or check with the provider. For protocol background, see Supported protocols and parameters. Use your own server details to fill in the fields.

Import and update with Subscribe

To add a subscription, enter the complete link in the relevant Subscribe section, save it, and then update it. The path and query string may be needed for authentication; omitting any part can return an error page or an empty result. Don’t remove parameters to shorten the URL, and don’t post credentials in public. After updating, return to SERVER to check that the expected entries appeared, then select one to connect. You can rename the subscription for clarity, but keep enough information to identify its source and know which group to update later.

A successful subscription update means its contents were retrieved and parsed; it doesn’t guarantee that every server is currently available. A failed update doesn’t necessarily mean all servers are down. Check the underlying network, whether the link is complete, whether authentication is still valid, and whether the response has the expected format. If you already have a working list, keep it for now and note the error before troubleshooting. Don’t delete the whole subscription group first. Updates may add, remove, or rename entries, so check that the selected server is still there afterward.

QR codes, links, and configuration files: what each can do

Scan QR Code is useful for importing recognized connection details, but a QR code is only a way to carry information, not proof that it’s valid. After scanning, check the protocol and address before saving. If the result is an ordinary web page, go back to the source and confirm that you scanned the right code. Apply the same checks to clipboard and file imports: inspect the object created rather than relying on a success message. Use a specific option such as Import from Cloud JSON only when your existing details call for it; don’t keep trying an incompatible file in different import options.

Maintain Config and subscriptions separately. Updating the server list doesn’t automatically create the rules you need, and switching configurations isn’t a substitute for refreshing a subscription. If rules refer to custom policy names, make sure they’re recognized in the current setup. Keep the original details before making local changes, and note whether you changed a single server, a subscription group, or a configuration file. Knowing which object you’re working with makes it easier to decide whether to reimport, update a subscription, or adjust only the active configuration when a list changes.

Global Routing: Config, Proxy, Direct, and rule order

Global Routing determines the overall routing mode in use. The options are Config, Proxy, and Direct; the interface displays these English labels. They’re not server protocols or speed ratings. Config uses rules in the current configuration to choose how requests are handled. Proxy sends requests that the selected proxy policy can handle through that policy. Direct connects directly. Confirm the current mode before troubleshooting: the same server can handle a request very differently depending on the routing mode.

Use the routing mode to narrow down the issue

If the same request works in Proxy but fails in Config, check which rule matched and which policy it references before changing authentication details. If both fail, check the underlying network, server, and DNS resolution. Direct provides a comparison with the direct path; it doesn’t prove that the proxy path works. After testing, restore the mode you actually need. Leaving a temporary setting in place can make later traffic data and browsing behavior differ from what you expect.

Rules match from top to bottom; put specific conditions first

Rules combine a condition, a policy, and an order. Matching is generally checked from top to bottom, and the first matching rule determines what happens. Put specific exceptions before broad conditions, and place FINAL last as the fallback. DOMAIN matches a complete domain, DOMAIN-SUFFIX matches a domain suffix, and DOMAIN-KEYWORD matches a keyword in a domain. IP-CIDR and IP-CIDR6 match address ranges, while GEOIP uses IP geolocation data. Don’t copy a rule just because its keyword looks familiar; make sure the request provides the information that rule needs to match.

[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

This example sends one exact domain through DIRECT, then routes other matching requests under the same suffix through PROXY. A private address range uses DIRECT, GEOIP handles IP location, and FINAL provides the fallback. It demonstrates syntax and order only; it isn’t a universal setup. In particular, GEOIP rules don’t replace domain rules and can’t guarantee that usable address information is available for every request. Before using the example, check your existing rules, policy definitions, and local network needs. Don’t replace your entire configuration with the example.

Keep policy names separate from routing modes

PROXY, DIRECT, and REJECT in rules are policy keywords. They’re different in concept from Proxy and Direct in Global Routing. A configuration may also refer to defined policy groups or specific names, which must match exactly. A syntactically valid rule doesn’t guarantee that its target policy exists, and an existing policy doesn’t guarantee that its selected server works. When checking a configuration, follow the chain: which rule matched, what it points to, and what the policy ultimately selects. Don’t stop at reading the rule condition.

Complex pages can involve multiple requests. A page may load its main domain, resource domains, and API domains separately, and each may match a different rule. If a page opens but some content is missing, identify the actual destination of the failed request before adding a rule. DOMAIN-KEYWORD can be too broad and affect unrelated domains; prefer a condition that describes the target precisely. Add only a few rules at a time and note why each local exception exists. That makes it easier to check whether it’s still needed after a subscription or configuration update.

After importing a configuration, explicitly select the file you intend to use; editing a file doesn’t make it active. After saving, check that the configuration is usable. If needed, reconnect to rule out the effect of an existing connection, then retest the same destination. Reopening a page may not be enough to test a new policy when a long-lived connection is still open. Start a new request according to the test app’s behavior. To explain why a rule change didn’t affect the result, consider the selected configuration, rule order, and request lifecycle together.

Connections and verification: from server selection to locating the failure

Before connecting, return to Home and confirm that the intended server is selected in SERVER, not just opened in its edit screen. Check that Global Routing matches the purpose of your test, then switch on the control at the top. Watch the system and app status, and wait for the connection process to finish before testing. For the first check, choose a server with clear details and one fixed destination. Don’t update subscriptions, edit rules, and run several tests at once. A repeatable test tells you more than a one-off success.

Three layers to check when verifying a connection

The first layer is the system connection status, which indicates whether the network extension is active. The second is the server path, which indicates whether the current endpoint can establish the required communication. The third is the actual request, which depends on the destination domain, DNS resolution, rules, and the destination service. These layers can produce different results without contradicting each other. For example, a normal system status doesn’t rule out a page failure, and a responsive server port doesn’t prove that authentication and forwarding work. Record the layer where the failure occurs rather than describing everything as “can’t connect.”

Connectivity Test is a quick check, but its result depends on the test method, destination, and current network. A reading represents a particular path at that moment; it isn’t a ranking of everyday performance. Run the test, then open a specific real-world destination and check that the page or request completes. If the test and real-world result differ, compare their destinations, protocols, and policies instead of treating either as definitive. For a walkthrough, see Select a server and verify it with Connectivity Test.

Check the network, endpoint, DNS, and rules in order

1. Confirm the device has a working internet connection and that any network sign-in or confirmation is complete.
2. Check the selected server’s address, port, authentication, and required transport parameters.
3. Confirm that domain names resolve, and distinguish an unreachable address from a DNS failure.
4. Check the routing mode, active configuration, and policy applied to the failed request.
5. Finally, check the destination service’s response and account requirements.

If a request times out, compare it with another server you already have and know works, then try another network you can control. Keep the destination and configuration unchanged so you can identify what caused the difference. If the same endpoint works on another network, investigate restrictions, network access, or path conditions on the original one. If only one endpoint fails across all networks, check its details and service status first. Don’t change the port, password, TLS, and DNS all at once without evidence; even if the connection starts working, you won’t know why.

For authentication or TLS errors, compare each detail with the original information. Adding rules won’t usually fix authentication failures, and randomly weakening certificate verification isn’t a safe fix for a name mismatch. Check that the device date and time are correct, understand how SNI and the connection domain relate to the certificate requirements, and confirm the expected parameters with the provider. If the error points to a formatting problem, correct the imported details rather than retesting the same invalid entry. Keeping the exact error text helps distinguish authentication, handshake, and destination-response issues.

Check the request itself when only some requests fail

If only one page or app feature fails, first check whether other destinations work under the same conditions. Then check whether the failed destination uses additional domains, a different transport, or a persistent connection. Browser and in-app caches, as well as existing connections, may preserve earlier results; after changing a rule, start a new request before comparing. The destination service’s sign-in state, region settings, or account requirements can also affect the response. Not every such issue is a client problem. Narrow down the scope of the failure to make logs easier to interpret.

When you need diagnostic records, capture only the short period needed to reproduce the issue. Note the time, destination, selected server, and routing mode, then make one request and check the relevant records. Before sharing, remove subscription links, authentication fields, full keys, and unrelated browsing details. You can share the error type, protocol name, and comparisons you’ve already tried, but don’t expose full connection details. For common status explanations and next steps, see the FAQ.

After a successful test, repeat the same request at least once and confirm that an update hasn’t changed the configuration or selected server. For scenarios that require ongoing use, also observe what happens when the network changes, but test that separately from the first connection. Write down a short baseline: the network, server, routing mode, and destination that worked. When an issue comes up again, reproducing this baseline is usually faster and safer than re-entering every parameter from scratch.

Data and traffic: understand the scope before judging where requests go

Data helps you observe traffic recorded by the app; it isn’t a complete measure of network quality. Before reading the numbers, check the selected statistics scope, object, and time period. A server view shows traffic attributed to different connection endpoints, while an app view shows communication attributed to apps. The views may use different attribution methods and cover different things, so unequal numbers don’t necessarily mean the statistics are wrong. Read the current view’s labels first, then relate the numbers to the action you just took.

What upload and download indicate

Upload is data sent from the device; download is data received by it. Opening a page usually involves more download, but request headers, authentication, acknowledgments, and control traffic also use upload. Uploading content can cause a noticeable increase in upload traffic. Usage depends on what you’re doing, so a slow increase in one direction doesn’t by itself indicate a problem. Connection maintenance, retries, and background activity can also generate traffic when no page is open. Use a short test window to make the increase from a specific action easier to identify.

Keep total usage separate from transfer rate. The total is the amount of data over the selected statistics period; an instantaneous or short-term rate describes changes in transmission over a shorter interval. A total that has already accumulated doesn’t disappear when the connection stops, so it doesn’t prove the connection is still active. Conversely, a brief period with no visible rate may simply mean the request has finished. When observing an operation, compare the readings before and after it rather than looking at one moment in isolation.

Check changes, not guesses based on totals

1. Confirm the server, Global Routing mode, and configuration; pause unrelated high-traffic activity.
2. Note the current value for the statistic you’re tracking and confirm it’s within the scope of this test.
3. Perform one repeatable action and wait for it to finish or return a clear error.
4. Return to Data, check what changed, and use request records to verify the policy.

An increase in a server’s statistics means some communication was attributed to it, but it may not all come from the page you just opened. Background sync, notifications, and other app activity may happen at the same time. If there’s no increase, check whether the request matched DIRECT, reused an existing connection, loaded from cache, or was viewed under the wrong item. Data provides useful clues, but verify the rule that matched against the active configuration and relevant request records. Don’t use traffic statistics to claim more than they show.

Compare server and app views

The server view is useful for checking whether communication starts through a new endpoint after you switch servers, or whether an entry you no longer use still has activity. The app view helps you see whether an action in a particular app coincides with an increase in traffic, but what it shows depends on the information available to the system and app. Don’t assign unattributed traffic to an app without evidence. These views can help narrow down an issue, but they aren’t two perfectly matching bills: their aggregation methods differ, so adding or subtracting the numbers may not be meaningful.

In Config mode, some requests may connect directly while others use PROXY, so server traffic and the device’s overall usage usually aren’t the same thing. Your provider may also use its own usage measurement, billing period, or traffic-handling rules. App, system, and server statistics can all differ because of time ranges, protocol overhead, and attribution scope. Align the time periods and objects before comparing figures; a single discrepancy doesn’t prove anything is wrong.

Resetting statistics and tracking them over time

If the current interface offers an option to clear statistics, first confirm which object and scope it affects. Clearing local statistics doesn’t reset your provider’s usage, delete a server, or update a subscription. If you need to compare historical results, record them before starting a new test period. For long-term tracking, use consistent conditions, such as a similar task, network, and routing mode. If conditions vary significantly, record them separately instead of combining them into one trend.

If the statistics don’t match what you experience, return to the layered checks in the previous chapter. Traffic with a failing page may point to a post-authentication request, resource domain, or response issue. A working page with no traffic attributed to the expected server may mean the request went direct or came from cache. Consider these possibilities before clearing statistics or switching servers repeatedly. For details on the views, see Reading server and app statistics in Data. Use the labels shown in your current interface as your reference.

Common Settings: On Demand, DNS, and diagnostic options

Change Settings to meet a specific need, rather than turning everything on at once. Some options affect when the system initiates a connection, some affect DNS or logging, and others come from the active Config. Before changing a setting, establish its scope: does it affect one server, the current configuration, or the app as a whole? The interface may change over time, so look for the English setting name and read its current description. Don’t rely on screenshots from other devices to find an option in a location that may not exist in your interface.

On Demand: connection triggers are different from rule-based routing

On Demand starts a connection when specified conditions are met. It controls when a connection is requested, not which policy handles a particular domain. Global Routing and the active configuration still determine how requests are routed. These features can work together, but neither replaces the other. Before enabling On Demand, make sure manual connections work reliably; automatic triggers can make an existing issue harder to observe. If you need automatic behavior, decide which network conditions should start a connection and which should leave it disconnected, then set and test them one at a time.

When testing On Demand, observe a complete network change. Record the connection status beforehand, trigger the intended condition, and check whether the system starts a connection and whether an actual request succeeds. An enabled switch alone doesn’t prove that the conditions are set correctly. If the app reconnects after you disconnect manually, an existing trigger may be responsible; it doesn’t necessarily mean the app can’t stay disconnected. To stop automatic connections temporarily, check On Demand and its conditions first, then disconnect manually. Restore the settings afterward if needed.

On Demand
Global Routing
Config
Connectivity Test

These are setting names to check, not an importable configuration. For automatic connections, check On Demand. For request routing, check Global Routing and Config. For connectivity, run Connectivity Test and make a real-world request. Tracking these separately helps avoid changing rules to fix an automatic reconnect or disabling automatic triggers to fix a domain’s policy. Every change should answer a specific question.

DNS: check for resolution issues before changing settings

DNS translates domain names into address information needed for a connection, and can affect address-based rules and connection setup. If a domain fails while other requests work, DNS is one possibility, but not the only one. First check whether the same domain resolves under the current configuration, then use the connection error to guide the next step. Different configurations may already contain DNS settings, so changing several places at once makes it hard to tell which setting takes effect. Confirm the active configuration, note its existing values, and test one change at a time.

Don’t treat an arbitrary DNS server address as a universal fix. DNS routing, server reachability, encryption, and rules all need to be considered. A value that works on one network may not work on another. After changing it, make a new request and, if needed, account for cached DNS results and existing connections before comparing the same destination. If there’s no improvement, restore the original setting and continue checking rather than stacking more changes. Names on private networks may depend on local DNS, so preserve that requirement.

Logs, certificates, and features to enable only when needed

Enable diagnostic logging only when needed, then check whether it can be turned off once you’ve collected enough information. Detailed logs may include domains, timestamps, and connection details; remove sensitive information before exporting or sharing them. Before using certificate-related features that change how encrypted traffic is handled, understand their trust scope, which destinations they affect, and how to reverse the change. A basic server connection and rule-routing setup doesn’t require extra certificates just to make the settings look complete. Use these features only for a specific debugging need and when the relevant apps and services allow it.

For UDP, IPv6, and similar behavior, check whether both the server protocol and current network support it rather than changing only the client. If a service relies on a particular transport, test that capability while leaving other conditions unchanged. A switch can’t add a capability the server doesn’t provide. Use the appropriate rule type for IPv6 addresses and check it against the actual DNS results. If the issue only occurs on one network, compare network capabilities and path differences before changing the configuration.

After changing settings, return to Home and confirm the selected server, intended Global Routing mode, and active configuration. Then test one ordinary request and one request that needs the special setting. This final check can catch cases where a temporary change fixed one feature but altered your everyday connection. Stable use isn’t about having lots of settings enabled; it’s about every setting having a clear purpose, a verifiable result, and a known way to restore it. Leave settings unchanged when you don’t need them.

Routine maintenance: updates, backups, device transfers, and repeatable troubleshooting

Once the connection is working, maintenance is about keeping track of changes. App updates, subscription updates, configuration updates, and server selection are separate actions, so record them separately. The app updates through the App Store. A subscription update retrieves server details; a configuration update changes rules or related settings; selecting a server only changes the active connection target. Don’t assume that one successful update means everything else is up to date. When a problem occurs, start by identifying which layer changed recently to narrow down the cause.

Record a baseline before updating; check what changed afterward

Before updating a subscription, confirm its source and which entries currently work. If needed, note the name of the server you’re using. After the update, check which entries were added, removed, or renamed, and whether the selected item still points to the intended server. If list changes break a custom policy reference, you may need to fix the rule or policy mapping; you don’t necessarily need to reimport all app data. For subscription authentication, expiration, or response issues, check with your provider. This manual covers how to import and maintain details you already have.

Keep a restorable copy before updating a configuration, and distinguish remote content from local edits. If you’ve added custom rules to a configuration that may be overwritten by an update, note where they are and what they do, then check each one afterward. Don’t paste everything from an old configuration into the new file without checking it; some settings may no longer apply. A safer approach is to verify the updated configuration first, then add back only the local exceptions you still need, testing a fixed destination after each change.

Back up relationships and settings, not just one file

A useful backup note should include the source of your servers or subscriptions, the active configuration name, Global Routing mode, essential local rules, and important settings. A configuration file alone may not contain all authentication details; a subscription link alone may not include local edits or system permissions. Before using an export or backup option in the app, check exactly which items it includes and decide whether anything else needs to be noted separately. Backup files may contain sensitive information, so store them somewhere you control and protect access to them.

After backing up, make sure the files can be read rather than waiting until you switch devices to discover they’re missing. Check that the files exist, use the expected format, and contain the key items. Don’t overwrite your active setup just to test a backup. Avoid putting keys, passwords, or full subscription URLs in public notes or screenshots. When recording troubleshooting details, use a label or storage location instead of full credentials. If a sensitive link was exposed, ask the provider how to replace or revoke it, then update local references.

On a new device, repeat the steps: get, import, authorize, verify

On the new device, first restore Shadowrocket from the App Store, then check what came back from your backup or device restore. Verify the server list, configuration files, and system VPN authorization separately; don’t assume the old device’s system state transfers exactly. After importing your details, test a manual connection to a fixed destination before restoring automatic behavior such as On Demand. On iPhone and iPad, check the current interface and selected items rather than relying on taps based on the old device’s layout. The App Store listing remains the source for system requirements and purchase eligibility.

Keeping the old device until you’ve verified the new one can help you compare parameters, but take care not to change either setup by mistake. After confirming that the new device works, handle credentials, subscriptions, and backup files on the old one as needed. Reinstalling shouldn’t be your first step for an ordinary connection problem; it may erase local configuration and require extra authorization. Consider it only when you know the setup needs to be rebuilt and have confirmed that the details can be restored. For purchase recovery, see Restore a previous purchase.

Keep a minimal troubleshooting log

For ongoing maintenance, keep a brief log of the time, network type, destination request, server, routing mode, configuration name, exact error, and most recent change that worked. Don’t include browsing content or authentication details; record only what’s needed to reproduce the conditions. When an issue occurs, try the known baseline first, then compare recent changes. Change one thing at a time, define what success looks like, and revert changes that didn’t help. A clear record is easier to reuse than a list of methods you’ve already tried, and reduces repeat work when the same issue returns.

To repeat the connection steps, use the Quick Start Guide. For a specific question, visit the FAQ. To verify a purchase or app identity, return to the App Store guide. The chapters on this page can also serve as a maintenance checklist: verify the app and information sources, check permissions and imports, then review routing and connection results before interpreting statistics and settings. Keeping these layers distinct makes routine changes easier to base on evidence rather than repeated resets and guesswork.