Shadowrocket Troubleshooting: Connection, Subscription & DNS Issues

01　VPN toggle won’t stay on: Check VPN configuration permission first

If the toggle on Home won’t stay on, the issue is likely at the stage where the device sets up its local connection. This is different from a web page failing to load. Note whether tapping the toggle triggers a system permission prompt, immediately switches back off, or changes only the status text. Treat these as separate symptoms to narrow down the cause. Repeatedly updating a subscription usually won’t fix a system permission issue, and DNS shouldn’t be the first setting you change.

Check the device’s network and system prompts

Turn off the Shadowrocket connection, then open a page in Safari that should already be accessible on your current network. If public Wi-Fi requires a sign-in, complete that first, then return to the app. A VPN toggle that briefly turns on doesn’t confirm that a remote service is working if the underlying network isn’t connected. When using cellular data, also check the app’s cellular data permission in system settings so the connection isn’t limited to Wi-Fi.

The first time you connect, the system may ask whether to add a VPN configuration. Confirm that the request is from Shadowrocket, follow the system prompts, and complete any required authentication. If you previously dismissed the prompt, return to Home and try connecting again to see whether it reappears. No prompt doesn’t necessarily mean permission was granted; check the VPN section in system settings for the configuration.

System menu names and locations can vary by language and OS version. Search for VPN in Settings. Check whether the configuration exists, can be enabled, and is allowed on the device instead of relying on one fixed menu path. Organization-managed devices may restrict adding VPN configurations. Ask the device administrator to verify any restrictions; changing server details won’t bypass device policies.

Check for connection conflicts, then recreate only what’s needed

If the device has other VPN configurations, first check which one is currently routing network traffic. Pause other features that use a VPN tunnel, then test Shadowrocket by itself. Some network filtering features may also use related system capabilities, so disable and test them one at a time rather than turning everything off at once. If disabling a feature fixes the issue, re-enable it and test again to confirm the conflict.

If the toggle turns off and then comes back on by itself, check On Demand. Automatic connections triggered by network conditions may reconnect after you disconnect manually. Note the conditions, temporarily disable On Demand while troubleshooting, and run a complete test using the manual toggle. Don’t mistake an automatic reconnect for a faulty toggle, and don’t clear the connection conditions before recording them.

If a Shadowrocket configuration is already present in system settings but enabling it fails immediately every time, disconnect and restart the device, then test once more. Only if the issue still reproduces consistently should you consider removing that VPN configuration and letting the app request a new one. Save the app’s configuration and server details first. The system VPN configuration, Config files, and subscription list are separate; don’t delete other data along with the VPN configuration.

How to tell whether this step is complete

If the toggle stays on and the VPN status in system settings matches the app, the local tunnel is established. That doesn’t confirm server authentication, DNS resolution, or access to the destination. Next, go to “Connected, but no internet.” If the connection still drops immediately, note the exact error and when it occurs: before permission is granted, after permission, or while switching networks. This is more useful for diagnosis than simply saying “it won’t connect.”

02　Connected, but no internet: Separate routing mode from rules

The VPN indicator means the device has established a local tunnel; it doesn’t mean every connection has reached its destination successfully. The selected server, Global Routing mode, active Config, and DNS can all affect the result. Prepare two test destinations that should already be accessible: one to check the local network and one to check forwarding through a server you already have. Use familiar, ordinary web pages rather than testing only one app’s content.

Keep the server fixed, then compare three modes

Go to Home and confirm which entry is actually selected under SERVER. An entry appearing in the list doesn’t mean it’s selected, and a subscription update may reorder entries. Run Connectivity Test on the selected entry and note the result. A response only shows that the test path received a response; it doesn’t confirm that every website, transport, and DNS query will work.

Next, check Global Routing. Config uses the active configuration to determine where traffic goes; Proxy tests access through the selected server; Direct provides a baseline using the local network path. Switch modes temporarily for diagnosis, not as a permanent fix. Note the original mode, test the same destination each time, then restore the original setting.

Mode	What it checks	What the result suggests
Config	Check the active rules and policies	If only this mode fails, check which rule is matching first
Proxy	Check the current server path	If it fails, check the server and DNS resolution
Direct	Compare against the underlying network	If it fails, check local network conditions first

