1. App Store Purchase and Verification
First confirm you have the right app, then prepare your connection details. Shadowrocket is a closed-source commercial app for Apple platforms, available exclusively through the App Store. Purchasing the app gives you the right to use the client; access to your own subscription or server is a separate matter. Keeping these separate helps distinguish a purchase issue from a connection issue, and avoids mistaking the absence of a server to select after installation for a failed purchase.
Check three details on the App Store product page
Open the product page from our App Store verification guide, then check the app name, Shadowrocket; the developer, Shadow Launch Technology Limited; and the app ID in the page URL, 932747118. Also compare the icon with the official app icon shown in our site header. Similar names in search results are not enough to verify the app. Complete these checks on the same product page, then review the purchase button, compatibility, and app description.
The icon, developer, and app ID on the product page help identify the app. Do not rely only on search ranking or a Chinese nickname in the name. If the developer shown on the page does not match, return to the verification steps before continuing; do not assume that subsequent permission or purchase screens belong to the same app. When checking, distinguish the app name from the developer name: they are separate fields.
Price, devices, and purchase eligibility
Shadowrocket is a one-time purchase. The US storefront price is about $2.99; the actual price, currency, and taxes depend on what the App Store page shows. Before purchasing, check the Apple Account used for App Store purchases and the storefront it is set to. Keep the purchase record provided by the system after checkout. The price says nothing about connection quality and does not indicate a server's validity period, available traffic, or supported regions.
This guide focuses on iPhone and iPad. You can also check the compatibility section on the same product page for Mac, Apple TV, and Apple Vision. Always refer to the App Store page for system requirements and purchase eligibility. Successful installation on one device does not guarantee compatibility with another. Before using the app on a second device, check its system, the purchase record, and the compatibility details separately.
Installation, restoring purchases, and updates
After purchase, install the app from the App Store. To reinstall it or move to another device, check your purchased items using the original purchase account and follow the store's restore options. If the page still shows a price, first verify the account currently used for App Store purchases, the purchase record, and the product. Do not pay again immediately. The account used for other system services may differ from the one used for App Store purchases; check the actual purchase record.
Restoring the app and restoring connection settings are two different things. The App Store can help you recover a purchased app, but check server addresses, subscription contents, the currently selected configuration file, and local rules separately according to how you originally saved them. Do not assume reinstalling will restore all your previous connection details. Family Sharing eligibility depends on the App Store page and what your account actually shows; do not infer it from how other apps handle purchases.
Updates are also handled through the App Store. Before updating, note the server you are using, the Global Routing mode, and the Config file name. Back up important local changes first. After the update, verify your existing connection before changing settings. This makes it easier to tell whether a difference came from changed data, the network, or your latest action. Check the store's update history for details; this guide does not list specific app versions.
Before continuing, confirm the app opens normally and that you have your own server details or subscription ready. Proceed to permissions and imports only after confirming the purchase record, device compatibility, and app installation. For answers about restoring purchases, pricing, and where to get the app, see Restore Purchases and Pricing.
2. First Launch and VPN Configuration Permissions
On first launch, get familiar with the app before handling system permissions. Home is where you view existing servers, choose a connection, and control its status. Config manages configuration files; Data shows traffic and requests; Settings controls app behavior. Layouts may vary by device or app update, so look for the English interface labels rather than relying on where a button appeared in an older screenshot. The goal of your first connection is to establish a clear, testable baseline—not to enable every setting at once.
What system VPN permission means
Shadowrocket uses the system VPN configuration mechanism to establish a connection. When you first start a related action, the system may ask to let it add a VPN configuration and confirm using your device's authentication method. This allows the client to work in the system network path; it does not verify the server or confirm that you have authenticated with the remote service. App installation, system permission, and server authentication are separate stages and should be diagnosed separately.
Before granting permission, make sure the prompt comes from the system and that you have verified the app is Shadowrocket. After granting permission, return to the app and check the connection status. If you previously dismissed the prompt, try connecting again and follow the current system prompt; do not repeatedly delete the app to get around a dismissal. If needed, check the VPN section in system Settings. Menu locations depend on what your device currently shows.
Establish a baseline before the first connection
While disconnected, confirm the device can access familiar websites. This rules out issues such as Wi-Fi authentication not being completed, cellular data being disabled, or a temporary network outage. If even basic webpages will not load, troubleshoot the network first. The client relies on the existing network to connect to a server. A VPN indicator does not provide basic network access or automatically complete a public Wi-Fi sign-in process.
Next, check whether Home already lists a server you recognize. An empty list means you have not added connection details; it does not mean installation failed. Check that existing entries match your own records, especially after restoring a device or importing an old backup. Choose one complete, clearly identified entry for testing. For now, avoid changing several uncertain settings at once.
For your first test, check the current On Demand status. If On Demand is enabled, it may reconnect based on network conditions, making it hard to understand what happens after you disconnect manually. For a clear test, note the existing settings, then temporarily turn off automatic triggers. Restore the conditions you need afterward; do not change all automation settings without recording them.
Handle other permissions according to the task
When using Scan QR Code, the system may request camera access. Camera permission is not required to connect if you are entering details manually or importing from an existing link. For actions that access devices on your local network, also watch for relevant system permission prompts. Relate each prompt to the action you just started; do not treat unrelated permission changes as a general-purpose connection fix.
VPN configuration permission is not the same as installing a certificate. A standard server connection should not be described as requiring HTTPS decryption. If a configuration uses certificates, rewriting, or other advanced processing, first understand its purpose and scope, then assess it separately. Do not add certificate trust just because a webpage will not load, or routinely disable certificate validation during initial setup; doing so changes the security boundary.
If the connection switch turns off immediately after you turn it on, first check whether a system prompt is still pending, then check that the configuration is complete. If the switch stays on but webpages do not respond, continue to the connection verification chapter. Note whether the issue occurred before permission, after permission, or while requesting a destination to narrow down the cause. Rapidly toggling the switch makes the sequence harder to follow. Wait for each change to settle before checking the next item.
This chapter is complete when the app's identity is verified, the basic network works, system permission prompts have been handled, and automatic connection conditions are known. Then proceed to import a server or subscription. For the shortest setup sequence, return to the Quick Start Guide; to check import fields and how configurations relate, continue to the next chapter.
3. Add Existing Servers and Subscriptions
First, distinguish server entries, subscriptions, and configuration files. A server entry describes how to connect to a remote server. A subscription retrieves and updates entries in bulk. A Config file mainly describes how traffic is handled and related parameters. They can work together, but they are not interchangeable. Seeing a server in the list does not mean the intended routing rules are active; importing a rules file does not mean it contains a usable server.
Add Server and manual fields
On Home, open Add Server and select the protocol that matches your existing details before filling in the fields. If you choose the wrong protocol, other fields may look similar but still fail to connect. Enter the hostname or IP from your details in the address field and use the specified port. The address field generally should not include a webpage path or explanatory text. Do not use an admin webpage URL as the server address or guess the port from a number in the name.
Authentication fields vary by protocol. Enter the original password, UUID, encryption method, or key from your details; do not fill in missing values based on other entries. After pasting, check for leading or trailing spaces and line breaks, but do not change capitalization or remove special characters. A remark helps you identify an entry; it cannot fix its address, authentication, or transport parameters. If a required field is missing from your source details, verify them rather than repeatedly trying common values.
| Detail type | Check carefully | Common mix-up |
|---|---|---|
| Shadowsocks | Address, port, password, encryption method | Using a remark as the address, or selecting the wrong encryption method |
| VMess / VLESS | UUID, transport method, and existing TLS parameters | Entering only the UUID and missing transport-layer requirements |
| Trojan / Hysteria2 | Authentication details, TLS, and existing transport parameters | Confusing the certificate domain with the connection address |
| WireGuard | Key, address, endpoint, and routing details | Copying only the endpoint and missing the complete configuration |
When TLS is involved, the connection address, certificate verification name, and Host or path in the transport may each serve a different purpose. They may sometimes be the same, but that does not make them interchangeable in every case. If an import succeeds but the handshake fails, first check that these fields are complete rather than relaxing validation. The presence of an advanced option does not mean every protocol needs it changed.
Subscribe and bulk updates
To add an existing subscription, use the relevant Subscribe option in the app and paste your full subscription URL. Subscription URLs often contain access credentials, so keep them private; do not share screenshots or paste them into public notes. Before importing, check for spaces, line breaks, or Chinese punctuation. A subscription URL and a server address serve different purposes; do not paste an entire subscription into a single server's address field.
Updating a subscription retrieves server details again; it does not extend the validity of an existing service. After a successful update, check whether the currently selected server is still there, whether its name changed, and whether any manual edits were overwritten. If an update fails, the old entries may remain, but that does not mean their parameters are still valid. Distinguish a retrieval failure, content that cannot be parsed, and a server that cannot connect; each calls for a different approach.
If a subscription comes back empty, first check that the URL is complete, then confirm the current network can reach the subscription endpoint and review the app's message. Do not immediately delete all old entries just because the result is empty; save anything you need as a baseline for comparison. If the same URL returns different results on another network, record it as a difference in the subscription retrieval path rather than assuming all servers have stopped working.
Import with a QR code and check the results
When importing with Scan QR Code, the QR code may contain a single server or other configuration details; check what the app parses. Before importing, confirm the content comes from your own records. Afterward, open the entry and check its protocol, address, port, and authentication fields. Options such as Import from Cloud JSON also require the expected data format; a filename or extension alone does not prove the contents are compatible.
After importing, first check that the number and names of entries match what you expect. Then inspect at least one entry you plan to use, select it explicitly, and verify the connection. A region in the name does not guarantee the actual route, and a latency test does not prove that a service works. For guidance on choosing among existing entries, see Notes on Latency Tests and Choosing a Server.
If you need to keep manual edits, record them first, then decide whether future subscription updates should overwrite them. Do not switch between duplicate entries with the same name without noting which one is selected, or you may attribute one entry's successful result to another. By the end of this chapter, you should be able to identify the entry you are using, where its details came from, and what the next update may change.
4. Global Routing and Rule Matching
Global Routing determines the overall way traffic is handled. The three modes are Config, Proxy, and Direct. Choose the right mode before looking at individual rules; otherwise, you might change rules while in Proxy mode and expect routing results to change. Server entries define how to connect, while Global Routing determines the overall routing choice. Both need to be clear.
What Config, Proxy, and Direct do
| Interface label | How it works | What to check |
|---|---|---|
| Config | Uses the rules and related settings in the currently enabled configuration | Which rule matches the destination and which policy it uses |
| Proxy | Uses proxy handling as the overall choice | Whether the existing server connection can handle the request |
| Direct | Uses direct handling as the overall choice | How the current network reaches the destination directly |
These three modes help compare routes; they are not three different servers. After switching modes, send a new test request. You may need to close and reopen an existing page because an established connection may not be recreated using the new choice. Direct is not the same as turning off the app's connection switch: the system tunnel and request handling are separate layers. To compare with the network when disconnected, record the switch status separately.
Before using Config mode, open Config and check the name and contents of the currently enabled file. A file appearing in the list does not mean it is active; editing a copy does not mean the running configuration has changed. Save it and enable it as required by the interface, then verify it with a new request. If filenames are similar, use clear remarks to avoid confusing copies and misjudging whether an edit took effect.
Rules are evaluated in order; FINAL is the fallback
Rules in the [Rule] section are checked from top to bottom. When a rule matches, its policy is applied. Put narrow exceptions before broader rules, and put the fallback at the end. DOMAIN matches a specific domain; DOMAIN-SUFFIX covers a domain and its subdomains; DOMAIN-KEYWORD has a broader scope, so consider whether it could match unintended domains before using it.
[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8, localhost
dns-server = system
[Rule]
DOMAIN-SUFFIX,apple.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,ads-example,REJECT
GEOIP,CN,DIRECT
FINAL,PROXYThis is a syntax example, not a complete configuration for every user. PROXY means proxy handling, DIRECT means direct handling, and REJECT means reject. The example domains illustrate matching only; they cannot be used to verify an actual service. FINAL,PROXY applies to traffic not matched by earlier rules. Before using it as a fallback, make sure that is what you want.
IP-CIDR and IP-CIDR6 match address ranges, while GEOIP uses address geolocation data. These are different from matching domains directly. Domain requests may involve a resolution step; no-resolve avoids triggering domain resolution just for that address rule. It does not turn off DNS for the whole app. Geolocation data also cannot replace observing an actual request.
Make one small change, then check the match
When troubleshooting a destination, start by adding a narrowly scoped rule to a copy of the existing configuration and place it before any broad rule that could override it. Change only one condition at a time, save, and send a new request to check the actual destination and policy. Do not change servers, DNS, and rule order all at once; even if the issue clears, you will not know which change mattered, making it harder to reproduce next time.
Local network settings also need to be considered in the context of the actual subnet. The examples list only some private address ranges; your device's network may use different ones, so check your own network details. If a local service remains inaccessible, also check discovery, device permissions, and network isolation. A single direct-routing rule does not guarantee that all local communication will work.
You can assess a rule's effect only when Config mode is active, the correct file is enabled, and a new request actually matches it. For more examples of rule ordering, see Rule Priority and the FINAL Fallback. You can also look up keywords in the Glossary.
5. Establishing and Verifying a Connection
Verify a connection in stages: the basic network works, the client connection stays active, the server path works, and the destination request is handled as expected. No single icon or test number covers all four stages. Before testing, note the current network, selected server, Global Routing mode, and Config file. Then change only one variable. This turns “it worked before, but not now” into a set of conditions you can reproduce and verify.
Run a baseline test in order
While disconnected, first open a familiar webpage to confirm the device is online. Then select a verified server, set a clear Global Routing mode, and turn on the connection switch in Home. Wait for the status to settle and handle any pending system prompts. If the connection stops immediately, check the prompt or log generated by that action rather than repeatedly refreshing a webpage; the issue may not have reached the destination request stage yet.
Once the connection stays active, test one or two clearly chosen destinations in a new page. Prefer sites you normally use and can easily assess; do not start multiple downloads or video apps at once. First check whether the page loads fully, then try images, sign-in, or another relevant action. Seeing a page title proves only that some resources loaded, not that the entire service is working.
When testing Config, check which policy the destination actually matches. When testing Proxy, be clear that you are observing the proxy route. Treat Direct as a comparison with direct access over the current network. If a destination works in Direct but fails in Proxy, the two routes behave differently, but you still need to distinguish server, authentication, resolution, and destination restrictions. This alone does not prove a configuration field is wrong.
What Connectivity Test can and cannot tell you
Connectivity Test and related latency tests usually measure reachability and response time using a particular probe method. The app's current settings determine the method and destination. A number does not prove that every service works, and a timeout does not necessarily mean every connection has failed. Check the probe destination, then consider the result alongside real webpage access. Do not rank results from different test methods as if they used the same standard.
Low latency reflects response characteristics for a specific test; it does not directly indicate sustained transfer speed, connection stability, or video loading performance. When choosing among existing servers, consider when the test was run, the network environment, actual usage, and protocol details. Avoid switching frequently because of one changed result: doing so interrupts existing sessions and mixes results from different servers in later records.
Narrow down the issue by where it occurs
| Symptom | Check first | Then check |
|---|---|---|
| Connection switch will not stay on | System permission, configuration completeness, prompt from the current action | Confirm whether the server connection stage has started |
| Requests to a domain fail | DNS, domain spelling, actual destination in the records | Distinguish a resolution failure from a connection failure after resolution |
| Authentication or handshake error | Protocol, credentials, TLS, and device time | Check each item against the original details |
| Only some page resources fail | Resource domains, matched rules, reject policies | Check failed requests, not just the address bar |
If you see a resolution issue, do not immediately replace every DNS setting with an unfamiliar address. First confirm the domain is correct, check whether the basic network requires authentication, and see where the failed request stops. Connecting directly to an IP is not equivalent to accessing a domain: TLS, virtual hosting, or content delivery may depend on the domain name. Failure to access an IP does not prove the domain has a resolution problem.
For authentication or TLS issues, check the original server details: password, UUID, certificate name, transport parameters, and device time. A noticeably incorrect time can affect certificate validation. Do not hide incorrect details by turning off validation, and do not attribute every handshake failure to network speed. If the subscription was just updated, confirm that the selected entry is the one you tested before.
If an issue appears after switching networks, run the same short tests on Wi-Fi and cellular, and record the results before and after switching. Failure on one network but not another suggests a difference in the underlying path, but keep the server and configuration unchanged for a valid comparison. If public Wi-Fi requires sign-in, complete that first and then reconnect the client; otherwise, the sign-in page can confuse server troubleshooting.
A useful verification record includes the test time, network type, entry remark, mode, destination, visible error, and no credentials. If you still cannot identify the issue, keep the clearest recent failure sample and open Data to inspect the related request. Do not clear the records and rely on memory, or share logs that expose a full subscription URL, password, or key.
6. Data: Traffic and Request Monitoring
Data helps turn “a page is having trouble” into specific requests and traffic changes. It shows network activity handled by the app, but does not automatically explain every service failure. When reading records, distinguish the request destination, policy, connection status, and traffic statistics. Available fields may vary by view; refer to what the app currently displays. Open Data with a specific question in mind rather than browsing a large volume of records at random.
Use one action to identify a group of requests
Before monitoring, stop unnecessary background activity or pause high-traffic tasks. Note the current time, then perform one clear action in the target app, such as opening a page. Look for new requests around that time. Do not refresh several apps at once and guess which record corresponds to the issue; one task may already generate requests to multiple domains, and other activity makes them harder to identify.
If there are many records, narrow them down by destination domain, time, or the filtering options provided by the app. First find requests directly related to the issue, then check the activity around them. A webpage's main domain may serve only as the entry point; images, scripts, sign-in, and APIs may use other destinations. If the main page works but a feature does not, look for new requests triggered by that feature instead of checking only the initial page load.
Separate rule matching from traffic direction
In the visible records, check whether the destination used PROXY, DIRECT, or REJECT, and compare that with the intended rules. If it was REJECT, first check for an overly broad keyword or an existing rule that caused the match. If it used DIRECT when you expected a proxy, check the current mode and enabled file. Do not simply delete all reject rules; first test a narrowly scoped exception, then decide whether to change the original rule's scope.
A single page may use several policies; this can be a normal result of split routing. Some resources may go direct and others through a proxy without indicating a configuration conflict. The key questions are whether those choices match your intent and whether the service works. Conversely, all requests using the same route does not necessarily mean the rules are broken; the current mode, rule scope, or fallback may be making that choice.
Upload or download bytes show that data was exchanged within the relevant scope, not that the service worked. Failed sign-in pages, retries, and error responses also generate traffic. To determine whether a sign-in, file transfer, or media playback completed, check both the result in the service and the related requests. A connection marked as ended may simply be a normal short-lived connection; do not treat that status alone as a failure.
Understand what the traffic figures include
Cumulative values in Data, per-session figures, and usage reported by a service provider may use different measurement methods. Whether direct traffic appears in a view, when its count starts, and whether protocol overhead is included all depend on that view's definition. Do not assume the total shown by the client is the remaining allowance on your subscription, or infer that a remote bill is wrong from one cumulative figure.
To observe traffic changes for a task, record the starting and ending values and test duration, while keeping other network activity to a minimum. Before using a clear or reset option, check which records it affects. Deleting history will not fix server authentication, change rule matching, or restore remote usage allowance; it changes the local diagnostic data. Keep useful samples while troubleshooting.
Turn observations into a testable change
Suppose images fail on a page but the main page loads. First identify the image destination and check whether it was rejected or handled with a different policy. Then change the handling for that destination alone in a copy of the configuration and repeat the same action. If the images load, the route change is relevant; next check whether the rule is too broad or affects other destinations. Do not treat a temporary test configuration as the finished solution.
If the records show that a request used the intended proxy but the service still fails, continue by checking remote connectivity, TLS, and the destination's response instead of repeatedly changing rules that are already correct. If you cannot find the request, first check the observation time, filters, and connection status. An app cache may mean an action did not send a new request; trigger a fresh action before concluding that the client did not handle the app's traffic.
Before exporting or sharing diagnostics, remove access credentials from subscription URLs, server authentication fields, keys, and any unnecessary private destination domains. The most useful report is usually a short time range with one clear destination, expected policy, and actual error—not the entire history. Keep enough context to troubleshoot while minimizing sensitive details, and make the results easier to compare after a fix.
7. Settings, DNS, and On Demand
Adjust Settings to address a specific need. First identify whether the issue concerns automatic connections, resolution, testing, or record retention, then change the relevant item. More options do not mean a more stable connection; overlapping automation and configuration overrides can make diagnosis harder. Before making changes, save the working state and note which values come from Config, which come from app settings, and which are temporary choices for the current session.
On Demand triggers and the manual switch
On Demand triggers connections or disconnections under configured conditions. It does not provide a server or fix invalid authentication details. Conditions may involve Wi-Fi, cellular networks, or domains; available options depend on the current interface. First make sure manual connections work reliably. Otherwise, automation will repeatedly trigger the same failure, draining battery and adding noise without fixing the underlying connection issue.
When setting Wi-Fi conditions, check the network name and intended action, especially for similarly named networks, network changes, and temporary disconnections. For cellular conditions, consider whether the behavior is what you want when the device switches from Wi-Fi. A domain condition defines when to trigger a connection; it is not the same as a Config rule that determines where a request goes. One controls when the connection starts, the other how traffic is handled afterward.
After configuring the conditions, test both matching and non-matching scenarios, and observe what happens after a manual disconnect. If the connection quickly returns, first check whether On Demand triggered it again rather than assuming the switch is broken. Test one easy-to-understand set of conditions at a time, and add complexity only after confirming the results. For more on conditions, see Notes on On Demand Wi-Fi and Cellular Triggers.
DNS and configuration scope
DNS resolves domain names to addresses, but a successful resolution does not guarantee that an address is reachable, and reachability does not mean service authentication succeeded. When a domain fails, first distinguish the resolution stage from the subsequent connection stage. Do not attribute every access issue to DNS or replace several DNS settings without recording the original values; that can change the cache, addresses, and routes for the same destination at once.
In the configuration example, dns-server = system means using the relevant system resolution settings. Choose the method based on the existing configuration, network conditions, and trust requirements. If related options appear in both app settings and the Config file, check which source is active. Seeing a value in one place does not mean every request uses it. After a change, wait for the state to settle and test with a new request.
DNS resolution and routing decisions may be related. For example, address rules need address information, while domain rules can match a domain directly. If resolution results vary by network, the final route may change too. To isolate an issue, keep the server, configuration, and destination the same while checking one DNS setting. Do not add address rules and change the resolution method at the same time, or it will be difficult to tell what caused the difference.
Connection tests, logs, and security boundaries
If you can change the Connectivity Test target or method, record the values before and after. Results from different methods cannot be compared directly, and there is no reason to choose an irrelevant target just to get a smaller number. Routine tests only help determine whether an existing entry is worth checking further; real-world service behavior remains the deciding factor. Testing too often also creates more network requests, so do not treat every minor fluctuation as a failure.
Use logging settings for a specific troubleshooting session. If you need more detail, enable an appropriate level, reproduce the issue, save the relevant excerpt, then restore your usual settings. Keeping large volumes of records indefinitely adds management overhead and accumulates more private network information. Before sharing, redact sensitive details and check whether the export contains server authentication, subscription credentials, or unnecessary browsing history.
Read the descriptions of options involving TLS validation, certificates, rewriting, or other advanced processing before using them. Ordinary connections should not depend on casually weakening validation to stay available. If a connection works only after changing the validation boundary, recheck the server details, certificate name, and time settings. For options you do not understand, keeping a known working value is easier to maintain than enabling settings one by one from another configuration.
Verify settings by checking the first connection, manual disconnection, network switching, and the state after using the device again. This is especially important for On Demand: one test on the current Wi-Fi is not enough. Once behavior is stable, keep a concise record explaining what each setting is for, not just its value. When troubleshooting later, you can see why it is there and whether it still suits the current environment.
8. Configuration Backups, Updates, and Maintenance
The goal of maintenance is to preserve a working baseline and keep a record of every change. App updates, subscription updates, rule edits, network changes, and account recovery are separate events; handle them separately where possible. If you change several things at once, it is difficult to identify the cause of any new issue. You do not need to reset everything routinely. Save your information, narrow down the scope, and make small, testable changes to make recovery and diagnosis easier.
Keep a baseline you can restore
When the connection works, record the selected server remark, Global Routing mode, Config file name, key settings, and most recent verification method. Save copies of locally edited configurations and give them names that make their purpose clear. A backup is more than copying a file: make sure you know which copy to enable when restoring. Store details that contain credentials in a secure place; do not put them in public notes just for convenience.
Configuration backups, subscription URLs, and server credentials are separate kinds of information. Restoring a configuration file may restore rules without restoring every server. Keeping a subscription URL does not mean its remote contents will never change. If you use the app's export or sync features, first check what they include, then verify the results on a second device. A successful import alone does not mean every part of the original device's state was transferred.
Update subscriptions and rules separately
Before updating a subscription, note the entry you are using and any important local edits. Afterward, check whether entries were removed, replaced, or renamed, then run a short test. If the subscription content has changed, verify the new details rather than forcing old values back in. For content you need to maintain manually, define a separate process so updates do not silently overwrite it.
When updating a rules file, check the match scope, order, fallback policy, and any newly added advanced processing. Do not enable a configuration obtained elsewhere just because its name looks familiar; first review the parts relevant to your needs. In particular, the final policy, reject rules, DNS, and certificate settings can significantly change behavior. Keep the original file and test a copy before replacing it so you can revert quickly if something goes wrong.
If only one destination fails after an update, compare its rule and request record; do not immediately roll back every server update. Conversely, if several destinations fail at the authentication stage, check the server details before adding exceptions for each site. Classify issues as details, route, rules, or service response to avoid accumulating more temporary fixes in one configuration.
Moving to a new device, reinstalling, and transferring to iPad
When changing devices, use the original purchase account to restore the app from the App Store, then restore your own details. Refer to the App Store page for system requirements and purchase eligibility. On first launch, still check VPN configuration permission, the selected server, and the enabled file. Restoring a purchase does not replace connection verification. A system backup may retain some state, but check what the new device actually shows and verify it with a test.
When moving from iPhone to iPad, landscape mode, split view, or the wider layout may change where controls appear. Find features by their labels, such as Home, Config, Data, and Settings. First verify a single existing server, then restore rules and On Demand conditions gradually. The two devices may have different networks and use cases; you do not need to force identical settings just to make the interface look the same. See also Restoring Purchases and Using the iPad Layout.
Keep failure samples; avoid repeated resets
If a connection suddenly fails, first note what happened between the last successful use and the first failure: was there a subscription update, network change, rule edit, or system setting change? Keep the current error and recent requests, then try to return to a known baseline. Resetting everything removes both clues and working settings. Consider a broader cleanup only when you know your backup can be restored and narrower troubleshooting has not helped.
You can remove entries you no longer need, but first distinguish manually added entries from subscription-managed ones to avoid duplicate entries returning at the next update. Periodically check rules for duplicates, overly broad matches, and exceptions you no longer need. Clean up one type of issue at a time and verify common destinations afterward. The number of items deleted is not a measure of good maintenance; clearer behavior and easier recovery are.
When describing an issue to someone else, include the device type, current network, steps, Global Routing mode, destination, and type of error. Redact server, subscription, and log details. For field definitions, see the Glossary; to repeat the first connection, see the Quick Start Guide; for common beginner mistakes, read 10 Common Questions from Beginners.
After maintenance, run the same short tests for frequently used pages, necessary local access, and network switching, then update your baseline record. If something changes later, compare it with this record instead of guessing at every parameter from scratch. You can consult individual chapters as needed, but it is best to follow the sequence of purchase, permissions, details, routing, verification, and observation so each step has a clear input and result.