Shadowrocket Troubleshooting

Connection toggle won’t turn on: Check system authorization first

If the toggle won’t stay on, first distinguish between a system tunnel that fails to start and a tunnel that starts but cannot access the internet. The first may look like the toggle immediately switches off, authorization prompts keep appearing, or the VPN status in Settings never changes. The second usually stays connected but fails to load content. Watch Home through one complete connection attempt. Avoid toggling rapidly, which can make a normal startup look unresponsive.

Check first-time authorization and local configuration

When connecting for the first time, the system may ask permission to add a VPN configuration and request your device passcode or other system authentication. Continue only if you initiated the action in Shadowrocket. If you dismissed the prompt, return to the app and try connecting again. The in-app toggle and system authorization are separate steps; importing a server does not mean the device has allowed a tunnel to be created. After authorization, check whether the system and app show the same status.

Open Settings and check for a VPN configuration associated with Shadowrocket. The system menu name may vary by OS version, so use Settings search rather than relying on a fixed path. If several network configurations are present, note their names and purposes, then temporarily stop other connections that route device traffic. Don’t delete them in bulk. Some configurations on work- or school-managed devices may be restored automatically by management policies.

On Home, check that a valid server is selected. Look for the selection indicator rather than just checking whether the list contains entries. Open the server and confirm that Address, Port, and protocol details are saved correctly. If you edited it and exited immediately, reopen it to verify that the changes stuck. Missing fields or an invalid configuration can cause startup to fail. Test whether the server can actually communicate in the next stage; a toggle that switches off does not by itself prove the remote server is at fault.

Check On Demand and system restrictions

If the connection turns back on after you manually disconnect, check On Demand first. It can connect automatically when configured conditions are met, which may make the toggle seem unresponsive when automatic and manual controls are both in use. Note the current conditions, temporarily turn off On Demand, then test a manual connection and disconnection. Restore automatic conditions one at a time only after manual control is stable. Don’t change On Demand rules and switch servers at the same time.

If the button is unavailable or the authorization prompt never appears, check whether the device is managed by an organization or restricted from changing VPN settings. Ask the device administrator about management restrictions; reinstalling the app repeatedly usually won’t change a policy. On a personal device, close network-intensive tasks, restart normally, and test again. A restart can clear a temporary state, but it won’t fix server settings or network conditions.

On Wi-Fi that requires a sign-in page, disconnect the tunnel and complete network authentication before connecting. Otherwise, the device may be connected to Wi-Fi while the sign-in page still blocks internet access. Confirm basic connectivity with a regular webpage instead of relying on the Wi-Fi icon. If the toggle stays on using another network you already know works, investigate the original network’s access requirements rather than immediately clearing app data.

When to recreate the VPN configuration

Recreate the VPN configuration only if its authorization state appears abnormal, the system and app statuses remain out of sync, and the checks above have not helped. Back up your server details and Config first. Disconnect and turn off On Demand, then remove only the system VPN entry you have confirmed belongs to Shadowrocket. Return to the app and request authorization again. Removing a system VPN entry is different from deleting an in-app server; read the confirmation carefully to avoid losing data you still need.

After recreating the configuration, test with as few variables as possible: one verified server, a manual connection, and On Demand temporarily off. If it still disconnects immediately, save the error message, steps to reproduce it, and the system connection status. If the toggle stays on but you still can’t access the internet, continue to the next section. Don’t start with a network settings reset. It affects other saved networks and may erase the conditions you need for comparison.

Connected but no internet: Test the server and rules separately

A connected status only shows that the device started a network tunnel; it doesn’t prove that every request reached its destination. Choose one website you know works as a baseline, then test the destination that fails. Note whether all apps fail, just one website fails, or only some resources fail to load. A generic browser error can cover DNS resolution, connection, or certificate problems. Keep the original message rather than assuming the server is unavailable.

Use Global Routing for a comparison test