If Proxy works but Config doesn’t, passwords are unlikely to be the next thing to check. Open Config and confirm which file is active. Check whether the destination matches REJECT or is routed to a policy that doesn’t exist or isn’t configured correctly. If Direct works but Proxy fails, don’t assume the rules are at fault; check the server timeout and DNS sections to narrow it down.

Check rule order against the actual match

Rules are generally evaluated in order, so a broad rule near the top may handle a connection first. DOMAIN-SUFFIX applies to a domain and its subdomains; IP-CIDR applies to an address range; FINAL handles connections that didn’t match earlier rules. Check the actual destination and match result rather than just finding a rule that looks relevant in the file. A web page may also request several subdomains, so a working main page doesn’t guarantee that its images and sign-in requests work.

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

This example illustrates rule order; it isn’t a complete configuration for every network. Put the more specific ads.example.com rule before the broader example.com rule so it isn’t handled by the suffix rule first. GEOIP relies on address location data and cannot replace every domain rule. Don’t replace your active Config with the entire example. Copy the configuration and change only the rule you’ve confirmed is causing a problem.

Separate app issues from network issues

If Safari works but one app doesn’t, check whether that app uses separate domains, real-time communication, or another transport. Reopening the app can trigger a new connection, but don’t clear its sign-in data right away. Cached content isn’t proof that a request succeeded; refresh and confirm the new request completes, then check the connection log for the matching time and destination.

After changing a rule, make the same request again and check whether the error is gone. If switching networks fixes it, keep that condition in mind and continue checking the local network and DNS rather than crediting an unrelated last-minute change. For a shorter checklist, see Troubleshooting when the VPN is on but there’s no internet. For first-time setup, return to the Getting Started guide.

03　Server timeouts: Separate transport, TLS, and authentication

A “timeout” means a step didn’t finish within the allotted time; it doesn’t necessarily mean the password is wrong. DNS resolution failure, an unreachable address, a blocked port, an interrupted TLS handshake, or an unresponsive server can all result in a timeout. Note the network, server entry, and exact error message first. Then check the address and port, transport settings, TLS, and authentication in that order instead of changing every field at once.

Test the same server on different networks

Keep the same SERVER entry and test it on available Wi-Fi and cellular data. If it fails on only one network, the cause may be that network’s access requirements, DNS resolution, address family, or transport restrictions. Don’t delete the server based on this alone. If another server entry you already have works on the same network, focus next on this server, its port, or its protocol settings rather than the app as a whole.

Check the server address for extra spaces, line breaks, or leftover text from copying. Enter the address and port in their separate fields as provided by your service provider; don’t paste a full web URL into the hostname field. If you use a domain name, check that it still points to the expected address. If your provider has changed the endpoint, use your own latest configuration. Don’t guess a common port number; it must match the server’s listening port.

The Connectivity Test may not use the same method as real-world traffic. No result for an entry doesn’t prove every request will fail; a response doesn’t prove that TLS, authentication, and every transport are working. Also test an actual web page and check which stage reports an error. Repeating latency tests alone usually doesn’t provide enough diagnostic information.

Check protocol settings one by one; don’t assume default values

First, confirm the protocol type in Add Server or the server edit screen. The Shadowsocks encryption method and password, the UUID for VMess or VLESS, and the authentication details for Trojan must match the server. Fields for one protocol can’t be reused for another. Seeing TLS in both configurations doesn’t mean the transport, hostname, and port are interchangeable; compare each field with your original server details.

Field group	What to check	Common mix-up
Address and port	Target host and listening port	Using the admin page URL as the server address
Authentication	UUID, password, or key	Spaces added when copying, or outdated credentials
TLS	Server name, certificate, and device time	Forcing the connection address and certificate name to match
Transport	Type, Host, path, and related settings	Missing the leading slash in a path or changing its case

The TLS server name is used for certificate validation and the handshake; it doesn’t have to match the connection address. Host and path may be required by the transport and shouldn’t be replaced with the server domain without checking. For certificate errors, first confirm the system date and time, then check the name and certificate validity. Don’t treat disabling certificate verification as a normal fix; it can hide a name mismatch or an incorrect connection destination.

Know when the server provider needs to check

