Shadowrocket
Complete User Guide

Get and install

First identify your platform, then choose the right download source. Get the iPhone / iPad version from the App Store. For Mac, Windows, Android, and Linux, choose an installer from this site's download page; files are served from /dl/shadowrocket/. An app purchase on your phone is not an installation method for a computer, and downloading the app does not complete setup. Installation prepares the client; connecting still requires your own server details or subscription URL.

Check the iPhone / iPad App Store listing

Open the product page from the App Store link on the download page. Check the app name, Shadowrocket, the developer, Shadow Launch Technology Limited, and app ID 932747118. The icon should match the official icon in this site's header. These details are more reliable than searching for “Shadowrocket” alone; similar names do not necessarily refer to the same app. Check the App Store page for the current system requirements before installing.

The iPhone / iPad version is a $2.99 one-time App Store purchase. Mac, Windows, Android, and Linux versions are free. The store displays local currency based on your account's storefront; check the product page before paying. To install on another iPhone or iPad, first make sure the App Store is signed in with the account used for the purchase, then find the app in your purchased items. If it does not appear in search, check your account's region and the app's availability rather than repeatedly changing client settings.

Choose a desktop or Android installer

Mac downloads are available for Apple silicon and Intel. Open About This Mac: choose the Apple silicon build if it lists an Apple chip, or the Intel build if it lists an Intel processor. After downloading, open the disk image, move the app to Applications, and launch it from there. Avoid running it from the disk image long-term; otherwise, it can be harder to replace the app, remove the download, or manage system permissions later.

For Windows, download the installer from the download page, close any running instance of the app, and complete the installation. For Android, choose the arm64 package. If your device reports that it is incompatible, check the device architecture and system requirements rather than repeatedly trying to install it. On Linux, choose deb or rpm for your distribution; AppImage is an option when you prefer a standalone file. All installers are listed under downloads for all platforms. This guide does not list installer filenames that may become outdated.

Understand first-launch security warnings

Desktop and Android installers are not code-signed, so the system may block the first launch. Before responding to a warning, confirm that the file came from this site's download page, matches your device, and displays the expected app name. Organization-managed computers may prevent users from allowing an app; contact your device administrator in that case. Do not disable device-wide security protections just to launch one app, and never follow the steps below for a file from an unknown source.

If Mac says the app “is damaged,” delete the download and get it again from this site to rule out an interrupted download or the wrong package. Only if the app is in Applications, came from the correct source, and is still blocked by quarantine should you run the command below in Terminal. It recursively removes extended attributes from that app's directory; it does not repair a genuinely damaged file. Do not broaden the command's scope. Relaunch the app afterward. If it still fails, keep the full error message and continue troubleshooting.

xattr -cr /Applications/Shadowrocket.app

For AppImage on Linux, grant execute permission in the file manager to avoid mistyping the filename. If it still will not launch, check your distribution's runtime requirements and the Terminal error; do not mistake a missing runtime for a subscription problem. For more about chip selection and system warnings, see installing on Mac and Windows and Linux package formats.

First launch and permissions

On first launch, confirm what you see on screen before setting up connection permissions. On iPhone / iPad, the main areas are Home, Config, Data, and Settings: Home manages servers and starts connections, Config manages routing rules, Data shows traffic-related records, and Settings adjusts client behavior. Labels may appear in different places depending on the interface language and system layout. Use the option names and current screen as your guide, not button colors alone.

Client settings and system VPN permissions are separate

Servers, subscriptions, and rule files in the client are app configuration. The system prompt to “Add VPN Configuration” grants network access to the device. These are separate things: importing a server does not authorize the system VPN, and system authorization does not provide a usable server. On the first connection, Shadowrocket requests permission to create a system VPN configuration. Once allowed, the client can handle the device traffic it is configured to process. Seeing this prompt does not mean the server is connected.

Before granting permission, make sure you just started the connection from Shadowrocket, then follow the system prompt to confirm with your device passcode or biometrics. This is device authentication, not a subscription password or server credential. If you canceled, return to Home and, after confirming the server entry is complete, turn on the connection again to retry. Repeatedly canceling the prompt and changing routing rules will not resolve missing system permission.

