ShadowrocketTroubleshooting Guide

Connection switch won’t stay on: VPN configuration permissions

If the switch turns off immediately after you turn it on, first check whether the system allows Shadowrocket to create a VPN configuration. Don’t start by changing your subscription. An unreachable server usually affects requests after a connection is established; if system permission has not been granted, even correct server settings won’t enable normal traffic routing. Turn off the connection, make sure the device can browse ordinary websites, then try again. Note whether the system shows a permission, authentication, or management restriction prompt, and record its full text.

First-time authorization and recovering from a declined prompt

The first time you connect on iPhone or iPad, the system may ask to add a VPN configuration. Confirm that the prompt appeared after opening Shadowrocket, then allow the configuration and complete any device authentication required by the system. Allowing it only authorizes creation of the network extension configuration; it doesn’t confirm that the subscription is valid or the server is online. If you previously tapped Don’t Allow, try connecting again from the app. If the prompt no longer appears, check the VPN section in system settings for the corresponding configuration.

System settings menus can change between versions. Use Settings search to find VPN. Check the configuration name and associated app so you don’t mistake an unrelated configuration for Shadowrocket. If the relevant entry is damaged or duplicated, save your in-app configuration and disconnect first. Then remove only the invalid entry you can confirm belongs to Shadowrocket, and return to the app to authorize it again. Don’t remove configurations installed by a school, employer, or device management; these may be controlled by management policies, so confirm your device permissions first.

Switch turns off, automatic reconnection, and configuration conflicts

If authorization is complete but the switch still turns off immediately, check whether another VPN connection is taking over the network, including network-filtering tools that use a VPN interface. Temporarily stop other connections and test again; don’t change DNS and rules at the same time. If the switch turns itself back on after you turn it off, check On Demand and the corresponding system-level on-demand settings first. A connection trigger may be overlapping with manual control; the switch changing state alone doesn’t prove the app has crashed.

Managed devices may restrict adding VPN configurations or changing network extensions. Reinstalling repeatedly won’t remove those policies and could erase your existing configuration. Check whether the system shows a management profile, then ask your device administrator about the restriction. On a personal device, save your configuration and restart once to clear a network extension that may not have been released properly. After restarting, test a minimal configuration with one existing server. Once the switch stays on, restore On Demand and other automation settings.

Tell permission issues apart from an app crash

An app moving to the background doesn’t mean the connection has stopped; check the system VPN status and make an actual request. If opening a particular configuration causes the app to exit, save a copy of that configuration and check recently added rules, external resources, and unusually long configuration content. Don’t keep importing the same file and creating more copies. Retest with a configuration that worked before: if the old one works and the new one doesn’t, investigate the differences rather than starting with account or subscription expiration checks.

If macOS, Windows, or Android blocks the app on first launch, follow the installation approval instructions on the download page before continuing with connection troubleshooting. On Mac, check Privacy & Security for “Open Anyway.” On Windows, verify the package source and then select More info in SmartScreen. On Android, allow the app you’re using to install the package to install unknown apps. Launch problems during installation and internet problems after connecting are different issues; record and troubleshoot them separately rather than treating installation approval as a network fix.

Connected but no internet? Start by checking the routing mode

A VPN status of Connected only means the network extension is active; it doesn’t prove that every request reaches its destination. If no websites load, turn off Shadowrocket and try a site that normally works directly on the same network. If it still fails, check Wi-Fi, cellular data, network authentication, or system time first. If it works with Shadowrocket off, compare the selected server, Global Routing mode, and DNS. Use the same destination for each test so changes on the website itself don’t affect the results.

Compare the three modes

In Global Routing, Config routes traffic according to the selected configuration. Proxy sends applicable requests through the proxy route, while Direct provides a direct-connection comparison. You can switch modes temporarily for troubleshooting, but note the original mode and selected configuration first. If Proxy works but Config fails, check rule matches, policy targets, and configuration resources. If Proxy fails but Direct works, check the server or proxy route. If both fail, revisit the basic network, DNS, and destination service.

These results are clues, not definitive proof. Some destinations may not be reachable over your current direct route, so a Direct failure may not be a useful comparison. An app may also reuse an existing connection, causing requests immediately after a mode change to keep using the old route. After switching modes, close the destination app’s existing page and make a new request; if needed, disconnect and reconnect Shadowrocket. Don’t draw conclusions from refreshing a page that has been open for a long time, and don’t treat the VPN icon as proof that browsing works.

