Shadowrocket
Troubleshooting Guide

01 / VPN CONFIGURATION

Connection switch won’t turn on or turns off immediately

First distinguish an authorization issue from a connection failure

If the connection switch on Home won’t stay on, first check whether the system allows a VPN configuration to be created. The first time you connect, the system may ask you to approve adding a VPN configuration and authenticate with your device passcode or another system method. This authorization lets the app create a network tunnel; it does not verify the remote server. If you dismissed the prompt, return to the app and try connecting again to complete the approval instead of repeatedly changing server passwords. Note whether the switch turns off before you approve the prompt or shortly after it turns on; each points to a different cause.

Open system Settings and look for a Shadowrocket configuration in the VPN settings. The exact location may vary by system version; use Settings search if needed. Check whether another VPN session is already active. In general, a personal device can’t keep multiple VPN connections active at once. End the other session, then test Shadowrocket again. Don’t delete all network configurations unless you know what they’re for, especially on a work or school device, where managed settings may enforce important access controls.

Clear lingering state in reversible steps

1. Stop the current connection, wait for the system VPN status to clear, then reopen Shadowrocket.
2. Temporarily turn off On Demand to prevent automatic connections from interfering with manual tests.
3. Make sure an existing server is selected, save the configuration, then try connecting once.
4. If the connection still closes immediately, restart the device and test again on the same network. Record the result.

If a configuration exists in system settings but the app still can’t establish a session, first make sure your configuration is backed up. Then remove only the VPN configuration clearly associated with Shadowrocket and let the app request authorization again. This removes a system network authorization record; it does not reset a remote account or fix an expired service or incorrect settings. Before proceeding, make sure you can retrieve your existing configuration again. Don’t make reinstalling the app your first step: local servers, Config files and diagnostic records may be lost.

Check system restrictions and connection triggers

Managed devices may restrict adding VPN configurations, changing network settings or running certain network extensions. If a system control is unavailable, a message says it’s managed by an organization, or a configuration keeps reappearing automatically, ask your device administrator about the applicable policy. A device passcode, Screen Time restrictions and management policies are separate issues; remote server details can’t change them. On a personal device, also check available storage and whether other apps are having issues before concluding that a network extension failed to start.

On Demand starts connections when its configured conditions are met, so a connection that turns back on after you switch it off isn’t necessarily a faulty switch. Turn off On Demand first and confirm that a manual connection stays active. Then restore its trigger conditions one at a time. If the issue occurs only when switching Wi-Fi networks, locking the screen or leaving a particular network, record the exact action rather than just saying it disconnects occasionally. Repeating the same test under the same conditions helps distinguish a system-restarted session from an unexpected app shutdown.

If the connection still won’t turn on, note the device model, whether it meets the listed system requirements, the authorization prompt, whether the device is managed and the steps that reproduce the issue after a restart. For the app and system requirements, see how to verify the genuine app. System requirements are as listed on the App Store page. Don’t keep deleting configurations without noting the original error; the first message is often more useful for diagnosis than the outcome of later attempts.

02 / REQUEST PATH

Connected, but webpages won’t load

First establish a baseline with the connection off

Stop Shadowrocket and open a page that normally works on your current Wi-Fi or cellular network. If it still fails with the connection off, check the network itself: whether Wi-Fi requires a sign-in page, whether the router has internet access, whether cellular data is allowed and whether the signal is unstable. Public Wi-Fi may require completing its sign-in page while the connection is off. Reconnect only after authentication succeeds. If the underlying network isn’t working, changing rules will only add variables.

If browsing works with the connection off but fails when it’s on, narrow down the scope. Test two different destinations to determine whether all requests fail, only one app is affected or a particular domain is failing. Use the same page and steps for each comparison. One test may display cached content while another makes a fresh network request. An old page in the browser doesn’t prove the connection is working: reload content that needs the network and check whether the corresponding request appears in the app’s request log.

Use Global Routing to narrow down the cause

Global Routing determines how requests are handled overall. Config mode evaluates the active rules; Proxy mode checks the route through the selected server; Direct mode checks access without proxy routing. Use these modes for brief comparisons, not as universal fixes. When testing is done, restore the mode you need and confirm that the intended Config is active. Seeing a configuration in the file list doesn’t mean it’s the one currently in use.

