Shadowrocket
Complete User Guide

1. Get Shadowrocket from the App Store and Verify It

Confirm the app’s identity before completing your purchase. Shadowrocket is a paid commercial app for Apple platforms, available exclusively from the App Store. Before opening the store, read the app authenticity guide and check the developer, official icon, and app ID. The name or a similar-looking icon in search results isn’t enough to verify an app. Open the product page and check these details together, then let the system handle the purchase.

Check the Developer, Icon, and App ID

The developer should be Shadow Launch Technology Limited, and the app ID is 932747118. You can identify the app ID in the product page URL as id932747118. The icon should match the official icon used on this site: a blue-and-purple outlined design on a white background. Check all three details together. Don’t rely on search ranking, extra wording in the app name, or promotional text in an image. Once you’ve confirmed the app, check the price, compatibility, and purchase button.

Use the App Store listing to verify the price, compatibility, update history, and purchase terms. This guide doesn’t specify a minimum OS version because device requirements may change on the store page. iPhone and iPad are the primary devices covered here. For Mac, Apple TV, and Apple Vision availability, check the compatibility section of the same product page. Refer to the App Store listing for system requirements and Universal Purchase availability.

App Purchase vs. Connection Service

A one-time purchase describes how you pay for the app; it does not include a server, subscription link, or service traffic. After purchasing, you still need your own server details or a subscription from a service provider you already use. Whether the app opens, the purchase succeeds, and a server connects are separate things to check. For example, if the app is installed but the server list is empty, you’ll usually need to import your details; that doesn’t mean the purchase failed.

The amount shown in the purchase confirmation, in your local currency, is the price to use. The US storefront reference price is $2.99; the App Store listing is authoritative. Apple’s purchase flow handles account region, payment requirements, and storefront details. If a purchase won’t go through, first check the specific message from the system. Don’t repeatedly change Shadowrocket’s network settings: server settings in the app can’t fix an App Store account or payment issue.

Redownload a Purchase, Reinstall, or Move to Another Device

If you’ve purchased Shadowrocket before, first make sure the App Store is signed in to the account used for the original purchase, then look for Shadowrocket in that account’s purchased apps. If the product page still shows a price, don’t confirm another purchase right away. Check the account, purchase history, and store message first. The name and location of the purchased apps section may change with system updates, so follow what appears on your device. To get the app on another device, also check its compatibility and the conditions listed in the store.

Getting the app again and restoring its data are separate processes. The store confirms your purchase eligibility; whether your subscriptions, configuration files, custom rules, and traffic records are still available depends on device migration or backup restoration. Save any data you need before deleting the app. Being able to redownload it from your purchased apps doesn’t mean all your settings will be restored automatically. Check the product page and your Apple account to see whether Family Sharing applies; don’t assume it does during configuration import.

App updates are also delivered through the App Store. Before updating, note the server and configuration that currently work; after updating, repeat the checks in Chapter 5. For purchase and redownload questions, see Restore a Previous Purchase and Pricing and One-Time Purchase. This chapter covers app identity and purchase terms. The following chapters deal with connection details. Keeping these issues separate helps avoid troubleshooting the wrong thing.

2. First Launch and System Permissions

On first launch, get familiar with the main areas before changing settings. Home shows your servers, lets you choose a connection, and provides the connection toggle. Config manages configuration files; Data shows traffic and connection records; Settings contains app preferences. The layout may vary by device. To look up interface terms, refer to the English interface terms guide. Don’t guess where an option is based only on its icon.

When VPN Configuration Permission Is Requested

When the app is ready to connect, the system may ask to allow a VPN configuration to be added. This prompt authorizes a network extension configuration; it doesn’t add a server or purchase another service. Make sure the prompt comes from the Shadowrocket you’re using, then follow the system instructions to authorize it. You’ll still need valid server details and the right connection mode—authorization alone isn’t enough.

If you dismiss the permission prompt, return to the app, check the connection toggle, and try the normal connection flow again. Don’t tap the toggle repeatedly in quick succession; it can be hard to tell which action triggered the prompt. If the system reports a configuration management restriction or says it can’t add the configuration, check the device’s settings and management status. Restrictions on managed devices may not be removable from within the app. When troubleshooting, note the exact message rather than classifying every authorization failure as a server issue.

Grant Permissions When You Need Them

