01 / APP STORE
App Store Purchase & Purchase History
Confirm the app’s identity before purchasing. Shadowrocket is a paid client for Apple platforms, available exclusively through the App Store. The Get the App page brings together the App Store link, authenticity checks, and guidance on restoring a purchase. This chapter explains why to complete these checks before importing a configuration. Buying the app and obtaining server details are separate steps: a successful App Store transaction gives you the right to use the app, but does not provide a server to connect to.
Check the developer, icon, and app ID
When searching the App Store, don’t rely on nicknames or similar-looking names. Open the product page and check the name, Shadowrocket, the developer, Shadow Launch Technology Limited, and app ID 932747118 in the product link. The icon should match the official icon shown in this site’s header. Check the name, icon, and developer together. If search results include similar names, review the full product details before paying instead of relying on the results list.
The app ID is an important way to confirm the product. The id932747118 at the end of the product page URL identifies the app covered by this manual. Refer to the current App Store product page for its description, compatibility, purchase details, and update history. This guide does not rely on a fixed version number, since the app display and system settings can vary with the device. If the developer or app ID does not match, return to the Get the App page and check the link again.
What a one-time purchase covers
Shadowrocket is sold as a one-time purchase. Check the App Store page for the price, currency, and purchase eligibility. Keep this distinction in mind: a one-time client purchase is not a subscription to a service. The app uses server details to connect and apply routing rules; obtain server addresses, credentials, and subscription links from your provider. Your app purchase history does not indicate whether a subscription is valid, and an expired subscription does not mean you need to buy the app again.
Before paying, check which account is currently signed in to the App Store. If you reinstall the app or switch devices later, you’ll need to find the purchase under the original account. The account used for other system features may differ from the App Store purchase account, so the name at the top of device settings is not enough to confirm who made the purchase. If the store button doesn’t show what you expect, check your purchase history and account before proceeding. Don’t make repeated purchases just to test restoration.
Device compatibility and purchase restoration
This guide focuses on iPhone and iPad. Compatibility with Mac, Apple TV, and Apple Vision is also listed on the same App Store page; check that page for system requirements and purchase eligibility. Availability on one device does not guarantee that another device meets the requirements. Before switching devices, check the target device’s compatibility, the App Store account, and whether the original purchase appears in its history.
Restoring the app and restoring its configuration are separate tasks. Getting the app again does not automatically restore server details, subscriptions, or rule files. Before deleting the app, record any settings you need and keep your configuration safe. After reopening the app, check the actual contents of Home and Config. Family Sharing eligibility, availability in your storefront, and any verification steps are subject to the App Store page and system prompts. Don’t assume that one successful restoration applies to every account and device.
By the end of this chapter, you should be able to answer three questions: Does the app identity match? Which App Store account owns the purchase? Where are your server details stored? If you can’t confirm any of these, resolve that first, before importing a subscription. For store listings and reinstall scenarios, see Restore a Purchase. For help identifying the app in search results, read How to Verify the Official App.
02 / FIRST LAUNCH
First Launch & System Permissions
When you first open the app, get familiar with what each screen does before changing settings. Home is for viewing servers and connecting; Config manages rule configurations; Data shows traffic; Settings contains client options. The order of items may vary by device, display language, and app state. This guide uses English labels to help you find features, rather than relying on a button’s exact position. Check which screen you’re on before adding, switching, or deleting anything.
Understand the VPN configuration permission
When you first connect, the system may ask for permission to add a VPN configuration. This authorization lets the client create a system network connection; it does not confirm that a subscription was imported successfully. Start the connection yourself, read the system prompt, confirm that it comes from Shadowrocket, and follow the on-screen steps. If you cancel, the app’s connection switch may not stay on. Check whether authorization was completed before changing server credentials or importing the same subscription again.
The VPN configuration saved by the system and the server list in Home are separate layers. The system configuration lets the system initiate a connection; the server list provides the connection target and protocol settings. Deleting the system VPN configuration does not delete servers, and deleting a server may not remove a configuration already saved by the system. When troubleshooting, first identify which layer you need to change. Don’t mistake “authorize again” for “delete all servers” and make the problem harder to isolate.
Camera, Clipboard & Local Content
When you scan a code using Scan QR Code, the system may ask for camera access. This permission is only needed for live scanning. If you decline, check Shadowrocket’s camera permission in system settings, or add the details manually if you already have them as text. A camera permission issue is not a server problem; the connection process hasn’t started yet. A QR code may contain complete authentication details, so check its source before scanning, then verify the imported type and address.
Before importing from the clipboard, make sure you copied the complete link or configuration text—not a webpage title, explanatory paragraph, or truncated address. Whether the system shows a paste prompt depends on the current action and system behavior; follow the prompt if it appears. If the expected item doesn’t show up, check the original content and its format. Don’t repeatedly tap import and assume it worked. Confirm the import by checking what was actually added in Home or Config.
Start with a test you can reproduce
For your first setup, choose one clear test target. Add one server entry you know is valid, note the current Global Routing selection, and then turn on the connection. For now, avoid changing DNS, On Demand, or complex rules at the same time. If the connection fails, you can then narrow it down to authorization, server settings, or the basic network instead of untangling several untested changes. Change one thing at a time—that’s the basis for every troubleshooting step that follows.
If the device already has another VPN configuration, check which one is active in system settings before connecting. Consider the system connection status alongside the switch in the app. A status bar indicator alone does not prove that a site is using the expected route. Avoid rapidly switching the connection on and off between system settings and the app; connection and disconnection processes can overlap with screen updates, making it hard to tell which action caused the result.
After granting permission, return to Home and confirm that the server is still there and the correct item is selected before moving on. If the switch turns off immediately, note whether a permission prompt appeared, whether a system configuration already exists, and whether the app shows an error. These details are more useful than simply saying “it doesn’t work.” For a quick walkthrough, see the Setup Tutorial. For common permission and system status questions, see the FAQ. The goal of this chapter is to understand what the permission does—not just to see a switch turned on.
03 / SERVER & SUBSCRIBE
Add a Server & Import a Subscription
Before importing, identify what you have: complete details for one server, a single share link, a subscription link, or a rule configuration file. These are different types of data, even when they all look like text, and they don’t belong in the same field. A server entry describes a connection target; a subscription retrieves and updates multiple server entries; a rule configuration determines how requests are routed. This guide assumes you already have your own subscription or server details. Get them from your provider.
Enter each server parameter in the right field
In Home, use the add option to open Add Server. Choose the Type first, then fill in the fields required by that protocol. If you choose the wrong type, the connection may fail even when the address and password look correct. Enter only the server address in the address field and use the supplied port. Match the password, user ID, encryption method, transport settings, and TLS parameters to the original details. A remark is for identifying the entry; it cannot replace the actual server address.
Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, and Hysteria2 use different fields; there is no single set of parameters that works for every protocol. If you encounter an unfamiliar field, check the information source instead of copying a value from another entry. In particular, distinguish the connection address, the server name used for TLS, and the transport-layer Host. These may differ and serve different purposes; don’t change them all to the same value just for consistency.
| Parameter | Check | Common mistake |
|---|---|---|
| Type | Match the original protocol | Guessing the type from its name or appearance |
| Address & port | Check the supplied values character by character | Pasting a full webpage URL into the address field |
| Credentials | Include the complete password or user ID | Copying extra spaces or missing the final character |
| TLS & transport | Enter each value according to the original parameters | Treating Host and the server name as the same field |
Import a subscription and verify updates
To import a subscription, choose the appropriate Subscribe type in the Add screen, paste the complete subscription link in the corresponding address field, and give it a recognizable name. After saving, wait for the import to finish. Return to Home and check whether a subscription group appears and contains server entries. A group name without usable entries does not mean the import succeeded. First check that the link is complete, the response succeeded, and the subscription is still valid; then proceed to connection testing.
Subscription links may contain access credentials. Leading or trailing spaces, line breaks, or text truncated by a messaging app can prevent them from being read. A link opening in a browser does not mean it returns subscription content the client can read. If it shows a sign-in page, a general information page, or an error, check what the original link is for. Don’t try to fill the returned text into server parameter fields, and don’t post the complete link publicly for others to inspect.
Updating a subscription rereads its remote contents, so entry names, counts, and order may change. After an update, check that the currently selected server still exists; don’t assume that the connection target is unchanged just because the update finished. Keep a record of any manually entered parameters so you don’t mistake temporary changes for permanent subscription content. Before deciding how to maintain notes or configuration changes, check whether an update will overwrite them.
QR Codes, Share Links & Configuration Files
Scan QR Code is just an import method. After scanning, check the protocol, address, and authentication fields. A QR code may contain server details or a subscription link, so a successful scan alone doesn’t tell you what was imported. Share links also need to be copied in full. If multiple entries appear, identify the source and purpose of each one. The number of imported entries is not the measure of success; start with one server whose parameters are clear and that you can select.
Check rule files in Config separately from servers in Home. Importing rules does not give you a server, and importing a subscription does not mean Config already contains routing rules that suit you. For your first test, verify the server details, check the routing mode, and then test the rules. For more on protocol fields, see Protocols and Type Explained. Use your original details for connection parameters; don’t substitute example values from an article for your actual credentials.
04 / GLOBAL ROUTING
Global Routing: Three Modes & Rule Order
Check Global Routing before connecting. The three modes—Config, Proxy, and Direct—determine how requests are handled. They are not server protocols or speed settings. Switching modes won’t fix an incorrect password, an expired subscription, or an unreachable server; it changes how routing decisions are made. When troubleshooting, note the current mode. Otherwise, the same request may take different paths at different times and make the server appear to work inconsistently.
Choose Config, Proxy, or Direct
Config handles requests according to the active configuration and its rules. Use it for everyday routing when you know how requests should be handled. Rules can send some requests through a proxy, connect others directly, or reject specific requests. Proxy sends requests toward the proxy as its primary route, which can help isolate the effect of rules when checking whether a server can handle a request. Direct routes requests directly; a successful result in this mode does not prove the proxy server works. Interpret all three modes in light of the target request and actual system state.
| Mode | What it depends on | Question to check |
|---|---|---|
| Config | Rules and policies in the active configuration | Which rule matched this request? |
| Proxy | Proxy routing and the actual proxy target | Can the request succeed with rule differences ruled out? |
| Direct | Direct access on the local network | Can the local network reach this target directly? |
If a request works in Proxy but not in Config, check the rules and policy targets first; don’t immediately assume the server suddenly stopped working. Conversely, a site working in Config doesn’t necessarily prove the proxy works—it may have matched DIRECT. To test reliably, decide which route the request should take, then check which policy it actually matched. When you finish, restore your normal mode so a temporary troubleshooting change doesn’t persist.
Read rules from top to bottom
Rules are generally evaluated in order, and the first match determines what happens next. Put specific rules before broad ones. DOMAIN matches an exact domain; DOMAIN-SUFFIX matches a domain suffix; DOMAIN-KEYWORD checks for a keyword in the domain; IP-CIDR and IP-CIDR6 match address ranges; GEOIP uses the address’s geographic location; FINAL handles requests not matched earlier. Rule keywords describe the match condition, while the final policy describes what to do with the request. Read them separately.
[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThe .conf snippet above is for learning only; it is not a complete configuration and may not suit every network. The first line matches one exact domain; the second covers the relevant domain suffix; the third shows a private address range with no-resolve; the final line uses FINAL to handle remaining requests. example.com and example.org are sample domains. Understand each rule before pasting it. When editing an existing file, first check for duplicate or broader rules that are already there.
Policy Targets & Checking Whether Rules Apply
PROXY, DIRECT, and REJECT specify proxy, direct, and reject handling. If a rule uses a custom policy name, that policy must be defined in the active configuration. Don’t use a server remark as a policy name and assume the client will find the right target automatically. When reviewing a rule, check both whether it matches and where its policy points. A successful match and a successful connection are separate checks.
After editing Config, confirm you changed the active file, save it, and reload or reconnect as prompted so new tests use the updated configuration. Existing connections may continue using their previous routes, and app caching can obscure changes, so make a new request to verify. For more keyword details, see Rule Syntax Basics. Look up unfamiliar terms in the Glossary. Keep a copy of the original file and confirm each change before adding more rules.
05 / CONNECTIVITY
Connect & Verify in Stages
Verify a connection in this order: basic network, server selection, system authorization, test request, and rule match. A switch staying on only indicates that the client and system are in the corresponding connection state; it does not prove every destination is reachable. A server appearing in Home only confirms that its entry is saved. Check each state separately to avoid drastic responses—such as clearing all configuration or buying the app again—when just one site won’t open.
Start with the selected server
In Home, find the server you want to test, select it, and confirm its selection indicator. If a subscription group contains many entries, decide which one you’re testing; don’t confuse the group name with the actual connection target. If you’ve just updated the subscription, check that the selected entry is still valid. Then check Global Routing and note whether it’s set to Config, Proxy, or Direct. If Config uses a custom policy, confirm it points to the target you expect.
Turn on the connection switch at the top, complete any required system authorization, and wait for the status to settle before testing. If the switch turns off immediately, check permissions, the system VPN status, and any error shown by the app. If it stays on but requests fail, check the server and network; don’t treat these as the same problem. Avoid rapidly toggling the switch while testing: connection attempts may overlap, making prompts harder to match to the actual request.
What Connectivity Test can tell you
Connectivity Test checks connectivity under the conditions of the selected test. Interpret its result in light of the current routing mode, test target, and selected server. One successful test does not mean every site and app will work. Different test methods may use different routes and protocols, and a single number cannot replace a real request. For your first test, keep the server, network, and target fixed. Change one variable at a time so you can compare results reliably.
Run Connectivity Test first, then try a target you know should be reachable. Check that the page loads fully, not just that its title appears. If the test succeeds but the target fails, the cause may involve the target itself, DNS, rules, certificates, or app caching. If both the test and multiple targets fail, check the basic network and server parameters first. Also distinguish TCP requests from other transport requirements: a working webpage does not verify every type of communication.
Narrow down the problem based on symptoms
After disconnecting, first check that the device can reach ordinary targets on its own. Rule out incomplete Wi-Fi sign-in, unavailable cellular service, or a temporary network outage. Once the basic network is working, reconnect to the same server and compare. If the issue occurs on only one network, focus on that network’s conditions and transport requirements. If it occurs across networks, check the server address, port, credentials, and TLS parameters. Changing networks is one variable; note it in your test record and don’t change rules at the same time.
If tests succeed in Proxy but fail in Config, check the active configuration, matched rules, and policy targets first. If only one domain is affected, check whether an earlier rule overrides it and whether DNS resolves it as expected. If all entries fail at once, don’t immediately conclude every server is down. Also check the basic network, system time, shared subscription status, and recently changed common settings. Multiple entries can share a dependency, so their number doesn’t mean they’re independent.
After verification
After the connection passes, restore your usual Global Routing mode and test the same target again to make sure success isn’t limited to a temporary mode. Open Data and check that new requests use the expected policies; make sure no temporary DNS or debugging options are still enabled. For issues that persist, write down reproducible steps and consult the connection troubleshooting section of the FAQ. For a step-by-step walkthrough, see First Connection Checks. Always verify your own parameters.
Success is not one lucky test; it’s being able to explain which target you’re using, how requests are routed, and how to repeat the test. A stable baseline gives you something to compare against when analyzing Data or changing Settings. Without one, adding more options only creates more uncertainty.
06 / DATA
Monitor Data & Understand Requests
Data shows traffic activity recorded by the client. Use it to check whether a test produced requests, which targets are communicating repeatedly, and whether traffic is handled as expected. It is not your provider’s billing statement or a complete history of all network activity on the device. Before reviewing the data, check its scope, the connection status, and the test time. A rising total doesn’t prove that a page you just opened used that traffic; background sync and existing connections may also contribute.
Set a time window for your test
Before testing, note the current statistics or list, and close foreground tasks you don’t need. Then perform one clear action, such as opening a page or refreshing it once. Return to Data and look for new activity instead of guessing from the cumulative total. If you need to clear statistics, check what will be cleared and read any prompt. Keep any important information from the existing record. Clearing local statistics does not clear remote usage, change a subscription’s validity period, or affect your provider’s records.
Requests upload data too, including connection setup, request headers, and content submitted by an app. Reading a webpage does not mean uploads must be zero. Download totals may differ from a file’s stated size because of protocol overhead, caching, retries, or compression. Don’t use tiny differences in a single test to diagnose a problem. It’s more useful to compare whether the same action produces noticeably different results under the same conditions.
Connect requests, rules, and policies
If the current screen provides request or connection details, focus on the target, handling policy, and time—not just traffic volume. In Config mode, a page may request its main domain, image domains, API domains, and other resources, each matching different rules. If the main page opens but images don’t, those resources may have taken different routes; it doesn’t necessarily mean the whole server is unavailable. Identify the target for the failed resource, then check the relevant match in Config.
When you see DIRECT, first ask whether that was expected. When you see PROXY, check its actual target. Don’t infer the policy from a site’s language, appearance, or loading speed. A full domain may not always be shown; some connections may display mainly address information, and established connections may continue using earlier decisions. After changing rules, make a new request and inspect its record. That’s more reliable than expecting an existing connection to change immediately.
| Observation | What to check next | What you can’t conclude yet |
|---|---|---|
| No obvious new records after a test | Whether a new request was made and whether cached content was used | The server is definitely down |
| One target keeps retrying | Target reachability, rules, DNS, and authentication | Every app is unable to connect |
| Statistics keep increasing | Background sync and tasks still in progress | Only the current page is using the network |
| Local statistics differ from remote usage | Measurement scope, period, and calculation method | One set of records must be wrong |
Distinguish traffic volume, speed, and stability
Total transferred data shows how much has already been handled; a short-term change reflects activity over a brief period. Neither indicates long-term stability. If a page has finished loading, little new traffic may appear while it stays open. A short-lived spike may come from background activity rather than the test target recovering. To check stability, repeat the same action, see whether the error recurs, and consider the connection status instead of chasing a higher momentary number.
Keep results from different networks separate. Conditions on Wi-Fi and cellular networks can affect connection setup and transfer performance; don’t combine their cumulative statistics into one comparison. If you suspect a setting is causing repeated reconnects, record what you observe, revert only that setting, and test again. Don’t clear statistics, update a subscription, and change rules all at once. Even if the result improves, you won’t know which action made the difference.
Privacy when sharing diagnostic data
Traffic and request records may include domains, paths, device usage patterns, or authentication-related data. Before sharing, keep only what’s needed to troubleshoot and remove account details, subscription credentials, full server authentication fields, and private request parameters. A field that looks like a random string may still be a usable credential; don’t publish it just because you’re unsure what it does. After testing, stop any extra recording you no longer need to avoid keeping unrelated data.
The goal of this chapter is to build an evidence trail: identify the test action, find new requests, check the handling policy, and then decide whether to investigate the server, rules, or target. Data provides evidence, but doesn’t make those decisions for you. Combine the observed symptoms with the minimal test record from the previous chapter; this is usually more useful for troubleshooting than a screenshot showing only a cumulative total.
07 / SETTINGS
Common Settings & When to Change Them
Adjust Settings one item at a time, and only after verifying a basic connection. Don’t turn on every switch the first time you open the app. Settings work at different levels: some affect when to connect, some affect name resolution, and others affect tests and records. Before changing one, write down the issue you want to address and check the item’s description and current value. If an item mentioned here isn’t on your screen, use what your device actually shows. Don’t guess at a similarly named feature or apply every setting from another configuration.
On Demand: connection triggers, not server repairs
On Demand triggers connections based on conditions. Its behavior also depends on the system VPN configuration, network changes, and device management. First confirm that manual connections work reliably, then consider enabling it. Otherwise, faulty server parameters and automatic triggers can combine to cause repeated connection attempts, changing switch states, or inconsistent results after a network change. On Demand controls when a connection is attempted; it does not fix an unavailable server.
Before enabling it, be clear about what you expect: which network conditions should trigger a connection, when it should stop, and what should happen after you disconnect manually. After changing the setting, test real scenarios separately, such as using the app in the foreground, switching networks, and waking the device. Check the system’s actual behavior; an enabled switch in Settings does not prove that every condition is working. When troubleshooting automatic reconnects, temporarily return to manual connections to separate trigger behavior from server issues.
DNS: distinguish resolution failures from connection failures
DNS resolves domain names to addresses; successful resolution is only one prerequisite for connecting. A domain that won’t resolve is a different problem from a connection that fails after an address is returned. First check whether the issue affects only domain-based requests, then review DNS-related settings in both the active Config and Settings. A file configuration and the interface settings may both affect the result. Refer to the current item descriptions and actual request behavior; don’t check only one place and assume the other has no effect.
More DNS options do not necessarily mean better results, and changing them at random won’t improve access to every target. The resolver itself must be reachable, and its returned addresses must work with the intended routing. If only some targets fail after a change, note their domains and the old and new settings, then restore the original values for comparison. Successful access by direct IP does not prove domain resolution is working. A test page displaying content also doesn’t rule out different domains or cached data in the app’s actual requests.
Testing, logging & certificate settings
The test target and method affect how to interpret Connectivity Test. If you change a test setting, keep its original value and verify the new one with a target whose purpose you understand. If the target is unavailable, the result may reflect a problem with that target, not the server. Use logs and diagnostic records temporarily for a specific issue. Longer and broader recording isn’t necessarily easier to analyze. When testing is complete, check for unnecessary detailed logging and handle existing records with privacy in mind.
Take particular care with certificate and HTTPS settings. A standard server connection or basic routing rule is not a reason to enable decryption inspection. If you encounter a certificate error, first check the device time, target domain, and server TLS parameters; turning off verification is not a routine fix. If you don’t understand what a certificate option does, leave it as is and read its current description. Don’t change the device’s trust decisions just to make one error message disappear.
Setting scope & how to revert changes
After every change, know whether the value applies to one server, a Config file, or the app as a whole. Changing transport parameters for one server doesn’t update other subscription entries. Switching Config doesn’t necessarily restore every app setting. A simple note of each setting’s scope can explain why a problem persists after switching servers or why the result changes when you use another configuration file. When troubleshooting a shared issue, check the settings layer common to the affected items first.
To revert changes, undo them in reverse order, one at a time, and test after each—don’t reset everything at once. If you need a reset, back up your servers and configuration first, confirm where sensitive information is stored, and note which values you’ll need to enter again. The goal of Settings is predictable behavior, not more options. Keep only changes whose purpose you can explain. Look up unfamiliar interface terms in the Glossary before deciding whether to change them.
08 / MAINTENANCE
Subscription Updates, Backups & Maintenance
Good maintenance preserves a verified working state and makes every change traceable. App updates, subscription updates, rule edits, and device migration are separate tasks; don’t combine them into an unrecorded trial-and-error session. When something goes wrong, first identify what changed most recently, then make the smallest necessary correction. If you can still reproduce a basic connection, there’s no need to delete every server and configuration for one isolated issue. Maintenance should reduce uncertainty, not make you start over.
Handle app and subscription updates separately
Update the app through the App Store, and refer to its product page for current compatibility and details. Updating the app does not confirm that a subscription is still valid or guarantee that a remote server’s status is unchanged. Subscription updates retrieve content from your provider; the two updates have different sources and purposes. Record the current connection result, perform one kind of update, and test again. Once that works, proceed to the next update so you can link any issue to a specific change.
Before updating a subscription, note any manual changes you need to keep. Afterwards, check the group contents, selected entry, and targets referenced by your rules. If names or entries have changed, records based on names may no longer be accurate; recheck the address and purpose. If an update fails, don’t delete the existing group right away. First check whether its old entries still connect, then inspect the subscription link, basic network, and returned content. Keeping a working state helps distinguish an import problem from a server problem.
Back up content and credentials separately
Before backing up, list what you need to preserve: server details, subscription links, Config files, original values for necessary Settings, and the App Store account associated with the purchase. If you use the app’s current export feature or save files through the system, check exactly what it includes; don’t assume one file contains every setting. Afterwards, confirm you can find the files, their names are clear, and their location is suitable for long-term storage. A backup you can’t access does not prepare you for restoration.
Configuration files and shared content may contain passwords, user IDs, or subscription credentials; don’t store them publicly as if they were ordinary documentation. Remove sensitive details from copies used to discuss a problem. Keep the necessary fields in backups intended for restoration and protect them appropriately. These copies serve different purposes; don’t rely on a redacted diagnostic copy as your only recovery file. If credentials were exposed accidentally, ask your provider what to do and check whether the old details are still valid.
Restore in stages when switching devices or reinstalling
On the new device, first get the app from the App Store. Check the App Store page for system requirements and purchase eligibility, then open the app and review its actual state. Restore one server or subscription, complete system authorization, and verify a manual connection. Once that works, restore Config and your everyday Settings, then test On Demand. Don’t import everything at once and judge restoration by the connection switch alone; an old setting may only affect behavior after a network change.
A configuration that worked on an old device may have depended on its network, system permissions, or server details that are still valid. If the new device behaves differently, compare these prerequisites instead of assuming the file is damaged. Keep the working records on the old device, and compare server parameters, Global Routing, and the active Config one at a time. Handle sensitive data on the old device only after confirming restoration is complete. See Restore a Purchase for App Store purchase recovery. Don’t treat restoring a purchase and migrating a configuration as the same step.
Use a consistent review and troubleshooting process
After each important change, repeat the same checks: confirm the server, verify Global Routing, test Connectivity Test and the actual target, check that Data shows the expected policy, and turn off temporary debugging options. If the problem returns, stop making changes and write down what changed between the last working state and the first failure. This helps narrow down the cause and prevents a temporary setting from remaining enabled for days, leading you to troubleshoot from the wrong assumptions next time.
When asking for help, include the device type, network conditions, routing mode, whether the issue is reproducible, checks you’ve already tried, and any error message without credentials. Avoid vague descriptions like “can’t connect” or “it’s slow,” and don’t make a full backup your first attachment. Return to the relevant chapter based on where the problem occurs: for import issues, check servers and subscriptions; for routing issues, check Global Routing; for switch or request problems, check connection verification; for automatic triggers, check Settings.
You should now have a complete workflow: App Store purchase confirms the app, first-use authorization sets up the system, server details provide a connection target, Config determines routing, tests and Data provide evidence, Settings control behavior, and backups and records make recovery possible. You don’t need to repeat the whole process every day. When something changes, start with the affected layer. For quick steps, see the Setup Tutorial; for common questions, see the FAQ; for rule details, continue with the related guides on this site.