If the fields match, the connection fails on multiple networks, and the underlying network works, ask your own service provider whether the endpoint is still active, authentication has changed, and the server is listening normally. You can share the time of the issue, protocol, error type, and tests you’ve already run, but never post complete credentials in a public log. Changing DNS in the app can’t fix a remote server that has stopped responding.

With WireGuard, a completed handshake doesn’t necessarily mean application traffic is flowing. With Hysteria2, also consider whether UDP works on the current network. Don’t enable every option just to “cover all cases.” Use only the settings your server requires. If needed, read the VMess and VLESS field guide to understand each field before changing it.

04　Subscription update failed: Separate retrieval from parsing

Importing a subscription involves at least two steps: retrieving the content from its URL and parsing that content into server entries. A URL opening doesn’t mean it returned a usable subscription, and imported entries aren’t necessarily able to connect. First identify whether the failure occurs while fetching the URL, receiving the response, parsing entries, or connecting to a server. If existing servers don’t work, don’t assume the subscription update is the cause.

Check the URL and account status first

Copy the subscription URL again from your own service provider and check that the beginning, ending, and query parameters are intact. Some URLs contain account credentials, and a single missing character may cause access to be denied. Don’t include instructions, quotation marks, or trailing punctuation in the URL field, and don’t remove long-looking query parameters. Check long URLs privately; don’t paste them in public forums.

If a page asks you to sign in or displays an account message, it isn’t the same as a subscription URL that can be fetched directly. Use the subscription URL your provider specifically supplied for client apps, not an admin page. Subscription content can use different encodings and formats, so a string of text in a browser doesn’t necessarily mean it’s invalid. Don’t save a web page’s content and import it as a configuration file.

Also check the status and usage limits of your existing service. The app purchase and remote service are billed separately; a one-time app purchase does not include a service plan. Buying the app doesn’t generate server details. This guide covers importing and troubleshooting only; it doesn’t provide subscription URLs. Contact your own provider about account status or an expired URL.

Use the response to decide what to check next

If an update times out, verify the underlying network first, then check DNS resolution and access to the subscription domain. For an authentication error, check whether the URL has expired or its credentials have been reset. For a parsing error, check whether the response is actually a subscription format or has been replaced by a sign-in page, notice page, or empty response. Don’t label every failure “bad server”; some happen before a server list is retrieved.

When you already have a working connection, the subscription request may be affected by the current connection, routing, and DNS. Keep the URL unchanged and try once while disconnected and once with the working connection, noting the difference. The goal is to check the URL’s retrieval path, not to rely on one mode permanently. If both attempts fail, test on another underlying network instead of refreshing repeatedly.

Frequent updates in a short period may trigger rate limits on the remote service. If you see a rate-limit message, wait as instructed by your provider rather than repeatedly deleting and adding the same URL. If you need to edit the subscription entry before importing again, save its name and relevant settings, and check whether other configurations refer to its entries. Clearing it without checking can break selections that were working.

After importing, verify the list and selected entry

When the update finishes, check that the number and names of entries look right, then confirm the currently selected SERVER. If an old entry was removed or renamed, your previous selection may no longer point to the server you intended to use. Run Connectivity Test on an entry you already have, then load an actual web page. The update is useful only if the list is refreshed, the right entry is selected, and the connection works.

If you edit entries created by a subscription, expect a later update to overwrite those changes. Record anything you need to keep, and test it in a copy that won’t affect the original subscription. Subscriptions generally maintain server details, while Config controls rules and other settings; they aren’t interchangeable. After importing servers, confirm that Config and Global Routing still match your usual setup.

05　Slow connection: Separate latency, throughput, and individual site response

Start by describing what “slow” means: a long wait before a page starts loading, slow downloads after it starts, repeated video buffering, or sluggish response from one site. These symptoms can occur at different stages. Connectivity Test results mainly compare how quickly the test path responds; they don’t translate directly into download speed. A server with a lower test result may not deliver more throughput at the current time.

Set up comparable test conditions

Use the same device, Wi-Fi location, server, and test file, and pause high-bandwidth tasks on the device. Cloud sync, system updates, and video streaming compete for network capacity, making tests hard to compare. Don’t change both the server and network in the same test; if the result changes, you won’t know which factor mattered. Change one thing at a time and note the approximate time.

