Shadowrocket Complete User Guide

Verify the App Store listing and purchase

Verify the app before purchasing. Shadowrocket is a paid commercial client for Apple platforms, primarily used on iPhone and iPad. It is available exclusively through the App Store. Compatibility for Mac, Apple TV, and Apple Vision is also shown on the same product page. Check the App Store listing for system requirements and whether a purchase works across devices. The steps in this manual focus on iPhone and iPad; layouts on other devices may differ.

Check the app name, developer, and app ID

Open the store listing from the App Store verification page, then check the app name, Shadowrocket, the developer, Shadow Launch Technology Limited, and the app ID in the product URL: 932747118. Compare the store icon with the official icon in this site’s header. A similar name does not guarantee it’s the same app. Search ranking, extra descriptions, and page colors are not reliable ways to verify an app; use the information shown on its product page.

The App Store listing is also where to check price, compatibility, and update history. Before purchasing, expand the compatibility details and confirm that your device is supported. Check the price shown for your current storefront and at checkout. Example prices in articles are not a guarantee of the final charge, and compatibility cannot be inferred from a device’s product family alone. Available options may differ between devices of the same model depending on their system status.

Separate the app purchase from the connection service

Shadowrocket is a one-time purchase, priced at about US$2.99 on the US storefront; other storefronts show local currency. The App Store listing has the current price. The purchase covers use of the client. Server addresses, authentication details, service availability, and data allowances come from a service you already have; purchasing the client does not provide them. If the server list is empty after installation, import your existing configuration rather than buying the app again.

Before purchasing, check which App Store account is in use and keep the purchase record. On some devices, the system account and the account used for App Store purchases can be managed separately, so the name at the top of the device settings alone may not identify the purchasing account. If you switch devices, reinstall the app, or look up a charge later, find the original purchase record. Server names, configuration notes, and connection status in the client do not prove a purchase was made.

What to expect when installing, restoring, or updating

After purchasing and installing the app from the store, open it once and confirm that the main screen loads before setting up subscriptions or permissions. If the store asks you to pay again, check the account and purchase history before confirming. Redownloading with the purchasing account, eligibility on other devices, and Family Sharing availability depend on the App Store listing and your account settings.

Restoring on a new device involves two separate things: restoring the app purchase and restoring in-app data. Finding the app in your purchased items does not guarantee that servers, subscription links, or local configurations will also return. Before switching devices, check for an available configuration backup and save the original details for services you already use. A server note alone is usually not enough to rebuild a connection; it does not include the protocol, port, and authentication parameters.

Manage app updates through the App Store. Before updating, save the configuration and connection details you need. Afterward, check that the default server, Global Routing, and active configuration are still as expected. If the store cannot install the app, first check App Store account, payment, device storage, and system compatibility issues. This stage does not involve a remote connection, so changing DNS or rules will not resolve a purchase or installation problem.

You’re ready to move on when you can verify the product in the store, identify the purchasing account, open the app, and locate your existing connection details. Having the app icon on your Home Screen is not the whole preparation process. Keep app acquisition and data recovery separate so you can tell whether a later connection failure involves the app, its settings, or the remote service.

First launch and VPN configuration permissions

After opening the app for the first time, get familiar with Home before connecting. Home brings together the connection switch, Global Routing, Connectivity Test, and SERVER list. The layout may vary by device or app state, so identify features by their English names rather than fixed screen positions. For a detailed walkthrough, see First launch and the Home screen. This chapter focuses on permissions and how they relate to connection status.

Four things to check on Home

The connection switch starts or stops the current connection. Not Connected means the connection is not currently established; it does not mean the app purchase failed. Global Routing determines whether traffic follows the configuration’s rules, uses a proxy route, or connects directly. The SERVER list contains selectable servers. Opening an item to edit it and selecting it as the default server are separate actions; confirm each one independently.

