Shadowrocket
Troubleshooting Guide

Tell apart a switch that won't turn on from one that turns itself off

If the switch won't stay on, first check whether your system allows a VPN configuration; don't immediately change your server password. In Home, select an existing server and make sure you're not still in an edit form, then try connecting. The first time you connect, your device may ask to add a VPN configuration. Approve the system prompt only if it identifies the Shadowrocket you're using. If you dismissed the prompt, return to the app and try again to see if it reappears.

Record which of these three things happens: nothing when you tap the switch, a system prompt appears but setup isn't completed, or the switch turns on briefly and then turns off. For the first, check whether the app responds to other actions. For the second, check device authorization. For the third, look for the app's connection error. “It won't turn on” isn't specific enough: these symptoms point to different issues—the interface, system permissions, or the connection process—and need to be handled in different orders.

If the interface appears unresponsive, wait for any import or test to finish, then return to Home and try again. Closing and reopening the app normally can clear a temporary interface freeze, but it won't fix a server issue. Repeatedly tapping the switch can mix together several connection attempts and make errors hard to match to an action. One complete attempt with a recorded result is more useful than switching it on and off repeatedly.

Check system settings and On Demand

Open Settings on your device and look for the VPN configuration management screen. Confirm that a configuration for Shadowrocket exists, and check whether another network tunnel is connected. The location of this screen can change; use Settings search to find it. Disconnect other active tunnels, then return to the app and try one manual connection. Don't delete configurations you don't recognize, especially those installed by a school, employer, or device management policy.

If the switch turns back on after you turn it off, or keeps changing when you switch networks, check On Demand. Its conditions may trigger another connection attempt, which is different from a standard manual-switch issue. Note the existing conditions, temporarily turn off On Demand, and test whether a manual connection stays stable. If it does, restore the conditions one at a time to identify which network condition triggers the connection or disconnection.

On managed devices, system policies may restrict adding or changing VPN configurations. If the authorization option is unavailable or the system says configuration is restricted, ask your device administrator what settings are allowed instead of repeatedly reinstalling the app. App settings can't override device management policies. Check that the system allows a connection before investigating server addresses, protocols, or rules.

Save your information before recovery steps

If the switch turns on briefly and then turns off, first make sure the selected server details are complete: the address and port aren't blank, the right protocol is selected, and the imported entry hasn't become invalid. Compare each field with the information from your service provider; don't rely on the entry name. If the error points to DNS, authentication, or a certificate, go to the relevant section. System authorization may already be complete, so there's no need to repeat the VPN configuration steps.

Before rebuilding the system VPN configuration, save any configuration files and server details you need, and confirm you can still get the subscription from your service provider. Removing the system VPN configuration and deleting the app are different actions with different effects. Don't do both before making a backup. After rebuilding the configuration, manually connect with one verified server. Leave complex rules and On Demand off for now so you can tell whether the basic connection works.

Record specific results, such as “system prompt completed, other tunnels disconnected, manual connection still drops.” If the problem persists after restarting your device, use the error shown in the app to continue investigating. For purchase or app-source questions, see how to verify the App Store version. Don't confuse app acquisition with connection settings. System requirements are as listed on the App Store page.

Check the basic network first, then compare routing modes

If the connection is established but you can't access anything, temporarily disconnect Shadowrocket and try a site that normally works on the same device and network. If it still fails, check Wi-Fi, cellular data, your router, or network sign-in first. Public Wi-Fi may require you to complete a sign-in page. Changing proxy rules usually won't help until basic network access is available. Sign in, then try connecting again.

Once the basic network works, keep the destination and server the same and compare Config, Proxy, and Direct under Global Routing. These are the exact mode names shown in the app. After each change, make a new request rather than checking a page that's already open; some apps reuse old connections, which may not immediately follow the new routing decision.

Use the comparison to understand the result, not to pick a mode as a permanent workaround. If Direct works but Proxy doesn't, the direct path is available, but the server path needs investigation. If Proxy works but Config doesn't, check which rule matches, where its policy points, and DNS. If all modes fail, check the destination, device network permissions, and DNS results instead of treating different issues as one.

Check rules based on the scope of the problem

If only some pages or apps fail, note one destination that works and one that doesn't. Check the domain used by the failed request and whether it followed the expected policy. A page may request several domains; if the main content loads but images or sign-in fail, check those related requests too. Don't replace the whole configuration with broad proxy or direct rules to fix one page.