When using Scan QR Code, the system may request camera access. You only need to grant it if you plan to scan your own connection details with the camera. Denying camera access doesn’t prevent you from adding a server manually or importing an existing subscription. If you need to scan later, check the app’s permissions in system settings. If multiple QR codes appear in the camera view, make sure the recognized result matches the connection details you intended to import.

Pasting a link from the clipboard, selecting a configuration file, or using another import method may also trigger a system prompt. Match each permission to the action you’re taking: check the paste request when pasting, and check the file source when selecting a file. There’s no need to grant unrelated permissions in advance. If nothing imports, first check whether you dismissed the system picker, then verify the content format.

Check System and App Connection Status Separately

A VPN Connected message in the system only indicates that the relevant network configuration is connected. It doesn’t confirm that the remote server, DNS, or destination website is working. Likewise, allowing a VPN configuration won’t establish the intended proxy connection if no valid server is selected in Home. For your first connection, check in this order: details imported, server selected, mode confirmed, toggle on. Don’t treat a single status indicator as a final diagnosis.

If other apps or system configurations that use network extensions are active on the device, first confirm which connection is actually in use. Don’t switch multiple network tools and system settings in the same test; interruptions caused by a configuration change can be mistaken for a Shadowrocket issue. Don’t delete a system configuration if you’re unsure what it does. Check its name, source, and device management requirements before deciding whether to disable it or contact the administrator.

Establish a Baseline for First Use

At first launch, note three things: whether Home loads normally, whether the VPN configuration was added successfully, and whether you’re using Wi-Fi or cellular. Don’t include passwords or a complete subscription URL in your notes. These details help identify whether a problem occurs before the app opens, during system authorization, or while connecting to the remote server. If the app opens normally but network requests fail, checking your connection details is usually more useful than repeatedly reinstalling the app.

Once permissions are handled, if the server list is still empty, continue to the next chapter to add your existing details. If the list has been restored, confirm the selected server and Global Routing rather than relying on what you remember from your old device. Device migration may preserve some data, but network conditions and system authorization must be checked on the current device. The goal of first launch is to establish a clear starting point, not to configure every advanced option at once.

3. Import Existing Servers and Subscriptions

Before importing, distinguish among three types of information. A single server entry contains the details for one connection. A subscription URL retrieves and updates a group of servers. A configuration file defines DNS, rules, and other operating settings. These may appear in the same set of instructions, but they serve different purposes. Entering a subscription URL in a server address field, or treating a configuration file as a server password, won’t work. Identify the type of information first, then choose the right import method.

Enter Details Manually with Add Server

To add details using Add Server, choose the Type that matches your existing information, then enter the address, port, and authentication fields. Enter only the server hostname or address in the address field; use the port provided in your details. Don’t paste a full link, including its protocol prefix, into a regular address field. After entry, check each field against the source, especially leading or trailing spaces, Chinese punctuation, and letter case. Saving confirms that the entry was created, not that the connection works.

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard, HTTP, and SOCKS5 don’t all use the same fields. A password required by one protocol doesn’t mean you should enter the same information for another. Enter UUIDs, keys, TLS names, and transport paths in the fields specified for that protocol. For advanced options not explained in your details, ask the service provider you already use rather than copying settings from an unrelated entry with a different protocol.

Subscription URLs and Group Updates

Get an existing subscription from your own service provider, then add it using an import option supported by the app. If you use the Subscribe type in Add Server, enter the subscription URL and a name that helps you identify it. Save and update the subscription, then check that the expected servers appear. A successful subscription download and a working server are two separate checks: the first confirms that the list can be retrieved; the second tests a specific connection from that list.

If a subscription update fails, first check that the URL is complete, contains no line breaks, and is reachable on your current network. If the response is a login page, notice page, or unsupported data, the app may not be able to create a server list from it. An existing service may have expired, the link may have changed, or authentication details may no longer be valid. Compare the app’s error with the subscription status from your provider. Don’t repeatedly delete and recreate entries just because the number of servers changed.

QR Codes, Links, and Configuration Imports

Use Scan QR Code to import a QR code you already have. After scanning, check that the Type, name, and key parameters match what you expected. A QR code is only a way to carry information; it doesn’t guarantee that the details are correct or valid. The same applies to link imports. QR codes, complete subscription URLs, and share links containing access credentials are sensitive. Don’t include them in public screenshots, comments, or troubleshooting records.