First disconnect and check whether ordinary pages load reliably on the underlying network. Then reconnect and test the same destination. If it’s already slow while disconnected, check Wi-Fi signal, router load, or network access first. Cellular signal and congestion can also vary; the signal bars don’t tell the whole story. Move to a location with a stable signal and test again before changing protocol settings.

Avoid repeatedly testing large files in a short period. Speed tests use your own network data and can heat up the device. Look for stability, time to first response, and sustained transfer—not a particular number. If only the first visit is slow and later requests recover, look at DNS, the initial handshake, and caching before concluding that server bandwidth is insufficient.

Choose troubleshooting steps based on the scope of the issue

If several destinations are slow but Direct works normally, focus on the server path, remote load, and protocol transport. If only one site is slow, the site itself, content delivery location, or routing decision for that domain may be involved. Check which policy the destination actually used in the connection log before changing rules. Routing every domain through Proxy may hide the issue without fixing it.

If images load quickly but video buffers, or web pages work while real-time communication is unstable, consider differences in connection type. Some features rely on UDP; others use long-lived connections. A successful TCP test doesn’t cover every use case. Ask your own provider whether the server entry supports the required transport and check local network conditions; don’t infer that the entire protocol works from one latency test.

If the slowdown follows the same server when you switch between Wi-Fi and cellular data, prioritize checking the server or remote route. If it occurs on only one network, keep the server settings unchanged and focus on the local connection, address family, and network access conditions. If another server entry you already have works on the same network, record that evidence before making unrelated configuration changes.

Be cautious with MTU changes and repeated retries

Small requests working while large ones stall can sometimes involve path MTU, but this is a later troubleshooting step, not a routine first move. Rule out packet loss, server load, and destination issues first. Only test an MTU-related setting if the current protocol and configuration provide one and you’ve saved its original value. Don’t copy a one-size-fits-all value from an unknown source or blame every slow connection on MTU.

Repeatedly disconnecting and reconnecting adds handshake and DNS overhead and may interrupt long-lived connections that still work. Give each request enough time to observe what happens, and distinguish slow connection setup from slow data transfer after connection. If reconnecting helps briefly but performance drops again under heavy traffic, note the pattern instead of reconnecting repeatedly. This can help identify remote limits, network congestion, or device temperature.

Success means the task works reliably under the same conditions, not that a test number improved by chance. After identifying the issue, restore the Global Routing mode that fits your needs and undo test settings without evidence behind them. If you keep an exception rule, note its target and purpose so a temporary setting doesn’t add unexplained variables to future troubleshooting.

06　DNS issues: Test resolution separately from connectivity

DNS translates domain names into addresses. If a server latency test responds but a page says the host can’t be found, takes a long time, or loads only some resources, check DNS as a separate step. A certificate error in the browser is different from a DNS resolution failure. Note the exact domain, error message, and connection mode, then check whether a response included an address and what type it was.

Confirm the active configuration and DNS path first

Open Config and confirm which file is active, then look for settings that affect DNS. Editing a file that isn’t enabled won’t change runtime behavior. If there are custom DNS services, Host mappings, or other overrides, record their original values and identify which layer handles the request. System settings, the router, and in-app configuration may all play a role; don’t assume every query uses the same resolver.

Choose a full domain name that fails and compare it with one that works. Use the diagnostics and connection logs available in the app to check whether there’s a resolution result, whether it times out, and whether the connection proceeds. If the domain resolves but TCP or TLS fails afterward, focus on the network or handshake. Repeatedly changing DNS may only change the destination address without fixing the actual problem.

A custom DNS service also needs to be reachable over the network. If its address depends on a DNS lookup that can’t complete yet, it may create a startup dependency issue. Check where DNS requests actually go and whether the behavior changes before and after the connection is established. Don’t change the resolver, Global Routing, and rules all at once; you won’t know which step altered the DNS path.

Check Host mappings, IPv6, and network differences

An outdated Host mapping can pin a domain to an old address and prevent normal DNS updates from taking effect. Disable the mapping related to the failing domain in a copy of the configuration, then try the request again. For content delivery networks, a fixed address may no longer be appropriate for the current network. Don’t keep a one-off working address permanently or treat access by IP as a substitute for testing the full domain.