Rules in Config are generally evaluated in order. A broad rule placed first may take precedence over a more specific rule below it. Check the position of custom rules, policy names, and the final FINAL rule. Also distinguish REJECT, which explicitly blocks a request, from a connection failure: REJECT is a rule decision; a connection failure means access didn't work after routing was decided. If the app's logs show a reject policy was matched, check whether that rule is intentional.

The snippet below illustrates rule order; it isn't a complete replacement for your configuration. It first matches a domain suffix, then addresses in a specified region, and finally applies a policy to unmatched requests. The example domain is for syntax only. For troubleshooting, use a destination you've verified. Changing FINAL can affect many unmatched requests, so don't change it without recording the original value.

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

Verify new requests and the actual recovery

After changing modes, end the failed page's old request and open the destination again. Try a new browser tab, or leave and reopen the relevant page in another app. If cached content appears but refresh fails, the network isn't restored. Check the page's main content, image resources, and an action that requires a network request. This helps distinguish full access from cached content or an existing session.

If the browser works but one app doesn't, check its cellular data permission, whether it requires access from a particular region, and whether it relies on a separate connection or account status. An access restriction returned by the app isn't necessarily a tunnel problem. Don't keep switching servers and trigger more sign-in checks. Save the error text and determine whether the failure happened during connection or after a response came back from the service.

After access is restored, set Global Routing back to the mode you need and retest the destination that failed. If it only works temporarily in Proxy but still fails in Config, fix the rules rather than treating the comparison as a complete solution. If you're new to setup, revisit the Global Routing guide. For quick answers and purchase questions, see Troubleshooting.

Break a failed test into checkable stages

A failed Connectivity Test only means that this test didn't complete as expected; it doesn't prove the server is permanently unavailable. First confirm that the test is for the currently selected server and note which test method you used. Different methods check different stages: an open port doesn't prove protocol authentication succeeded, and successful authentication doesn't guarantee that a particular destination is reachable. Interpret the result alongside a real request.

Check the address and port first. Make sure the address field doesn't contain a protocol prefix, spaces, line breaks, or a path that isn't part of the hostname. Don't use a subscription URL as a server address or enter a web-based admin page under Add Server. If the address is a domain name, check whether the device can resolve it. A DNS failure happens before connecting to the server, so fix DNS rather than repeatedly changing authentication fields.

Next, keep the same configuration and switch the basic network once, for example from Wi-Fi to cellular data. If it times out on only one network, investigate the local network, routing path, or restrictions on the transport in use. If it fails on both, ask your service provider whether the server, port, or settings have changed. Keep the server and destination the same for each comparison so the network difference is useful evidence.

Check protocol-specific settings without mixing fields

For Shadowsocks, check the encryption method and password. For VMess and VLESS, check the identity and transport settings required by the server. For Trojan, focus on the password and TLS-related fields. Fields from different protocols aren't interchangeable, so don't copy every option just because two entries use the same address. A successful import only means the text could be parsed; it doesn't confirm that the details match the server's current settings.

TLS connections also depend on the server name, certificate validity, and device time. Use the SNI required by the server; don't enter an arbitrary domain just because it opens in a browser. For certificate errors, first check the device's date and time, then verify the domain, SNI, and server certificate. Disabling certificate verification isn't a routine fix: it can hide a hostname or certificate problem and weaken verification of the server's identity.

If the server uses a transport such as WebSocket, check that the path, Host, and TLS settings match. Paths may be case-sensitive and may need their leading slash. Don't copy explanatory notes from setup instructions into a field. If anything is unclear, check the original information from your service provider rather than trying several guesses in a row and creating a combination that's hard to reproduce.

Distinguish persistent failures from intermittent timeouts

If timeouts happen only at certain times, note when they occur, the current network, server, and test destination rather than saving only a failed result. Brief congestion, network changes, and server load can all affect a test. Run a few comparisons with pauses between them; avoid constant testing. A large number of concurrent requests can add interference and make an intermittent issue look continuous.

If the test completes but a page still fails, try a known accessible, lightweight page to distinguish “connection to the server” from “accessing a destination through the server.” Destination restrictions, DNS differences, and rule routing can all cause the second stage to fail. Conversely, the test destination itself may be unavailable even when normal app traffic works, so don't delete a server based on one test alone.