Check rule order and the final policy

In Config, check the file that’s actually selected, not just the name of a recently imported file in the list. Rules are generally evaluated in order, so a broad rule near the top may match before a more specific one. FINAL determines where requests that didn’t match earlier rules go. The example below illustrates syntax; it is not a complete replacement for your configuration. The example domain is for demonstration only. Before making changes, confirm what PROXY and DIRECT mean in your configuration.

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

If only one website fails, look for DOMAIN, DOMAIN-SUFFIX, or REJECT rules that apply to it, and check which rule the request actually matched. A site may use several domains for login, images, and API requests; the homepage loading doesn’t mean every dependency is using the right policy. Trace the failing request’s domain instead of deleting the entire rules file. If the matched policy refers to a missing policy name or unavailable server, fix that reference and test again.

Change the configuration only when you have evidence

Keep a copy of the original configuration, then create a test copy with only the necessary rules and compare them using the same existing server. If the test copy works, the cause is more likely to be complex rules, resource references, or additional settings. If both fail, check the server and DNS again. Don’t replace the configuration, subscription, and system network settings all at once; even if that fixes the problem, you won’t know why. For guidance on when to use each mode, see the three Global Routing modes.

After fixing the issue, switch back to your usual Config and retest the page that failed, a regular direct-access page, and an app you use often. A successful temporary Proxy test doesn’t mean routing rules are fixed. Record the specific rule, policy, or DNS setting you changed, then remove any temporary test entries. Keep these minimal reproduction steps so you can compare them directly if the same symptoms return.

Server timeouts and protocol parameter mismatches

Break a server timeout into four stages: address resolution, port connection, protocol handshake, and destination request. No result from Connectivity Test doesn’t necessarily mean the server is completely offline. The test destination may be unreachable, the test method may not fit the server, or the protocol handshake may have failed; all can look similar. First note whether one server or an entire group is affected, and whether it happens only on a particular network. Use the current details from your service provider; don’t infer the protocol from a server name.

First check whether the address and port are reachable

In the server details, check that the address contains no spaces, line breaks, or protocol prefix, and that the port matches the server settings. The address field generally expects a hostname or IP, not a complete web URL. For a domain, first check that it resolves. For an IP address, you may still need to enter a separate server name for TLS. If a server fails only on one Wi-Fi network but works on cellular, check network sign-in requirements, UDP support, or outbound restrictions before resetting all your servers.

If an entire server group times out, check whether its entries share a domain, subscription, or network egress. Different-looking names may use the same underlying address. Compare with an entry that you know worked before, then check whether the server is under maintenance and whether your authorization is still valid. Don’t run endless tests: repeated concurrent probes add network load and may trigger server-side limits. Wait for one test to finish and keep a few representative results; patterns are usually easier to spot that way.

Check handshake settings field by field

If the port is reachable but requests still fail, check authentication, encryption, and transport settings. Shadowsocks encryption method and password must match. For VMess and VLESS, the user ID and transport settings must match the server. For Trojan, check the password and TLS settings. Don’t reuse old fields just because the server address is the same. A subscription update may change the transport, while manually created entries won’t update automatically; compare each field with the current details.

If you see a certificate error, first check the device date, time, and time zone, then confirm the server name matches the certificate. Don’t routinely bypass certificate verification; that weakens server identity checks and won’t fix a wrong address or an expired server certificate. For WebSocket connections, distinguish the connection address, Host, and path; don’t remove a field just because it looks redundant. The exact error message about a handshake, authentication, or certificate is more useful for diagnosis than a generic timeout.

Cross-check test results against actual access

A latency test measures the response under a specific test method; it doesn’t guarantee that pages, large downloads, or video playback will work well. If the test fails but browsing works, check the test target and method first. If the test succeeds but a website fails, check DNS, rules, and the destination service. Compare multiple existing servers on the same network, with the same target and configuration, to narrow down variables. For guidance on choosing a server, see latency tests, regions, and protocol types.

When contacting your service provider, include the protocol type, network where the failure occurred, approximate time, whether all servers are affected, and a redacted error message. Don’t send your full subscription link, user ID, password, or private key. The client can help verify field consistency and identify the scope of a problem, but it can’t replace server logs. If the same handshake stage fails on multiple networks, ask the server operator to check authentication, listening ports, and certificates instead of repeatedly changing unrelated settings locally.