Some networks return IPv6 addresses without providing reliable IPv6 connectivity. If the issue occurs only on a specific network, check whether the failed connection used IPv4 or IPv6, then compare it with a test of the underlying network. Receiving a particular address type doesn’t by itself prove DNS is at fault. If you temporarily change an address-family setting, note the original value and retest on other networks so you don’t fix one environment and break another.

Local devices, internal domains, and public domains may require different DNS paths. A public resolver may not know the names of local devices; workplace or home resources may depend on the network’s own DNS information. If only internal resources fail, first check the local network and route, then see whether those domains are being sent to a remote resolver by mistake. Sending every domain to the same resolver isn’t a universal solution.

Understand the difference between domain rules and address rules

DOMAIN and DOMAIN-SUFFIX match domain names; IP-CIDR and GEOIP apply to addresses. Some address rules depend on DNS results, so rule matching and DNS aren’t entirely independent. First use a specific domain rule to confirm the policy, then check whether an address rule changes the result. Don’t keep adding broad keyword rules before confirming the target domain; they can affect unrelated requests.

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

This example shows that a specific rule should come before a broader one; it isn’t a complete solution for a real network. portal.example.com is an example domain, not a real service endpoint. After making a change, start a new request so the new connection uses the updated result. System and app caches may retain an earlier result temporarily, so no immediate change after saving doesn’t necessarily mean the configuration failed to apply.

To confirm DNS resolution, check that the domain returns a reasonable address, the request follows the expected policy, and the page actually loads. For more details, see DNS settings and resolution troubleshooting. If you’re unfamiliar with the terms, start with the quick reference, then return to the affected domain. You don’t need to rewrite your entire DNS configuration at once.

07　Battery drain and heat: Check activity before reconnects

When the VPN stays on, processing data through the tunnel contributes to related system activity, but the percentage shown on the battery screen isn’t a standalone power measurement. Shadowrocket’s share may rise when other apps are less active during the same period. Assess an unusual change alongside total battery loss, screen use, network traffic, device temperature, and repeated reconnects—not from a single percentage alone.

Compare observation periods under similar conditions

Check the selected time period on the system battery screen and compare usage with the screen on and off. Note whether you watched videos, transferred files, used navigation, or synced data during that period. High-bandwidth tasks through a VPN naturally require more processing; that’s different from repeated background wake-ups while idle. Compare two periods with similar usage instead of a busy day with one when the device was barely used.

Also note the network type and signal conditions. A weak cellular signal can make the device work harder to maintain a connection, and weak Wi-Fi can trigger retries. If the device heats up only in one location, move somewhere with a stable connection and observe before changing rules. If it warms up only while charging and handling heavy traffic, pause the task and let the device return to normal temperature before testing again.

Background indexing and syncing after a major system update or restoring data may also affect battery life. Wait for those activities to settle before deciding that the connection is causing ongoing extra drain. Don’t run repeated speed tests while the device is hot; they add load, increase power use, and make later performance results harder to compare. If the system warns that the device is too hot, follow its instructions first.

Check On Demand and repeated connections

Open the connection log and check for frequent disconnects and reconnects. Each reconnect may require DNS resolution, a handshake, and authentication, adding work compared with maintaining a stable tunnel. If reconnects happen while switching between Wi-Fi and cellular data, check network stability. If they affect only one server entry, return to the server timeout section and check its settings and remote status. Frequent automatic reconnects don’t mean the connection is more reliable.

If On Demand conditions change frequently, connections may behave differently than expected. Note the conditions, temporarily disable automatic triggers in a controlled environment, and connect manually to see whether repeated reconnects continue. If the connection stabilizes, restore conditions one at a time to find the trigger instead of repeatedly turning the toggle off indefinitely. If you need On Demand, keep its conditions clear and purposeful.

Some protocols have keep-alive settings to maintain network mappings or connection state. An overly frequent interval may increase network activity, but disabling keep-alives at random can affect reachability on some networks. Change this only if your existing configuration includes the setting and you understand its purpose. Don’t copy values from another protocol or sacrifice necessary connectivity just to improve idle battery readings.

Reduce background tasks and diagnostic activity