When contacting your service provider, include the protocol, error type, network comparison, and steps to reproduce the issue. Don't share passwords, identity details, or a complete subscription link. For details on Trojan fields, see Trojan settings explained. If the settings are verified but the remote server remains unreachable, wait for your provider to confirm its status rather than changing unrelated local rules.

Tell apart fetch failures, parsing errors, and unavailable entries

If a Subscribe update fails, first identify where: the remote content couldn't be fetched, the content was fetched but couldn't be parsed, or the update completed but the servers won't connect. These are different problems and need different fixes. A subscription update imports remote information into the app; it doesn't guarantee that every server is currently reachable. If a server times out, keep the update result and troubleshoot it separately in the previous section.

Get subscription links from your service provider. Copy the entire URL, including its query parameters. Check that a long link wasn't wrapped, truncated, or copied with leading or trailing spaces. Don't remove parts that look like random characters; they may be needed for authentication. Don't use an account page, help page, or configuration display page as the subscription URL. A page showing text in a browser doesn't mean it's returning data the app can use.

Note your existing subscription groups and working entries before you manually update. Check the result and the app's message. If some servers still work, keep those details rather than deleting the entire group to retry. Depending on the update method, entries may be renamed, reordered, or changed. Recheck the selected entry before connecting. A missing old name doesn't necessarily mean the subscription has failed; check whether the entry was replaced or moved.

Check the access path and returned content

If fetching fails, confirm that the current basic network can reach the service hosting the subscription. If needed, compare the result with the connection off and with an existing working connection, changing only the access path each time. Update requests may not follow exactly the same path as ordinary web requests, so use the result shown in the app. If your provider requires specific access conditions, follow their instructions rather than changing the URL's domain or protocol at random.

For authentication failures or access denied messages, check whether the subscription was reset, account authorization changed, or the link is no longer current. Repeatedly requesting an expired authentication link usually won't restore access. If the response says requests are too frequent, stop updating and wait as your provider instructs. App purchase status and remote subscription authorization are separate; buying the client again won't renew an expired subscription.

If the content is fetched but can't be parsed, check that the format from your provider matches the import option. The response might actually be a sign-in page, error message, or maintenance page rather than server details. Text on a page doesn't mean it's in the right format. Don't copy an entire webpage into a configuration file or edit encoded content by hand. Ask your provider to confirm the response type and supply details compatible with the import option you're using.

Check the selection and persistence after an update

After a successful update, return to Home and check that the selected server still exists and belongs to the right group. Run a connection test on one entry. If all new entries fail, check the protocol and ask your provider about server status. If only some fail, note their names and error messages for your provider. A change in the number of entries doesn't by itself indicate an app problem; the remote content may have changed.

Before editing a subscription entry manually, consider whether the next update will overwrite your changes. To test one field, save its original value and, if needed, create a separate manual test entry for comparison. Don't copy and edit the same server across several groups; it will be difficult to tell whether you're connecting to the original or a temporary copy. Remove temporary test entries when finished and use clear names.

If updates haven't run for a while, first check that the app has the network access it needs when an update runs, then review the update settings. Background activity depends on system scheduling; an update not appearing at the expected time doesn't mean the subscription has expired. If a manual update works but a background one doesn't, check the device environment and system restrictions rather than regenerating all server details.

Keep a clear record: the link source is confirmed, whether fetching and parsing succeeded, and which entry connects after the update. If the cause is still unclear, send your provider the error text with authentication details removed and note which stage failed. Never post the full link in a public forum. For quick subscription answers, see Troubleshooting. For the initial import steps, follow the user guide.

First identify what's slow

Break “slow speeds” down into slow initial loading, slow transfers, video buffering, occasional pauses, or drops after switching networks. Initial loading mainly involves DNS, connection setup, and handshakes; sustained transfers also depend on bandwidth, congestion, and the destination service. One latency number can't explain both. Choose an action you can repeat, note what happens at the start and during the sustained part, then decide what to check.

First check the basic network on the same device. Make sure large file syncs, system updates, or ongoing transfers from other apps aren't using the network at the same time. Traffic changes in Data can help identify activity, but high traffic doesn't mean a server is fast, and low traffic doesn't mean the connection has failed. Wait for other heavy network use to finish before comparing results, so the device's overall load isn't mistaken for proxy performance.