If Proxy works but Config fails, check which rule matched the failing request and which policy it selected. A broad DOMAIN-KEYWORD rule, a REJECT rule placed too early or an unexpected DIRECT policy can change the route. Rules are generally evaluated in order: find the rule that actually matched, then check whether a broader condition appears before it. Simply adding a correct rule at the end may not help if an earlier rule already matches the request.

Use a minimal rule set to understand matching—don’t overwrite your configuration

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

Here, example.com is only an example of the syntax, not a connectivity test service. DOMAIN-SUFFIX matches the specified domain and its subdomains; GEOIP matches based on IP address location; FINAL provides a fallback policy for requests that don’t match earlier rules. To experiment, duplicate your existing Config and save it as a test file. Keep the original intact. These three lines are not a complete configuration for every situation. Don’t remove existing DNS settings, policies or other required configuration along with them.

If both Proxy and Config fail but Direct works, check the server settings, remote availability and DNS along the proxy route. If only one app is affected, check whether it uses its own connection method, has kept an old session or is allowed to use cellular data. If needed, fully quit and reopen the app to ensure you’re testing a new connection. Restarting the target app and rebuilding the VPN session are separate steps; test them separately to find out which one changes the result.

If a request matches REJECT, first verify what the domain is used for. Temporarily disable only the suspected rule and test again; don’t remove all blocking rules. A page may rely on several domains, and blocking just one request can leave part of the page blank or prevent sign-in. For more on the limits of this approach, see how to write REJECT rules. If all modes fail while the underlying network works, note the time and error type for a failed request, then continue to the next section.

03 / SERVER PARAMETERS

Server timeouts and protocol handshake failures

Interpret test results by layer

Connectivity Test and server latency tests show only whether a particular test completed over the network at that moment. They don’t reflect every browser request. A failed test might involve address resolution, a port connection, a protocol handshake or the test destination. A successful test doesn’t guarantee that the remote server can reach every destination. Note which test you used, then check the page that actually fails. Compare results from the same test method; don’t compare numbers from different tests as if they were equivalent.

When checking a server address, make sure copying it didn’t add spaces, line breaks or punctuation. The address should match the details for your existing service, and the port must correspond to the selected protocol endpoint. A domain resolving successfully doesn’t mean its port is reachable; a successful port connection doesn’t mean authentication worked. If your existing details list multiple ports or transport methods, match each field to the correct endpoint. Don’t combine one endpoint’s address with another endpoint’s TLS or transport settings.

Check how protocol fields relate to each other

The server name used for certificate validation in TLS may serve a different purpose from the address used to establish the connection. Use the details provided in your existing configuration. Don’t infer the meaning of transport fields such as Host or path from their names. If the service configuration changes, parameters in an older subscription may still import but no longer complete a handshake. Update your own subscription and confirm the update succeeds, then compare the fields before and after. This helps avoid selecting an outdated entry among several similar ones.

Check the system date, time and time zone; automatic settings are usually best. A significant time difference can affect certificate validation or time-sensitive authentication. If you see a certificate error, don’t treat disabling verification as a permanent fix. Check the server name, device time and remote certificate status. Bypassing verification can hide the real cause and makes it impossible to tell whether the settings were fixed or the error was simply ignored. Troubleshooting is complete only after testing again with verification restored.

Compare networks to pinpoint routing issues

Keep the server and settings unchanged, then test on Wi-Fi and cellular. If the issue occurs on only one network, check for access restrictions, differences in UDP handling or differences in address-family support. This narrows the problem down to the network path; it doesn’t identify a specific device fault. If one server fails but other servers already available in the same subscription work, ask the original service provider to check that endpoint before rebuilding all your client settings.

With WireGuard, check both that the Peer can communicate and that AllowedIPs covers the destinations you want to route through the tunnel. Handshake and routing are separate issues; a successful handshake doesn’t guarantee correct routing. Don’t confuse the private key with the remote public key, and never expose your private key when sharing diagnostics. See WireGuard parameters explained for details. Don’t randomly replace keys to troubleshoot routing.

When reporting the issue, describe it in terms such as “the handshake times out for this protocol on this network; here’s what happened on another network.” Include the types of fields you checked, not full authentication details. For a consistent sequence of checks, see the server timeout checklist. Repeated rapid retries rarely fix a remote issue and can make results from different times harder to compare. Gather a reproducible example before deciding what to try next.