After authorization, you can find the configuration in the VPN section of system settings. The exact menu path varies by system version; search Settings for VPN if needed. Removing a system VPN configuration generally does not remove servers from the app, but you will need to authorize again next time you connect. Do not delete network configurations belonging to an organization or work app unless you know what they do. On managed devices, policy may control whether configurations can be added or removed, and users may not be able to restore them.

Grant permissions when a feature needs them

Scanning a QR code may prompt the system to request camera access. Allow it only if you plan to use Scan QR Code; you can still import using an existing text link or by entering details manually. To re-enable camera access, find Shadowrocket's permissions in system settings rather than reinstalling the app. Check the QR code's source before scanning. A successful scan means the data was readable, not that its settings are appropriate for your account or still valid.

When importing from the clipboard, the system may ask whether to allow pasting. First confirm that you copied your own share link or subscription URL, then approve the action. The clipboard may still contain something copied earlier, so check the imported type, remark, and hostname. If you need to access devices on your local network, also check the system's local network permission. It is separate from the system authorization required for a VPN connection.

You do not need to enable every permission just to dismiss first-run prompts. A better approach is to perform a specific action, read the prompt, grant only the permission it requires, and verify the result. Leave permissions unchanged if you do not need the feature. Notifications, camera access, and network configuration serve different purposes. If a permission is denied, check which feature it affects instead of assuming the entire client is unusable.

Check for existing connections and management policies

If the device already has another VPN connection or network extension, stop any connection that could conflict with this test before starting Shadowrocket. Multiple apps competing for the system network path can cause the switch to turn off immediately, the status to fluctuate, or requests to continue using an old connection. For troubleshooting, keep only the connection you need and note its state before stopping it. Restore other connections afterward if needed. Do not delete all network configurations as a substitute for identifying the specific conflict.

Public Wi-Fi may require browser-based sign-in first. Until you complete the network's sign-in page, client connection tests and subscription updates may fail. Temporarily disconnect, make sure the network can open the sign-in page, complete authentication, then return to the client. Both Wi-Fi and cellular need basic connectivity. Without it, correct server settings cannot establish a remote connection, and a system VPN icon does not mean the device has internet access.

After granting permissions, leave On Demand off for now and make one manual connection. This makes it easier to distinguish changes caused by your own action from automatic triggers. If the system configuration was deleted, the permission prompt keeps reappearing, or you cannot find the entry in Settings, see the guide to the Add VPN Configuration prompt. Keeping the full error message is more useful than simply saying “it won't connect.”

Add servers and subscriptions

First identify what you have. A single share link describes one server, a subscription URL usually returns a group of servers and related information, and a Config file defines routing rules and configuration behavior. They serve different purposes. Treating a rules file as a server subscription, or entering a single server link in the wrong place, can result in a failed import, an empty list, or a named configuration that cannot connect. Before importing, confirm the content type and required fields with your own service provider.

Enter details manually with Add Server

On Home, open Add Server, choose the protocol that matches your existing details, then enter the address, port, and authentication information. The address field usually takes a hostname or IP address, not a web page path. Use the connection port provided by the server. Remarks are for your own reference; changing one does not change the connection destination. Keep the original details nearby to check each field, and do not use a website login password as the server password.

Protocol determines what each field means. Shadowsocks requires a matching encryption method and password. VMess and VLESS commonly use an ID and transport settings; Trojan commonly uses a password and TLS; WireGuard uses keys, addresses, and peer information. Different protocols require different fields, so do not copy settings from one protocol to another. If your details omit an advanced option, confirm whether it is required rather than guessing; an incorrect value can cause the handshake to fail.

Keep path capitalization and leading slashes exactly as provided.

Import a share link or QR code

A link prefix can help identify the protocol, but it does not confirm that every parameter is present. Keep encoding, special characters, and query parameters intact. Line breaks added by a messaging app may not be part of the link; avoid copying trailing punctuation. For the difference between a single server link and a subscription URL, see Share Link Format Guide, then return to this chapter to check the fields.

