Shadowrocket Troubleshooting Guide
Identify the failing layer first, then change one variable at a time.
This page is a troubleshooting reference for users who already have their own subscription or server details and need to diagnose connection issues. If you have not completed the initial setup, start with the quick-start guide to establish a baseline. If you can connect but are experiencing a specific symptom, use the contents below to find the relevant section. The tutorial covers the main setup steps; this page explains failure cases, comparison methods, and recovery limits.
The app is a one-time purchase; connection service is separate. Check the app purchase, your existing connection service, and your current network independently. For legitimate access and purchase restoration, see the App Store download guide. This site does not provide, sell, or recommend servers or subscriptions.
Connection switch won’t turn on: Check VPN settings and system restrictions
A switch that immediately turns off, one that remains stuck connecting, and a missing authorization prompt are three different symptoms. If the switch turns off, first check whether the system accepted the VPN configuration. For a stalled connection, use the error log to determine whether the server connection began. If no prompt appears, authorization may already have been granted, or device-management policies may be restricting it. Note what happens after you tap the switch; avoid toggling it repeatedly, as this can make it harder to distinguish the original failure from a later reconnection attempt and does not replace checking permissions.
Distinguish first-time authorization from an existing configuration
The first time you start a connection from Home, the system may ask to add a VPN configuration. Confirm that the prompt appeared after you opened Shadowrocket, then follow the system instructions and complete any required device authentication. This permission allows the app to create a system network tunnel; it does not verify that the server details are valid or mean the app purchase includes connection service. If you canceled authorization, return to the app and try connecting again. Do not delete other network settings just to make the prompt reappear. If permissions are in order but the connection still fails, continue with the configuration and network checks later in this section.
On a device you have used before, search for VPN in Settings to see whether the corresponding configuration exists and which one is currently establishing the connection. Settings categories may move between system versions, so use search rather than relying on a fixed path. If another VPN is active, disconnect it and test Shadowrocket on its own. Do not remove configurations managed by your workplace or school without approval. Device management, content filters, and network extensions can all affect connectivity; ask the device administrator to confirm any restrictions imposed by management policies.
Rule out connection conflicts in order
Disconnect Shadowrocket, temporarily pause On Demand, and check that the system has not automatically enabled another VPN. Then leave the current settings screen, return to Home, and confirm that the selected SERVER is still the one you intended before trying to connect again. If the switch stays on but webpages fail, the issue is at the access layer; continue to the next section. If it switches off immediately, check the error details around that time. Distinguish a permission denial, a failed configuration setup, and a server handshake failure rather than relying on the switch’s color alone.
If the system VPN configuration appears to be in a bad state, first save your in-app servers and Config Files, then disconnect and disable automatic connection triggers. Remove only a VPN configuration you can confirm belongs to Shadowrocket, then return to the app to trigger system authorization again. Removing the system VPN configuration is not the same as deleting in-app configuration; the former rebuilds the system connection entry, while the latter may erase rules and settings. On a managed device, stop if you cannot remove or add a configuration and check with the administrator before trying again.
Don’t reinstall before checking the network
On Wi-Fi that requires a web sign-in, disconnect the VPN, complete the sign-in, and confirm that ordinary webpages load before trying to connect. A network showing as connected does not guarantee a working internet connection: the router may not have assigned an address, the sign-in may have expired, or the network may restrict access. Retest on another network you can use. If only the original network fails, keep your current app configuration and investigate that network. If every network fails, check system permissions, server details, and the device’s date and time.
This section is complete when the system accepts the VPN configuration, a connection attempt produces an identifiable result, and you can distinguish “tunnel not established” from “access failure after tunnel establishment.” For checks on app access, system requirements, or restoring a purchase, see how to verify the app. System requirements are as listed on the App Store page. For an overview of the sections shown on first launch, see Home and VPN authorization so you do not mistake a system authorization issue for a subscription problem.
Connected, but no internet access: Narrow it down with three routing modes
A connected status confirms only that the system tunnel is established. It does not confirm that DNS resolution, server forwarding, or the destination website is working. First disconnect and visit a site that normally works to confirm the underlying network is available. Then reconnect and visit the same address, noting the difference. If it fails while disconnected too, address the network or destination site first; do not assume the rules file explains every problem. If only one app or website fails, record its exact domain, error message, and the steps that trigger the issue. Avoid describing a localized failure as a total loss of internet access.
How to use Global Routing for diagnosis
Check Global Routing on Home. Config applies the currently active configuration to traffic; Proxy and Direct can be used for comparison. These mode names are related to the PROXY and DIRECT rule keywords, but they are not the same setting. For diagnosis, keep the network and selected server fixed, then change one mode at a time and retry the same destination. Compare the results, but do not leave a temporary test mode in place as your everyday setting. For local addresses, specialized rules, or system traffic, interpret the results alongside the actual connection records.
| Routing mode | What it tests | What the result suggests |
|---|---|---|
| Config | Current configuration and policy matching | If only this mode fails, check rules and DNS first |
| Proxy | Forwarding path through the selected server | If it fails, check the server, handshake, and destination |
| Direct | Direct-path comparison | Interpret alongside a test with the connection off |
If Proxy works but Config does not, the selected server provides a working path to that destination. Focus on whether the active configuration sends it to DIRECT, REJECT, or another policy. If Direct works but Proxy fails, check the selected server’s details, status, and exit path first. If all three modes fail, confirm the destination itself is available, then check DNS and the current network. One successful test does not prove all traffic works, and one failure does not prove a particular rule is wrong. Review connection records and repeat the test before drawing a conclusion.
Check the active configuration, not just what you edited
Open Config and confirm that the file you just checked is the one actually in use. Editing one file while another remains active is a common reason correctly written rules appear to have no effect. Keep the original file and create a separate test configuration. Start with a few rules to verify the destination, then add the original rules gradually. Rules are matched in order, and the first match takes effect; a broad rule near the top can prevent later, more specific rules from being reached. Check the match type, domain scope, policy name, and position of FINAL.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECTThe example above illustrates the structure: send the example domain and its subdomains to PROXY, use DIRECT for the specified private IP range, and let FINAL handle everything else. It is not a complete configuration for every network and does not replace DNS or other settings in an existing configuration. To test a real issue, replace the example domain with the one you need to check and confirm that your server works first. If your existing setup uses policy groups, verify their definitions before renaming anything; otherwise, a rule issue can become a policy reference issue.
Close the loop with a connection record
Reopen the destination and check the connection or diagnostic records available in the app. Find requests from the same time and verify the actual domain, matched rule, policy, and error. A page may use separate domains for sign-in, images, and APIs. If the homepage loads but sign-in fails, check the second request rather than adding only the homepage domain. After testing, restore your normal Config and disable temporary test settings. For an explanation of the modes, see Global Routing modes: Config, Proxy, and Direct. For rule scope, see rule types explained.
If the connection record shows that a request used the expected policy but the destination returned a refusal or sign-in error, check the destination account, browser session, and server exit conditions. Do not try to fix every website error by continually broadening proxy rules. Save clear evidence first, then decide whether to continue with the server timeout or DNS section.
Server timeout: Check the address, handshake, and forwarding separately
A timeout in Connectivity Test does not prove that the server is down. The test method, destination, current network, and server configuration can all affect the result. Check which test method was used, then verify actual webpage access. A reachable port does not mean protocol authentication succeeded, and a responsive test destination does not mean every website is accessible. Treat the test as a clue, not a complete diagnosis based on one number or timeout label. Keep the server, network, and test destination the same to establish a comparable baseline.
First check that the server details are complete and consistent
Open the selected SERVER entry and compare its details field by field with your own server information. The address, port, protocol type, authentication fields, and transport settings must form a matching set. When copying manually, check for leading or trailing spaces, missing characters, and line breaks; do not paste explanatory text into a field. If the server address is a domain, confirm that it resolves. If the connection still fails after entering the address, do not skip checks for the certificate and server name. A field that merely looks similar has not necessarily been verified.
| Protocol or parameter group | What to verify | Common false assumption |
|---|---|---|
| Shadowsocks | Method, password, address, port | Assuming a reachable port means authentication works |
| VMess / VLESS | Identity fields, transport type, TLS, and path | Checking only the address and overlooking transport requirements |
| Trojan | Password, TLS, server name | Using the connection address for every name field |
| Hysteria2 / WireGuard | Verify authentication and protocol-specific settings against the original information | Applying configuration settings from a different protocol |
Choose the next step based on the failure stage
If the log shows a DNS resolution failure, go to the DNS section first. If the connection is refused, the destination path is behaving differently than it would during a simple timeout; check the address, port, and whether the server is listening. If the connection is established but authentication fails, focus on the password or identity details. For TLS errors, check the device date and time, server name, and certificate status. Error wording can vary by protocol, so preserve the original message when reporting the issue rather than writing only “can’t connect.” Redact any private details it may contain.
For TLS connections, the connection address, server name, and transport-layer Host may differ. Enter them according to your existing server information; do not set them all to one value just to reduce the number of fields. With transports such as WebSocket, also verify the path, capitalization, and relevant request headers. A single character difference in the path can connect to the right host but fail to reach the intended service. Do not disable certificate verification to hide a name mismatch; that neither explains the cause nor preserves normal verification safeguards.
Use network comparisons to distinguish client issues from path issues
Keep the same server configuration and test it on two networks you can use. If it works on one but consistently times out on the other, check restrictions on the original network’s exit path, sign-in status, and support for the protocol transport. If it fails on both, compare other entries you already have in the same subscription. If only one entry fails, the issue is more likely with that server or its configuration. If every entry fails, check whether the subscription changed as a whole, authentication expired, or a shared device setting was modified.
Do not keep changing the port, protocol, and authentication fields at random. If the server details are maintained by your service provider, share the test time, network type, failure stage, and redacted configuration differences, and ask whether the requirements for that entry have changed. If you manage the server yourself, check its logs for that time to see whether the connection arrived, authentication was accepted, and subsequent requests were sent. A client that receives no response and a server that explicitly rejects authentication require different troubleshooting paths.
Save the entry after making changes, select it again, and establish a new connection so you are not judging the result of an old session. Once access is stable, restore your usual automatic triggers and rules. For protocol field definitions, see the glossary.
Subscription update failed: Distinguish a retrieval failure from an import error
When a Subscribe update fails, keep the entries that still work; do not immediately delete the entire subscription. A subscription update involves retrieving the URL, receiving a response, parsing its contents, and updating entries. A failure at any stage can make the update appear unsuccessful. First record the exact message and update time, then check whether the existing entries still connect. If an update fails but the old entries work, focus on the subscription retrieval path or content rather than changing every server parameter.
Verify the URL source and completeness
The subscription URL should come from your own service details. Preserve the full query string when copying it, and check for spaces, quotation marks, line breaks, or explanatory text. Some services provide a management page, an information page, and a subscription URL; a page that opens in a browser is not necessarily importable subscription content. Do not use a sign-in page URL as a Subscribe URL, and do not remove trailing parameters just because the link is long. Subscription URLs may contain credentials, so redact sensitive parts before sharing screenshots or diagnostic records.
If the address in your service details has changed, confirm the new one through the original management channel before editing the app. Do not rely on an old URL in a forwarded message. Opening the URL in a browser can help reveal a sign-in page, error page, or redirect, but browsers and apps may make requests differently. A URL opening in a browser does not guarantee that the app can import it. In particular, content displayed by a browser may depend on an existing sign-in session, while a subscription request needs data that can be retrieved independently and is in a supported format.
Choose a troubleshooting path based on the response
If an HTTP status is available, check subscription credentials and account status first for authentication errors. If the resource is missing, check whether the path has changed. If requests are being made too frequently, stop retrying and wait as required by the service. Server-side errors need to be checked by whoever maintains the subscription. A connection timeout is not a content-format error; check the current network and subscription-domain resolution first. Retest with the same URL each time so you do not change the network and link simultaneously and lose a useful comparison.
If the message points to a parsing failure, check whether the response contains protocol entries, a configuration file, or webpage text. A subscription and a complete configuration file used in Config are different types of data; do not put them in the same input just because both are links. Some entries may contain field combinations that the current app does not support. If some entries import while others fail, check the protocols and settings of the failed entries rather than assuming the entire URL is unusable. Refer to the current app documentation for supported formats.
Keep existing entries to avoid losing a connection needed for updates
A subscription URL may require an existing connection path to retrieve its contents. If you delete all servers before updating, you may lose the access needed to fetch the subscription. Save your current configuration and working entries first, then check whether the update request used the expected path. Do not assume it uses the same connection as the webpage you just opened. If the selected server no longer works, compare only entries and networks you already have and can use; do not bring in data from an unknown source to bypass troubleshooting.
After a successful update, checking whether the entry count changed is only a first step. Confirm that the selected entry still exists, its key parameters were not overwritten, and duplicate names have not caused you to select the wrong item. If you manually adjusted an entry, find out whether the next subscription update will overwrite those fields. Keep a separate copy for comparison if needed. An update completing does not mean the server can connect; data retrieval and an actual server connection must be verified separately.
By the end of this section, you should be able to identify whether the issue is an incorrect URL, a failed retrieval path, an abnormal response, or an unsupported format. For the basic import steps, see the quick-start guide. If you are importing a rule configuration, read Config File sections explained; do not confuse a server subscription with a rules file. After recovery, perform only one necessary update and connection test to avoid adding new restrictions through repeated refreshes.
Slow connection: Separate initial page load, ongoing transfers, and isolated stalls
“Slow” can describe at least three things: a long wait before a page opens, slow transfer after loading starts, or lag in just one app or website. Identify which stage is slow before testing. A delay before the first page may involve DNS, the handshake, or redirects. Ongoing transfers are more affected by path capacity and congestion. Isolated lag may relate to a particular domain, protocol, or destination service. A Connectivity Test response time applies only to that specific test; it does not measure sustained transfer speed or replace real-world testing.
Set up repeatable test conditions
Keep the device, network, server, mode, and test destination the same. Pause large syncs, system downloads, and other sustained transfers, then wait for current requests to finish before retesting. Record the test time and whether the device is in Low Power Mode, sharing a hotspot, or has a weak signal. Do not compare one-off results from different times or destinations, and do not run several speed tests at once; concurrent tests compete for bandwidth and can make a normal path look unstable. A few short tests to spot a trend are more useful than chasing one peak result.
On the same network, first disconnect and check the destination over Direct, then connect and use Proxy to test the server path, and finally use Config to check your usual routing. If Proxy is fine but Config is slow, check whether some destination resources are being sent through a different policy. If both modes are slow but other existing servers work, the current server path is more likely the issue. If every mode is slow, check Wi-Fi signal, network congestion, and the destination service before making major configuration changes.
Identify slow requests within the page
A page can request text, images, scripts, video, and sign-in APIs at the same time. The main page loading does not mean every dependent domain is working. If images load slowly, sign-in spins, or playback stalls after starting, check connection records from the same time to find requests that keep failing or retrying. Adding a rule only for the homepage domain may miss the resource that is actually stuck. Conversely, broadening the domain scope for convenience may change paths that were already working. Base rule changes on actual requests.
If the first visit is slow every time but later visits improve, look at resolution, connection setup, and caching. If transfers pause periodically over a longer period, consider network switching, packet loss, path congestion, or competition for server resources. Caching affects comparisons, and a browser refresh may continue using an existing connection. For a retest, try to start a fresh request and note whether it is the first visit. You do not need to clear all app data to test, and clearing data is not a general speed-up method.
Adjust protocols and MTU only with evidence
A more complex transport is not necessarily faster. Whether a protocol is suitable depends on the server configuration and current network. If you suspect a transport is restricted, compare entries you already have that are correctly configured; do not change the protocol name on the client side alone. Do not copy a fixed MTU value from an online article either. Investigate this only when small requests work, large ones stall, and repeated comparisons support the theory. Save the original value, change one item at a time, and retest with the same destination. Restore it if the result is unclear.
A destination service may also behave differently depending on sign-in state, resource type, or exit conditions. If other websites work but one destination remains slow, check the destination and the server-to-destination path separately; that does not establish that the client as a whole is slow. Device heat, heavy background activity, and retransmissions on a weak signal can also affect perceived speed. Let the device return to a normal operating state before testing again so you do not mistake a temporary system load for a rules issue.
Once you have identified the cause, keep only changes that explain and improve the issue, remove temporary test rules, and recheck your usual Config. For routing only selected websites, see how to route selected domains. If the delay is during resolution, continue to the next section instead of replacing every server as a substitute for DNS diagnosis.
DNS issues: Distinguish server-domain resolution from destination-domain resolution
DNS problems do not always mean that no domains open. A server address may fail to resolve, one subdomain may fail, the first page load may be slow, or access may break after switching networks. First establish whether the failure occurs before or after the server connection. If the server domain cannot be resolved, the protocol connection cannot start. If a destination domain fails to resolve, the tunnel may already be established. These stages can use different paths and dependencies, so changing one DNS setting does not necessarily fix both.
Use the error log to identify the resolution stage
Check the error at the time of failure to see whether it refers to the server address or the destination. If the server domain has no usable resolution result, confirm that the underlying network works, then check the spelling, the active configuration’s resolution settings, and system network status. If the server is connected but a specific destination fails, compare that domain in different modes and check whether its request is routed through the expected policy. Successful domain resolution only means an address was returned; it does not guarantee that the service at that address is reachable. Check the subsequent connection separately.
Do not rely only on whether you can open a website by entering its IP address. Many sites use the domain to select the correct site, validate certificates, and set request headers. Failure to open an IP address does not prove the network is down, and a response from an IP address does not prove that the original domain resolved correctly. A more reliable test keeps the original domain and compares resolution and connection records on the same network and destination. If the app provides diagnostic details, record the result type, timing, and failure stage rather than capturing only an address that looks unusual.
Check for a circular dependency in the resolution path
With encrypted DNS, the resolver’s own domain also needs to be resolved and connected to. If resolution depends on a proxy that is not yet connected, while the proxy server’s domain depends on that resolver, the two can wait on each other. Before changing settings, map out three steps: what resolves the server domain, what connects to the resolver, and what resolves the destination domain. Start by restoring a DNS configuration you have verified works, then add custom settings one at a time. Do not layer several resolvers and guess which one is active.
DNS parameters in Config, system network resolution settings, and other network extensions can all affect results. First confirm which Config is active, then check for [Host] local mappings or other overrides. An old local mapping can bypass normal resolution and pin a domain to an address that is no longer suitable. If you need to keep a mapping, document its purpose and review it periodically. If its source is unknown, save a copy and disable that mapping on its own for a retest instead of deleting the entire configuration.
[Host]
example.com = 192.0.2.10
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXYThe following is a structural example; the example address in the documentation is not an actual destination to visit. [Host] can affect domain-to-address mapping, while domain and address rules determine subsequent routing. In this example, no-resolve prevents this address rule from actively triggering domain resolution. It does not mean that all requests stop using DNS, nor does it guarantee that the domain will be resolved on the server side. Do not treat this single option as a universal DNS fix; interpret it in the context of rule order and the actual connection path.
Watch for dual-stack networks and cache changes
The same domain may return different address types, and the current network may not be able to reach them equally well. If one network works and another fails, compare the address types actually used with the connection errors instead of disabling a network capability outright. If only some addresses are unreachable, the issue may be in the path or on the server. Changing resolution only changes which address is selected; it may not remove the underlying cause. A brief issue after switching networks may also involve an old cache or connection. End affected requests, establish a new connection, and then retest.
Recovery checks should cover the server connection, the affected domain, and one domain that already worked, so fixing one case does not break another. Record which DNS setting or mapping changed the result, then restore temporary test items. For configuration sections, see [General], [Rule], and [Host] explained. For the scope of domain and address rules, see the glossary. Resolved addresses and browsing history can also reveal private information; share only what is needed for diagnosis.
Battery drain and issues after an update: Retest against recent changes
Investigate increased battery use and connection changes after an update by starting with a timeline. Note when the issue began, what changed beforehand, which network was in use, and whether there was sustained data transfer. Do not assume that every battery listing for Shadowrocket means a particular setting caused the drain. The VPN extension handles traffic for other apps, and system attribution depends on how the device was used. Consider Screen Time, network activity, and repeatable comparisons instead of comparing percentages over different time periods.
For increased battery use, check retries and sustained activity first
Under similar usage conditions, compare a stable connection with a period of repeated connection failures. A server that keeps failing, a weak signal, frequent network changes, and other apps repeatedly requesting unavailable resources can all increase network activity. Check for repeated connection errors, then find domains or background requests that keep failing. If an app is syncing continuously, pause its task and observe the change; that is more informative than disabling every rule. Do not drain the battery to test. Compare similar time periods under similar loads.
Check whether On Demand behaves as expected, especially whether network changes repeatedly trigger connections. Temporarily turn off automatic triggers, establish a stable connection manually, and observe the result. If the issue clearly improves, restore conditions one at a time. On Demand controls when connections start; it is not a traffic-routing mode. Changing it does not replace fixing rules. If the connection keeps coming back after you disconnect, determine whether this is automatic triggering or repeated recovery after a failure. Do not keep toggling settings in both the system and the app without checking what triggered the connection.
Keep only the records you need during diagnosis, then restore your usual logging settings to avoid retaining detailed diagnostics longer than necessary. Also consider device temperature, cellular signal, hotspot use, and background backups. If the device continues to heat up or drain battery after disconnecting, investigate the system and other apps as well. Do not disable certificate verification, randomly change protocol settings, or delete system configurations as battery-saving measures; these actions do not establish a cause-and-effect link between the setting and battery use.
After an update, first identify what actually changed
App updates, system updates, subscription updates, and remote configuration updates may happen around the same time, but they change different things. First determine whether the issue is a changed interface location, one failed entry, all connections failing, or different rule matching. Check the app’s App Store description and update notes, and verify whether your subscription or configuration changed at the same time. Compatibility and system requirements are as listed on the App Store page; do not assume your device is compatible based on an old screenshot from another device.
Keep a copy of the configuration that worked before the update and compare protocol settings, policy names, DNS, local mappings, and rule order with the current version. If a remote update overwrote the same configuration, verify the file contents before attributing every change to the app. If an old field is no longer applicable, adjust it according to the current app documentation. Do not add back several unknown settings at once to recreate old behavior. A simple test configuration provides a baseline for distinguishing a configuration issue from a shared runtime environment issue.
Start recovery with reversible steps
First disconnect and reopen the app, then test with a verified server and minimal configuration. If necessary, save your records and restart the device. If only the original configuration fails, restore it section by section to find the trigger. If every configuration fails, continue checking the system VPN state and network conditions. Deleting the app affects local data, and reinstalling it does not automatically restore your servers and rules. Consider it only after backing up, confirming you can restore what you need, and ruling out other causes. For purchase restoration, see the restore purchases and reinstall guide.
After confirming recovery, re-enable your original On Demand settings, everyday configuration, and background tasks one at a time. If the issue returns after restoring a particular item, keep that trigger condition and investigate further. If it cannot be reproduced, note that service has temporarily recovered and continue monitoring rather than claiming the root cause is known.
iPad-specific troubleshooting: Compare networks, configurations, and recovery from sleep
iPad and iPhone troubleshooting follows the same general approach, but network conditions, system permissions, app layout, and background usage may differ. Do not copy every system setting just because one device works, and do not share subscription credentials from the other device to compare results. First confirm both devices use the same valid service details, destination, and similar network conditions, then compare the results. App purchase coverage, compatibility, and system requirements are as listed on the App Store page. For the access method, see iPad download and first launch.
Rule out configuration differences that only look the same
Check the selected SERVER, Global Routing mode, and active Config one by one. The same display name does not guarantee the same contents; an old subscription entry may keep the same name while using a different address or settings. Compare key fields and the active file, not just the list title. The wider iPad layout may show a list and editing view at the same time. After saving a change, confirm that the item is actually in use; do not assume that selecting it in the editor has switched the active connection.
VPN authorization must be confirmed separately on each device. Permission granted on another device does not authorize this one. If the iPad switch immediately turns off, follow the first section to check the system VPN configuration, other connections, and device-management policies. An iPad used at school or work may be subject to management requirements. If you cannot add, change, or remove a configuration, contact the administrator first. Do not assume differences between managed and personal devices indicate an app issue, and do not remove management settings without approval.
Test Wi-Fi and hotspot networks separately
A Wi-Fi-only device can be compared on another Wi-Fi network you can use or a personal hotspot. A hotspot changes the underlying network path, so it does not change only the device. Even two devices on the same router may use different bands, isolation policies, or sign-in states. First disconnect the VPN, confirm that the iPad has completed network sign-in and can access ordinary websites, then connect. If only one Wi-Fi network fails, keep the server settings and investigate that network instead of rebuilding every entry.
If printers, local webpages, or home devices are inaccessible, distinguish system local-network permissions from routing rules. If the system requests relevant permission, check it for the intended use. Rules should send the actual local subnet through the appropriate path. Do not assume every router uses the same private subnet; check the address range on the current network. Local services addressed by domain may also rely on local DNS and discovery. A result from external DNS may not work for local access, so a broad rule alone may not fix the issue.
[Rule]
DOMAIN,localhost,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
FINAL,PROXYThe snippet above shows the relationship between private address ranges and a fallback policy; it is not intended to replace your everyday configuration. Before using it, check the current network, existing policies, and whether remote services also use private addresses. If a private network needs to be reached through a proxy, sending everything directly can break that scenario. Put the specific rule before broader rules and verify the match with a real local access attempt. For first-match behavior and the meaning of FINAL, review the rule types guide.
After waking the screen, check only what changed
If the connection worked before the screen locked but fails after waking, first note whether the network changed during sleep, then check On Demand and connection records. Resuming from system sleep can leave an old connection unusable; opening a new page is a more reliable test than waiting on the old one. If one app is stuck in a multitasking view, that does not mean all network access has failed. Compare other access on the same device before deciding whether to reconnect. Repeatedly removing the app from the recent-apps view is not a reliable way to keep a background connection alive.
At the end of troubleshooting, you should be able to identify a specific cause: device authorization, a configuration difference, a network restriction, local-network routing, or connection recovery after sleep. If you still need help, organize the comparison conditions for both devices and redact the error records; do not send the full subscription. After returning to normal use, follow the setup tutorial to verify a connection and routing again. For feature limits and the purpose of On Demand, see the features guide. Keep a copy of the configuration you have verified works so you can use the same baseline next time.