Subscribe update failures, empty lists, and duplicate entries

A failed Subscribe update and an unavailable server in a subscription are different issues. The first occurs while downloading, authorizing, or parsing subscription content; the second occurs when connecting to an imported entry. Keep the old list and record the exact update error, then determine whether the subscription address is unreachable, the response status is unexpected, or the content can’t be parsed. Don’t delete entries that still work because one update failed; removing and re-adding them can erase useful configuration differences.

Check the link and access route

Get the subscription link from your service provider and copy it with all query parameters intact. Automatic line breaks in chat apps, trailing punctuation, extra spaces, or pasting a character entity instead of the original symbol can change the link. The token in an example only illustrates the format and won’t work for an actual update. Don’t show your real link in public screenshots, issue titles, or browser sharing history; it often contains credentials that grant access to your personal server list.

https://example.com/sub?token=xxxx

If the error mentions hostname resolution, TLS, or a timeout, disconnect first, confirm that the basic network works, and check the device time. Then check whether the update request depends on a proxy route that’s no longer working. If updates fail only while the proxy is on, note the original settings and temporarily retry over a working network route. Don’t assume subscription updates always follow a particular Global Routing mode; check the current settings, request logs, and test results.

Tell authorization failures apart from invalid content

If the response says unauthorized, forbidden, or address not found, use the information from your service provider to check whether the link was revoked, reset, or expired. Refreshing repeatedly won’t restore expired authorization. If the response is a login page, network sign-in page, or error text, the request may have succeeded but the content still isn’t server data the app can import. This is common on public Wi-Fi before sign-in; disconnect, complete network authentication, then try again.

If the request completes but nothing is imported, check whether the format supplied is supported by the import method you used. Subscribe, an individual server link, a QR code, and a Config file serve different purposes and aren’t interchangeable. Don’t judge content by its file extension alone, and don’t use a webpage’s instructions URL as a subscription link. If your provider offers multiple formats, choose the one marked for Shadowrocket. If the format isn’t specified, ask before trying the same address through every import option.

Resolve missing entries, duplicates, and manual edits after an update

A change in the number of servers after an update may reflect changes to the remote list, filtering settings, or replaced entries; it doesn’t automatically mean the app deleted them incorrectly. Check the group associated with Subscribe, then see whether manually added entries are mixed into the same view. Subscription-managed fields may be overwritten by the next update. Before keeping individual edits, check how the entry is managed. If needed, create a clearly named manual copy and note that it won’t follow subscription updates automatically.

Duplicate entries usually come from adding the same link more than once, overlapping servers in different subscriptions, or having both a manual copy and an automatically updated entry. Before cleaning up, check each group’s source and update history; don’t delete entries based only on their display names. Keep one confirmed working Subscribe entry, then remove duplicate sources gradually. If a new list replaced old parameters and connections started failing, compare the address, port, TLS, and transport fields with a copy you haven’t deleted, then ask your service provider to confirm any differences.

After recovery, avoid unnecessary repeated manual refreshes. Update as needed and keep a copy of the most recent working configuration. Before importing again, follow the Subscribe import steps and use the right import method and content type. For QR codes, see how to use Scan QR Code. If you suspect an authorization link has been exposed, ask your service provider to reset it, then update the client record rather than merely changing its display name.

Slow speeds, lagging pages, and dropped connections

First clarify what “slow” means: a long wait before a page opens, images loading slowly, low download speeds, or a connection that drops after a while. These may point to DNS, handshakes, sustained bandwidth, packet loss, or network changes, respectively. Note the network, destination, selected server, and any other downloads in progress, then compare the same activity with Shadowrocket off. A single latency reading doesn’t measure throughput across the whole route, and a destination’s own speed limit isn’t a client performance issue.

Make test conditions repeatable

Choose a destination you use regularly and test it repeatedly in the same place and on the same network. Pause system updates, cloud sync, and other high-bandwidth tasks so that competing traffic doesn’t look like proxy slowdown. Wi-Fi signal bars don’t fully reflect connection quality; wireless congestion, router load, and saturated upload bandwidth can all cause delays. First compare performance near the router with your usual location, then compare Wi-Fi with cellular to separate local network issues from remote route issues.