Add and update an existing subscription

Add and update an existing subscription

Get the complete subscription URL from your own service provider. In Add Server, choose Subscribe, enter the URL, save, and then update it. The path and query parameters are often part of how the URL is identified; do not remove trailing content to shorten it. After an update, check the group and server entries, not just whether a subscription name appears. A saved name with no fetched content is not a completed import. If the first update fails, do not rush to delete existing working entries.

Updating a subscription makes a network request. An expired URL, a change in account status, a network problem, or an unexpected response can cause the update to fail. If old entries are still present, keep them and note the error. Then determine whether the address is unreachable, returns a login page, or contains data the client cannot parse. An update is not a connection test: a fetched server list only confirms that the details were retrieved. Verify that the entries work in a later chapter.

Subscription URLs may contain access credentials. Do not post a full URL, share QR code, password, or key in a public screenshot. When asking for help, share only the protocol, error message, and a redacted outline of the settings.

Three Global Routing modes

Three Global Routing modes

Use Config for rule-based routing

Before using Config, check which configuration file is currently selected on the Config screen. Importing multiple files does not activate them all, and editing an unselected file will not affect the current connection. Note the file name, then check the rule order and policy names. Remote configurations may reference other resources; if those resources cannot be retrieved, the file's presence does not mean all its rules are ready. Check the actual contents rather than relying on a familiar-looking title.

Rules are usually evaluated in order, and the first match determines how traffic is handled. Put specific destinations before broader rules, and place the final fallback last. If a broad rule comes first, later, more specific rules may never match. The example below shows only the basic structure of a rule section; it is not a complete configuration and contains no server details. Test it in a copy and confirm the policy names used by your current configuration before applying it. Do not overwrite an existing file directly.

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

This example handles specified domains first, then a domain suffix, local address ranges, and a regional match, before sending all remaining destinations to PROXY. The example domains are for illustration and do not imply that the same policy is right for your actual traffic. Keep keywords such as PROXY and DIRECT unchanged. If your configuration uses custom policy groups, make sure the rule refers to a group that actually exists; otherwise, the policy target may not work.

Understand rules by what they match

DOMAIN matches a full domain name, DOMAIN-SUFFIX matches a domain and its subdomains, and DOMAIN-KEYWORD matches a keyword in the domain. Keyword matches can be broader than expected, so consider false positives before using them. IP-CIDR and IP-CIDR6 match address ranges; GEOIP relies on address-location data; FINAL handles destinations not matched by earlier rules. Domain rules match hostnames, so do not put a full web page path after DOMAIN.

DNS resolution affects address-based rule matching. A domain can resolve to multiple addresses, and caching or network changes can produce different results. “Matched yesterday, not today” does not necessarily mean the rule text changed. Check the request's domain, its resolved addresses, and the actual match record. Matches such as USER-AGENT depend on the relevant request information being available; do not assume they can identify the full behavior of every encrypted connection.

Narrow down the cause with Proxy and Direct

If you suspect a Config rule is sending a request along the wrong path, temporarily switch to Proxy and test the same destination again. If Proxy works but Config fails, check the active configuration, matched rule, and policy target first; there is no reason to immediately re-enter every server setting. If both modes fail, continue checking the server, authentication, and basic network. Restore the original mode when testing is complete so a temporary troubleshooting setting does not become your permanent setup.

Direct can help determine whether the normal direct route works, but it does not guarantee that every destination is reachable on every network. A failed direct connection alone does not prove the client is at fault; check the basic network and whether the destination is actually reachable. Keep the device, destination, and test time as consistent as possible when comparing results. Change one variable at a time so you can identify what caused the difference.

After changing rules, test one destination that should connect directly and another that should use a proxy, then check the actual match records. A page loading only shows that at least one route works; it does not prove all traffic is being routed as expected. Save a copy of the configuration before making changes. Verify only the destinations affected by the change, then expand testing once you confirm there are no unintended matches. Find brief definitions of rule keywords in the glossary.