Note the current Global Routing mode before testing, and understand what each option does. Config applies the rules in the current configuration. Proxy sends eligible requests through the proxy path for comparison. Direct provides a direct-connection comparison. These options aren’t ranked by strength. Restore the original mode after testing; a temporary switch to Proxy does not prove that the rules have been fixed.

If Direct works but Proxy fails, check the default server and protocol settings first. If Proxy works but Config fails, focus on rule matching and policy routing. If all three fail, disconnect completely and test the underlying network before continuing to the DNS section. Direct mode may still be affected by network handling and DNS settings, so record switching to Direct and disconnecting the tunnel as separate tests.

Follow the rule order to find where requests are routed

In Config, confirm which file is active; don’t just inspect a similarly named file. Rules are generally evaluated in order, so an earlier match can prevent later rules from being considered. Check whether a broad DOMAIN-KEYWORD rule, domain suffix rule, or IP rule is matching the target too early. Confirm that the selected policy exists and points to the intended server. A rule can be written correctly and still fail if its policy is unavailable.

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

This example only illustrates matching and fallback behavior; don’t replace your existing file with it. DOMAIN-SUFFIX applies to the example domain and its subdomains. DOMAIN-KEYWORD is broader, so consider unintended matches before changing it. FINAL handles requests that didn’t match earlier rules. Adapt the example domain to your destination, and check which server PROXY uses. If you use a custom policy name, verify that its name matches every reference; a spelling mismatch isn’t a network problem.

If text loads but images, sign-in, or video fail, don’t check only the domain in the address bar. A page may load resources from multiple domains or redirect during authentication. Reproduce the issue once and review available request records in the app. Compare the destinations and policies for successful and failed requests. Change only rules supported by evidence. Moving an overly broad keyword rule to the top because one resource failed can hide the real cause and affect more traffic than necessary.

Separate app issues from destination service issues

If only one app is affected, try its website in a browser as a comparison. A working website doesn’t guarantee that the app’s internal APIs work, but it can narrow the problem. Check whether the app has an existing connection, then switch policies, fully quit and reopen the app, and retry the request. Existing connections may continue using their original path; changing a rule does not force every existing connection to select a new policy immediately.

If the failure is an account restriction, account notice, or content permission issue, distinguish the destination service’s response from a network timeout. A successful connection cannot change your account status on the service. Restore the original configuration, then use the rules for specific websites guide to organize any exceptions you need. This round of rule troubleshooting is complete only when the target request consistently uses the intended policy and still succeeds after reconnecting.

Server timeout: Check reachability, then protocol authentication

A server timeout can have several causes. Address resolution failure, an unreachable port, mismatched protocol fields, and failed TLS verification can all eventually produce a timeout or error. First identify which test the app ran, then check what happens during an actual connection. A latency test returning a result only shows that the stages involved in that test responded; it doesn’t guarantee successful authentication, destination requests, or sustained transfers.

First, check that the server details match

Open the selected entry on Home and compare Type, Address, Port, and authentication fields against your original information. Addresses can accidentally include leading or trailing spaces, a full link can be pasted into Address, or a subscription URL can be mistaken for an individual server address. Use the specified port; don’t guess based on the protocol name. If you imported the entry by scanning, open it afterward and verify the fields. A successful scan only means the content was recognized.

Check whether the details are still valid and whether the service has changed its endpoint or authentication requirements. You can refresh your existing subscription and compare the old and new entries. If you saved any custom parameters manually, don’t assume an update preserved them or try to recreate them from memory. Comparing the original details, what the app actually saved, and the currently selected entry is more useful than repeatedly trying different parameters.

Test on the current network, then repeat the same test on another network you already know works. If both fail, focus on the server status and settings. If only one fails, investigate that network’s port, transport, or access requirements. This comparison can’t prove that either side is faulty, but it can help distinguish a local network issue from a configuration problem. Keep the server and test method the same for a meaningful comparison.

Check the key fields for each protocol