04 / SUBSCRIPTION UPDATE

Subscribe import failed or updates aren’t working

Separate a fetch failure from a parsing failure

A subscription update involves several stages: fetching the URL, contacting the server, receiving a response and parsing its contents. “Update failed” is only the outcome; first find out which stage failed. No response and an unreadable response call for different checks. For the first, look at the network, URL and authentication. For the second, check whether the response is actually subscription content Shadowrocket can recognize. Keep your existing working entries while troubleshooting. Deleting the entire subscription group after every failed update removes the old configuration you need for comparison.

Copy the full subscription URL again from your own service details. Check for leading or trailing spaces, line breaks, missing query components and accidentally added punctuation. Subscription URLs often contain credentials; don’t include them in public screenshots, chat messages or diagnostic attachments. If you need to show the request structure, keep only the domain and field names, and remove all field values. Don’t repeatedly paste the full URL into different websites for testing. If someone else gets the URL, they may be able to access your account or service.

Choose a troubleshooting path based on the response

If you see an authentication failure, insufficient permissions or access denied, first check the subscription status, whether the URL was reset and any access restrictions in the account page provided by the original service provider. Buying the client again won’t restore remote authentication. A one-time client purchase is not a service plan: your App Store purchase record and credentials for a service you already use are separate. See pricing and one-time purchase details. An App Store purchase record doesn’t prove that a subscription is still active.

A login page, maintenance notice or other webpage in the response doesn’t mean the subscription update succeeded, even if the request completed. The client needs subscription data it can recognize, not just any content a browser can display. If the request was redirected, check that the final response still belongs to the expected service flow. Don’t try to fix a parsing error by manually removing authentication details from the URL. That usually turns the request into an unauthenticated one and takes you further from the original problem.

If the current connection isn’t working, the subscription request may also be routed through a failing proxy path. Keep the old entries and compare update results with the connection stopped and with an existing working connection. Check how the active Config handles the subscription domain. Don’t assume every update request takes the same route, or that a service page opening in a browser means the app’s subscription request will succeed. The sessions, authentication and responses may differ.

After a successful update, check what actually changed

1. Confirm the operation reports success and check which servers actually appear in the subscription group; don’t rely on the message alone.
2. Check whether the selected entry still points to an old endpoint. If needed, select an existing updated entry.
3. Check which subscription group similarly named servers belong to, so you don’t test a leftover configuration by mistake.
4. After a connection test succeeds, clean up old entries if needed, keeping a configuration copy you can refer back to.

A smaller server list after an update doesn’t necessarily mean entries were lost during import. The original service may have changed its entries, account permissions or subscription contents, or a filter may be hiding some records. Compare the response with the group contents and check whether the expected entries were in the original data. A name change doesn’t necessarily mean the server settings changed; an unchanged name doesn’t prove the address, port or authentication details are still the same. Compare fields, not just how the list looks.

Manually added servers and subscription-managed servers work differently. Changes to a subscription entry may be overwritten at the next update. If you need to test a parameter temporarily, save the original value and note why you changed it. Don’t build a long-term workflow around reapplying edits after every update. If the remote service keeps returning incorrect parameters, ask the original provider to check them. Temporary edits in the client can help confirm a cause, but they can’t fix the subscription source itself.

If you’re unsure how to import a subscription, return to the Getting Started Guide to check how to add an existing subscription. For questions about accounts and purchases, see the FAQ. Identify which stage failed before changing settings; you’re more likely to get a useful result than by replacing the URL, rules and server all at once.

05 / PERFORMANCE BASELINE

Slow speeds, loading stalls and network switching

Break speed issues down by symptom

“Slow” might mean a long wait before a page first opens, a low sustained download rate, video playback that keeps buffering or a long delay reconnecting after a network switch. These can involve DNS, connection setup, sustained throughput or session recovery. One latency number can’t explain them all. Note when the slowdown occurs, then choose the relevant test. Watch the time before a request starts separately from the speed after data begins transferring; otherwise, a DNS delay can look like a bandwidth problem.

For a useful comparison, keep the device location, destination, network and test time as consistent as possible. First stop the connection and check the underlying network, then test with the same existing server. Next, compare with another server you already have access to, changing only that one variable. Don’t change networks and protocols at the same time, or you won’t know what affected the result. Use a test that resembles the actual issue; a single short request working doesn’t rule out problems with long connections or larger transfers.