Connectivity Test checks whether servers in the list can be reached. Its results can help narrow down a problem, but they do not replace testing actual access. If the list is empty on first launch, there are no servers to test. A populated list does not mean every item works. First verify the details in Chapter 3, then use test results as a reference. Avoid repeatedly toggling the connection switch before the required information is in place.

Also distinguish the status shown in the app from configuration stored in the system. The system may retain a previously added VPN configuration even when the app is not connected. Likewise, opening the app successfully does not mean the system has allowed it to establish a connection. Check the selected item and switch in the app, then check the system VPN status. Don’t infer where all traffic is going from a single status-bar icon.

Understanding the system prompt to add a VPN configuration

When the app requests the network connection it needs, the system asks you to confirm adding a VPN configuration. This is Apple’s process for managing connection permissions, not a purchase confirmation or subscription sign-in. Confirm that the prompt appears while you are actively using Shadowrocket, then follow the system instructions to allow it and complete any required authentication. You can save your current work before confirming so you don’t lose track of what triggered the prompt.

If you previously denied permission, return to the app and check whether you can start the connection request again, then follow the current system prompt. Settings paths may change between system versions; use Settings search for VPN and check whether a Shadowrocket configuration is present and what its status is. Don’t add multiple configurations you can’t identify, or delete other network configurations that are still in use just to retry. Check which app or service each configuration belongs to first.

On organization-managed devices, management policies may restrict network configurations. If you can’t confirm or add the configuration, or the switch immediately reverts, check whether the device has relevant restrictions and ask the device administrator which settings are allowed. Reimporting a subscription will not change system policies. When troubleshooting, record the exact system prompt; it is more useful than a vague description such as “nothing happened.”

Establish a baseline for your first connection

For the initial setup, use a manual connection and leave On Demand disabled. Follow one clear sequence: prepare a server, select it as the default, check the routing mode, turn on the connection, and verify access. Then you can link each status change to the action that preceded it. If you enable automatic triggers, change settings, and update a subscription all at once, it becomes much harder to identify what caused a connection to recover or drop—or whether any individual change took effect.

After granting first-use permissions, note whether the app can keep the connection switch on and whether the system shows the corresponding connection. If the switch won’t stay on, check permissions, configuration validity, and error messages first. If it stays on but access fails, move to connection testing. These are different troubleshooting paths. Don’t treat “permission allowed,” “switch on,” and “target accessible” as a single success condition.

By the end of this chapter, you should be able to identify the areas on Home for connection, routing, testing, and server selection, and know whether system permission has been granted. Not every destination needs to work yet, but you should know whether you’re missing server details, permission, or a connection test. For the shortest setup path, return to the setup guide. To understand where settings come from and what imports do, continue to the next chapter.

Importing servers and subscriptions

Before importing, identify what you have: individual server details, server share content, a subscription link, or a configuration file. Each serves a different purpose. A server entry stores the parameters for one connection; a subscription updates a list of servers; a configuration file organizes routing and related settings. Entering a configuration file URL as a subscription, or putting an ordinary webpage URL in the server address field, can result in a parsing error or unexpected content.

Add a server manually and verify its parameters

To add a server manually with Add Server, select the protocol first, enter the address and port, then check authentication and transport parameters. Use details from a service you already have; don’t guess based on the server name. The same domain can use different ports, and the same port can carry different protocols. Complete-looking fields don’t guarantee the combination is correct. After saving, reopen the edit screen and check each field, especially for extra spaces, line breaks, or full-width characters introduced during copying.

The table describes what to check; it does not mean every protocol uses the same fields. If the service details include a transport path, hostname, or TLS server name, enter each according to its purpose rather than putting everything in the address field. The server address identifies the connection endpoint; TLS-related names are used for the corresponding identity check. These values may match, or the service configuration may specify different values. They are not interchangeable.

Import an existing subscription and check the result