In TLS configurations, the connection address and certificate name may serve different purposes. Address identifies the connection endpoint; Peer/SNI may be used for server-name and certificate handling. If your original details specify a name, use it as provided instead of replacing every field with the same IP address. A device date and time that are significantly wrong may also affect certificate validity checks. Check the time and name first, then investigate further based on the error message.

Don’t leave Allow Insecure enabled to mask a certificate error. This option changes verification requirements, and even a successful short-term connection doesn’t prove the server is configured correctly. Instead, check the hostname, certificate name, and TLS requirements provided by the server, then restore certificate verification. If your details are incomplete, ask your own service provider to confirm the required fields. Examples in this manual can’t replace your actual connection parameters.

Finish by testing an actual request

After running Connectivity Test, open a known working website and check whether its content loads. If the test returns a result but the page fails, continue with DNS and rules. If only large requests fail, check transport and path issues in the speed section. Don’t compare different test readings as though they measure the same thing: tests may use different methods, destinations, and timeout settings, so different values don’t necessarily mean the same connection changed performance.

For WireGuard, also check Allowed IPs and the local address range; these aren’t ordinary rules for entering destination websites. Check handshake status separately from website access, as an incorrect route range can make some destinations unreachable. For a field-by-field explanation, see WireGuard configuration fields. Don’t copy addresses or keys that aren’t yours.

Keep a troubleshooting record of the protocol, test network, failure stage, and whether every server fails. If one entry fails while other existing entries work, you can temporarily use a verified configuration for comparison and ask your own service provider to check the failing entry. Hide authentication values and full server addresses when sharing records. Field names and the error category are usually enough; there’s no need to publish complete connection details.

Subscription update failed: Separate the request, content, and import results

A Subscribe update has several stages: the app reads the URL, sends a network request, receives a response, parses the content, and saves the entries locally. Failure can occur at any stage. Record the original message and when it appears; don’t delete the existing group as soon as an update fails. Previously saved servers may still work. Deleting the group removes useful comparison data and may not fix an error returned by the source.

Confirm the link is complete and from the right source

Copy the subscription URL again from your own service provider, rather than using text forwarded multiple times that may have been truncated. Check for line breaks, spaces, or trailing punctuation, especially in query parameters. Authentication data in a URL is sensitive; don’t include it in public screenshots, online conversion tools, or comments. If you only need to check the field format, use an example URL instead of your real one. Don’t expose credentials more widely just to troubleshoot.

Make sure the URL points to subscription content, not an account management page, payment history, or a webpage that requires sign-in. A page opening in a browser doesn’t mean it returns server details the app can parse. If the response is actually a login prompt, error message, or maintenance page, the app usually can’t import it as a server list. Check the URL type with your own source rather than repeatedly changing protocol fields.

Treat the first import and routine updates as separate cases. For a first-time failure, check the URL, response format, and network. If it worked before but now fails, also check whether the subscription URL changed, authentication expired, or the server changed its content. A local group name alone doesn’t confirm that the URL is unchanged; the name can stay the same while the saved link changes. Hide the full URL before recording or sharing it.

Run a repeatable update test

Manually update once on the current network and wait for a clear result before trying again. Repeated taps can create overlapping requests or trigger rate limits. If the app says the request is temporarily unavailable, keep the existing entry and try once more later. Before switching networks, note whether you’re connected and which Global Routing mode is active. Otherwise, a successful update may only mean the request took a different path, not that the URL content was fixed.

If an existing connection may affect the subscription request, disconnect and retry while the underlying network is available. You can also compare with a connection you’ve already verified works. The request path may depend on relevant app settings, so use actual records rather than assuming all updates use the same path. Watch for a circular dependency: your only server has stopped working, but you need that server to retrieve updated content.