Connect and verify

Verify a connection in stages: confirm the device has basic internet access, check the client status, then confirm that actual requests use the expected route. An enabled Home switch, a system VPN icon, and a result from a server latency test each indicate a different status. None alone proves that every app is working. Choose a familiar destination you can test repeatedly, and avoid changing the server, rules, and network at the same time; otherwise, the results will be hard to interpret.

Establish a repeatable manual connection

Turn off automatic triggers for now and note the current network, selected server, Global Routing mode, and configuration file. Turn on the connection switch on Home and wait for the status to settle. If it disconnects immediately, check for a permission prompt, system error, or conflict with another network connection. Do not cycle through a dozen servers at this stage. Results from individual server tests are hard to compare until the client is running steadily; resolve local permission or startup issues first.

If the status is stable, open a browser and visit a test destination, then check the app you actually need. Apps may reuse old connections, handle DNS differently, or keep their own cache, so a successful browser test does not mean every app is in the same state. For an app that was already open, finish the current request and reopen it. For persistent connections, reconnect before checking again so an old connection is not mistaken for the result of your new settings.

Interpret Connectivity Test results

Connectivity Test compares connectivity under the current test conditions. The method, test destination, network type, and server load can all affect the result. The displayed time is not a long-term performance guarantee or a download speed. Use the same test method and test at similar times when comparing servers. A failed test may mean the test destination is unreachable or the server does not support that method. Verify with actual access as well; do not remove an entry based on one result alone.

If latency is low but pages will not load, check whether the request needs a different transport, whether authentication is failing, and whether routing points to the intended server. If latency is high but the service works reliably, there is no need to change everything just to improve the number. More useful signals are whether requests complete, connections drop frequently, or the issue occurs only on a particular network. Recording test conditions tells you more than repeatedly refreshing the test.

Choose a troubleshooting path based on where it fails

If every server fails to connect, check basic internet access, system time, and whether your subscription details are valid. Incomplete network sign-in, a significantly incorrect device clock, or revoked system permission can all affect connections. If only one server fails, check its address, port, authentication, and transport settings, and ask the provider of your existing service about its status. Do not clear the entire subscription group because one entry failed; the others provide useful comparisons.

If the client connects but domain names do not load, check resolution results and DNS settings. If only certain destinations fail, check rule matches, the destination service, and whether it uses a special connection method. For a certificate error, first check the system time, TLS server name, and whether the network redirected you to a sign-in page. Do not routinely disable certificate verification. Authentication errors and certificate errors occur at different stages; keep the original messages and handle them separately.

If Wi-Fi works but cellular does not, or vice versa, repeat the same test without changing other settings. Networks may handle UDP, persistent connections, or particular ports differently; changing a remark will not address those differences. First determine whether the issue follows the network or the server, then check the relevant protocol settings. If you need help from your service provider, share the network type and the stage where the error occurs; do not send your full subscription credentials.

Diagnose “connected but no internet”

Break this symptom into four checks: is the local client running, can it reach the remote server, is Global Routing set correctly, and do DNS and rules match the request? Check in that order to avoid changing rules repeatedly when the server cannot authenticate, or reinstalling when a rule is the problem. See troubleshooting an enabled switch with no internet for detailed steps, or visit FAQs for quick answers.

After testing, restore settings for normal use, including Global Routing, the selected configuration file, and any automatic connection conditions you paused. Disconnect and reconnect once to make sure the apparent success was not caused by a stale connection. If a problem appears only after extended use, note whether you switched networks, locked the screen, or updated a subscription beforehand. That timeline may be more useful than a single test result.

Do not treat successful access to one destination as comprehensive proof of anonymity or privacy. The client handles connections according to its configuration; the actual route also depends on the system, network, and destination app. This guide helps confirm that the configuration matches actual requests, not draw broad conclusions from one icon. Keeping the test scope clear makes it easier to reproduce the same issue later.

Data: traffic and request records