When comparing multiple existing servers, keep the target, protocol use, and test time as consistent as possible. A server’s geographic label doesn’t tell you how long the route is, and low latency doesn’t guarantee enough bandwidth during peak hours. Check both the initial response and sustained transfer: a slow start followed by steady transfer points to DNS or handshake delays; a fast start followed by repeated pauses points more toward packet loss, server load, or destination limits. Results apply only to the conditions at the time and shouldn’t be used to create a permanent ranking.

Check for misleading results from routing and connection reuse

Different page resources may match different rules, and a failing group of requests can hold up the entire page. Check the stalled domain rather than testing only the homepage domain. If Config fails but temporary Proxy works, investigate rules and policies. If both are slow, compare servers and the basic network. After switching servers, existing long-lived connections may continue using the old route. Close the relevant sessions and start new requests; only new connections can show whether the switch took effect.

If calls, games, or other real-time apps disconnect, check separately whether they need UDP and whether the current protocol and network allow that traffic. A website loading doesn’t prove UDP works; protocols that use UDP may also fail to connect on some Wi-Fi networks. Don’t change MTU or transport settings at random. First confirm that the issue occurs only with a particular packet type or network. If an adjustment is necessary, follow server-side recommendations, save the original value, and retest one setting at a time.

Narrow down the issue with Data and request logs

When checking Data, first confirm the statistics scope, time period, and current connection status. Traffic increasing for a server means that data passed through that entry; it doesn’t prove the destination finished loading. App-level statistics may also include system services, background refresh, and cached content. A page loaded from cache can’t test actual speed. Note a baseline, make one deliberate request, then check whether the traffic increase matches the request logs. For details, see how to read traffic statistics on the Data page.

If the connection drops only when the screen turns off, you leave Wi-Fi, or the device switches to cellular, treat it as a network transition issue first. If reconnecting restores service immediately, check On Demand conditions and whether the old session has expired rather than changing every server. Network addresses often change on the move, and some long-lived connections need to be re-established. Whether new requests work is a better measure of the current configuration than whether an old session stayed open. Retest while stationary to rule out movement-related changes.

After identifying the cause, remove temporary rules and special parameters added for testing, restore your everyday configuration, and retest browsing, sustained transfers, and network switching. Don’t keep multiple overlapping “optimizations” enabled; each extra setting makes diagnosis harder. A fix is reusable only when you can explain which change resolved which symptom, rather than relying on a one-off speed improvement.

DNS resolution failures and unexpected rule matches

DNS issues often show up as domains that won’t load, long waits on first access, failed resources, or different results across networks. Check whether resolution completes, whether the returned address is reachable, and which route the DNS request uses. Don’t treat “the domain fails but its IP works” as definitive proof: HTTPS certificates, virtual hosting, and website routing often depend on the domain. Accessing an IP directly may reach a completely different service, so it isn’t a reliable comparison.

Distinguish DNS timeouts from connection failures after resolution

First check the failed stage in request logs. If no address is returned before the request times out, check DNS server reachability and the route used to reach it. If an address was returned but the connection fails, check the destination connection, rules, or IPv6 route. If several unrelated domains fail at once, investigate DNS first. If only one domain fails, also consider its DNS records, certificate, or service status. Record the full failing hostname so you don’t confuse an API subdomain with the homepage domain.

The device may be affected by system DNS, manually configured Wi-Fi DNS, in-app settings, and other network filters at the same time. Record the original value at each layer, then identify which one is currently active. Don’t change several addresses in both the system and app at once; you won’t be able to interpret the results. With encrypted DNS, also confirm that its hostname resolves and TLS connects. Switching to a different DNS protocol won’t automatically fix network problems between the device and the resolver.

Check whether DNS and routing depend on each other

Some configurations need to resolve the server’s hostname before the proxy can connect, but may route that DNS request through a proxy that isn’t established yet, creating a dependency loop. If resolution fails during startup, check how the server address is resolved, not just how website domains are. Compare with a configuration that worked before and identify which requests use system DNS and which use in-configuration DNS. Restore a minimal route that can start the connection first, then gradually re-enable other DNS settings.

Domain-based rules and address-based rules match different things. DOMAIN-SUFFIX can match a specified domain and its subdomains; IP-CIDR, IP-CIDR6, and GEOIP apply to addresses. Adding an address rule with no-resolve generally means not to trigger a domain lookup specifically for that rule; it doesn’t disable DNS for the entire client. The example below shows rule structure only. Documentation-only IP addresses and example.com are instructional material, not a definition of your local network or actual requirements.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

IPv6, cache, and local network boundaries