Keep the destination, server, and Global Routing mode fixed, and run a few tests close together in time. Don't change the network, server, and protocol all at once and attribute the improvement to just one of them. First compare the same server on two networks, then compare two of your existing servers on the same network. Change one variable at a time so the result can point to a specific bottleneck.

Compare the local network, server, and destination separately

If performance is poor only on one Wi-Fi network, check signal strength, distance from the access point, router load, and network sign-in status. Retest somewhere with a stronger, steadier signal before changing protocol settings. When comparing with cellular data, account for differences in signal and network type too; a test while moving doesn't represent performance in one fixed location.

If only one server is slow on the same network while other existing servers work, focus on that server's load and the route to it. If several servers are slow but Direct works, that still doesn't prove the app is at fault; the servers may use similar routes or remote exits. Compare the destination, time, and protocol to see whether the results follow a consistent pattern, then give your provider reproducible details.

If only one website or service is slow, test other destinations through the same server first. Content delivery, account restrictions, service status, and access region can all affect results. A test file's throughput doesn't represent every site's loading experience. A fast download doesn't prove that short connection handshakes are equally smooth. Test the operation that actually feels slow rather than chasing a better-looking number.

Check transport characteristics before adjusting settings

Some protocols rely on UDP, and certain networks may handle its reachability and sustained traffic differently. With Hysteria2 or WireGuard, first confirm that the network and server support the required transport, then check the protocol settings. A working TCP connection doesn't prove that the UDP path is available. Match the protocol to the server configuration rather than changing the client type while keeping unrelated settings.

Don't start by changing MTU, concurrency, or connection keep-alive settings. For example, fragmentation or packet loss on a particular path may cause small requests to work while larger transfers stall, but congestion or destination restrictions can look similar. Lowering MTU without evidence may affect other apps. If a test is needed, note the original value, change one setting, and restore it if there's no improvement.

If the pause starts only after switching networks, wait for the system to finish connecting to the new network, then make a new request. Some apps keep old connections and need to reconnect; that doesn't mean all traffic is still unavailable. Compare a new browser request with the old session in the affected app to help determine whether the issue is with the tunnel or the app restoring its session. Don't repeatedly toggle the connection and switch networks at the same time; that can interfere with reconnecting.

To verify an improvement, repeat the complete operation that was slow and check that it remains stable. One faster page load isn't enough reason to save a set of unverified changes. Record which variable helped and whether the slowdown returns when you restore its original value. For more detailed testing, see a step-by-step guide to diagnosing slow speeds. For context on traffic figures, see how to read the Data traffic panel.

Confirm that the problem is actually happening during DNS resolution

DNS problems may show up as a server hostname that won't resolve, some destinations reporting that the address can't be found, or different results for the same domain after switching networks. First distinguish a server address that won't resolve from a destination domain that won't resolve. The first can prevent the proxy connection from starting; the second may occur after the connection is up. Record the domain and the stage where the error occurs to decide whether to check the local network, DNS settings in the app, or the server path.

Don't rely on opening a destination by its IP address as a substitute for checking DNS. Many services need the correct domain for TLS and virtual-host matching; failure to open an IP doesn't prove the network is unavailable. Likewise, a connection to an IP doesn't prove the domain's page will work. Instead, use DNS or request details visible in the app to check whether the domain resolved and which policy the request followed.

Use a destination you know should work, and keep the current network unchanged while checking. If one domain fails, verify its spelling, the domain's status, and the server address provided by your service provider. If many unrelated domains fail at once, look first at the DNS service or the path used to reach it. Don't label server-side errors, failed account checks, or blank pages as DNS problems without evidence.

Check the resolution path, cache, and address type

Review DNS-related settings in the current Config, and check for additional DNS settings or network management policies on the device. First list the settings that may affect resolution, then decide which one to test. Before switching DNS services, make sure the chosen address is reachable over the required protocol and network path. An inaccessible DNS service could turn a problem affecting one destination into a failure for every domain.

If you use encrypted DNS, check the server name, certificate, and access path too. Establishing an encrypted DNS connection may itself require resolving the server name first. A broken dependency can cause failure during startup, so encryption alone doesn't guarantee that the resolution path is correct. Follow the configuration instructions; don't treat a standard DNS address, an encrypted DNS address, and a web URL as interchangeable.