Manage configuration files in Config separately from the server lists updated by Subscribe. After importing a file with rules, confirm whether it has been selected as the active configuration. After updating a subscription, check that the default server is still available. Some files may include both servers and settings; don’t infer their purpose from the file extension or name alone. Check what the app actually recognizes in the imported content.

After importing, return to Home and explicitly select a server. Check that the selection indicator is beside the entry; opening its edit screen isn’t enough. Entries with similar names are easy to confuse, so give manually added servers descriptive labels—but never put a password in a label. Before removing duplicates, check which group they came from. Entries generated by a subscription may reappear on the next update, so manage the subscription source rather than deleting its entries one by one.

The goal of this chapter is to confirm that the details were recognized correctly and that you can identify the currently selected server—not to fill the list with entries. Next, choose Global Routing and test the connection. If a subscription update fails, keep the exact error and steps that led to it, then use the maintenance steps in Chapter 8. This helps distinguish a failure to retrieve the list from a server that can’t be reached.

4. Global Routing and Rule Order

Global Routing determines how current traffic is handled. The three modes—Config, Proxy, and Direct—correspond to rule-based routing, proxying all traffic, and connecting directly. For everyday rule-based routing, Config is usually the mode to use. Proxy and Direct can help with specific scenarios or controlled tests. Changing this mode doesn’t change the server or select a different configuration file. Check the mode, active configuration, and selected server separately.

What Each Mode Controls

Understand these modes alongside the app’s system bypass settings, traffic interception boundaries, and the configuration in use. They don’t guarantee that every system communication on a device follows the same route. Switching to Proxy can help determine whether a rule is involved, but it won’t fix every connection failure. Switching to Direct doesn’t prove that DNS, the remote website, or the current network is working.

Read a .conf File in Order

This configuration snippet explains the syntax; it isn’t a ready-to-use configuration for every network. [General] contains general settings, and [Rule] contains rules. Rules are generally checked from top to bottom, and the first match determines how traffic is handled. PROXY, DIRECT, and REJECT are policies, not server protocols. Save the original file before editing, and change one thing at a time.

[General]
bypass-system = true
dns-server = system
skip-proxy = 192.168.0.0/16, localhost

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

In this snippet, example.com and subdomains matching the suffix condition are handled by DOMAIN-SUFFIX, so they won’t reach the later DOMAIN-KEYWORD rule. Other domains containing the relevant keyword may match the next line. IP-CIDR applies to address ranges; GEOIP checks address location data; FINAL is the fallback when no earlier rule matches. Putting a broad rule first may prevent later rules from handling their intended targets.

Domain Rules and IP Rules Aren’t Interchangeable

DOMAIN matches an exact domain, DOMAIN-SUFFIX matches a suffix and its subdomains, and DOMAIN-KEYWORD matches a keyword. Keyword rules can cover more than you might expect, so check whether a new rule could affect similarly named targets with a different purpose. IP-CIDR and IP-CIDR6 describe the corresponding IP ranges; they don’t directly identify a website. A service may use multiple domains and IP addresses, so one matching rule doesn’t mean every request from that page follows the same route.

GEOIP relies on IP location data and the address actually resolved; don’t infer a match from a page’s language or a company’s location. DNS resolution can affect which destination address an IP-based rule sees, but DNS settings aren’t routing rules. For conditions such as USER-AGENT, first check what the app supports and what information is actually available. Don’t assume it can reliably identify every encrypted request.

How to Verify Rule Changes

First confirm that Global Routing is set to Config and that the active configuration is the file you just edited. Send a request to a specific target, then check available records for its domain, matched rule, and policy. If the record still shows the old route, check whether the app needs to reload the configuration or reconnect. The target app may also be reusing an existing connection. A page loading doesn’t prove that a new rule took effect; cached content can make the page appear normal.

If local network access is failing, check the actual IP ranges, relevant bypass settings, and rule order—not just whether public websites work. For DNS principles, see DNS settings explained; for quick definitions, see the quick reference. The key is to check the complete chain—mode, configuration, rule, and policy. Remembering one keyword can’t replace checking the full route.

5. Connections, Connectivity Test, and Troubleshooting

Test a connection at three levels: whether the app establishes a connection, whether the selected server works, and whether the request to the actual destination succeeds as expected. The Home toggle, Connectivity Test, and real-world access each provide different information and aren’t interchangeable. Before testing, confirm that your current network works, your existing details are still valid, and a server is selected. Don’t update a subscription, change DNS, and switch configurations midway through the test.