If you already have a subscription, use the app’s add option, select Subscribe, enter the complete subscription URL, and save it. Then run the relevant update action. Subscription links often contain access credentials: copy the full link, but don’t post it in public chats, screenshots, or problem reports. After importing, return to the SERVER list and check that the expected groups and entries appear. Seeing a subscription name alone does not confirm that its server entries were retrieved successfully.

If the list is empty, first check whether the update is still in progress, the request failed, or the returned content could not be recognized. Verify that the link is complete, including its beginning, end, and query parameters, and that it points to a subscription rather than an account-management webpage. Then ask the original service provider about the subscription status and supported content format. Don’t keep adding the same URL; duplicate groups with the same name make later updates and cleanup harder to manage.

Updating a subscription can add, remove, or change server entries; it is more than a display refresh. Before updating, note which group contains the current default server, then check that the selection is still valid afterward. If a server has been renamed, don’t assume it disappeared based on the old note alone; check the group and the provider’s information. For an empty list or parsing error, see Subscription parsing: troubleshooting checklist.

Importing shared configurations, QR codes, and configuration files

Before using Scan QR Code, confirm that the QR code comes from trusted materials for a service you already use. After import, check the protocol, address, and note shown in the app. Scanning saves manual entry; it does not verify the remote service’s quality or ensure the parameters are still valid. If the QR code is displayed on the same device, use the corresponding import method available in the app. Don’t send an image containing credentials to a public QR-scanning service.

After importing shared content, check whether you saved an individual server or a subscription entry. An individual entry does not necessarily update automatically; entries in a subscription may change when it is updated. If editable fields differ from the original information after import, keep the original details and check protocol support and parameter mapping field by field. Don’t immediately overwrite a server that still works; you may need it as a baseline for comparison.

After importing a configuration file, check in Config which file is currently enabled. A saved file and an enabled file are different states. Before importing a configuration with rules, review its policy references, final rule, and DNS settings, and check whether it depends on additional rule resources. If a referenced policy is missing, being able to open the file does not mean its routing logic is complete. The next chapter explains how rules work with Global Routing.

You’re ready to move on when the list contains identifiable servers, you know their source, key parameters match the original information, and subscription updates can be checked. Finally, select a default server explicitly; finishing an edit does not select the server. Keep a working set of parameters as a fallback before configuring routing, so you can troubleshoot import and routing issues separately.

Routing modes and rule order

Global Routing has three modes: Config, Proxy, and Direct. They change how routing decisions are made; they do not fill in a missing server password or fix a remote service problem. Check the current mode before troubleshooting, especially when a server test returns a result but an app doesn’t behave as expected. The issue may be that a rule selected a different policy, not that the default server failed.

First determine what controls the traffic

Config is useful for handling different destinations with different rules, provided the active configuration is clear. Proxy can help check whether the proxy route works in general, but it does not guarantee identical behavior for all special traffic or system activity. Direct does not mean “stop the app.” To end the current connection, use the connection switch. To compare routing behavior, change Global Routing.

Read rules from top to bottom

Rules are generally checked in order; the first applicable match determines the policy. Put specific conditions before broader ones, and use FINAL at the end for connections that match no earlier rule. A broad rule placed too early can prevent later, more specific rules from matching. When troubleshooting, don’t just search for a domain. Read the rules above it and check which policies they actually select.

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

This is a syntax example, not a complete configuration for every environment. DOMAIN matches a specified domain; DOMAIN-SUFFIX matches a domain suffix; DOMAIN-KEYWORD matches a keyword in the domain; IP-CIDR matches an IP address range. GEOIP relies on corresponding IP data, so it is not definitive proof of a destination’s business location. FINAL is the fallback at the end and should match the default route you expect.

In this example, the exact-domain rule comes before the keyword rule. The fact that a keyword includes example does not mean every related request will go direct. Domain rules and IP rules use different information, and what a connection exposes for matching also affects the result. The name shown in a browser’s address bar is not proof that the entire page uses just one domain.

Distinguish rules, policies, and the active configuration

