Shadowrocket
Setup and Configuration Reference

01 / APP STORE

Getting and Purchasing the Official App

Confirm the product before you buy and install it. Shadowrocket is a paid client for Apple platforms, available exclusively through the App Store. When similar names appear in search results, don't rely on a translated nickname alone. Visit the App Store purchase and verification guide and check the developer, official icon, and app ID before proceeding.

Check These Three Details on the App Store Listing

The developer should be Shadow Launch Technology Limited, and the app ID in the product page URL should be 932747118. The app name can help you find the listing, but it is not enough to verify it on its own. Open the product page and check the developer field; this is more reliable than relying on a search result snippet. If anything doesn't match, stop and return to the correct listing before purchasing.

The icon should match the official icon shown in this site's header: a white background with a blue-purple outlined graphic. The icon is only one of the three checks; it does not replace verifying the developer and app ID. If you save the App Store link, keep the complete product URL. When returning from a browser bookmark, check the URL and page details again to avoid confusing a similarly named product with the same app.

Review the product page's compatibility and purchase information before buying. iPhone and iPad are the primary devices covered in this guide. Compatibility with Mac, Apple TV, and Apple Vision is also listed on the same App Store page. System requirements and purchase eligibility are as stated on the App Store page; don't assume a purchase applies to a particular device based on installation results on another device.

Client Cost vs. Connection Configuration

Shadowrocket is sold as a one-time purchase. The US storefront price is about $2.99; the actual price is the amount shown on the App Store at the time of purchase, and other storefronts display local currency. The client purchase is paid through the app sales channel. Whether a server works, when a subscription expires, and which connection parameters are available depend on your existing service; buying the app does not determine these.

A one-time client purchase is not a service subscription. If no server entries are available after installation, that doesn't mean the purchase failed; it means your connection details haven't been imported yet. Make sure you have a subscription URL or complete server parameters before moving to Chapter 3. If you don't have them yet, you can still read the interface and rules chapters without repeatedly reinstalling the app.

Treat your purchase account and configuration data as separate things. App Store purchase records confirm your eligibility to get the app; servers and rules in the app are separate data. Getting the client again after changing devices doesn't mean your subscription, manually added entries, and local configuration have all been restored. Check purchase restoration and configuration restoration separately; one does not verify the other.

After Installation

Once the app has finished downloading, open Shadowrocket from your device's Home Screen. First make sure it opens normally, then consider connecting. As you read this guide, note your device type, network, and how you obtained your existing configuration. You don't need to upload this information; it is only a baseline for troubleshooting. If something goes wrong, it can help identify whether the issue is with installation, importing, or connecting.

If the App Store says you've purchased the app but your current device still asks you to pay, first check that the account currently used for App Store purchases matches the original purchase record, then review your purchased items. Don't treat the device's sign-in status and the store's purchase status as the same thing. Handle payment, storefront availability, and purchase record issues according to the App Store prompts.

App updates are also delivered through the App Store. Keep important configurations before updating, then test a familiar connection before changing protocols, rules, and DNS all at once. The App Store release notes describe feature changes. This guide doesn't assume a particular app version or fixed screen layout; if an option has moved, follow its current name and description in the app.

02 / PERMISSION

First Launch and VPN Permission

On first launch, get familiar with the interface, then handle system authorization when you're ready to connect. Shadowrocket needs permission from your device to add a VPN configuration. This is separate from whether your server account is valid. Approving the system prompt only allows the app to establish the corresponding connection; it does not verify the remote server, rules, or DNS.

Home, Config, Data, and Settings

Home is where you view server entries, choose a connection, and control it. Config manages the active rule configuration. Data shows traffic and request details. Settings contains common behavior options. Learn what each section is for rather than looking for buttons at exactly the same screen coordinates on every device; layouts vary with screen size and app updates.