Follow a Consistent Connection Test Sequence

In Home, select the target server and confirm the selection indicator is beside it, then check Global Routing. Turn on the connection toggle. If the system asks to authorize a VPN configuration, follow Chapter 2. Wait for the status to stabilize before testing. If the list contains entries with the same name, compare their groups and Type to avoid editing one entry but connecting to another.

Run Connectivity Test and note the actual result—success, failure, or timeout—then try accessing a real destination. A test only reflects the conditions of its target and method; it can’t guarantee that every service will work. If the test fails but real access works, check whether the test target has its own reachability restrictions. If the test succeeds but a particular page fails, check the domains, DNS, and rules used by that page.

Latency Numbers vs. Real-World Access

Latency tests help compare response times under the same conditions; they don’t directly measure bandwidth, sustained stability, or performance with a particular content service. Results aren’t directly comparable when the test time, network, target, or method changes. A single low latency result doesn’t confirm that authentication, transport settings, or long-lived connections are working. When comparing servers from a subscription you already have, see latency, regions, and protocols explained for context.

Narrow Down the Problem Based on What You See

If every destination fails, first check your basic network, then verify the selected server’s address, port, authentication, and TLS settings. If you can’t access ordinary services on the current network, resolve that issue first. If only this server fails, compare it with another entry from details you already have. If the other entry works, you’ve narrowed down the problem, but a single test doesn’t prove the original server is permanently unavailable.

If only some destinations fail, note the exact destinations and when the problem occurred, then check which rules matched their requests. A webpage may use separate domains for its main document, images, APIs, and authentication. An incorrect route for just one of them can cause a partial failure. Switching to Proxy is a short-term comparison only; restore the original mode after testing. If the page works after switching, investigate routing and DNS rather than deleting the entire configuration.

Switching Networks and Reconnecting

After switching from Wi-Fi to cellular, you may need to re-establish the existing connection. Wait for the network to stabilize, turn the connection off and back on, then repeat the same test. Keep the destination and server unchanged so you can tell whether the network made a difference. If you also change servers and configurations, you won’t know which change fixed the problem—even if it starts working again.

For TLS or authentication errors, compare each field with your existing details and check the device’s date and time. Don’t disable certificate verification as a default fix: it changes the connection’s verification requirements and may hide a domain name or time setting error. Ask your existing service provider about fields you can’t identify. When reporting a problem, include the error type, protocol, steps, and network type. Don’t share complete passwords, keys, or subscription URLs in public records.

At the end of a test, you should be able to state your current network, selected server, Global Routing mode, active configuration, and actual test results. This short baseline is more useful for diagnosis than “connected but not working.” Next, check Data to investigate the request—not to substitute a total traffic figure for a connection test.

6. Data: Traffic Statistics and Request Records

Data shows the traffic and connection information recorded by the app. It can help answer questions such as whether a test generated a request, which destinations had issues, and whether traffic followed the expected rules. It isn’t a service provider’s account statement, and it doesn’t represent all network activity on the device. Check what the figures cover and their time range before interpreting them. Don’t subtract figures from different reporting periods and use the result to infer a problem with the app or service.

Check the Reporting Period Before the Numbers

When reviewing traffic, check whether the screen shows the current connection, a particular reporting period, or cumulative records, and distinguish uploads from downloads. Reconnecting, resetting statistics, restoring app data, and the settings in use can all affect the reporting period; check the current screen for details. When recording a number, include the start and end times. Otherwise, it’s hard to tell whether a change came from your test request or other background activity.

The app and service provider may measure traffic in different places. Protocol overhead, accounting methods, connection retries, time windows, and units can all cause discrepancies. Traffic shown in Data doesn’t mean the provider will charge the same amount, and you can’t infer your remaining service balance just from the cumulative total on your device. For existing service limits and validity, check the account information from your provider.

Track One Request at a Time

To troubleshoot, minimize other activity: record the current state, open one specific destination, then return to Data and check for changes during that period. If several apps refresh at once, the records may include requests unrelated to your test. System background traffic may also appear, so don’t immediately assume an unfamiliar domain belongs to the page you just opened. Look at the timing, destination, and results from repeat tests together.

If the current screen shows destination domains, addresses, policies, matched rules, or error details, check each one. The domain tells you what was accessed, the policy shows how it was handled, and the error points to the stage where it failed. Read them together. A request matching DIRECT doesn’t automatically mean a rule is wrong; revisit the active configuration only if that route conflicts with what you expected.