While troubleshooting, avoid running broad Connectivity Tests continuously or keeping diagnostic logs at unnecessarily high detail. Tests and logging also use processing and storage. Once you have enough evidence, restore the settings you need for everyday use and monitor battery use during normal activity. If your configuration includes extra processing tasks, disable them one at a time in a copy rather than deleting anything you can’t explain.

Check whether an app is repeatedly retrying failed requests while connected. If a destination matches REJECT, some apps may keep trying; DNS errors can cause the same behavior. Fix the rule or DNS path instead of simply reducing the frequency of tests. Match frequently repeated destinations in the connection log with the apps in use to distinguish background app traffic from tunnel maintenance.

Record a reproducible finding, such as “the device heats up only when this server entry repeatedly reconnects on the same network,” rather than “the VPN drains the battery.” If the issue remains noticeable after pausing high-bandwidth tasks, using a stable network, and restoring necessary settings, save redacted logs and note the battery observation conditions for follow-up. Don’t keep the device hot just to test, and don’t treat a factory reset as a routine solution.

08　Issues after an update and on iPad: Check what changed

If a problem appears after an update, first identify what changed: the app, the OS, a subscription refresh, a Config replacement, or the network. Several changes may happen on the same day, but timing alone doesn’t prove they share a cause. Note the server, mode, and network used the last time everything worked, then compare them with the current state. The goal is to find what changed in behavior, not to overwrite everything with an unverified old configuration.

Save your data, then run a minimal retest

Save the current Config, custom rules, and any server details you need. Identify which information came from a subscription and which was entered manually so you can restore it. Then restart the app and test the existing configuration; if needed, restart the device to reinitialize its network state. If the issue continues, make a copy of the configuration and test with only the essential rules and one server you already have. Don’t clear data that’s working.

If the minimal configuration works but the original doesn’t, restore the original rules and settings in groups until you find the difference. Test the same destination after each change instead of restoring everything at once. If both fail, check VPN permission, the underlying network, and server settings. If an error points to configuration syntax, check nearby separators, policy names, and fields—not only the line you just changed.

Check the App Store listing for update details and system requirements. To verify the app, see the Purchase & Verification guide and confirm the developer is Shadow Launch Technology Limited, the official icon matches, and the app ID is 932747118. Shadowrocket is a closed-source commercial app for Apple platforms. Get and update it through the App Store; purchasing it again won’t fix network settings.

Check iPad and iPhone differences one by one

If the same server details work on iPhone but not on iPad, first confirm both devices are actually using the same network. The iPhone may be on cellular data while the iPad is still on Wi-Fi, even if the network names look similar. If your iPad supports Wi-Fi only, retest on another available network rather than following cellular data checks that don’t apply to that device.

A purchase record doesn’t prove that local configurations are identical. Compare the selected SERVER, Global Routing, active Config, DNS settings, and On Demand conditions on both devices. Check manually entered fields one by one. When copying a configuration, confirm you copied the active file rather than an older saved version. Matching entry names aren’t enough; entries with the same name may have different addresses or settings.

The iPad layout may change with orientation, window size, or multitasking. Lists and editing areas may appear side by side; use interface labels such as Home, Config, and Settings to identify the right section instead of looking for a button in a fixed spot on the left or right. When entering a long URL, check that the keyboard hasn’t added spaces or punctuation, and verify the text before saving.

Wake from sleep, local network, and reinstall considerations

If the issue occurs only after the iPad has been idle for a long time, first check whether the network is back after waking it. Then disconnect and reconnect manually once. If that restores the connection, note whether it coincided with a network change or an On Demand condition, and continue checking reconnects and DNS. Don’t rebuild every configuration each time the device wakes; that can hide a network recovery timing issue and erase useful troubleshooting evidence.

If only local devices, internal pages, or printing fail, check the relevant system permissions and whether the target traffic is routed through Direct as expected. Local address ranges, internal domains, and public internet destinations may need different handling; check the actual address and DNS result. Don’t route all traffic through Direct permanently to fix one local destination, and avoid broad address rules that could affect other connections.

Before reinstalling, make sure you can read your configuration backup, restore manually added entries, and locate your own subscription URL. App purchase restoration and purchase eligibility are subject to the App Store listing. See the Getting Shadowrocket on iPad guide and Restore purchases on a new device guide. Restoring a purchase restores access to the app; it won’t recreate your existing servers or rules.