Official Manual / Reference
Shadowrocket Complete User Guide
Work through setup, permissions, imports, routing, and maintenance step by step. Identify the current stage before changing anything.
This guide explains how the steps fit together, parameter limits, and troubleshooting order. It is designed for reference after your first successful connection. For a quick setup, start with the Getting Started guide; return to the relevant section here for specific fields or rules. The instructions assume you already have your own subscription or server details.
- Supported devices iPhone / iPad
- Available from App Store
- Reading order Eight stages
Stage 01 / Verify the app
Get Shadowrocket from the App Store
Shadowrocket is a paid, closed-source app for Apple platforms, primarily used on iPhone and iPad. Before getting started, distinguish the app from a server and a config: the app establishes connections and applies rules, a server provides a connection endpoint you already have, and a config determines how traffic is handled. Buying the app does not provide the other two. Identify what you still need before proceeding; a completed purchase does not mean a connection is ready to use.
Open the App Store from the download guide
Open the App Store purchase and verification guide, then use its store button to visit the product page. Check that the app is named Shadowrocket, then verify the developer information. Don’t rely only on a shortened name or icon color in search results; similar listings may belong to different products. The download guide explains how to purchase and verify the app. This manual covers configuration after verification and does not offer another way to get it.
Check all three details to verify the app: the developer is Shadow Launch Technology Limited, the official icon matches the one in this site’s header, and the product page URL includes app ID 932747118. The icon is only one check; it does not replace verifying the developer and app ID. If any detail doesn’t match after opening the page from search results, leave the page, return to the download guide, and open it again before deciding whether to buy.
Check the price and compatibility
Shadowrocket is a one-time purchase. The US storefront price is $2.99 as a reference; the actual price, taxes, and currency are shown on the App Store product page and purchase confirmation screen. Prices in different storefronts cannot be compared by amount alone, and the reference price in this guide is not proof of what you will be charged. If the page shows a re-download icon, first check whether the current account already has a purchase record; there’s no need to buy it again.
System requirements are always as listed on the App Store product page. Before purchasing, check the compatibility section for your device and OS, then make sure you have enough storage. Compatibility and purchase availability for Mac, Apple TV, and Apple Vision are also as listed on the App Store page; get the app on those devices from the App Store as well. The steps below focus on iPhone and iPad, so don’t assume the same controls are in the same places on other devices.
Prepare after installation
After purchasing or re-downloading from the store, wait for the app to appear on your Home Screen, then open Shadowrocket. An empty list at this point means no server has been imported yet; it doesn’t mean the purchase failed. Have your existing subscription URL or individual server details ready, and make sure they’re still valid. Don’t enter purchase credentials as a server password or use your App Store account password as connection credentials.
Connection details usually include an address, port, protocol, and authentication fields; the exact combination depends on the server. If you only have a subscription link, first confirm that it provides subscription content for a client to read, rather than a login page for your provider’s account. Ask your provider to clarify any fields you’re unsure about. Example domains in this guide illustrate the format only; don’t use them to test a real service or replace your own credentials with sample values.
When changing devices or reinstalling, first look for Shadowrocket in your App Store account’s purchase history. Purchase history and in-app data are separate: being able to re-download the app does not guarantee that servers, configs, or usage data will be restored. Make sure you still have valid connection details before restoring. If the old device is still available, organize your subscription sources and config backups before transferring to the new device; erase content from the old device only afterward.
You’re ready to move on when you’ve verified the app, installed it, and prepared your existing connection details. An incompatible store listing, incomplete payment, or missing purchase record is an App Store access issue; see the restore purchases guide or FAQ. Changing routing rules won’t fix store access, because those settings are unrelated to purchasing or installing the app.
Stage 02 / Set permission boundaries
First launch and VPN permissions
Start by learning what each screen is for. Home manages servers and connection status; Config manages config files; Data shows usage; Settings contains related options. The layout may vary by device or app version, so follow the labels on your current screen. Identify which screen you’re on before looking for a setting. This helps avoid confusing Config on the Config screen with Config as a Global Routing option.
What system authorization does
When Shadowrocket connects, iOS manages its VPN configuration. The first time you turn on the connection switch, iOS may ask to allow adding a VPN configuration. Read the app name and prompt, confirm they match the action you just took, then grant permission and complete any device verification requested by iOS. This allows the app to establish the relevant network connection; it does not confirm that the server is available or guarantee that a particular website will use the proxy.
If you canceled the permission prompt, return to the app and avoid rapidly toggling the connection switch. Confirm that a default server is set, then try connecting again and watch for the prompt. If the device is managed by an organization, its policies may restrict adding VPN configurations; check with your administrator. Don’t delete all system network settings to solve a permission issue. First determine whether permission was canceled, blocked by a policy, or the connection details are incorrect.
After granting permission, search for VPN in system Settings and check whether the relevant configuration appears and what its status is. System menus can change, so use search on your device. Don’t judge connection status only by whether an icon appears in the status bar; its visibility can vary by screen layout. Check the in-app switch and system connection status, then confirm with an actual access test.
Distinguish required permissions from action-specific permissions
When using Scan QR Code, the system may ask for camera access. You only need to grant it when scanning your own server or subscription QR code. If you haven’t granted camera access, you can use an existing link or enter the details manually; lack of camera access doesn’t prevent every import method. QR codes may contain complete authentication details, so verify their source before scanning. Check the type and address after importing, and don’t publish the QR code image.
When reading a link from the clipboard, the system may show a paste notification. Copy only the content you intend to import, then use the app’s paste or import action. Extra explanatory text, line breaks, or spaces in the clipboard can cause parsing to fail. Don’t put a subscription URL on a public webpage to get around a prompt. Go back to the original details, copy the full link again, and import it using the option shown in the current interface.
Importing files or cloud content depends on the source you choose and the permissions granted by the system. Opening the file picker only confirms that the app can access the selected file; it doesn’t mean the file format is suitable for that import option. Subscriptions, config files, and server QR codes serve different purposes, so use the corresponding import option for each. For content from your own cloud backup, check the file name and purpose before deciding whether to replace the current config.
First-run checks, in order
For initial troubleshooting, keep On Demand in a state you understand and control the connection manually. Automatic triggers can make the connection turn back on soon after you turn it off. Check On Demand before assuming the app is malfunctioning. Once a manual connection is stable, configure automatic connection conditions as needed and confirm that they behave as expected when switching networks.
If another VPN connection is configured on the device, check in system Settings which configuration is currently active. Don’t change multiple connection settings at once and guess which one took effect. Note the current state, temporarily disable connections unrelated to this test, then verify the result. Restore them afterward as needed. Follow your organization’s device management requirements; don’t delete managed network settings that may be needed for other purposes.
At the end of this stage, you should be able to identify the current screen, whether VPN configuration permission has been granted, whether On Demand is enabled, and what additional permissions an import requires. If the app opens but there’s no server, continue to the next chapter. If a server is available but the system won’t establish a connection, resolve the permission issue first. If permissions are fine but the connection still fails, check authentication and network access rather than repeating the same step at the wrong level.
Stage 03 / Prepare a connection
Add a server or import a Subscribe link
A server is a specific connection endpoint; a subscription is a source for a group of server details; and Config describes routing and related settings. They work together but aren’t interchangeable. First identify what you have: protocol, address, port, and authentication details can be added manually; a client share link should be imported using its corresponding option; and a subscription URL belongs in Subscribe. Don’t guess what something contains based only on its file extension.
Check the Add Server fields
Find the add option in Home and open Add Server. Select Type first, then fill in Address and Port from your details, and finally verify the authentication and transport parameters required by that protocol. The selected type determines what the fields mean, so changing it after filling them in can leave parameters missing. After saving, return to the list and reopen the entry to make sure auto-fill or clipboard content didn’t overwrite anything.
Address usually takes a domain name or IP address, while Port is entered separately as a number. Unless a field explicitly requires a complete URL, don’t put the protocol prefix, path, and port in Address. The server’s domain, TLS verification name, and transport Host may be the same or different; enter each one as specified rather than assuming they match. If authentication fails, first check which value belongs in each field, then make sure nothing was truncated.
| Type | Check carefully | Commonly confused fields |
|---|---|---|
| Shadowsocks | Address, port, encryption method, password | The encryption method must match the server |
| VMess / VLESS | Address, port, UUID, transport, and TLS parameters | A UUID does not replace transport settings |
| Trojan | Address, port, password, and TLS parameters | The certificate verification name may differ from the connection address |
| Hysteria2 | Address, port, authentication, and TLS parameters | Also confirm that the current network allows the relevant UDP traffic |
This table highlights key checks; it does not list every optional field for each protocol. For additional transport paths, Host values, or other parameters, follow your server details and the field descriptions in the current app. Don’t copy a password from one protocol into an identity field for another, and don’t disable certificate verification to hide a name mismatch. Correct the configuration first, then check whether the server side needs adjustment.
Import an existing subscription
If you have a subscription URL, choose Subscribe in the add flow, enter the complete URL in the appropriate field, save it, and wait for the update result. Subscription URLs may contain account-identifying parameters, so treat them as sensitive information. Don’t post the full link in a public discussion, or remove query parameters just to make it easier to remember. The address structure shown below is an example, not a usable service.
https://example.com/sub?token=xxxxAfter the update, return to Home and check whether the subscription group and server entries appear. Confirm that their types and names match your details. More entries only means the content was read; it doesn’t mean every endpoint can connect. If the update fails, check that the link is complete and valid, and that the current network can reach it. If the update succeeds but no entries appear, check whether the response uses a subscription format supported by the app.
Don’t use your provider’s account dashboard URL as a subscription URL. A dashboard usually contains a login or management page, not a server list. If the import reports that the content can’t be recognized, check its purpose in your own account rather than repeatedly adding the same URL as new groups. Adding it again won’t fix a format issue and can make it harder to identify the default server and subscription source for future updates.
QR codes, default servers, and update behavior
After using Scan QR Code, check the parsed result before saving. A QR code may represent either a single server or a subscription; its format alone doesn’t tell you which. QR codes from an old device also need checking in case the authentication details have changed. If scanning fails, check that the image is clear and the full QR code is visible. Don’t crop off part of it and try again, or upload an image containing authentication details publicly.
After importing, tap the circle beside the target server in Home to make it the default. Before connecting, check the selection indicator again instead of assuming the last entry you edited is the active one. A subscription update may replace or remove entries, so verify the default selection afterward. For guidance on choosing a server and understanding latency, see Choosing a Server and Testing Latency.
Before editing a subscription entry locally, check whether a future update will overwrite your changes. If you need a separate test entry, save it using the app’s available management options and note how it relates to the subscription source. If you have only one working connection, don’t delete it before adding a replacement. Test the new details first, then remove the old entry. You’re ready to move on when you have a clearly identified source and a complete, selectable server.
Stage 04 / Choose where traffic goes
Global Routing modes and rules
Global Routing determines how traffic is handled for the current connection. The three common modes are Config, Proxy, and Direct. Selecting a server only specifies which endpoint a proxy connection uses; it does not determine whether every request goes through it. When troubleshooting, note the default server, routing mode, and active config. Without these details, results for the same website under different modes can’t be compared meaningfully.
Select a mode before interpreting results
| Interface option | What it does | What to check |
|---|---|---|
| Config | Applies the rules and related policies in the current config | Whether the target matches the expected rule |
| Proxy | Uses the proxy as the primary routing method | Whether the selected server can connect |
| Direct | Uses a direct connection | Compare against direct access on the current network |
To use rules for routing, first review the file on the Config screen and select it, then set Global Routing to Config. Importing a config file doesn’t necessarily make it the active file. If changing a rule has no effect under Proxy, check the routing mode before moving the rule again. The selected mode determines whether rules are applied to current traffic.
Some interfaces also include a Scene option. Think of it as a feature for organizing behavior around configured conditions, not a general-purpose replacement for the three routing modes. If you don’t need a specific scene, use the three basic modes to validate the connection first. When automatic scenes and On Demand are both involved, check the conditions for each before diagnosing a state change; not every automatic action is caused by rule matching.
Rule order and fallback behavior
Rules are usually checked from top to bottom, and the first match determines what happens next. Put specific targets first, broader conditions later, and FINAL last as the fallback. PROXY and DIRECT are rule policy keywords; they’re not the same as the Proxy and Direct options in the interface. Preserve the original capitalization and comma-separated format when editing. Don’t put explanatory text in a rule field.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYThis example sends the example domain and its subdomains to PROXY, routes the specified private address range through DIRECT, applies the GEOIP condition to matching addresses, then sends remaining traffic through PROXY. It’s a .conf snippet for illustrating rule order, not a complete config for every network. When adding it to an existing file, edit the existing [Rule] section, keep other required sections, and don’t stack multiple fallback rules.
| Keyword | What it matches | Notes |
|---|---|---|
| DOMAIN | An exact domain name | Consider a separate rule if subdomains should also match |
| DOMAIN-SUFFIX | A domain suffix and its subdomains | Usually easier to scope narrowly than keyword matching |
| DOMAIN-KEYWORD | A keyword in a domain name | Broad matching; check for unintended matches |
| IP-CIDR / IP-CIDR6 | IPv4 / IPv6 address ranges | Check the actual destination address and address family |
| FINAL | Traffic not matched by earlier rules | Put it at the end of the rules |
Limit the scope of changes
Domain rules take a domain name, not a webpage path or full URL. The protocol prefix, path after the slash, and query parameters in a webpage address don’t belong in the DOMAIN-SUFFIX domain field. In an IP rule, no-resolve prevents that rule from triggering an extra domain lookup; it doesn’t disable DNS for the entire config. If the target actually uses IPv6, checking only IPv4 ranges won’t explain all requests.
Before editing, duplicate the current config and add one condition at a time, each with a clear purpose. Make sure the file saves and is selected, then test against a fixed target. If the result differs from what you expect, check whether an earlier rule matched, whether the page requests other domains, and whether the connection is still using an existing session. Refreshing the page may reuse an existing connection; reconnect after saving, then repeat the same test.
To proxy only specific websites, you can use explicit domain rules and fall back to FINAL,DIRECT. Keep in mind that a page may also load login, image, and media resources from separate domains. Don’t broaden keyword matching until its scope is impossible to explain just because one resource fails. See Config Rule Examples for Specific Websites for step-by-step guidance. Make the smallest change first, then expand the rules based on actual requests.
Stage 05 / Verify in layers
Connection switch and Connectivity Test
Check connection status in three layers: system authorization, server connectivity, and access to the target. Turning on the switch only confirms that a connection was initiated; a VPN status shown by the system doesn’t mean every destination is accessible. Fix one server and one routing mode, then run a repeatable test before expanding your checks. If you change the server, network, and config all at once, you won’t know which change affected the result.
Start with the shortest connection path
Return to Home and confirm that the target server’s selection indicator is on, then check Global Routing. To test basic server connectivity, temporarily select Proxy and note the original mode so you can restore Config afterward. Turn on the connection switch, respond to any system permission prompt, and wait for the status to stabilize. Don’t keep switching servers while a connection is being established; that mixes the status and errors from different attempts.
Next, run Connectivity Test and check the result and any error shown in the current interface. It checks a specific test operation; it doesn’t guarantee that every website will work. If the test fails, check whether the error indicates a timeout, a resolution failure, or an authentication issue. If it passes, try a destination you’re authorized to access and can normally reach. The in-app test and real-world access complement each other; don’t draw conclusions from only one.
Latency tests also depend on the method used. Different methods may check connection setup, a protocol handshake, or the round-trip time for a particular request, so results can’t be compared without knowing the method. Low latency doesn’t guarantee sustained download speed or stability at peak times. For a fair comparison, keep the network, test method, and timing consistent, and repeat the test. Don’t treat one unusually low result as typical performance or assume a timeout means the details are permanently invalid.
Troubleshoot at the right layer
If the switch won’t stay on, check whether the system allows the VPN configuration, whether device management restricts it, and whether another connection is active. If the switch works but all requests fail, check the address, port, authentication details, and protocol type. If it fails only on a particular Wi-Fi network, check whether a web sign-in is required, then compare with cellular data. Reconnect after changing networks so you’re not judging based on an old connection state.
For authentication errors, check the password, UUID, or other identity field first. Watch for leading or trailing spaces and line breaks when copying. For a connection timeout, check the server address, port, and network reachability. For TLS errors, verify the name, device date and time, and server details. Don’t disable verification as soon as you see a TLS error; it may point to a configuration mismatch. Correct the mismatch before testing again.
If Proxy works but Config doesn’t, check rules, policy references, and DNS-related settings before considering another app purchase. If Direct works but Proxy doesn’t, focus on the selected server and its connection path. If both fail, first rule out an issue with the destination or local network. These comparisons help narrow down the cause but don’t, by themselves, prove that a device or service is working properly.
Handle partial success and stale sessions
If text loads but images or video don’t, inspect the resource requests instead of checking only the page’s main domain. Login redirects, media, and APIs may use different domains or connection paths. First check whether the main page and failed resources use the same route, then consider adding rules. Browser cache can also make old content appear to work; use a new request to check the current state.
After switching from Wi-Fi to cellular, existing connections may need to be re-established. Check that the new network works, then turn the connection off and on again and repeat the same test. For protocols such as Hysteria2 that use UDP, also consider whether the current network supports the relevant traffic. Don’t adjust a large number of protocol parameters to work around a network restriction. Note what differs between networks, then check with your own provider.
If you need help, note the device OS, current network, server protocol, routing mode, test target, and exact error message—but remove subscription URLs, passwords, UUIDs, and other authentication details. Describing what you did and what happened is more useful than simply saying “it won’t connect.” For the first connection workflow, see First Connection Check; for common issues, see the FAQ. You’re done with this stage when the test is repeatable, not just when a page happens to load once.
Stage 06 / Understand usage data
Reading Data and interpreting usage
Data shows network activity recorded by the app; it isn’t a carrier billing page. Before comparing values, confirm the view, what’s being counted, and the time range. Upload is data sent from the device, while download is data received. A total is the sum over a period; a rate reflects activity at a moment or over a short window. These values aren’t interchangeable, and a single number can’t tell you whether a connection is healthy.
Check the current Data view
When you open Data, start by checking the selected view. The server view shows which connection is carrying traffic; the app view shows which sources of requests the app can identify and categorize. These aren’t two ways of sorting the same bill: their coverage, categorization, and starting point may differ. Don’t add every row together or match them one by one without first confirming what each view measures.
If a list item can’t be clearly identified, treat it as a limit of the app’s current identification and connection records—not immediate proof of an abnormal process. System services, background activity, and in-app requests can all make names less obvious. Consider when the activity occurred, which apps were open, and what the connection was doing. A displayed name alone doesn’t reveal the full contents of a request or replace checking the device’s app permissions.
Before reading a total, check whether the interface specifies its time range, whether it has been manually cleared, and whether the value continued after an app restart or data restore. If no starting point is shown, don’t label it “this month’s usage.” Data from different devices shouldn’t be assumed to be continuous. For long-term tracking, record your own start date and readings, then compare the same time ranges without assigning unsupported billing periods to the numbers.
Why Data may differ from your bill
A carrier measures billable traffic on its network; Data records activity the app can observe. Protocol overhead, connection maintenance, retransmissions, and requests that don’t follow the same processing path can all create differences. The device may also switch between Wi-Fi and cellular, so usage from both networks shouldn’t be treated as one billing period. Data can help you understand trends, but your carrier’s records determine charges and allowances.
Server-side usage may also be measured differently—for example, by direction, billing period, or individual session. Don’t use one client-side reading to infer your provider’s billing formula. If you need to investigate a difference, first align the time range, units, and direction, then ask your provider. Without a shared measurement method, a difference in the numbers alone doesn’t show that either side is wrong.
| What you see | Check first | What you can’t conclude from it |
|---|---|---|
| Switch is on, but usage is low | Whether there are new requests, or traffic is using Direct or cache | Low usage alone doesn’t mean the connection has failed |
| Upload keeps increasing | Cloud sync, file uploads, and background activity | Traffic direction alone doesn’t indicate a problem |
| The total changes | View, reset action, and tracking start point | It isn’t automatically usage for the current billing period |
Observe the change with a repeatable action
To check whether an action generated traffic, note the reading first, perform one clearly defined action, wait for the interface to update, then check the difference. Pause unrelated large file syncs or media playback during the test to reduce background noise. Don’t attribute every increase over a short period to a page you just opened; background apps may also be communicating. Repeat the same action if needed and compare the results.
A switch that’s on with little visible usage doesn’t necessarily mean the app has stopped working. A page may load from cache, use a direct route under the current rules, or simply make no new requests. Conversely, usage can increase when the screen is idle because of normal background sync. Before drawing a conclusion, check Global Routing and Config to confirm the expected route, then use Data as supporting information—not as a substitute for checking routing.
A changing instant rate reflects a short observation window, not long-term bandwidth. Video buffering, segmented downloads, and short connections can all produce a high reading followed by a lower one. Compare performance using the same task and similar network conditions; don’t compare a cached load with a complete download. Check the units too: bytes and bits are different, so numbers can’t be compared without accounting for the displayed unit.
Before clearing Data, save any readings you need and check what will be reset. Clearing changes the displayed statistics or related records; it won’t reset server authentication or fix connectivity. Hide any details that could identify your account or server before sharing a Data screenshot. For more on the views, see Understanding Data Usage Readings. The goal here is to interpret the numbers correctly, not to replace your bill with app statistics.
Stage 07 / Manage setting changes
Settings, DNS, and On Demand
Change Settings only to address a specific issue; don’t turn options on one by one. First define the result you want, such as connecting under certain conditions after a network change, fixing domain resolution, or changing the test method. Then find the relevant option. A config may also contain related settings, so identify where an option comes from before changing it. If both app settings and the current config affect the same behavior, check the interface guidance and test to see which one takes effect.
On Demand: when it connects and stops
On Demand lets the system initiate connections under configured conditions; it isn’t a general fix for server problems. Before setting it up, verify that the same server connects in manual mode. Then configure only the conditions you actually need. Choose from the network types, network names, and other match criteria available in your current interface. Don’t assume an option you’ve seen elsewhere is available on your device.
After setup, test both matching and non-matching scenarios, and check what happens when switching networks. If the connection turns back on after you turn it off, check whether the trigger conditions are still met. To pause automatic behavior for a test, disable the relevant triggers before disconnecting manually. Repeatedly pressing the Home switch can interact with automatic conditions and make it seem as though disconnecting didn’t work.
Automatic connections still require a valid server and a working network. After waking from sleep, switching networks, or joining Wi-Fi that requires a web sign-in, the system status and actual access may not update at the same time. Sign in to the network before testing the connection. Overly broad conditions can trigger on networks where you don’t need them; start with the fewest conditions, confirm the behavior, then expand them as needed.
Check the problem before changing DNS
DNS resolves domain names to addresses and is one part of the connection path. If a domain won’t open but an address is reachable, that may point to a resolution issue—but it isn’t conclusive, because certificates, virtual hosts, and service access methods can also differ. Consider the error, resolution result, and routing mode together. Don’t attribute every website failure to DNS, or stop troubleshooting just because a different DNS setting happened to work once.
Before changing DNS, note its current source and value. If it comes from the selected Config, copy the config before editing it. If you’re changing it in the app, record the relevant screen and option. Change only the setting under investigation, save, reconnect, and make a new request. Existing connections and cached results may persist, so test a new session rather than relying on a page that has already loaded.
Don’t use a DNS address in place of a proxy server address, or vice versa. DNS resolves names; a proxy server address establishes the proxy connection. Domain rules, IP rules, and resolution behavior are also related, and whether a rule needs resolution depends on its type and parameters. If you see no-resolve, interpret it in the context of that rule; it doesn’t describe how the entire app handles network traffic.
Protocols, TLS, and test options
TLS settings should match your server details. Check the verification name, transport requirements, and device time. Don’t lower verification requirements to avoid correcting inaccurate details. For protocols or features that use UDP, confirm that both the current network and server support the relevant traffic. If something doesn’t work on one network, compare networks first, then check protocol requirements; don’t assume every failure calls for “more advanced options” in the app.
When changing the latency test method, read the current option description and compare results using the same method. The test target’s availability can affect readings, so failure with one method doesn’t necessarily mean all requests will fail. Likewise, a successful test doesn’t prove that other destinations or long transfers will work. For an overview of Hysteria2’s transport limits, see The Hysteria2 Protocol Explained.
Before enabling more detailed diagnostic logging, consider that logs may include domain names, addresses, and connection details. When troubleshooting is finished, restore your usual logging level if appropriate so you don’t retain more data than needed. When sharing an error, include only the relevant redacted lines; don’t send a complete config containing subscriptions and authentication details. Others need to understand the failure path, not gain access to your connection.
You’re done with this stage when you can explain the purpose, test, and rollback steps for each change—not when you’ve turned on more switches. If a change doesn’t help, restore the original value before checking something else. If you’ve lost track of which changes are still active, return to the most recent working config copy and establish a stable baseline before testing again in the order described in this chapter.
Stage 08 / Keep a recoverable setup
Updates, backups, and routine maintenance
The goal of routine maintenance is to know what you’re using, where your details came from, and how to return to a working state if something goes wrong. Server subscriptions, Config files, and app updates are separate processes: subscription updates change server details, config updates change routing and related settings, and App Store updates change the app. Success in one area doesn’t mean the others have changed too. Identify which layer you’re working on before making changes; don’t redo everything at once.
Handle the three types of updates separately
Before updating a subscription, check its source and whether it’s still valid. Afterward, check whether entries were replaced, whether the default server is still selected, and whether protocol parameters changed; then test the connection. If the subscription update fails, keep existing working entries rather than deleting the entire group. If a server still connects but the subscription won’t update, the problem may be limited to retrieving the subscription content. Troubleshoot those paths separately.
Before updating Config, save a copy of the current working file and verify the purpose and source of the new content. If you added local rules to the old config, an update may change them; compare the relevant sections first. After saving, confirm that the intended file is selected and test key destinations. Similar file names don’t mean two configs are equivalent; rules, policies, and related settings determine how they behave.
Update the app through the App Store, using the device’s automatic update settings or the store’s update option. After updating, check that your existing details still work, then test a commonly used connection. If behavior changes, review the current interface guidance and update notes provided by the store. Don’t assume from memory that a particular version must have fixed or introduced an issue. This manual doesn’t maintain a list of version numbers or release dates.
Back up your details and move to a new device
Keep server details, subscription URLs, and complete configs distinct when making backups. A copy of a rule snippet usually won’t restore all authentication and connection parameters; a subscription URL may not include servers you added manually. Use the app’s current export or backup options and check what they include. After creating a backup, make sure the file opens and its contents are complete, but don’t test it by overwriting your only working config.
Backups may contain passwords, UUIDs, subscription parameters, and other authentication details, so store them somewhere protected that you control. Use a descriptive file name without including complete credentials. For transfers between devices, use a storage and transfer method you trust, then delete temporary copies when you’re done. Before asking for help with a config, make a redacted copy. Keep the original backup in your own storage instead of attaching it publicly.
When moving to a new iPhone or iPad, restore the app from the App Store first, then restore your details, and finally grant VPN permission on the new device. Purchase history, app data, and system permissions are separate; don’t assume they’ll all transfer together. Keep the old device until the new one passes connection and rule checks, then clean it up as needed. Compatibility and purchase availability are as listed on the App Store page. For restore issues, see the Restore Purchases section.
Keep a concise troubleshooting log
A troubleshooting log can be brief, but should include a recognizable server name, protocol, routing mode, config name, network, and test result. Never include real credentials. When something breaks, think back to the most recent change: a subscription update, rule edit, system permission change, or network switch. Identifying what changed makes it easier to test the relevant layer than to re-enter every field.
Check in this order
1. Is the current network working?
2. Is the default server still selected?
3. Is Global Routing set as expected?
4. Is the expected Config file selected?
5. Do Connectivity Test and real-world access agree?
6. Can you restore the last change to its previous state?You can tidy up entries you no longer use, but first check whether they’re still selected by default or referenced by a policy or config. Keep a recoverable copy before deleting an old config, and verify the new source before removing an old subscription. Clear names matter more than having fewer entries: distinguish everyday configs from test configs so you don’t select an unverified file by mistake, especially at night or on an unstable network. Save any usage readings you need before clearing statistics.
If several destinations fail, check their shared connection path. If only one fails, start with that destination and its rules. When contacting your provider, include the protocol, network, and a redacted error message; don’t send App Store account details. For app purchase issues, return to the download guide. Look up terms in the glossary, or return to the Getting Started guide for the main workflow. Address each issue in the relevant section to avoid mixing problems from different layers.
After maintenance, return to your usual setup. Check the On Demand conditions, default server, and active Config, then make a new test request. Restore any temporary switches, note issues that still need watching, and keep the most recent working copy. The eight stages in this manual can be repeated as needed: identify the connection, grant permission, import details, choose routing, test, review usage, adjust settings, and save. Reinstalling repeatedly is no substitute for troubleshooting each layer.