Use Records to Check Rules and DNS

If a destination used an unexpected policy, first confirm that Global Routing is set to Config, then check the active configuration and rule order. If the destination is shown as an IP address, also consider DNS and how the app makes the request. Don’t turn a single IP in the records into a broad IP range rule. One address may host several services, and widening the range at random can affect requests that already work.

If a domain failed to resolve, check DNS conditions. If it resolved to an address but the remote connection timed out, check the server, route, and destination reachability. The two issues can affect each other, but the troubleshooting order differs. An error in the records is a diagnostic clue; it needs to be tied to what you were doing rather than interpreted on its own. For DNS settings, see Chapter 7 instead of repeatedly clearing Data records.

Resetting Statistics and Protecting Sensitive Information

Resetting statistics gives you a clean starting point for the next comparison, but it won’t fix a server, change rules, or reset your provider’s usage meter. Before resetting, save any figures and timestamps you need to compare so you don’t lose your only clue. To track a brief test, you can also record the difference before and after without clearing all historical data.

Before sharing records publicly, check for complete destination URLs, query parameters, subscription credentials, authentication fields, or personal browsing details. A screenshot without a visible password may still expose a link containing a token. For support, share only the error type and necessary fields, with unrelated identifying information removed. Keep enough context in the redacted text to show whether the issue was DNS, authentication, or a remote timeout.

For long-term monitoring, use the same time window and test method for meaningful comparisons. An occasional spike may come from normal background activity; don’t reimport every subscription just because of one change. If a problem keeps occurring, keep a concise timeline of network changes, configuration updates, and errors. It connects your actions to their results and helps guide the settings changes in the next chapter.

7. Settings, DNS, and On Demand

Adjust Settings to meet a specific need, rather than changing every option. When you’re starting out, keep a known-working baseline, then address DNS, On Demand, or diagnostic settings as needed. Some options are in the app interface, while others are in configuration files; consider both alongside the selected configuration. Don’t search for options based on screenshots from another setup or enter a similar-looking name if it doesn’t appear on your screen.

System DNS and Custom DNS

DNS resolves domain names to addresses used for connections; routing rules determine how requests are handled. They’re related, but not the same. The setting dns-server = system means that the system DNS settings are used for this item. It’s one starting point for understanding configuration behavior, but doesn’t guarantee the same result on every network. The DNS conditions provided by the system may also change when you switch between Wi-Fi and cellular.

[General]
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

If you need custom DNS or DNS over HTTPS, first confirm that the resolver address is reachable on your current network, then check the format supported by the app. The resolver itself also needs to be reachable; if it isn’t, changing DNS may cause more destinations to fail. Changing DNS doesn’t change server authentication, and encrypted DNS won’t automatically fix every connection problem.

After making a change, test the same destination and account for caching. The destination app may reuse a previously resolved address or existing connection, so an immediate lack of visible change doesn’t necessarily mean the setting failed. Confirm that the configuration is loaded, then reconnect if needed. Avoid repeatedly switching between resolver settings. For details, see System DNS, Custom DNS, and DNS over HTTPS.

On Demand Triggers Connections; It Doesn’t Fix Servers

On Demand triggers a connection when configured conditions are met. Set it up only after manual connections are stable. Enter conditions for network type, Wi-Fi name, or domain according to the current interface, and test each one separately. On Demand changes when a connection is made; it won’t fix an incorrect password, expired subscription, or unreachable server. If manual connections fail, troubleshoot the connection before setting up automatic triggers.

Before setting up a rule, write down what you expect—for example, “connect on a specified network”—then check for overlapping conditions. Don’t rely on memory to determine the priority of multiple conditions; refer to the in-app guidance and verify the behavior. Test in environments that both meet and don’t meet the conditions. Testing on just one network won’t tell you whether a condition is too broad or explain unexpected triggers later.

If the connection quickly resumes after you turn it off manually, check whether On Demand is still enabled before assuming the toggle is broken. For temporary troubleshooting, pause automatic triggers and establish a manual test baseline. For longer-term changes, see Set Up On Demand by Wi-Fi, Cellular, and Domain. Avoid changing trigger conditions and server details at the same time.

Limits of Diagnostic Toggles and Advanced Settings

Enable logging or diagnostic options only when needed, and keep in mind that records may contain destination and connection details. Restore the original settings when troubleshooting is complete. More logging doesn’t make a connection more stable; it gives you information to diagnose it. Check system time, certificate verification, and transport settings against the instructions for your existing service. Don’t treat security checks as general speed controls.