Account for cached results and existing connections after making changes. The system, app, and destination app may all retain earlier results, so one immediate refresh may not trigger a new lookup. End related requests, reconnect, and test again; restart the destination app if needed. Don't switch among several DNS services without recording the results. If the cache hasn't updated, you could mistakenly attribute the observed behavior to the latest change.

Also check whether IPv4 and IPv6 paths behave differently. Some networks return both address types but have an unreliable path for one; some services depend on a particular type. Don't disable all IPv6 support to fix one destination. Compare networks, domains, and the address type that failed to establish the scope, then make the smallest change supported by your current configuration.

Check DNS results alongside rule order

Domain rules and address rules match different things. DOMAIN matches an exact domain, DOMAIN-SUFFIX matches a domain suffix, and IP-CIDR and IP-CIDR6 match address ranges. If a request matches a broad rule first, a more specific rule below it may never be evaluated. DNS results can also affect address-rule matching. “DNS returned a result” and “the right rule matched” are separate things to verify.

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

These snippets illustrate different match types; they aren't a complete configuration. In this example, a domain entry is already covered by a suffix entry with the same policy. Both are shown for comparison, but a real configuration should avoid unnecessary duplicates. A private-address rule only handles matching address ranges; it won't necessarily fix every local-network discovery or device communication issue. Check the final section for local network problems.

After recovery, separately confirm that the server hostname resolves, the failed destination resolves, a new request matches the expected policy, and the page actually works. If any step is still failing, continue troubleshooting that layer instead of adding more DNS addresses. When contacting your service provider, share domains with sensitive details removed, the error type, and network comparisons. Don't expose dedicated URLs containing account identifiers or a complete configuration file.

First check for ongoing traffic and repeated reconnections

Investigate unusual battery drain using battery usage and screen activity in Settings alongside network activity at the time. The VPN connection carries traffic for other apps, and system attribution doesn't always show which app initiated all that activity. Don't assume the configuration is at fault based on a single percentage. Note when the drain occurs and check for video, syncing, uploads, or long-running network transfers.

Compare idle and active use separately. For an idle comparison, keep the network, approximate battery level, and observation period similar; avoid charging, downloading, or moving around at the same time. For active use, repeat the same task and note how long it takes. Short-term battery estimates are affected by temperature and system calculations, so they aren't precise measurements. Look first for observable clues such as continuous transfers or repeated connections.

An unstable connection may repeatedly retry, increasing network activity. Check whether the device keeps switching between Wi-Fi and cellular data, whether the signal is weak, or whether On Demand is repeatedly triggered by nearby conditions. Stabilize the basic network and temporarily turn off On Demand for one manual connection test. If the drain eases when reconnections stop, restore the conditions one at a time rather than disabling everything.

Reduce diagnostic overhead without skipping verification

Troubleshooting may involve temporarily enabling detailed logging or running Connectivity Test repeatedly. Once you have the evidence you need, restore the previous logging level and stop repeated tests so the diagnostic activity itself doesn't become a regular load. If Data continues to show traffic, check what other apps are doing. Cloud sync, media uploads, and background transfers can continue with the screen off; an apparently idle device may still be using the network.

If the device gets noticeably warm, stop heavy testing and let it return to a stable temperature before comparing connection performance. Temperature can affect system performance and wireless communication. Sustained transfers while charging can also add interference. Don't run stress tests just to collect more data. The goal is to reproduce the real-world issue and verify an improvement, not to find the limits of the device or network.

Battery issues also call for checking the device as a whole. If the same unusual drain continues with the connection off, review system battery records and activity from other apps instead of continuing to adjust proxy settings. If the issue occurs only with a specific network and server combination, focus on reconnections and transfer stability. Narrowing the scope to a reproducible combination helps distinguish device battery health from an app configuration issue.

After an update, restore a minimal working configuration first

If a problem appears after an update, determine whether it was an app update, system update, subscription update, or change to Config contents. They may happen around the same time but affect different things. Note the network and configuration used the last time everything worked, then check the current server, Global Routing mode, and selected configuration file. A subscription rename, changed policy target, or system permission change can make an issue look like it was caused directly by an app update.

Close and reopen the app normally, and restart the device if needed. Then test with one verified server and a simple destination. Temporarily disable custom complex rules, On Demand conditions, or other extended settings, but save their original contents. Test after restoring each item. If the basic connection works and fails only after adding one setting, you can focus on that setting instead of deleting all app data.