If the request succeeds but the list is empty, check whether the response contains valid servers and whether the app supports its format. If only some entries appear, compare the protocols and fields of the missing entries; don’t immediately overwrite your existing data. If your own source provides individual server details, add one manually and test it. This helps distinguish an unavailable server from content that wasn’t parsed correctly in bulk.

After updating, check the selection and local edits

After a subscription update, check the default server on Home again. If the previously selected entry was replaced, renamed, or removed, the current selection may no longer point to the same endpoint. Open the updated entry and review its key fields, then run Connectivity Test and try an actual request. A normal-looking list only shows that some content was imported; it doesn’t prove that authentication works, the server is reachable, or the current rules will select those entries.

Distinguish server details in a subscription from rule files in Config. Refreshing Subscribe does not necessarily fix the order of rules in Config, and reloading Config can’t restore an expired subscription. If you edited a subscription entry manually, an update may replace or reconcile those edits with the source content. Before maintaining custom settings, check where they’re saved and how updates affect them instead of filling them in from memory after every failure.

To recover, make changes in small, verifiable steps: keep the existing group, check the new URL’s content and one server, then remove duplicates only after everything is confirmed. Before deleting an entry, check whether any rules or policies depend on its name. For basic import steps, return to Getting Started. For the difference between an app purchase and existing service details, see the FAQ. This page explains how to handle details you already have and does not recommend subscription sources.

Slow speeds and frequent stalls: Pinpoint when they happen

Describe what’s slow: no response after tapping, slow images after the first screen appears, interrupted playback, or large transfers that stop partway through. Each symptom points to a different set of checks. A low latency reading doesn’t guarantee high sustained throughput, and one slow page may simply be taking time to respond. Repeat the test with a fixed destination before deciding whether the issue affects all requests.

Separate DNS lookup, connection setup, and transfer

The first visit being slow while the next is faster may be due to DNS caching, connection reuse, or destination-side caching; it doesn’t prove proxy speed. Test ordinary pages on two different services, noting how the first and second visits behave. Keep the network and server the same, and record whether you reconnected between tests. Clear comparison conditions make it easier to tell whether the delay occurred before connection or after content started transferring.

If a page title appears quickly but images or media keep loading, check whether the resources use different policies. A page’s main domain and its resource domains may take different paths. Adding a rule for only the main domain doesn’t prove that all content goes through the proxy. Check the failed resource’s route first, then adjust the smallest relevant rule. Compare sustained server and network performance only after you’ve confirmed the path is consistent.

Pause photo syncing, large uploads, and other tasks that continuously use the network. When an upload saturates the connection, ordinary webpages can also feel slow; repeatedly switching servers won’t resolve competition on the device. Test with one device and one task, then resume other activity one item at a time. Don’t run multiple performance tests at once: they compete for bandwidth and make results harder to interpret.

Check network changes and transport conditions

A strong Wi-Fi signal doesn’t guarantee a stable external connection. Keep the device in the same place, test the current network, then compare with another network you already know works. If stalling happens only in a particular location or on one Wi-Fi network, check its access quality, authentication status, and load from other devices. Moving between Wi-Fi and cellular can interrupt and reestablish existing connections, so record stationary and mobile tests separately.

If only some protocols fail on a particular network, check the transport conditions they require. For protocols using UDP, confirm that the current network actually supports it. A response from another type of test doesn’t prove that all transports work. Use your own complete, verified configuration for comparison; don’t guess ports, authentication, or transport settings just for a test. When comparing different protocols on the same network, note whether they use different servers.

If small requests work but large ones repeatedly stall, investigate path and MTU-related issues after confirming the address, rules, DNS, and authentication. MTU is not a universal speed setting: too small can add overhead, while too large can expose fragmentation or packet-handling issues on some paths. Only if your protocol and settings explicitly support it, record the original value and test one change at a time based on your configuration details. Don’t adjust multiple transport fields at once.

Use a focused test to reach a practical conclusion