Before connecting, check Home for your own server entries. If the list is empty, don't keep toggling the connection switch: it cannot create server details. After adding or importing, make sure you can reopen the saved entry and review it, then return to Home. This helps distinguish unsaved information from a connection failure.

Seeing a configuration name in Config doesn't mean its rules are active. First check which configuration file is selected, then check the Global Routing mode. Keep server selection, configuration selection, and routing mode distinct; this makes it easier to understand why different requests on the same device may be handled differently.

What System Authorization Actually Means

The first time you turn on a connection, the system may ask to add a VPN configuration and authenticate the change using your device. Read the prompt and confirm it appears after you initiate a Shadowrocket connection, then follow the system steps. This changes a device-level setting; you should not enter your server password during system authentication. Server credentials belong only in the relevant connection fields.

If you previously tapped Cancel, return to the app and try connecting again to see whether the system asks for authorization. If no prompt appears or the switch immediately turns off, check the VPN status and related messages in system settings. Managed devices may have additional restrictions. If you see a clear management policy message, don't keep deleting configurations to test; first confirm that this type of connection is allowed on the device.

After authorization, you still need to select a working server and confirm that your network can reach its address. The system's connected status is one part of the local connection process. Whether a webpage loads also depends on rules, server authentication, DNS resolution, and the destination site. Track “authorized,” “connected,” and “request succeeded” as three separate checkpoints.

Resolve Conflicts Without Resetting Everything

If the device already has other VPN configurations, identify which one is handling the connection during your test. Don't switch back and forth between related toggles and then judge the result. Stop the current connection, confirm the system is in the expected state, and then start Shadowrocket. Keep the names and purposes of existing configurations; don't delete items needed for work, school, or device management unless you understand the impact.

Leave On Demand off during your first validation. Automatic triggers can change the connection state as you switch networks or visit domains, making manual actions appear ineffective. Establish a baseline with one complete manual connect-and-disconnect cycle. Once the server works, add automatic connection conditions one at a time to see the effect of each setting.

Authorization works the same way on iPhone and iPad, but landscape orientation, Split View, and window width can change the layout. If you can't find an option, exit a narrow Split View and look for its English name in the full app window. A layout change is not a reason to reimport a subscription; it doesn't by itself indicate that configuration data is damaged.

Removing a VPN configuration from the system does not remove server entries from the app, and reinstalling the app does not resolve every permission issue. Rebuild an item only if the system clearly reports a configuration problem and you've kept data you can restore. Afterward, repeat the authorization and manual connection steps; don't assume the pre-removal status still applies.

03 / SERVER & SUBSCRIBE

Add Servers and Import Existing Subscriptions

Before importing, identify what kind of information you have. A single server entry describes one connection. A subscription URL usually retrieves and updates a group of servers. A .conf file mainly contains rules and related behavior. These can be used together, but a subscription URL is not a server hostname, and importing a rules file doesn't necessarily give you a working server.

Add Server: Check Each Protocol Parameter

To add a server manually, open Add Server from Home, choose the protocol that matches your existing details, then enter the server address, port, and authentication information. The protocol determines which fields are required; don't put one protocol's parameters into another protocol's form just because both ask for a password. Compare every field with the original details before saving, especially for extra spaces or line breaks introduced during copying.

Enter the supplied hostname or IP address in the server address field, and enter the port separately. Don't put a full web URL with its path into the host field. The display name is just a label for identifying the entry; it won't fix an incorrect host, port, or authentication detail. A clear name can also help you select the right entry and check it in Data later.

Shadowsocks typically requires checking the encryption method and password. VMess and VLESS commonly use a UUID and relevant transport fields. For Trojan, enter authentication and TLS details as provided. Hysteria2 and WireGuard use different parameter structures. Don't guess fields that weren't provided or apply one protocol's parameter conventions to every connection type.

Subscribe and Scan QR Code