Data helps you observe traffic and connection activity the client can record, then compare it with the current configuration. Read the statistics' scope and units before interpreting values. The system, client, and service provider may use different measurement methods, so different numbers do not automatically mean one side is wrong. When troubleshooting, focus on changes before and after a test, whether a request appears, and which route handled it—not just the cumulative total.

Traffic, speed, and latency are different

Cumulative traffic measures the amount of data over a reporting period, real-time speed measures data transferred per unit of time, and latency measures how long a test round trip takes. They answer different questions. An increase in traffic means data passed through the measured scope; it does not prove a page finished loading. Low instantaneous speed may simply mean the app is not making requests. A successful latency test does not guarantee stable large-file transfers. Do not use one measure as a substitute for another.

Uploads and downloads can both affect normal use. Opening a web page sends requests, authentication, and confirmation data; video playback may also involve uploads. Upload traffic is not automatically suspicious. Background apps, system sync, and retries generate data too. Before checking statistics, note which apps are running. If needed, pause other tasks and perform one test action so the change is easier to attribute. Do not use a full day's total to explain a request from a few seconds ago.

Use a focused test to trace a rule

If you suspect a destination is not using the expected route, note the current statistics, access that destination once, then check the available connection or request records. Look at the destination domain, address, policy, and point of failure; do not rely only on a familiar app name. A page may request content from several domains. If the main page loads but images fail, check each connection separately. Change a rule only after identifying the request that actually failed.

If a record shows DIRECT when you expected a proxy, return to Config and check the active file and rule order. If the record shows a proxy policy that points to an unconfigured group, check the group's selection. A matching rule does not mean the remote connection succeeded; resolution, handshake, or authentication can still fail afterward. Separating “why this route was selected” from “why the route failed” is clearer than switching servers while adding new rules.

If you do not see a destination in the records, do not immediately conclude that the app bypassed the client. It may be reusing an old connection, the current filters may not match, the page cache may have prevented a new request, or the logging feature may not cover that information. Refresh the request or restart the app, then check the filter scope. Not finding something in the log means only that it was not captured under the current observation conditions; do not draw a broader conclusion from that alone.

Understand differences in client and provider statistics

A provider's billing may include protocol overhead, traffic in both directions, specific multipliers, or a billing cycle, while client statistics reflect what the client can observe. Different start and end times or units also cause discrepancies. To compare usage, first check the reporting period, reset time, and units on both sides, then compare the same time range. Client data does not replace the remaining allowance shown in your service account, and text in a subscription name is not a reliable source of live balance information.

Direct and proxied traffic may appear in different reporting scopes. After switching Global Routing, a change in the total does not by itself show whether rules behaved as expected; check the individual request records. App updates, image preloading, and connection retries can all cause short-term spikes. If you suspect unusual usage, pause other tasks and record a test window, then resume apps one by one. Do not delete the configuration and lose the original evidence.

Limit logging and protect sensitive information

Connection records may include domains, times, addresses, and errors, so treat them as sensitive diagnostic data. Keep detailed records only for as long as troubleshooting requires, then restore your normal logging level. Before sharing a screenshot, check for full subscription URLs, authentication details, private server addresses, and personal browsing records. Hiding the title does not redact the body; also check QR codes and expanded details.

Before clearing statistics, decide whether you need them for comparison. Resetting gives you a fresh starting point for a test, but it will not fix a server, restore remote account allowance, or change rule matching. Note the reset time, then follow a consistent test procedure so the results can be interpreted. If the interface does not show the detail you need, return to a more basic connection test rather than inventing values or filling gaps with guesses.

After observing the results, state the conclusion precisely. For example: “On the same network, this destination matched DIRECT in Config and the request succeeded after switching to Proxy.” That is easier to reproduce than “traffic looks wrong” and points to the next check. Use Data as one source of evidence alongside Home status, the active Config, and actual access results; it is not a complete diagnostic on its own.

Common Settings