When comparing servers, keep the network, destination, request type, and approximate test time consistent. Servers in different regions or using different service endpoints may not be directly comparable. The goal isn’t to find the smallest-looking number; it’s to see whether an existing configuration reliably completes your actual request. Frequent switching can disrupt connection reuse and make it harder to determine whether the original stalling issue persists.

If only one destination is slow while others work under the same conditions, check the destination service and its resource paths first. If all destinations are slow, revisit the local network and selected server. Existing services may have their own status, usage, or concurrency limits; check your service details instead of inferring them from the app. The app purchase and server-side transport conditions are separate matters. A valid purchase doesn’t guarantee that the remote path is always the same.

When testing is complete, restore temporary modes, test rules, and transport settings. Keep only changes supported by evidence. A useful record explains the conditions under which it was slow, what comparison restored service, and which setting changed. A test result without the network and destination is difficult to reproduce. If you haven’t yet confirmed that the first connection works, read First connection testing before tuning performance.

DNS issues: Check resolution results and request paths first

DNS resolves domain names to addresses used for later connections. A failed domain request may involve DNS, but certificate errors, connection refusals, and destination response issues can also happen after resolution succeeds. Check the error and available records for a resolution failure before changing DNS. An IP responding does not prove that the domain resolves incorrectly: direct IP access may omit the hostname or reach a different certificate or service.

Check the underlying network and configuration source

Disconnect and test an ordinary domain first, then test the same destination with your current configuration. If the underlying network can’t resolve it, check Wi-Fi authentication, network access, and DNS settings already configured on the system. If it works on the underlying network but fails when connected, focus on the active Config and DNS settings in the app. Note which settings came from a configuration file and which were added manually; one setting may be affected by another source.

Check that the resolver address format matches the selected method. An ordinary server address and an encrypted resolver endpoint aren’t interchangeable strings. If a setting requires a complete endpoint, a domain alone may omit a required path. Conversely, a full URL may fail in a field that accepts only an address. Follow the current interface guidance and your own configuration details rather than combining fragments from unrelated examples.

Encrypted DNS still needs a network connection. If its endpoint uses a domain, the device also needs a way to resolve that endpoint’s address first. A dependency can arise if the DNS request relies on a proxy whose server address itself depends on the same DNS path that isn’t available yet. Identify what must be resolved first, where the request goes, and whether that path is already available. Adding more resolver addresses won’t solve a dependency by itself.

Understand the relationship between domain and IP rules

Domain rules match a destination name; address rules match an IP range, which may require resolving the name first. When checking rules, consider the request’s available information, the resolution result, and the final policy. Adding GEOIP somewhere in the file doesn’t replace all domain rules. Rule order still matters: an earlier match can prevent later rules from handling the same request.

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

This snippet only illustrates the order of domain rules, geographic IP rules, and a fallback; it isn’t a complete configuration for every network. GEOIP depends on the data in use and the resolved address; it doesn’t identify website content or account ownership. Save the original file before editing, and check which server PROXY uses. If only one domain needs an exception, prefer a narrowly scoped rule rather than changing the fallback for all requests.

A domain may resolve to multiple addresses, including both IPv4 and IPv6. If only some networks or destinations fail, check whether the current network can actually reach that address family and which address the failed connection used. Disabling IPv6 isn’t a universal fix. Use it only as a recorded, temporary comparison, then decide whether to keep the original setting based on the network’s actual support.

Clear cached results, then test a new request

After changing DNS settings, old cached results and existing connections may still affect the test. Use the cache-clearing option provided by the app, if available. If there isn’t one, stop the connection, reconnect, and fully quit and reopen the destination app. Don’t clear all app data just to reset one domain. Trigger the failed request again for each test; an old error page still on screen isn’t a new result.

If only some page resources fail, check the main domain, resource domains, and authentication domains separately. They may use different resolution results and rules, so fixing one domain doesn’t guarantee that the whole page works. Apps may use their own resolution methods, so their traffic may behave differently from ordinary system requests. Use observable records to investigate; changing one DNS setting cannot be guaranteed to alter how every app resolves domains.