To import an existing subscription, use the subscription import option in the app. Choose Subscribe or the relevant type shown in the current interface, then enter the URL provided by your service provider. A subscription link may contain personally identifying information, so protect it like a password. After importing, check the entry names, number of entries, and protocol types. Seeing a group of entries doesn't mean every connection is valid.

If a subscription update fails, first distinguish an incorrectly formatted URL from a retrieval failure. Check that the URL was copied in full and doesn't include quotation marks or line breaks, then confirm the subscription is still valid. A retrieval error may occur before any server connection test. Repeatedly changing server passwords won't help; check the update message and the subscription URL's access requirements first.

Scan QR Code is useful for importing connection details you already have, but scanning is just another way to enter data; it doesn't verify that the content is trustworthy. Check the QR code's source before scanning, then review the generated entry's protocol, address, and key fields before saving. Grant camera or photo access only as needed for the current action; importing one entry doesn't require access to unrelated data.

Subscription Updates and Config

Entries in a subscription may be replaced, removed, or renamed when it updates, so don't use subscription-managed fields as a permanent space for manual notes. If you need to keep a modified test entry, first check whether you can save a separate copy and record where it came from. Don't overwrite a frequently used subscription without a backup; otherwise, it may be difficult to tell your edits from remote changes after an update.

In Config, check separately whether the file is selected and whether the policies referenced by its rules exist. Successfully importing a file only means its contents were accepted; it doesn't mean every rule suits your environment. Before enabling an unfamiliar configuration, review General and Rule and confirm it won't apply unexpected policies. If you don't understand a complex section, leave it unchanged for now and consult a dedicated guide.

After importing, choose one entry and test its connection before organizing groups or update intervals. This separates input errors from bulk maintenance issues. For protocol fields, see Supported protocols and parameter overview. For configuration structure, see .conf section reference. Reimporting repeatedly is no substitute for checking the details.

04 / GLOBAL ROUTING

Global Routing: Three Modes and Rule Order

Global Routing determines the overall handling mode in use. Config applies the selected configuration, Proxy routes traffic through a proxy, and Direct connects directly; use these English names when working in the interface. These modes are not server protocols or speed ratings. First identify whether you're troubleshooting overall connectivity or a specific rule, then choose a mode to avoid drawing conclusions from the wrong test conditions.

What Config, Proxy, and Direct Each Test

Config uses the currently selected configuration to decide how requests are handled, making it suitable for everyday routing. It depends on the rules, policies, and referenced servers in that configuration all working as intended. If a destination fails in Config, check which rule matched before assuming the server is down; the rule may send it through Direct or explicitly set it to REJECT.

Proxy routes traffic through a proxy and can simplify rule-related factors during a test, but still requires a valid server, correct authentication, and a working network. It can't fix DNS failures, an unreachable remote server, or a problem with the destination itself. Change only this mode and check whether the same destination behaves differently. If you also switch servers, you can no longer compare the routing mode on its own.

Direct handles traffic as a direct connection; it doesn't mean the app is disconnected. When testing Direct, keep an eye on the system connection status and app settings. If a destination works in Direct, that only shows that the current network can reach that destination. It doesn't prove that other domains, ports, or the proxy server are reachable, and it doesn't justify a conclusion about the entire ruleset.

Rule: From Specific Conditions to FINAL

Read rules in order: check specific domain and network conditions first, then broader matches, and finally FINAL. Once an earlier rule determines how a request is handled, later similar rules usually won't change its result. Before adding a rule, search for existing entries. Put exceptions in the right place; an exception after a broad rule may be present but never match.

DOMAIN matches an exact domain, DOMAIN-SUFFIX matches a domain suffix, and DOMAIN-KEYWORD matches a keyword in the domain. Each covers a different range. Use keywords carefully, as they may match domains you didn't intend. Domain rules generally don't include webpage paths; don't paste a full page URL into them.

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