PROXY, DIRECT, and REJECT are common policy keywords in rules, each with a different purpose. If a rule refers to a custom policy name, check that the policy is defined and which server it ultimately uses. A file can appear syntactically correct but still behave unexpectedly if a policy name is misspelled. Preserve case, separators, and field order when editing; don’t replace an English comma with a full-width comma.

Config may contain multiple files. After editing one, save it, confirm it is the active file, and follow the app’s prompts to apply it to the connection. Renaming a file does not change its rules, and a remote configuration update may overwrite local edits. For custom rules you need to keep, identify where they are maintained and save a copy before updating. Don’t accumulate changes in a file from an unknown source.

For an issue affecting one destination, temporarily compare the results in Proxy and Config. If the proxy route works but the configuration route does not, focus on rules and policies. If both fail, check the server and remote conditions. After comparing, restore the routing mode you need; don’t leave a temporary troubleshooting setting in place as your everyday configuration. Change only one condition at a time and record the result to preserve useful cause-and-effect information.

Rule matches are not permanent conclusions. A destination may use multiple domains, addresses, and connection methods, and configuration updates can change rule order. Verify rules in the actual scenario instead of ending the check just because an example rule exists. For DNS and address matching, continue to Chapter 7. For common issues, see Troubleshooting.

Connections, verification, and layered troubleshooting

Assess connection success in layers: the underlying network works, server parameters are valid, the system permits a connection, the routing mode is correct, and the actual destination responds. A problem at any layer can look like “can’t connect,” but each requires a different fix. Describe the symptom first—for example, the switch won’t stay on, a test times out, only one destination fails, or the issue starts after switching networks—then follow the relevant checks.

Follow a repeatable connection sequence

First, confirm that your current Wi-Fi or cellular network can access the internet. If the network requires a sign-in or access confirmation, complete that first. Then return to Home, choose the server you want to test in the SERVER list, and confirm that the selection indicator is on the intended entry. Tapping an entry to view its details does not necessarily select it as the default. Don’t rely on a matching note alone; different groups can contain servers with the same name.

Next, check Global Routing. For an initial test, choose a clear proxy route, turn on the connection, and follow any system permission prompts. Once the status is stable, run Connectivity Test and make a new request in a browser or the app you need to use. For the full sequence of selecting a default server and running the first test, see First connection and connectivity test.

Keep the network, server, and destination fixed during a test; avoid changing all three at once. Pages may be cached, and the app may retain an existing connection, so account for whether a new request was actually made. A previously loaded page can make a failed connection look successful. Perform a clear new action and check connection records for activity matching the destination.

Separate test results from real-world access

Connectivity Test reports reachability under its current test conditions; it does not provide a complete verdict on every remote service. If a test returns a result but the actual destination fails, the cause may involve the destination, DNS, rules, or the app’s connection method. A timeout does not immediately mean every saved field is wrong. Compare other servers you already have, then try the same server on another underlying network to narrow down the cause.

If the connection switch turns off immediately, check the app’s message and system VPN status first, then verify permissions and configuration. If the switch stays on but all requests fail, check the default server, protocol, port, and authentication details, then confirm the remote service is available. If only Config fails, check the active file and its routing policies. If only one app has a problem, investigate its domains and requests rather than resetting the entire configuration.

Distinguish a brief interruption from a reproducible problem. Screen lock, network changes, or a remote connection reconnecting can create a temporary transitional state. Wait for the current action to finish before testing again. If you can reproduce the issue with the same steps, record the conditions. If it happens only occasionally, don’t immediately change several low-level parameters. Stacking changes can temporarily hide a problem while making the original conditions harder to reproduce and maintain.

Use minimal changes to isolate the failing layer

If several existing servers fail, check what they have in common: the same underlying network, configuration, DNS setting, or system restriction. If only one fails, focus on its parameters and remote status. This is more effective than changing settings at random. Keep one confirmed working entry as a control, and don’t overwrite its authentication parameters before recording the original values.