When a domain returns both IPv4 and IPv6 addresses, the two routes may have different levels of reachability. If a long delay occurs only on one network, check whether it tries an unavailable address route first. After saving the original settings, you can temporarily adjust the relevant IPv6 option for comparison, but don’t treat permanently disabling IPv6 as a universal fix. Check whether new requests work and retest on other networks; otherwise, a temporary workaround on one network may hide a mismatch between the configuration and the network’s actual capabilities.

After changing DNS, cached results and existing connections may remain in use. Disconnect and reconnect, then make a new request; restart the destination app if needed. Reinstalling Shadowrocket repeatedly isn’t a way to clear the cache. Local device names, printers, and workplace domains may depend on local DNS and can stop working if all requests are sent to a remote resolver. Keep local names on the right route when needed, and test internal addresses only on networks you trust. Don’t include sensitive hostnames in public reports.

Final verification should cover an ordinary domain, the domain that originally failed, and any necessary local services. Once rule matches and DNS results look right, remove temporary comparison settings. If you can reliably reproduce “DNS times out on one network but works on another,” share those results with the relevant network or server operator. A screenshot of one webpage error usually doesn’t show whether the failure occurred during DNS resolution, the handshake, or the destination response.

Excessive battery drain, heat, and repeated background connections

To assess battery drain, consider the usage scenario and observation period, not just the percentage in the system battery list. VPN-related activity may include work from other apps using the network extension. A higher share for one item may also reflect lower battery use by other apps during the same period. Note whether data is being transferred continuously, the signal is weak, the device is charging, and which configuration change preceded the issue. Avoid attributing brief heat to the proxy immediately after a system update, restore, or cloud sync.

Tell normal background activity apart from repeated retries

With a stable network and normal device temperature, compare similar periods with the connection on and little activity, during a sustained download, and with the connection off. Keep screen brightness, foreground apps, and network conditions as consistent as possible. If battery use increases only during heavy transfers, wireless activity and encryption may account for most of it. If the device stays warm with almost no active use, check background apps, connection retries, log writing, and automatic updates before changing protocol settings.

Look in request logs for repeated failures close together. Repeated timeouts to the same host, constant subscription refreshes, or ongoing server authentication failures can make the device reconnect over and over. Fix the earliest error first; later retries often stop as a result. Don’t shorten all timeouts to save battery; shorter waits can cause more reconnects. Avoid repeatedly running Connectivity Test for every server, too. Broad probing creates extra network activity and can skew battery observations.

Check On Demand and network changes

Set On Demand conditions to match your actual usage. A weak Wi-Fi signal, a switch to cellular, or an incorrectly configured network-name condition may trigger repeated connection starts and stops. Note the trigger conditions, then temporarily disable automatic connection and use manual control as a comparison. If battery drain and frequent reconnects both decrease, restore the conditions one at a time to identify the trigger. Closing the app interface doesn’t necessarily stop a background connection; check the system VPN status.

If the device moves between two Wi-Fi networks often or reconnects after sleep, existing sessions may expire and restart. First check whether the connection settles quickly instead of treating every restart as an error. Look for repeated failures, rapid switching, or prolonged activity when there’s no network traffic. Retest in one fixed location on a single network. If it works in a stable setting but not while moving, check Wi-Fi coverage, network switching, and on-demand conditions first.

Reduce extra activity while troubleshooting

Turn off detailed logging, extended traffic monitoring, and extensive tests once you’ve collected the information you need. Keep a few records that reproduce the issue instead of logging every request indefinitely. If the configuration includes scheduled updates or other recurring tasks, check their frequency and retry behavior. Disable nonessential tasks temporarily for comparison, changing one at a time and observing temperature and battery use in similar conditions. If you stop everything at once, it will be hard to identify the cause.

Different protocols, transport methods, and network conditions can affect processing overhead, but you shouldn’t switch settings without considering the server. First confirm that the parameters are valid and the connection is stable, then compare the performance of existing working servers. With a weak signal, repeated transmissions, packet-loss retries, and many small requests may matter more than the protocol name. Don’t look for a fixed battery-use figure without context: battery health, screen time, and ambient temperature all affect the result. Compare the same device before and after a change.

If the same issue continues after you turn off Shadowrocket, check system battery reports, background sync, and network signal instead of repeatedly importing the subscription. If it happens only with one configuration, keep the original file and reproduce the issue with a minimal test configuration, focusing on scheduled tasks, connection triggers, and retries. After making a fix, test both an idle period and normal use to confirm that connections aren’t restarting continuously. System battery reports cover a time window, so they won’t reflect a change immediately.