This example shows Rule structure only; it is not a complete configuration ready to enable on every device. The first domain rule may determine the result before later network or region conditions. The private network range illustrates IP-CIDR syntax. PROXY, DIRECT, and REJECT are policy keywords, while the interface modes Proxy and Direct use different capitalization. Don't confuse them with field names.

Domain Rules vs. Address Rules

IP-CIDR and IP-CIDR6 apply to their respective address ranges, while GEOIP relies on address classification data; these use different information from domain rules. Address-based conditions can only be evaluated once the destination address is known. A domain may resolve to multiple addresses, or its resolution may change with the network, so the matched rule can change too. Record both the domain and address when troubleshooting.

FINAL handles traffic that hasn't matched an earlier rule and belongs at the end of the ruleset. Moving FINAL up can prevent subsequent rules from taking effect as intended. When adding an exception, first identify which existing rule it needs to override, then place it appropriately. Don't put every new entry at the top just to give it “priority”; that makes the relationships between rules harder to maintain.

After changing rules, test a specific destination and check the policy in Data rather than just checking whether a page opens. A page may rely on several domains; loading the main document doesn't mean images, sign-in, and API requests took the same route. For keyword definitions, see Quick Reference. Once testing is done, restore your usual mode so a temporary test setting isn't left in place.

05 / CONNECTIVITY

Connections, Latency Tests, and Verification

Start connection checks with the local network and verify the server, protocol, rules, and destination access in turn. A latency test returning a number only means that the test received a response at that time; it doesn't replace testing a complete real-world request. Choose one server, one Global Routing mode, and one fixed test destination before comparing results. This avoids combining several changes into an ambiguous result.

Establish a Repeatable Test Baseline

First confirm that your Wi-Fi or cellular network works. If the network requires a sign-in page or has a temporary restriction, handle that with Shadowrocket disconnected. Changing server protocols won't help if basic network access isn't available. Note the network type before connecting; if you switch networks during testing, treat it as a new condition rather than relying on the previous result.

On Home, confirm that the selected server is the one you intend to test, check that its subscription is still valid, and make sure an update hasn't replaced its authentication details. Then check Global Routing and the active configuration. If server names are similar, open the details and check the address; don't rely on the selected position in the list, which may change after an import or update.

After connecting, check the app's prompt and system status, then make a new request to a destination. A page already open in a browser may be cached, and a page that stays on screen doesn't prove a new request succeeded. Reload a fixed destination and look for the corresponding entry in Data. Match the time of your action to the request result and handling policy to create a repeatable test.

Connectivity Test vs. Real-World Access

The test method and target used by Connectivity Test affect the result, so latency figures from different methods shouldn't be compared directly. Some tests focus on establishing a connection; others include the request and response. Check which method is in use and whether the results are consistent. A lower number in a single test doesn't automatically mean every webpage or app will load faster.

Interpret a test timeout alongside real requests. A server may not respond to one type of probe but may still handle the traffic you need. Conversely, it may respond to a probe but fail during authentication or forwarding. If the results differ, note the test method and error, then try a real request through the same server. Don't delete every entry based on one result in the list.

If every entry fails at once, check shared conditions such as the current network, subscription validity, test destination, or a recent settings change. If only one entry fails, check its protocol, address, port, and authentication. Broad failures and individual failures call for different checks. Narrow the scope before randomly changing encryption methods or DNS.

Narrow the issue by failure stage

For a domain resolution failure, check the resolution path first. For a connection timeout, check whether the server is reachable. For an authentication failure, verify the credentials. For a certificate error, check the server name, device time, and original TLS parameters. Error text may come from different stages, so keep the original wording rather than labeling everything “a network issue.” Don't disable certificate verification to hide a name mismatch.

If Proxy works but Config fails, focus on matched rules and their referenced policies. If both modes fail, check the shared server and resolution conditions. This comparison can narrow down the cause, but can't prove it by itself. Use the same destination, network, and server before and after testing; otherwise, the difference may be hard to interpret.