For TLS or authentication errors, check the device time, server-name requirements, and original parameters. Don’t disable verification at random as a substitute for checking them. For a domain resolution error, first determine whether the server domain or the destination domain failed to resolve; they point to different parts of the connection. For a timeout, consider the network, port, and remote status. The same error wording does not always mean the same cause.

If you need further help, share a redacted description of the issue, protocol, network type, Global Routing mode, and comparison tests already performed. Don’t disclose a full subscription, password, UUID, key, or URL with query parameters. You can include the relevant part of an error message, but mask server identity details. When contacting the original service provider, specify which entry and network reproduce the issue; that is clearer than sending the entire configuration.

By the end of this chapter, you should have a verifiable conclusion: either the basic connection works, or the problem is isolated to permissions, parameters, routing, name resolution, or the destination service. After a successful test, restore the Config mode you need and check typical destinations. Then use Data to observe actual traffic rather than treating one test result as a long-term measure of connection quality.

Traffic statistics and connection activity

Data shows traffic information and related connection activity provided by the app. Use it to answer questions such as whether traffic was generated, which action caused a change, and what the measurement covers. It is not the same measurement system as your service provider’s account records. Before interpreting any number, check the time range, measurement scope, and unit shown on screen. Otherwise, you may be comparing values that cover different things.

Check the measurement scope before comparing

Upload and download describe the direction of data transfer; instantaneous speed and cumulative data are different measurements. Speed reflects transfer over a particular time window, while cumulative data is the amount transferred over a given range. A momentary change in speed cannot be used to estimate monthly usage. Similarly, a period with no noticeable speed does not prove that there was no earlier background transfer. Interpret the results in light of the observation period and what you were doing.

Client statistics, system cellular-data statistics, and service-provider records can differ because their measurement boundaries, session scope, update timing, and protocol overhead may not match. For an account allowance, rely on the account records and measurement details for the service you already use. If figures differ, first check that you are comparing the same time period, device, and connection scope. A discrepancy alone does not prove that either side is wrong.

Before resetting or clearing statistics, save any readings you need and check which local records the action affects. Resetting numbers in the client does not restore a remote account allowance or change data already transferred. Don’t repeatedly clear statistics just to make them appear as zero; that removes the baseline needed for comparisons across time. For longer-term tracking, note the date and time, network, and usage scenario.

Observe traffic changes one action at a time

To check whether an action generates the expected traffic, note the current readings, pause other app activity if practical, and perform one clearly defined action, such as reloading a page. Then return to Data and compare the relevant records. If you also stream media, sync photos, and update apps, it will be difficult to attribute the total increase to one page, making the numbers less useful for troubleshooting.

Background sync, notifications, and app refreshes can all generate connections. Not tapping anything does not mean the device has no network activity. If traffic keeps increasing, first check what tasks the system and apps are running, then inspect the relevant connection records. Media caching and preloading can also transfer more data than the content currently visible on screen; interpret this in the context of how you use the app.

An increase in traffic proves that data was transferred, but it does not by itself prove that the expected rule matched. Check the specific destination, connection records, and routing policy together. In Config mode, a single page load may involve multiple domains, with different requests matching different policies. Total traffic cannot replace the rule checks in Chapter 4, and it cannot prove that an entire app always uses the same route.

Read connection details and protect your records

If the app’s connection details include fields such as destination, policy, or error, use them to investigate one specific request. Identify when the action occurred, find the corresponding destination, and check the policy and result. Don’t assume the first row corresponds to the page you just opened; background requests may appear at the same time. If a destination uses a shared domain or address, a fragment of its name alone cannot confirm which app it belongs to.

Records may include domains, addresses, timestamps, and other network details. Review them before exporting or taking a screenshot. When reporting a problem, share only the few entries relevant to it, and hide personal service information and credentials. If a full log would expose unrelated activity, extract the error time and necessary fields first. Troubleshooting usually needs clear context, not the largest possible amount of raw data.