Evaluate latency, packet loss and throughput separately

A fast connection setup means only that the round trip and handshake for that particular test went smoothly. It doesn’t guarantee sustained throughput. Remote server load, network congestion, destination limits and Wi-Fi interference can all affect transfer speeds. If waiting times vary significantly across tests, check whether the device is moving, the signal is changing or it’s switching access points. If you’re far from the router, wireless retransmissions may be worth checking before changing client rules.

If one destination is slow while others work over the same route, check its route, cached content and service status. Some pages display the main content first, then wait for resources from additional domains. If a secondary request uses the wrong policy or matches REJECT, the page may appear to be loading indefinitely. Check which domain was last waiting or failed in the request log rather than assuming the whole connection is slow. After adjusting the relevant rule, test the same page again.

Different requests in a Config may use different policies, so apps on the same device won’t necessarily behave alike. Briefly compare Proxy and Config to check for differences in rule routing, then restore the mode you need. If Proxy works better, find the specific matching rule instead of treating Proxy mode as the right answer for every situation. If both modes are slow, return to the server and network comparison rather than continuing to add rules.

Adjust MTU and long connections only when the evidence points there

Check MTU and path-related issues when small requests work but larger transfers stall, or when a specific protocol repeatedly pauses on a particular network. MTU affects the maximum packet size; a higher value isn’t always faster, and a lower value isn’t always more stable. Start with the value in your existing configuration or the app’s default behavior. If testing, change just one value at a time and record the results. Suitable values depend on the protocol and network, so don’t apply one fixed value to every entry.

When switching from Wi-Fi to cellular, the old connection may stop working and need a new session. If existing pages stall but new requests work, refresh the connection in the affected app first. If all new requests fail too, reconnect Shadowrocket. On Demand may affect when automatic recovery starts; first check that a manual connection works, then review the automatic connection conditions. Record which network you’re switching from and to instead of rapidly toggling back and forth.

During testing, reduce other heavy transfers, system backups and app updates to make results easier to compare. Also check Low Data Mode, the target app’s data settings and the device temperature, as each can affect app behavior. If the device is noticeably warm, let it return to normal operating temperature before testing sustained transfers. Don’t run more diagnostics or automatic tests to observe speed: the extra activity can affect network use and battery drain, making the original issue harder to isolate.

If the slowdown mainly affects the first visit to a new domain, see the DNS section. If it comes with frequent reconnects, return to the server timeout section. If the issue persists on one existing endpoint across repeated tests under the same conditions, share the time, destination type and reproduction steps with the original service provider after removing sensitive details. Don’t keep making random client setting changes.

06 / NAME RESOLUTION

DNS resolution failures and domain access issues

Resolution, connection and encryption checks are different steps

Accessing a domain usually involves resolving its address, establishing a connection and completing the higher-level protocol exchange. A page can fail at any of these stages; DNS is only one possibility. Start the checks in this section if your records show a resolution timeout, no available address or an unexpected resolution result. Replacing a webpage’s domain with its IP address isn’t a reliable general test: HTTPS also depends on certificate names and servers may choose content by domain. The resulting error may have nothing to do with the original issue.

First determine the scope: all new domains, one domain or only requests in Config mode. A previously visited destination may be cached, so reopening it shortly afterward doesn’t prove that resolution is consistently working. When testing the same domain repeatedly, remember that apps and the system may each keep their own cache. Rebuilding a session doesn’t necessarily clear caches at every level. Check the actual request log as well; don’t judge based only on how quickly a page refreshes.

Check whether the resolver is reachable over the current route

Review the DNS settings in the active Config and confirm which configuration they came from. Server entries in a subscription and DNS settings in a Config aren’t necessarily updated together; updating the subscription doesn’t guarantee that DNS settings have changed. If you use a custom resolver, make sure it’s reachable over the current network and policy. Encrypted DNS may also depend on first resolving the resolver’s own domain, TLS validation and request routing. A complete-looking address doesn’t guarantee it will work.

If disabling custom DNS fixes the issue, the problem may involve the custom resolution path, but that doesn’t prove the resolver service itself is at fault. Check whether the resolver is reachable on other networks, whether requests are routed incorrectly and whether the DNS settings work with the rest of the active configuration. Restore settings you’ve already verified, then reintroduce custom settings one at a time. Don’t add several addresses from unknown sources at once; it becomes difficult to tell which one was used when the failure occurred.