If the connection works but speed is inconsistent, look separately at network changes, destination response, server status, and sustained transfers. Large downloads, real-time communication, and short webpages behave differently; don't use one scenario to judge them all. Reproduce the most common failure first, then change one thing at a time and record the result before making further adjustments.

After testing, disconnect once and reconnect to confirm the result is repeatable. A successful first test may have relied on an existing session; reconnecting can reveal the underlying issue. If the connection remains stable, re-enable automatic behavior such as On Demand one step at a time. For the shortest procedure, return to the Quick Start; this chapter explains why each checkpoint needs its own test.

06 / DATA

Data: Traffic and Request Records

Data helps you inspect traffic handled by the current connection and find clues about requests. Don't treat its cumulative figures as a service bill. App statistics, system statistics, and measurements from your existing service may cover different scopes and periods. First decide what you're trying to find out: how a request was routed, where it failed, or how much data an action generated.

Match an Action to Its Records

Before testing, note the time, network, server, and Global Routing mode, then perform one repeatable action, such as reloading a specific page. Check Data for new records around that time. Don't open several apps at once and then guess which records belong to what. Background sync can also generate traffic, so use the domain or destination address to confirm a likely match.

A webpage often loads a main document, images, APIs, and other resources, so multiple domains are normal. Start with the requests related to the failed feature: a blank page may involve the main document, a sign-in failure may involve an authentication API, and missing images may point to resource domains. Checking these requests separately is more reliable than searching for the page URL and drawing conclusions about the whole site.

Use the fields available in the current interface as your guide. Focus on the destination, handling policy, matched rule, connection status, or error. Not every request shows the same information; an empty field doesn't mean the app didn't handle the request. If needed, make a new request to confirm it was generated after the current connection and configuration took effect, rather than being left over from an older session.

Trace the Result Back to the Configuration

If a request used DIRECT, find the rule that determined this and check whether it was expected. If it used PROXY, confirm which server or policy object was ultimately selected. When you see REJECT, first trace it to the rule that explicitly rejected the request rather than changing the server password; a reject policy may determine the result before any connection to a remote server is attempted.

Consider domain names and IP addresses together. A domain may resolve to multiple addresses, and one address may host multiple services; an address alone doesn't show the full context of a request. Some connection records may not expose information that can be matched against a domain rule. Keep track of what was visible at the time; don't assume a domain you found later was necessarily part of the original request.

After changing rules, make a new connection before checking the result. Existing connections may continue using the path established when they were created, so unchanged old records don't necessarily mean the configuration failed to save. Stop the relevant requests, reconnect if needed, and repeat the same action. Compare matched rules in the new and old records to see whether the change affected subsequent handling.

Cumulative Traffic and Data Privacy

Before reading traffic statistics, check their scope and starting point—for example, the current connection, a time period, or data accumulated by the app. Follow the current interface's description. Without a consistent measurement window, don't draw conclusions by comparing two figures. Reconnecting, clearing records, or changing display filters can also affect the scope, so note the conditions before comparing.

Upload and download figures indicate the direction of traffic, not whether a user actively viewed the content. Background refreshes, automatic backups, page preloading, and retries can all generate data. If usage rises unexpectedly, narrow the view to one app and a short time window, pause other obvious transfers, and observe the change. A rising total alone doesn't prove that a server entry is at fault.

Service-side and local measurements may differ because of protocol overhead, measurement periods, scope, or use on other devices. Check how each is measured rather than expecting every byte to match. Local Data is useful for investigating connection behavior; it doesn't replace your existing service's information about remaining usage, validity, or measurement rules.

Request records may expose domains, addresses, times, and clues about personal activity. Before exporting or taking a screenshot, filter for information relevant to the issue and hide subscription URLs, authentication fields, and unrelated activity. Keep the original error text if you need to reproduce the problem. Clearing records first makes it harder to investigate an old issue, so tidy up only after diagnosis is complete.