If many failed connections keep appearing, check whether they share a destination, policy, or time window. Repeated retries to the same destination can quickly increase the number of records without generating a comparable volume of successful traffic. Investigate the destination and routing layer rather than judging network load by the number of entries. Entry counts and data volume are comparable only when you know what each measurement covers.

After observing traffic, keep temporary tests separate from everyday use. For ongoing maintenance, record only key issues, before-and-after results, and the baseline you need; there is no need to collect every detail continuously. If Data shows activity but the destination still fails, check whether the response succeeded, the content was complete, and the app is working correctly. Traffic indicates activity somewhere along the connection; it does not automatically mean the request completed.

Common settings and automatic connections

Change Settings only after a manual connection works. Define the problem first, adjust the relevant setting, and keep a record of the original value. App settings, the active configuration file, and system network settings can all affect the same connection, so note which layer you changed. Don’t just record “changed DNS” or “enabled automatic connection”; include where you changed it, its previous state, and the test result.

DNS: understand where name resolution happens

DNS translates a domain name into address information needed for a connection. A connection can fail before, during, or after name resolution, so changing DNS will not fix every timeout. First determine whether the unresolved name belongs to the server or the destination, then check the relevant settings in the active configuration. If the server address cannot be resolved, the connection endpoint has not been identified. If the destination fails to resolve, investigate the current routing and DNS path.

System DNS, custom DNS, and DNS over HTTPS work differently. Choose an option based on the current network and whether the resolver is reachable. Encrypted transport describes how DNS requests are sent; it is not necessarily suitable for every network. After changing DNS, compare results using the same destination and server. Otherwise, changing networks at the same time can skew the comparison. For details, see DNS settings compared.

[General]
dns-server = system

This example shows where to configure system DNS in a configuration file. It is not a complete configuration or a universal recommendation. The setting belongs in the General section, not the Rule section. If the active file already has the same setting, check its current value and related entries before changing it. This avoids confusion from duplicate definitions. After saving, confirm that the file is enabled and follow the app’s instructions to test it again.

Caching can affect short-term comparisons. The same destination may continue using a previously obtained result, and the app may reuse an existing connection. When testing a change, check for a new request and review connection records rather than assuming it failed because the old page is still visible. If only one destination is affected, inspect its records and rules first; don’t immediately replace the entire DNS strategy with a more complex setup.

On Demand: verify manually before automating

On Demand manages connection triggers according to configured conditions. It does not repair an unhealthy server or replace first-time manual authorization. Before enabling it, confirm that the selected server works and Config behaves as expected, then review the conditions currently available in the app. Add only conditions you understand and test the status both when they are met and when they are not. This helps avoid unexplained automatic connections.

When testing automatic triggers, record the network, connection status, and action that triggered them. For example, after a network change, check whether the app enters the expected state and then verify actual access. A switch turning back on does not prove the remote connection succeeded. If the connection returns after you manually disconnect, check whether On Demand is still enabled and whether its conditions were met again instead of repeatedly deleting system configurations.

Connection settings and a disciplined approach to changes

Set TLS, transport methods, and other protocol parameters according to the requirements of a service you already have. They are not general-purpose optimization switches. For a compatibility issue, first check what the server supports. For troubleshooting, keep the original parameters and note how the error changes. Turning on an option just because its name sounds network-related may alter a previously working connection and mix a new problem with the original one.

If a configuration file and the app interface both contain related settings, don’t assume they all have the same priority. Check the active file, app guidance, and actual connection results to determine what takes effect. After a remote configuration update, check whether settings you relied on are still present. If you don’t understand an option, keeping its verified state is usually easier to maintain than changing several options at once. When you do need to make a change, test a copy with a limited scope first.

For each change, record four things: original value, purpose, result, and how to revert it. Be specific about the purpose—for example, checking whether a domain resolves—rather than vaguely aiming for better speed. The result should be reproducible, not based only on a momentary impression of page loading. If the change doesn’t help, restore the original value before trying something else. This prevents a buildup of settings with unknown purposes and gives you a clear baseline for the next chapter.