Check Config for references to missing policies, removed server names, and formatting errors. A saved configuration may still refer to items that no longer exist. If an explicit parsing message appears, use it to locate the relevant line and preserve the difference before and after your change. Don't combine a large number of settings from different sources to fix one error; dependencies between configuration items can make individually valid snippets fail when combined.

Remove the system configuration or reinstall the app only if you have backed up your information and know you need to. Get and update the app through the App Store. For restoring purchases and device compatibility, see how to restore a previous purchase. System requirements are as listed on the App Store page. After restoring, test the basic connection first, then bring your information back gradually. Reproducible steps are more useful for troubleshooting than an unverified claim that “the update broke it.”

Align the network and configuration before comparing devices

If the same subscription works on iPhone but not on iPad, first confirm that both devices are actually on the same network. The iPhone may have switched to cellular data while the iPad is still on Wi-Fi that needs sign-in or has a weak signal. Check the actual network, then compare the selected server, Global Routing mode, Config, and subscription update time. Matching server names aren't enough; entries with the same name may have different settings.

On both devices, use the same destination, server, and mode, then make new requests. Don't compare a page already buffered on one device with a first attempt on the other. If the iPad still fails with all conditions aligned, check its VPN authorization, date and time, device management policies, and additional network settings. A server working on another device doesn't rule out local permission or configuration differences.

Handle app purchases and configuration transfer separately. App availability for previous purchases, device compatibility, and system requirements are as listed on the App Store page. Having the app installed doesn't mean server details will appear automatically. Follow the iPad app availability guide to confirm the app, then get your subscription from your service provider and import it. Only then compare connection results, so missing configuration isn't mistaken for a purchase restoration failure.

Check multitasking, sleep, and network recovery

In iPad Split View or multitasking, the app may appear in a narrow area, and some settings may be hidden until you expand the view or scroll. The meaning of a setting doesn't change with the window size, but fields below the fold are easier to miss. When checking Add Server, scroll through each field. Save, then reopen the entry to review it. The visible top half of an edit screen isn't proof that all settings were saved.

If a problem occurs after closing the cover, leaving the device idle, or switching networks, test system network recovery, VPN connection status, and the destination app's session separately. First confirm the device can access the basic network, then check Shadowrocket's connection, and finally reopen the destination page. If a new request works but an existing video, file transfer, or session remains paused, the destination app may not have resumed its old connection. You may not need to rebuild the server configuration.

Test On Demand on iPad against the actual network conditions, one at a time. The device may stay on the same Wi-Fi for a long time while going through sleep, expired network sign-in, or an access point change. First confirm that a manual connection works, then restore On Demand and test what happens when the device wakes, leaves the network, and reconnects. One successful wake-up doesn't cover every network condition; keep records from real-world scenarios.

Distinguish local addresses, discovery, and proxy routing

If a home storage device, printer, or other local network service is inaccessible, disconnect first to compare, then confirm that both devices are on a network that allows them to communicate. Guest Wi-Fi, access point isolation, or different subnets can block communication by themselves. If access still fails while disconnected, check the router or device permissions. Only investigate Config routing rules once the basic local network path works.

Local network discovery and direct access by a known address are different behaviors. If the address works but automatic discovery doesn't, the cause may involve discovery traffic, network isolation, or the system's local network permission; adding a domain rule alone won't solve it. If the app needs local network access, check its authorization in Settings. Don't attribute every discovery issue to DNS or add broad policies for the entire network without a reason.

If you need direct access to a private address range, first confirm the actual subnet. Then add the appropriate IP-CIDR or IP-CIDR6 rule before any broad rule that would take precedence. Don't assume an example subnet matches your home network. For a service with both a domain and an IP address, check where the domain resolves; it may point to a remote address while you've only changed the local private-address rule.

Test and record access by known address, access by domain, and device discovery separately. If only discovery fails, investigate its discovery mechanism. If the domain fails but the address works, return to the DNS section. If all local network destinations fail, check network isolation and rule order. Separating these cases prevents a fix for one access method from changing other routes and causing new problems.

Finish with a reproducible record: device type, current network, connection mode, destination type, error text, and comparison results. Hide subscription URLs, authentication fields, and account details before sharing. Once the basic connection works again, return to the user guide for routine checks. For quick answers to common questions, see Troubleshooting. Keep the record so you can resume at the layer you've already verified if the same symptom returns, instead of changing everything again.