Settings changes how the client runs; it is not a general-purpose fix for every connection error. Keep a working baseline and change one item at a time. Available options may vary by system and feature, so refer to what is actually shown in your app. If an option mentioned in a guide is missing, do not look for a similarly named setting on an unrelated screen. First determine whether the feature depends on the current Config file, system permissions, or another condition.

On Demand connections

On Demand triggers system connection behavior based on configured conditions. It is different from manually turning on the switch on Home, and it does not choose a server guaranteed to work. Before enabling it, establish a stable manual connection and confirm that the server, Global Routing, and Config are set as expected. Otherwise, automatic triggers will repeatedly reproduce the same problem, causing repeated connections and disconnections or failures after a network change.

Before setting triggers, write down which network situations should start a connection and which should pause it, then configure each condition. If a condition uses a Wi-Fi network name, check that it matches exactly; similar names are not necessarily the same network. After enabling it, test what happens when you enter and leave each condition, and check whether disconnecting manually triggers another connection. To pause automatic connections temporarily, check On Demand as well as the Home switch.

DNS and resolution settings

DNS resolves domain names to addresses. Resolution failures can look like a working server with websites that will not load. Before changing anything, check whether the failure affects domain names specifically: testing a target by address and by domain uses different conditions, so do not compare it with an unrelated address. Config can also affect resolution. Distinguish global Settings options from the current configuration file to avoid changing both at once and losing track of the cause.

Do not replace all DNS settings just because you heard one resolver is faster. Resolver reachability, query routing, and caching all affect results; test whether a setting works on your current network. When resolution fails, record the original value, check that the network works, and see whether the configuration uses an unreachable resolution method. Make the smallest change needed. Reconnect affected services afterward and clear relevant caches if necessary; do not treat cache clearing as a required step before every connection.

TLS, transport, and certificate considerations

TLS options affect how the client verifies and establishes encrypted connections. The server address, server name, certificate, and system time must be consistent. Even when connecting by IP, you may still need the server name specified in your details. When a handshake fails, check each item rather than ignoring certificate errors. Disabling verification changes the security boundary; it is not a default maintenance fix and does not prove that the server is configured correctly.

Advanced transport settings should come from your existing server details. Enabling more Host, path, UDP, or protocol options is not necessarily better; a mismatch between client and server can cause failures. If your use case requires a particular transport, first confirm that the server supports it, then check the relevant fields. A successful browser request verifies only some scenarios; it does not prove that real-time audio and video or other apps have the capabilities they need.

Backups, imports, and logging levels

Before making a backup, check what it includes. Server entries, subscription URLs, configuration files, and app settings may not all be covered by the same export method. Review the exported contents, then store them somewhere you control. Subscription URLs and keys are sensitive; do not share backup files publicly as ordinary rule examples. When restoring a backup, account for device differences such as Wi-Fi names, file paths, and system permissions. Do not assume another device can use everything as-is.

Importing a configuration or backup may merge, replace, or add content. Read the prompt and keep a copy of what you have before proceeding. Do not import several old files in a row before confirming what will be replaced. After restoring, check the active Config, server group, and Global Routing, then test manually. Seeing a familiar remark only means some entries were restored; it does not confirm that system VPN permissions, automatic connection conditions, or remote resources were also restored.

Detailed logging can create more diagnostic data and make it harder to manage, so keep only what you need to locate the issue. After testing, remove sensitive records you no longer need, but save a redacted summary of the error first. Rather than retaining large logs you cannot interpret, record the conditions and one reproducible sequence. This makes comparisons more accurate after a system update or configuration change.

After changing Settings, check that On Demand is in the intended state so temporary test conditions do not continue affecting everyday connections. If you do not understand an option, leave it unchanged and read its documentation rather than trying several sets of values at once. To get back up and running quickly, follow the shortest setup path in the quick-start guide and verify the basic connection before restoring advanced behavior.

Routine maintenance and troubleshooting history

Routine maintenance should preserve a working setup and make changes traceable, not require regular reinstalls. Track app, subscription, and rule updates separately: an app update replaces the client, a subscription update refreshes server details, and a rule update changes routing decisions. These can happen independently. If an issue appears after an update, first identify which layer changed rather than attributing everything to “the update.”