Backups, updates, and everyday maintenance

The goal of everyday maintenance is to keep a working setup that you can understand and restore—not to accumulate more configurations. Know the current default server, subscription source, active Config, Global Routing mode, and automatic connection conditions. This information helps identify recent changes when something goes wrong and forms a recovery checklist when switching devices. A single screenshot of the app is rarely enough to restore the whole setup.

Back up servers, subscriptions, and configurations separately

Before making a backup, identify what it covers. Server parameters define the connection endpoint and authentication; a subscription link retrieves a server list; a configuration file stores routing and related settings. An export of one type may not include the others, so check the actual contents. If you use an export or backup feature provided by the app, read its instructions and check whether it includes sensitive data or depends on an account or other recovery conditions.

Store backups in a protected location you control, not in public links. Treat subscription URLs, passwords, UUIDs, and keys as sensitive information. Label backups so you can identify the configuration and scenario they belong to, but don’t put full credentials in a filename. If service details have changed, an older backup may no longer work. Keep enough history to avoid restoring the wrong version.

Before switching devices, run through the recovery process: make sure you can find the original purchase record, locate your existing subscription or server details, and understand policy references in your configuration file. You can do this with a copy without deleting the data you currently use. The point is to confirm that recovery materials exist, not to assume everything is ready because you once exported a file. If the only copy of a link is on a lost device, you may have no way to restore it.

Review updates in a consistent order

There are three kinds of updates: app updates, subscription updates, and configuration updates. App updates are managed through the App Store. Subscription updates can change the server list. Configuration updates can change rules, policies, and DNS settings. Avoid updating all three during the same troubleshooting session; otherwise, it is hard to tell which change affected the result. After each update, verify the basic connection and typical destinations before moving on.

After a subscription update, check that the default server still exists, then review changes to groups and entries. After a configuration update, check the active file, final rule, and custom policies, then verify that local edits were preserved. After an app update, review permission status, the connection switch, and automatic triggers. You don’t need to test every website, but cover the types of destinations you rely on, including local-network destinations that should connect directly.

If a problem appears, first revert the latest recorded change. If the subscription has changed, ask the original service provider about its status rather than forcing old entries over the new list. If changed configuration rules caused the issue, compare with a saved copy. Reverting helps restore a known state and identify the cause; it does not mean old content will work indefinitely. Reverting a local configuration cannot restore a server that is no longer available.

Organize configurations and keep a troubleshooting record

Periodically remove duplicate subscriptions, unidentified configurations, and inactive entries, but confirm they are no longer in use before deleting them. Check especially for files and servers with the same name so you don’t remove the one currently in use. Use clear notes to distinguish test setups from everyday configurations and record their source and purpose. A small number of clearly labeled fallback copies is easier to manage than a pile of old files with confusing numbers.

A troubleshooting record needs only information that helps identify the cause: what triggered the issue, what happened, the type of default server, routing mode, recent changes, and comparison test results. Remove subscription credentials and personal browsing details. If a change fixes the problem, note the final settings and remove temporary experiments you no longer need. Otherwise, weeks later you may remember only that you changed many things, without being able to reconstruct why.

If you need to reinstall, stop the connection first, check On Demand, confirm your data is backed up, and reinstall through the App Store. After installation, follow this manual in order: handle permissions, import existing details, select a default server, enable the configuration, test the connection, and restore automatic triggers last. Don’t import every old file and connect immediately; duplicate entries and outdated rules could reintroduce the same problem.

This completes the maintenance cycle: keep a baseline, make one change at a time, verify each layer, record results, and revert when needed. To retrace the main connection steps, use the setup guide. For common purchase or import questions, see Troubleshooting. To verify the App Store listing or restore a purchase, return to App Store purchase and restoration. This page explains the boundaries of each stage; actual parameters depend on the options in the app and the details for services you already have.