When reporting battery issues, include the device type, system version, network, connection duration, and main activity, along with redacted failure logs. A battery percentage screenshot alone lacks usage volume and observation period. You can also note the change in Data traffic to help distinguish heavy data transfer from repeated retries with little traffic, since each calls for a different investigation.

Issues after an update and iPad-specific checks

If a problem appears after an update, first identify whether the change was to the client, system, configuration, or subscription; timing alone doesn’t prove cause and effect. Note the network and configuration used the last time everything worked, then reproduce the issue in the current environment. A client update won’t normally restore server authorization that has expired. Likewise, changed parameters in a subscription updated around the same time may be mistaken for a client update issue. Keep existing files, groups, and useful screenshots before restoring or reinstalling so you don’t lose evidence of what changed.

Restore based on what changed; don’t reset everything first

Get and update Shadowrocket for iPhone and iPad through the App Store; check the App Store listing for system requirements. The iPhone and iPad app costs $2.99 as a one-time purchase. Mac (Apple silicon and Intel), Windows, Android, and Linux versions are free; packages for other platforms are available from this site’s download page under /dl/. A one-time client purchase is not a server plan, and reinstalling the client won’t restore subscription authorization revoked by your service provider.

When verifying the iPhone or iPad app, check for developer Shadow Launch Technology Limited, the official icon, and app ID 932747118. After changing devices or reinstalling, use the original purchase account to find your purchased apps. See how to restore a previous purchase for details. After restoring the app, check that your subscription, servers, and Config are intact. Don’t treat a system backup as proof that every current setting has been restored, and don’t rely on a single device to store passwords, private keys, or authorization details.

After an update, start with three basic checks: does the system network work, is the VPN configuration still authorized, and does one existing server work with a simplified configuration? If the old configuration fails but the simplified one works, restore rules and external resources one at a time. If every configuration fails, revisit permissions, DNS, and server settings. Don’t save every setting again right away; indiscriminate changes can overwrite useful clues. If the app exits, record what action triggered it instead of reporting only that it stopped working after an update.

iPad Wi-Fi, hotspots, and multitasking

For a Wi-Fi-only iPad, first distinguish a router issue from a proxy issue by testing another network you can use or a personal hotspot. On an iPad with cellular, test Wi-Fi and cellular separately. School, workplace, and public Wi-Fi may require a sign-in page; disconnect Shadowrocket, complete the sign-in, then reconnect. If iPhone works but iPad doesn’t, don’t assume the subscription is at fault: the devices may use different DNS, Config files, or system VPN configurations.

Split View and other multitasking setups can make it easy to confuse the configuration you’re viewing with the one that’s active. Return to Shadowrocket to confirm the selected server, Global Routing mode, and Config, then make a new request in the destination app. Don’t compare devices solely by display name; entries with the same name can have different ports, TLS settings, or transport fields. Checking the actual parameters one by one is easier than erasing the whole device and starting over, and it preserves working network settings for other apps.

When pasting subscription or server details with an external keyboard, check for leading or trailing spaces, smart punctuation, and line breaks. If you use a shared clipboard across devices, confirm that you copied the latest content. After importing with Scan QR Code, check the parsed entry type; a successful scan doesn’t replace checking the fields. If an iPad resumes after the screen turns off but a page still looks stale, make a new request before deciding the connection is broken. Old pages and long-lived connections don’t show the network’s current state.

Restore everyday settings and document the resolution

If you need to reinstall, first save any Config and server details that can be safely restored, and confirm you can get the subscription link again from your service provider. Exported data may contain sensitive settings; keep it in a secure location and don’t share it publicly. If a computer or Android device blocks the package after you download it again, follow the download page’s installation approval instructions. “Open Anyway” on Mac, “More info” in Windows SmartScreen, and Android install permissions only address launch approval; verify connections and rules afterward.

When troubleshooting is complete, restore your everyday Global Routing mode, On Demand settings, and required rules, and remove temporary DNS settings and test entries. Verify the operation that originally failed, an ordinary network request, and a new request after the screen turns off or the network changes. Record the scope, root cause, changes made, and test results. If the issue remains, share these reproducible details instead of only giving the device model. For any missed initial setup steps, return to the quick-start guide and check them one by one.