Understand the difference between domain and address rules

Domain rules and address rules rely on different information. Address-rule behavior may also depend on whether resolution is triggered and on related options. Check the domain and address used by the actual request and the rule it matched; don’t assume every request follows the same matching process. If a domain resolves to several addresses and some routes are unreachable, access may work intermittently. Compare resolution results with connection failures rather than keeping only one successful test.

IPv4 and IPv6 may have different reachability. A network advertising IPv6 support doesn’t guarantee that the current server, destination or every link along the route can handle the connection successfully. If the issue seems related to the address family, hold other conditions constant and compare resolution results with actual connection behavior. Don’t permanently disable an address family without evidence. If a change fixes the issue, record which route it fixed and whether it affects other access that already worked.

Local network names and routing boundaries

Names for devices on a home or work network may rely on local resolution or discovery. If you send all DNS requests to a remote resolver, it usually can’t resolve names that exist only on the local network. If public webpages work but local devices don’t, check local network permission, the local route and how the relevant domains are handled instead of cycling through more external resolvers. Separately verify that the local name resolves and that access to the device’s address is allowed.

After making a change, test the domain that failed, a newly established connection and the target app. Restore any temporary diagnostic settings. If the issue is fixed only in the browser, check whether other apps still have an old session or use their own resolution behavior. DNS changes aren’t a universal fix for connection errors. Once resolution succeeds, check the port, TLS and policy instead of repeatedly clearing caches.

07 / ENERGY AND LIFECYCLE

Battery drain, heat and repeated reconnects

Compare under similar conditions first

Assess unusual battery drain in the context of actual use. Sustained transfers, weak cellular signal, frequent network switching, video playback and a constantly lit screen can all increase energy use. The system’s battery screen reports activity over a specific period; a high percentage for one app doesn’t prove that it alone caused the extra drain. Compare similar durations, networks and activities before deciding whether a change in Shadowrocket’s connection or configuration is involved.

Note which settings changed before the issue began, such as adding an On Demand condition, enabling more detailed diagnostics, switching to another existing server or importing a new Config. Revert one change at a time and allow enough time to observe the effect. A few minutes of idle time don’t predict battery use for an entire day. Don’t compare heavy use while charging with light use while unplugged. Results from very different conditions are hard to interpret.

Check for reconnect loops and repeated failed requests

Repeatedly establishing and dropping a connection creates extra network activity. First check whether the VPN session is stable and whether the issue happens after locking the screen, leaving Wi-Fi or entering a low-signal area. If incorrect server settings cause continuous failures, fix the connection instead of just reducing diagnostic detail. An app that keeps retrying failed requests can also increase activity, so identify which app is making the requests and why they’re failing.

On Demand triggers connections; it’s separate from how rules handle requests after the connection is established. If its conditions don’t match your actual usage, it may create sessions when they aren’t needed or repeatedly reconnect after network changes. Turn it off first and check that a manual connection stays stable, then restore conditions one at a time. Test each added condition through normal screen-lock and network-switching scenarios. Don’t restore every condition at once and then guess which one changed the behavior.

Run diagnostics only while troubleshooting

Detailed logs, frequent Connectivity Test runs and continuous request monitoring are useful for short investigations, but don’t keep actively testing just in case something goes wrong. Once you have a record that reproduces the issue, return to the diagnostic level you need for everyday use. Logs may contain destination domains, addresses and usage times; keep and share them only as needed. After disabling extra diagnostics, repeat the same test to confirm the improvement wasn’t simply caused by stopping heavy usage at the same time.

If your configuration contains frequent automated tasks or processes that depend on external resources, check whether they’re repeatedly failing and whether they’re needed. Make a copy of the configuration, then temporarily disable only the added components while keeping the core connection and rules. Don’t clear the entire configuration and conclude that a rule caused the drain just because usage dropped; both traffic routing and usage may have changed. Narrow the cause to one component and confirm that the same issue returns when you re-enable it.

Distinguish an idle connection from active transfers

A persistent VPN indicator doesn’t mean the device is constantly working at the same intensity. An idle connection uses energy differently from heavy data processing, and background app sync can keep a device active even when it appears idle. If the device continues heating up while locked, first check system battery and network activity, then stop nonessential background tasks one at a time. Don’t keep waking the screen or refreshing test pages to observe what happens; those actions prevent the device from reaching its usual idle state.