This section is complete when the target domain returns a usable result, the subsequent connection follows the intended path, and it still works after reconnecting. If resolution succeeds but the handshake fails, return to the protocol section. If only Config fails, return to the rules section. Record the final DNS method and why you chose it, so you can tell whether a later issue comes from a network change or a configuration that reintroduced a dependency.

Battery drain and issues after an update: Restore a comparable baseline

Battery and update troubleshooting both depend on comparable before-and-after conditions. Record what changed before the issue started: an app update, system update, subscription refresh, Config edit, network change, or new automatic connection condition. Several changes on the same day don’t prove that any one caused the problem. Preserve the current state and make a backup before deleting the app; removal may lose local data and eliminate the conditions needed for comparison.

Distinguish background traffic from connection retries

Check the relevant time period in system battery usage, and note screen use, media playback, file syncing, and network changes. A VPN app handles device network traffic, so its battery statistics don’t necessarily mean the app initiated all that traffic. Other apps may keep network activity going through uploads and downloads. Pause high-traffic tasks and compare similar screen and network conditions; don’t draw conclusions from two entirely different usage scenarios.

Repeated timeouts and automatic reconnections can also increase network activity. Check whether only one server is failing or the device is repeatedly switching networks in a weak-signal area. Switch to a configuration you already have and have verified, then see whether retries decrease. If battery behavior improves once the connection is stable, investigate the failing entry rather than keeping it and trying to mask the issue with other toggles. A timeline of retries and network changes is more useful than battery level alone.

Temporarily turn off On Demand and check whether manual connections and disconnections stay stable. Automatic conditions that trigger too often can cause repeated connecting, disconnecting, and retrying. Restore conditions one at a time after troubleshooting. Stop persistent diagnostic logging or repeated manual tests once you have the information you need; diagnostics themselves add activity, so don’t create a continuous load while assessing idle usage.

After an update, check which settings are still in place

After updating the app, check the selected item on Home, Global Routing, the active Config, and On Demand conditions before reconnecting. Entries being present doesn’t mean the default selection stayed the same, and an unchanged filename doesn’t prove the same file is active. Restore the baseline from your pre-update record, then test one verified server and an ordinary destination. If that works, restore custom rules and other settings one at a time instead of blaming the update for every issue.

If you also updated the subscription, check whether the server details changed. If the system was updated at the same time, recheck VPN authorization and other network configurations. Timing can offer a clue, but it isn’t a substitute for a comparison. Some issues happen because an existing connection wasn’t restarted; disconnecting normally, reconnecting, and reopening the destination app can confirm this. If the system and app statuses remain out of sync, follow the connection toggle section instead of immediately rebuilding every configuration.

Updates are available only through the App Store. To verify the app, check the developer, Shadow Launch Technology Limited, the official icon, and app ID 932747118. System requirements are as listed on the App Store page. Before reinstalling, read Restore a previous purchase. A purchase record restores your eligibility to get the app; it does not mean your local servers, rule files, and custom settings are fully backed up.

Backups, recovery, and diagnostic records

When backing up, check Config files, server details, and any other settings you need to keep. Exporting a single rules file does not save everything. Open each backup to confirm it’s readable, and make sure you know what each file contains and how to restore it. Store files containing authentication details in a secure location, not a public sharing folder. For iCloud, confirm that syncing has actually finished before deleting anything from the original device.

If you need to reinstall, back up your data and confirm the purchasing account first. Then restore the app according to the App Store’s purchase and device eligibility information. Start by importing only the minimum required data and verify the connection before restoring other configurations. If an issue returns after restoring a particular file, focus on that file and its dependencies. For migration steps, see Config backup and restoring on a new device.