Plan the update sequence

Update the iPhone / iPad app through the App Store. For Mac, Windows, Android, and Linux, get the appropriate installer from this site's download page. Before updating on a computer, close any running instance and keep important configuration details. After installation, check system permissions and connection status again. If Android asks to allow installation from the current source, confirm that the file came from this site and revoke that source's permission afterward if desired. Do not expand installation permissions for other apps just because you are updating.

After a Mac update, check that you installed the correct chip version and follow Chapter 1 if the system blocks the app. For a Windows SmartScreen prompt, verify the file source, then use “More info” to see whether “Run anyway” is available. On Linux, using the same package format and package manager makes maintenance easier to track. If switching formats, first check whether the old instance is still running; otherwise, a desktop shortcut may launch the old file instead of the new download.

Update subscriptions when your internet connection is stable. Before updating, note the server remark you are using. Afterward, check that the entry is still there, whether its details changed, and whether the selected server changed. Subscription content is maintained by the provider of your existing service; a name change does not necessarily indicate a client issue. If an old entry disappears, first check whether the update completed and whether your account details changed. Do not manually restore historical settings you cannot confirm are valid.

Keep a rollback point for rule changes

Before changing rules, copy the working configuration, save it with a recognizable name, and note why you are making the change. Work on one destination or one clearly defined issue at a time, then test before continuing. When importing a remote configuration, review its DNS settings, policy groups, and references to remote resources; do not judge it by the number of rules alone. More configuration is not automatically a better fit. Unfamiliar settings may change access to your local network or the route used by other apps.

When a regression occurs, switch back to a verified configuration, keep the server and network unchanged, and visit the same destination. If it works again, compare the old and new rules and resolution settings. If it still fails, check server status and network conditions. A rollback is a way to isolate variables, not a conclusion. Do not switch configurations while also updating the subscription, changing networks, and replacing the server; you will not know which change restored the connection.

Prepare before changing devices or reinstalling

Before changing devices, back up the server details, subscription URLs, and Config files you need, and make sure you can open the backup. System migration may not restore VPN permission automatically, so the first connection may prompt you to authorize again. On iPhone / iPad, restore the app from purchased items using the original purchase account. The iPhone / iPad version is a $2.99 one-time App Store purchase; Mac, Windows, Android, and Linux versions are free and can be downloaded again from this site.

A screenshot showing only server names is not enough for a backup; it usually lacks authentication and transport settings. A backup also does not replace keeping your account information with your own service provider. If an old device is lost or you suspect a subscription URL has been exposed, manage the credentials through your existing service's account portal, then update the details on the new device. Deleting a local entry alone does not revoke remote credentials or invalidate an exposed URL.

Keep a concise troubleshooting record

A useful issue report states which network you were on, what you did, what you expected, what actually happened, and the most recent known change. The exact error text is more useful than a paraphrase, especially for resolution, connection, authentication, and certificate issues. Redact screenshots before saving them. Do not post full subscription URLs, share QR codes, or keys in public discussions, and leave out browsing history unrelated to the issue.

1. Check that the device itself has a working internet connection.
2. On Home, check the current server, Global Routing mode, and selected Config.
3. Repeat the same request to one destination and check the result in Data.
4. Change one condition at a time, record the result, then decide whether to keep or revert it.
5. After resolving the issue, restore automatic connections and your normal logging level, then save a redacted summary.

For quick answers, visit FAQs; for rule names and protocol fields, see the glossary; for first-time setup, return to the quick-start guide. If the issue is with server details or account status, contact the provider of your existing service rather than changing unrelated client settings. This manual explains configuration; it does not provide servers or subscriptions.

Maintenance is complete when the setup has a clear purpose, connections can be reproduced, sensitive details are stored securely, and temporary test settings have been restored—not when every switch has been changed. For a similar issue later, resume at the relevant point in these eight stages; there is no need to start over with installation. Keep each change small enough to explain, and it will be easier to restore your setup when devices or networks change.