Before changing an unfamiliar advanced setting, read the in-app guidance and record its original value. Change one item at a time. If something goes wrong, restore the original value and repeat the same test instead of stacking on more “might help” settings. Similar fields in a configuration file also need to be checked against the active configuration; editing a file doesn’t mean the app is using it. Record setting changes and configuration selection together.

If you’re only trying to make your first connection, there’s no need to configure every advanced option in Settings. First return to Chapter 5 and establish a working connection, then make any further changes one at a time. For interface terms and protocol parameters, see the quick reference. For an overview of the three connection modes, see Proxy Modes. The point of this chapter isn’t to prescribe a fixed set of settings, but to make sure every change has a testable purpose.

8. Subscription Updates, Backups, and Routine Maintenance

Routine maintenance has three goals: keep existing details valid, preserve configurations you can restore, and make problems easier to diagnose. Updating a subscription, updating the app, and changing rules are separate actions; avoid doing them all during the same troubleshooting session. If the connection works, don’t change a setting just because you see a new option. When something does need to change, record the current state and follow a clear sequence.

Check Subscriptions Before and After Updating

Before updating, confirm the subscription source and group, and note the selected server and active configuration. After updating, check for error messages, confirm the entries look as expected, and make sure the previously selected server is still there. A provider may change server names, count, or parameters; a different list doesn’t by itself indicate an app problem. If an entry has been replaced, select an available server again and test the connection.

If an update fails, don’t immediately delete the existing subscription. Check the network, link, service status, and whether the response is still recognizable subscription data. An existing server list may continue to work, but that doesn’t prove the subscription URL is still valid. Conversely, a successful update doesn’t prove that every server in the list works. Record list retrieval and server testing separately so you can tell your provider exactly where the failure occurred.

What to Include in a Backup

Using the export or backup options currently supported by the app, save the configuration files, custom rules, subscription sources, and manually added details you need. Don’t assume exporting rules also saves every server, or that a system migration will restore all app data. After backing up, check that you can identify each file’s contents and purpose, and note which details you’ll need to obtain again from your provider.

Backups may contain passwords, keys, complete subscription URLs, or other authentication details. Store them somewhere you control. Before asking for help, make a separate copy with sensitive fields removed; don’t share the original backup publicly. File names can describe the purpose and date of your personal backup, but shouldn’t contain credentials. If you keep multiple copies, mark which one you’ve verified so you don’t restore an experimental configuration by mistake.

Moving Devices, Reinstalling, and App Updates

When moving to a new device, first redownload the purchase from the App Store, then restore your data, and finally authorize the VPN configuration and test the connection on the new device. Purchase eligibility, app data, and system authorization each have their own restoration process; completing one doesn’t mean the others are done. You can keep the old device temporarily as a reference for settings, but whether both devices can use the same service at once depends on its terms.

If behavior changes after an app update, check the selected server, Global Routing, and configuration first, then review in-app messages and the App Store update notes. Don’t make reinstalling your first step: it can create extra data recovery work and remove useful troubleshooting clues. If you do need to reinstall, first make sure you have the right purchase account, an available backup, and any necessary credentials.

Use a Troubleshooting Sequence You Can Retrace

Check the basic network first, followed by system authorization and connection status; then check the selected server, connection mode, active configuration, DNS, and rules. Change only one thing at a time, and decide after testing whether to keep or revert it. For intermittent problems, record the order of network changes, device sleep, subscription updates, and failures. That’s more useful than repeating every possible step. A timeline can reveal whether the problem consistently follows a particular condition.

When requesting help, note the device type, current network, protocol, connection mode, exact error, and steps to reproduce it. You can copy the app version as it appears in your own troubleshooting notes, but don’t guess if you’re unsure. Share only the necessary fields with sensitive details removed. Don’t disclose complete subscription links, passwords, keys, or personal browsing records. The more precisely you describe the steps, the easier it is to assess the problem.

A complete workflow covers App Store purchase, authorization, importing details, choosing a mode, testing the connection, and keeping maintenance records. To repeat the steps from the beginning, return to the quick-start tutorial. For purchase and restore questions, see the FAQ in App Store Purchase and Download. For terminology, use the quick reference. Troubleshooting by stage makes ongoing maintenance easier than treating every issue as “can’t connect.”