If the issue is still reproducible, record the steps, current network, failure stage, whether only one protocol is affected, and which comparisons succeeded. Hide subscription links, authentication values, and personal request details before sharing. Battery records should describe actual usage; update reports should mention other settings that changed. Once service is restored, turn off temporary diagnostics and keep a verified backup so you have a baseline for the next change.

iPad troubleshooting: Separate account, network, and configuration differences

If Shadowrocket works on iPhone but not iPad, don’t assume the device model is the cause. The devices may use different networks, purchasing accounts, default servers, Config files, or DNS settings. First identify what you’re comparing: purchase eligibility, opening the app, establishing a connection, or actual access. Compare one layer at a time and use the working device as a reference. Don’t overwrite configuration unique to the other device without a backup.

Check purchase and authorization status first

The App Store is also the only way to get Shadowrocket on iPad. If you’ve already purchased it, check whether the Apple ID currently used for App Store purchases matches the purchase record, then review the status in purchased items. The iCloud account signed in on the device and the account used for App Store purchases may differ; rely on the actual purchase record. Check system requirements, purchase eligibility, and Family Sharing conditions on the App Store page rather than assuming eligibility because another device can install it.

After confirming that you can get the app, check VPN authorization on the iPad itself. Authorization on another device does not grant permission to add a configuration here. Watch for the system prompt on the first connection attempt and complete device authentication. On a managed iPad, also check whether organizational policies allow the network configuration. If the toggle won’t stay on, follow the first section; restoring a purchase does not replace system authorization, and an authorization issue is not a subscription format problem.

The app layout may change with window size, orientation, and system display settings. When checking Home, Config, or Settings, confirm which screen is open and which item is selected rather than assuming buttons are in the same place as on another device. After editing, return to the list and reopen the entry to confirm the changes were saved. In Split View, make sure the edit was actually submitted and isn’t still waiting for confirmation.

Set up a minimal comparison between devices

First connect both devices to the same working Wi-Fi network, then check the same existing server, Global Routing mode, and destination website. Don’t compare connection results when one device is on cellular and the other is on Wi-Fi. Even with the same network name, check separately for a sign-in page. If the iPad’s underlying network still fails when disconnected, restore network access before troubleshooting the app.

If the iPad uses a personal hotspot, also check the hotspot device’s network and connection status, then test the iPad’s basic access with an ordinary webpage. A hotspot provides network access; it doesn’t mean the iPad inherits the source device’s rules or connection settings. Use the connection and request records on the iPad itself. The source device’s status icon can’t tell you which path the iPad’s traffic is using.

Compare Type, Address, Port, authentication, and TLS-related fields one by one, then compare the active Config and DNS. Syncing and connecting successfully are separate issues: a file appearing on both devices doesn’t prove that both have the same file active. If server names match but the contents differ, compare the fields. If the contents match but behavior differs, check system network settings, address-family reachability, and current access conditions.

Check backgrounding, sleep, and reconnection

If the issue happens only after the screen locks or the device wakes, record the Wi-Fi status before and after, any network changes, and whether On Demand triggered. First reproduce it with a manual connection on a fixed network, then add the lock and wake steps. Don’t assume the tunnel stopped just because the foreground app doesn’t continuously show status changes; consider actual requests and system status together. Conversely, a system status that still shows a connection doesn’t guarantee every remote connection from before sleep is still working.

If the first request fails after waking but works after reconnecting, check whether an existing connection failed to reestablish or the network changed. Fully reopen the destination app, then disconnect and reconnect, recording which step restores access. Adjust On Demand only after the manual process is stable. Don’t rely on continuous automatic reconnection as a permanent workaround; it may hide a weak signal, expired authentication, or a persistently failing server.

After migrating a configuration, rerun Connectivity Test and verify access to an actual webpage, then test the apps you use regularly. Once the iPad is stable, keep a verified backup. There’s no need to force identical settings across every device; different networks may justify different, evidence-based changes. To check how to get the app, see Getting Shadowrocket on iPad. To set up a connection from scratch, return to Getting Started and follow the main steps.