If Data doesn't match what you see in the browser, first consider caching, existing connections, and whether you've identified the right request before expanding the investigation. Other system activity can also skew what you observe; not every record belongs to the app in the foreground. Use a fixed action, a short observation window, and repeated tests to build a reliable connection between actions and records.

07 / SETTINGS

Settings, DNS, and On Demand

Adjust Settings one item at a time after establishing a stable connection. First identify whether a setting affects resolution, trigger conditions, or connection behavior, then record its original value and why you're changing it. Options and names may vary by device and app version; follow what the current interface shows. You don't need to enable every feature, and complex settings aren't prerequisites for a successful connection.

DNS: Check the Resolution Path First

DNS resolves domain names to addresses, while routing rules determine how requests are handled. They are related but distinct. If name resolution fails, the browser may not have reached the normal connection stage, so switching proxy servers alone may not help. First find out whether the current DNS settings come from the app, the active configuration, or the network, then decide what to change.

General in Config and related items in Settings may both affect behavior; check how they interact in the current app documentation. Avoid entering different values in multiple places and keeping track of only one. Note the original settings and keep a copy of the configuration before making changes. During testing, change one source at a time and check resolution and access for new requests. Keep the change only after confirming the result.

More DNS servers don't necessarily mean better results. Different resolution paths may return different addresses or depend on the current network or proxy for access. First confirm that your chosen resolver is reachable under current conditions, then check whether it suits the destination. Repeatedly changing DNS isn't a universal fix; it can't correct a wrong password, server port, or reject rule.

Domain results may be cached, so an old address appearing briefly after a change doesn't necessarily mean the setting failed. Make a new request, re-establish the relevant connection, and check the resolution details. Accessing a site directly by IP isn't an equivalent test; TLS names and site routing may still depend on the domain. When the test method changes, be clear about which conditions it can actually verify.

On Demand: From Manual Baseline to Automatic Triggers

On Demand triggers connection-related behavior based on conditions and is best configured after manual connections are stable. First define which network conditions should connect and which should not, then add rules one at a time. Don't start by covering every Wi-Fi network, cellular connection, and domain. If triggers interact with the manual switch, it will be hard to tell which condition caused the result.

When setting a Wi-Fi name condition, check the actual network name and watch for similar names, guest networks, and automatic device switching. Matching a network name only describes a trigger condition; it doesn't mean that network offers the same access. Keep other conditions unchanged during testing, switch to the target network, wait for the status to change, then check the app and system status.

For cellular or domain-based triggers, also verify when they run and the order of the rules. The outcome depends on whether a request occurs, whether its domain matches, and whether the system allows the connection. Automatic connection doesn't guarantee that a server stays available. Even if the trigger fires, an unreachable remote server can still prevent access. Record “condition matched” and “service available” separately.

After turning off On Demand, check whether the current connection remains active and whether the system status is as expected. Disabling automatic triggers and ending an existing session are separate actions; the switch alone doesn't confirm that every connection has stopped. For a more complete guide to organizing conditions, see Set up On Demand connections.

Limits for Other Common Settings

If local network access fails, first check whether the destination is on the local subnet and how the current rules handle it, then review related settings. Home devices, printers, and admin pages may rely on local discovery; don't send all traffic through the same policy. After changing network options, test a specific local destination rather than treating a successful public webpage as proof that local access works.

For IPv6-related issues, first check which address type the current network and destination actually use, then review rules such as IP-CIDR6. Disabling an address capability may change the symptom without explaining the cause. Keep the original value and compare results for the same destination under different conditions. Make a lasting change only after confirming it is related to the issue.

Don't enable rewrite or certificate-related features in bulk just to get a basic connection working. They have distinct purposes and effects; understand each one, grant explicit authorization, and limit its scope. You can complete a normal server import, Global Routing setup, and connection check with a simpler configuration. If the issue isn't related to these additional features, leaving them unchanged makes troubleshooting easier.