The combination of protocol, network and server route can affect energy use, but protocol names alone don’t determine the outcome. Comparisons are useful only when the service endpoint and other settings are as similar as possible. Different endpoints you already have may also vary in remote location, load and transport settings. Prioritize confirmed reconnects, failed requests and weak signal before fine-tuning other settings. Until you’ve found the cause, don’t disable all background connections, which may affect normal notifications or syncing.

A useful battery report includes the observation period, screen use, network type, charging status, On Demand state and whether the connection reconnected. If the issue began after an update or device migration, keep these conditions in your notes and continue to the next section. System energy reports have limits; a single battery screenshot can’t replace a repeatable comparison or establish a guaranteed level of battery use.

08 / RECOVERY AND IPAD

Issues after an update and iPad-specific checks

Keep your configuration after an update, then rebuild the session

If an issue appears after a system or app update, first record the conditions when you noticed it. Don’t assume the update changed every setting. The remote service, current network or subscription contents may also have changed around the same time. End the old session, reopen the app and connect again. If the problem persists, check the selected server, Global Routing and active Config. Keeping a copy of the configuration that worked before the update can help reveal changes in selection or content.

A recovery sequence could be: confirm the underlying network works, check the current selection, temporarily turn off On Demand, reconnect manually, then follow the relevant troubleshooting section. Restarting the device may clear a temporary state, but it doesn’t replace checking the settings. If the issue returns soon after a restart, note what happened just before it failed, such as locking the screen, switching networks or updating the subscription. How long recovery lasts and what triggers the next failure help narrow things down more than simply saying “restarting didn’t work.”

Get app updates and redownload the app through the App Store. System requirements are as listed on the App Store page. For purchases and restoring the app, see how to restore a purchased app. Before reinstalling, make sure your local servers, Config files and required records are backed up, and that you can still retrieve your existing service details. An app purchase record isn’t a backup of local settings, and restoring a purchased app doesn’t guarantee that custom settings will be restored.

On iPad, check the selection and network permissions first

On iPad, even if you use the same existing subscription, confirm the selected server and Config on that device. Don’t assume two devices are in the same state just because Shadowrocket works on iPhone. The larger screen may show a list and details at the same time; viewing an entry’s details doesn’t necessarily select it for the active connection. Return to Home, check the actual selection and establish a new session. Follow what the current interface shows rather than guessing from a list position or the last entry you viewed.

Check whether the iPad is using Wi-Fi or cellular; different devices may be on different network routes. On cellular-capable models, check whether system settings allow the app to use cellular data. If only access to local network devices fails, check local network permission and the relevant rules. To compare iPhone and iPad, connect both to the same network and use the same configuration and destination. Otherwise, device and network differences are mixed together, so the results can’t isolate an app issue.

Screen lock, multitasking and configuration migration

In multitasking or Split View, whether an app remains in the foreground is separate from whether the system VPN session is still running. Check system status and the results of a new request rather than relying on whether a window refreshes. If issues appear after locking the screen, test the old connection in the app and a newly initiated request separately. If only the old connection fails, refresh the target app. If all requests fail, rebuild the VPN session. This helps distinguish an app session issue from a broader device connection failure.

When migrating settings, handle server details, Config files and system VPN authorization separately. For the first two, check what was imported and which items are selected. The new device will generally need VPN authorization again. Store configurations containing authentication details somewhere secure that you control; don’t share them publicly as ordinary examples. After migration, verify one existing server first, then check rules and automatic connections, and finally restore other custom settings. This makes it easier to identify the cause than importing everything at once.

Prepare a troubleshooting report others can follow

If the same configuration works on one device but not another, compare system permissions, network, time, app settings and actual request records one at a time. Don’t copy all system network settings or remove managed configurations unrelated to the issue. For getting Shadowrocket and opening it for the first time on iPad, see the iPad guide. For restoring the app after switching devices, see how to restore an app on a new device.

Finally, write down the shortest repeatable sequence: which network, which mode, what action, what error, which comparisons worked and the one setting changed most recently. Include only the time and redacted error category, not your full history. If the same symptom returns after recovery, repeat the checks in the order you’ve already verified. If the symptom changes, establish a new baseline in the relevant section; a fix that worked once may not apply permanently.