08 / MAINTENANCE

Maintenance, Device Migration, and Troubleshooting

The aim of routine maintenance is to keep configurations understandable and recoverable, not to reset them frequently. Keep your app purchase record, existing subscription details, server entries, active configuration, and personal changes separate. That way, you can address only the relevant parts when something goes wrong. After maintenance, test the connection again to make sure you haven't changed the server you use, Global Routing, or rule handling.

Keep a Working Baseline Before and After Updates

App updates come through the App Store; subscription updates retrieve server details from your existing subscription. Don't refer to both as “updates” in troubleshooting notes. If you update the app, refresh a subscription, and change rules all at once, it will be hard to identify the cause of a problem. Do these separately where possible, and test a fixed destination after each step before moving on.

Before updating a subscription, save any independent entries and notes you need, and check whether the active server could be affected by entry replacements. After the update, review name changes, the current selection, and connection results instead of relying on the update-complete message. If a new entry fails but an independent old entry still works, compare protocol fields and remote changes before clearing the entire app.

Keep a verified copy before editing a configuration file, and use clear names to distinguish everyday and test versions. Don't use your only working configuration as a temporary test area. Break complex changes into stages—domain rules, network range rules, and General settings—and test one stage at a time. This makes it possible to revert a specific change instead of rebuilding everything.

Check Three Layers When Restoring on a New Device

Layer 1 is eligibility to get the app. On the new device, check purchased items in the App Store using the original purchase account. System requirements and purchase eligibility are as stated on the App Store page. Redownloading the client restores only the app; you still need to open it and check your local data. A purchased marker in the store doesn't prove that server configurations have migrated.

Layer 2 is your server and subscription information. Restore it from the address or parameters you've saved, then confirm that it's still valid. A subscription that worked on the old device may no longer be valid, and a manually entered server may fail if copied fields are missing. Test one frequently used entry first, then organize the rest. Don't add automatic triggers before confirming a connection works.

Layer 3 is your active configuration and personal settings. After restoring rule files, check the selected configuration, Global Routing, DNS, and On Demand, then confirm system authorization for the first connection. Authorization on the old device doesn't replace approval on the new one. For purchase restoration and layout on iPad, see Restore purchases and use Shadowrocket on iPad.

Configurations used for migration may contain server addresses, subscription credentials, or other personal information. Store them somewhere secure that you control. After exporting, check the file contents and how to restore it; don't delete your only working copy just to test the backup. Once migration and connection checks are complete, remove temporary copies you no longer need.

Close the Troubleshooting Loop with Minimal Notes

At minimum, record when the issue occurred, device type, current network, server protocol, Global Routing mode, active configuration, and the original error text. Add the last known successful conditions and the most recent changes to help narrow the scope. Hide passwords, keys, full subscription URLs, and personal browsing details; keep only the structure needed to understand the issue.

When a problem occurs, reproduce it first, then identify the layer: can the app open, is authorization complete, was the information imported, is the server reachable, are the rules correct, and is the destination working? Each layer answers a different question; reinstalling isn't a solution for every symptom. Consider recovery actions only when the evidence points to local data or installation status, and keep recoverable information first.

Confirm the reverse after fixing the issue. Restore your usual mode, reconnect, repeat the action that failed, and check in Data that the rule and policy match your expectations. If it works only in a temporary test mode, troubleshooting isn't complete. Once the result is stable, clear diagnostic records and note the final change so you can compare it quickly if the same issue returns.

For long-term maintenance, remove test entries you've confirmed you no longer need instead of accumulating unexplained configurations. Keep a small set of clearly labeled baselines, and periodically check subscription validity and whether purchase records can be restored. For routine steps, see the Quick Start Guide. For terminology, see the Quick Reference. For purchase and installation issues, return to the App Store guide's purchase restoration section.