Shadowrocket Troubleshooting Guide

1. Establish a repeatable troubleshooting baseline

The first step in troubleshooting is not to change settings immediately, but to identify which layer is failing. When Shadowrocket establishes a connection, it involves the current Wi-Fi or cellular network, the system VPN configuration, the selected server, protocol parameters, rule matching, DNS resolution, and the destination site's response. A failure at any layer may appear simply as “a webpage will not open.” Skipping the layer-by-layer check and repeatedly toggling the switch often turns one clear problem into several changing variables.

Record the symptoms before testing

Before you begin, note four things: whether the issue occurs on Wi-Fi, cellular, or both; whether ordinary webpages work with Shadowrocket off; whether the connection switch stays on; and whether the issue affects all domains, one domain, or a particular type of app. Also record whether Global Routing is set to Config, Proxy, or Direct, and whether you recently updated a subscription, changed a Config, switched servers, or changed DNS. Do not save sensitive server content; record only the action sequence and results.

“Connected” and “transmitting correctly” are not the same thing. A VPN indicator in the status bar only means the system accepted the connection configuration; it does not prove that the server is reachable or that rules are sending requests to the intended policy. Conversely, one website failing does not mean the entire connection is broken. The domain may have matched REJECT, DNS may have returned an error, the destination may have refused the request, or the current rules may have sent it to an unavailable policy group.

Use the fewest variables for four comparisons

1. Turn off Shadowrocket and open two pages that are normally stable on the current network to confirm that the local network can transmit data.
2. Keep the same network and server, temporarily set Global Routing to Proxy, and check whether the issue remains.
3. Keep everything else unchanged, set Global Routing to Direct, and determine whether the system's basic network works while the connection is enabled.
4. Switch only to one server with verified, complete parameters and repeat the test to distinguish a single-server issue from a global configuration issue.

These four results quickly narrow the scope: if Direct works but Proxy fails, focus on the server and protocol parameters; if Proxy works but Config fails, focus on rules, policy names, and DNS; if the connection is off and Direct also fails, focus on the system VPN configuration, On Demand, or other network-extension conflicts; if every state fails, repair the current Wi-Fi or cellular network first. After comparing, restore the original Global Routing setting so a temporary test state does not become the permanent configuration.

Confirm the app source and prerequisites

If you cannot confirm the app source, purchase record, or app identity on the device, first check Official App Verification for the developer Shadow Launch Technology Limited, the official icon, and app ID 932747118. Shadowrocket is a one-time purchase client, but a one-time app purchase does not include a service plan; ongoing connections require your own subscription or server information. This guide explains diagnostics inside the client only and does not assess service providers.

During troubleshooting, avoid repeatedly deleting Config or overwriting all existing data. A safer approach is to note the currently selected server and configuration name, save a separate text copy of important custom rules, and then make one change at a time. If you ultimately need to contact your own service provider, include at least the time of the failure, network type, protocol name, Connectivity Test result, and whether only one server is affected. Do not include passwords, complete subscription URLs, or credentials in ordinary screenshots.

2. Connection switch will not turn on or immediately turns off

When the connection switch in Home will not stay on, the usual causes are an unapproved system VPN configuration, an abnormal network-extension state, repeatedly triggered On Demand rules, or an app configuration the system cannot accept. This differs from a server timeout: a server timeout often leaves the switch on while requests fail; an immediate switch-off points first to the device-side connection setup, not to rule changes.

Check first-time authorization and system status

The first time you enable the connection, the system asks to allow a VPN configuration to be added and may require the device passcode, Touch ID, or Face ID. If you cancel partway through authorization, return to Home and enable it again so the system can show the confirmation step. After authorization, open the VPN-related section of system settings and confirm that a Shadowrocket configuration exists. Menu names may differ between system versions; the important point is that the connection configuration is visible in the system.

If the system settings contain several VPN configurations that are no longer used, first identify which one is actually active. Do not let multiple connection tools repeatedly compete for the system VPN state; disconnect other network extensions before testing Shadowrocket. The system may briefly be in transition after a network change, device unlock, or restored data connection. Waiting ten to twenty seconds before trying again usually produces more useful results than rapidly clicking the switch.

Separate On Demand from manual connection testing

On Demand decides when to connect based on configured network conditions. Overlapping conditions, a changed Wi-Fi name, or rules that contain both connect and disconnect actions can make the switch turn on and then be processed again. When troubleshooting the manual switch, temporarily turn off On Demand in Settings and test only the manual switch in Home. If manual connection works again, system authorization and the basic configuration are likely usable; inspect the On Demand conditions one by one instead of rebuilding the server.

When checking conditions, start with the most specific network condition. For a condition tied to a particular Wi-Fi network, verify that the name matches exactly, including spaces and capitalization. For a condition based on network type, confirm that the device is actually using that network. Enable one condition at a time, lock and unlock the device, then test switching between Wi-Fi and cellular. Combine conditions only after each one works independently, so they do not override one another.

Rebuild the system connection without destroying existing data

If authorization is complete and On Demand is temporarily off but the switch still immediately turns off, quit Shadowrocket normally and open it again. Then toggle Airplane Mode once so the system recreates the network interface. If the problem occurs only on one Wi-Fi network, forget that network and join it again to rule out stale DHCP or local-network state. If the same issue occurs on Wi-Fi and cellular, consider recreating the Shadowrocket VPN configuration in system settings. Before doing so, make sure your server information and Config have reliable copies.

The goal of rebuilding the system connection is only to make the system accept the VPN configuration again; you do not need to delete subscriptions or individual servers. Afterward, keep On Demand off, select one server with clear parameters, set Global Routing to Proxy, and test one ordinary page. If the switch stays on, continue with the “Connected, but no internet access” section. If it still turns off immediately, restart the device and test again, and confirm that the device is not under management restrictions that prevent VPN changes.

Identify device-management and network restrictions

Organization-managed devices may restrict adding or changing VPN configurations, and the system usually displays a notice during authorization. Such restrictions cannot be fixed by changing Shadowrocket protocol parameters; the device administrator must confirm the permitted network policy. Router restrictions on a home network usually do not make the switch turn off immediately. They more often make the server unreachable after connection, so distinguish the two by whether the switch stays on.

Keep the final verification simple: the basic network works, On Demand is off, Global Routing is Proxy, one server is selected, and the connection has had time to settle. If the switch works under these conditions, restore the original settings one at a time and test after each change. This identifies the setting that triggers the switch-off instead of making you face the same issue again after restoring everything at once.

3. Connected, but webpages and apps cannot access the internet

A switch that stays on and a VPN status indicator with no data in webpages or apps is one of the most confusing failure patterns. Possible causes include an unavailable server, incorrect protocol parameters, rules sending all requests to the wrong policy, failed DNS resolution, or incorrect handling of local-network addresses. First determine whether all requests fail or only some, then decide whether to inspect Proxy, Config, or DNS.

Use Direct and Proxy to isolate the failing layer

Keep Shadowrocket on and set Global Routing to Direct. If ordinary pages still do not open, the issue is closer to the system network interface, local network, or connection configuration; switch between Wi-Fi and cellular and confirm that the underlying network can transmit data. If Direct works, switch to Proxy. If Proxy fails for everything, focus on the current server, port, protocol, and authentication parameters. If Proxy works but Config fails, the server is usually not the first suspect; inspect the rules and policy references.

Keep the target pages consistent during testing instead of using a different site each time. Browsers may retain cached content, and some apps retry automatically, so prepare two ordinary HTTPS pages and wait for the connection to stabilize before refreshing after each mode change. If one page works and another fails, record the failed domain and check Data or the connection log to see which rule it matched, rather than describing the result as “the network is intermittent.”

Check policy names and rule order in Config

Config matches rules from top to bottom, and the first matching rule determines the handling policy. PROXY, DIRECT, REJECT, or custom policy names at the end of rules must match policies that actually exist in the current configuration. If an imported Config refers to a policy group that does not exist, requests may not be handled as intended. After replacing a configuration, existing servers do not guarantee that the policy names in the old configuration are still valid.

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

In the example above, a specific domain is sent to PROXY first, local-network addresses connect directly, GEOIP is processed next, and FINAL handles everything else. Arrange the order according to the purpose of your own configuration. If FINAL is placed in the middle, later rules will never be evaluated. If a frequently used domain is mistakenly sent to REJECT, one site will fail immediately. Without a Direct rule for local-network addresses, printers, router admin pages, and other local devices may become unreachable when Shadowrocket is enabled.

Check whether the request was actually sent

When observing a failed request in Data, focus on the domain, connection result, matched rule, and policy—not just total traffic. No record at all may mean the app never sent the request, the request was served from cache, or the system network has not recovered. A domain with failed resolution belongs in the DNS section. A destination IP with a connection timeout points to the server or route. An immediate rejection points to REJECT or the destination's response.

Some apps maintain long-lived connections. After changing Global Routing or the server, an old connection may not be recreated immediately, so fully close and reopen the target app or wait for it to establish a new session. Repeatedly refreshing a browser does not represent every app's behavior. If the browser works but one app does not, check whether it uses a special connection method, has cached old DNS data, or is affected by a rule for its domain or USER-AGENT in Config.

Handle local-network and network-switching boundaries

When switching from Wi-Fi to cellular, existing connections pass through a network-interface change. Shadowrocket normally re-establishes the session, but a request in progress may fail once. Wait for the state to stabilize and test again instead of treating the transition failure as persistent. If recovery fails after every switch, check whether On Demand selects a different mode on the new network or whether Config uses inconsistent DNS for local and cellular networks.

If only local-network devices are unreachable, confirm their address range and use an appropriate IP-CIDR rule to send them to DIRECT. Do not arbitrarily broaden the range, or public addresses that should use another policy may be included. Reload Config after editing and test with a specific local IP. For details on top-to-bottom rule matching and FINAL, read Custom Rules and Priority.

4. Server shows a timeout or Connectivity Test fails

A timeout in the server list usually means the test request did not complete within the time limit, but “timeout” alone does not prove that the server has stopped responding. Failed DNS resolution, an unreachable port, mismatched protocol parameters, packet loss on the current network, server-side restrictions, or a slow test destination can produce similar results. Separate the checks for whether the domain resolves, the port is reachable, the protocol exchange completes, and a real request can transfer data.

Understand the limits of Connectivity Test

Connectivity Test quickly compares whether an entry can complete the specified test, but its number is not a complete measure of real-world use. A high result may reflect a momentary network fluctuation, and a timeout may be temporary packet loss. Test several times at intervals on the same network, look for persistent timeouts, and verify with a real HTTPS page. Do not run high-frequency tests across the entire list; they consume both local-network and server connections and make the results harder to interpret.

If only one entry consistently times out while other entries in the same subscription work, first check that entry's server address, port, and server-side status. If every entry times out, test the basic network and DNS, then switch to another local network. If all entries time out on Wi-Fi but work on cellular, the issue is more likely the current Wi-Fi, router, or upstream path. If both networks behave the same, verify that the imported content is complete and that the service provider has not made a broad change.

Check protocol parameters one by one

When adding a server manually, SERVER, port, password or authentication information, protocol type, and additional options must match the server information you already have. For Shadowsocks, check the encryption method and password. For VMess, VLESS, and Trojan, check the address, port, identity information, TLS, transport method, Host, and other fields. For WireGuard, check the keys, addresses, and route ranges. Hysteria2 also involves its corresponding authentication and transport parameters. Do not apply fields from one protocol to another based on assumptions.

After importing through Scan QR Code or Import from Cloud JSON, open the entry and check that all key fields are present. A QR code being recognized only means its text format can be parsed; it does not mean the server parameters are still valid. If your service provider has changed the server information, use the current content obtained from that provider. Do not randomly enable TLS, change the transport method, or rewrite Host without understanding the fields; these changes often make an almost-correct configuration completely incompatible.

Distinguish latency, packet loss, and throughput

Latency is the time required for one round trip. Packet loss causes retransmissions and pauses. Throughput is jointly affected by server load, path capacity, protocol overhead, and the local network. A low-latency entry is not necessarily faster during sustained transfers, and a high-latency entry is not necessarily unusable. First eliminate persistent timeouts, then compare stability under the same task. See Latency Tests vs. Real-World Experience for a detailed method.

If testing suddenly changes from normal to timeouts across the entire list, recall whether you updated a subscription, switched Config, changed DNS, or changed networks before the change occurred. Return to the last known-good state and reapply changes one at a time. If the address and parameters are correct but timeouts continue across different networks and times, give your service provider the test time, protocol name, and a redacted description of the failure so they can check the server, rather than changing unrelated client rules.

5. Subscribe update fails or imports an empty list

Subscribe reads the server list from a subscription address you already have. An update may fail during address entry, HTTPS access, DNS, the server response, content parsing, or writing the local list. An empty result does not necessarily mean the request failed; the response may contain no entries Shadowrocket can recognize, or an existing filter may hide them. Protect the subscription address during troubleshooting because it may contain private credentials.

Check that the address is complete

Open the relevant item in Subscribe and check the beginning, domain, path, and query portion of the address. Common copy errors include leading or trailing spaces, long URLs truncated by chat tools, or copying only up to the question mark. Do not paste a real address into public testing sites, and do not expose the complete query in screenshots. When contacting your service provider, show only the domain and error message and mask account-identifying parts of the path.

You can first turn off the Shadowrocket connection and access the subscription domain through the current underlying network to determine whether the domain can establish an HTTPS connection. This does not require exposing the content; it only checks local networking and DNS. If it works with the connection off but fails when enabled, check whether Config sends the subscription domain through the wrong policy. You can place a rule near the top that assigns the domain to a working policy and update again, but do not add an unknown domain to a broad rule without a reason.

Distinguish network failure from format failure

A network failure usually appears as a timeout, failed domain resolution, or interrupted connection. A format failure may complete quickly but create no server entries or show an unrecognized-content message. Investigate the former through DNS and the local network; for the latter, confirm that the server returns a current subscription format supported by Shadowrocket. The client being able to open a URL does not mean the returned text contains importable data.

If the same address updated successfully before but suddenly produces an empty result, do not delete the old list first. Record the old entry count and update time, perform one manual update, and observe the result. If the new content is abnormal, keeping the old data helps with further verification. Update again after the server recovers. If the old list has already been overwritten, confirm that the address is still valid before importing again. The subscription is maintained by your own service provider; the client cannot repair empty text, an error page, or invalid credentials returned by the server.

Handle duplicates, renaming, and filters

Adding the same address multiple times can create several Subscribe items, making it seem as though an update did nothing when you are actually viewing a different list. Check the subscription name and address domain, keep the needed item, and update it manually. If notes, sorting, or filters are in use, temporarily clear the filters to confirm whether new entries were written. A changed name can also make a familiar entry appear to have disappeared; check the server address and protocol type instead of relying only on the display name.

A subscription update only synchronizes server information; it does not ensure that every policy name in the current Config still matches the new list. After an update, the server may exist while a custom policy referenced by Config has no usable members, leaving Config unable to access the internet. First use Proxy to select a new entry directly and test it, then fix the policy relationships in Config. This separates a successful subscription write from a rule failure and prevents a rule issue from being mistaken for a subscription issue.

Use a stable update sequence

Update when the basic network is working: first confirm that ordinary pages load with the connection off, then update one Subscribe item. After the update, check whether the entries changed, run Connectivity Test on one entry, and only then enable the existing Config. The automatic update interval should not be so short that it repeatedly interrupts use, and it should not rely on many requests being completed every time the connection starts. If updates fail only on one network, record the network type and continue with the DNS section.

If the error occurs during scanning or file import, Scan QR Code requires complete, clear content, while Import from Cloud JSON requires a structure the app can recognize. Being able to select a file does not mean its contents are valid. Keep the original data before importing; if an error occurs, obtain valid content again from the source instead of guessing missing fields. See the import steps in the User Guide for the complete setup path.

6. Slow speeds, video pauses, or unstable connections

Break speed issues into five layers: the device's local network, server status, transmission path, protocol behavior, and destination site. A single speed-test number cannot represent sustained experience, and one app pausing does not prove that server throughput is insufficient. Effective troubleshooting requires the same device, network, time period, and test task, changing one variable at a time and repeating the test at least two or three times.

Measure the basic network ceiling first

Turn off Shadowrocket, run a basic test on the current Wi-Fi or cellular network, and watch for noticeable fluctuation. If the underlying network is unstable, enabling the connection usually amplifies retransmissions and latency; do not adjust the protocol first. On Wi-Fi, also consider distance from the router, band congestion, high-traffic tasks on other devices, and whether the device is syncing data. Testing again on cellular quickly shows whether the issue belongs only to the current Wi-Fi network.

When testing downloads, webpage loading, and video playback, record both how long the initial response takes and whether sustained transfer remains stable. The first is more affected by DNS, handshakes, and latency; the second is closer to throughput and packet loss. A slow first render followed by stable transfer may indicate a long resolution or handshake path. A fast start followed by repeated pauses points more toward packet loss, server load, or route fluctuation.

Keep other conditions consistent when comparing servers

Choose two servers you already have with complete parameters, set Global Routing temporarily to Proxy, and run the same task on the same network. Do not change DNS or protocol options while switching servers. If only one server remains slow, the issue is more likely that server or its route. If every server is slow while the connection-off test is normal, check how the local network handles the relevant protocol, DNS, and device state. If the connection-off test is also slow, fix the basic network first.

Server location is only one factor affecting the route, so do not judge speed by the name alone. The actual path can be affected by network conditions, server load, and the destination site's access point. A low Connectivity Test result only indicates a faster test round trip; it does not guarantee higher sustained throughput. Prefer entries that remain stable across repeated tests and real tasks with low error rates, rather than simply choosing the smallest number in the list.

Check that the protocol and additional parameters match

Incorrect protocol settings usually cause more than slow speed; they may also cause reconnects, handshake failures, or complete unavailability. If the connection works but is unstable, first confirm that the parameters match the server, then consider network behavior. Do not randomly change the encryption method, TLS, transport method, UDP options, or WireGuard route range in pursuit of speed. When client and server settings do not match, no optimization has a reliable basis.

Some real-time apps depend on UDP, and some networks handle UDP differently from TCP. If webpages work but real-time voice, games, or video calls do not, record the app and network type and verify UDP support within the limits of your server information. Do not make this judgment by blindly changing every option; check each setting against the protocol requirements. If you cannot confirm server capabilities, ask your service provider which parameters the current server supports.

Handle time-of-day patterns and brief fluctuations after switching

If performance is normal during the day but slows at a regular time, compare the basic network and multiple servers during that same period rather than across different times. Congestion often follows a time pattern; only recording the connection-off result lets you distinguish local-access congestion from a server-route change. After switching Wi-Fi, cellular, or servers, old connections may remain active briefly. Reopen the target app so it creates a new session before judging the result.

Restore Config after testing and check whether the speed issue affects only certain domains. If Proxy is normal but Config is slow, the domain may be handled by Direct or DNS may have selected an unsuitable address. Further server testing is not useful at this point; inspect the matched rule and DNS result. For a fuller layered example, read The Four-Layer Method for Locating Slow Speeds.

7. DNS resolution fails, domains will not open, or results are abnormal

DNS converts domain names into IP addresses. DNS problems often appear as a domain that will not open, a possible response when entering the IP directly, intermittent behavior for some domains, or old results that continue briefly after switching networks. Rules can also affect the outcome: Shadowrocket needs the domain or destination address first, then uses rules such as DOMAIN-SUFFIX, GEOIP, and IP-CIDR to choose a policy. Resolution and routing are different layers, but they influence the final behavior together.

First determine whether resolution is the problem

Choose one failing domain and one working domain and test them in the same state. If Data shows failed resolution, no destination IP, or a quick DNS-related error for the failing request, resolution is a likely cause. If a destination IP is present but the connection times out, return to the server or route investigation. Do not conclude solely from a browser message such as “server not found,” because browsers may use one message for different underlying errors.

Compare the results in Direct, Proxy, and Config. If Direct works but Config fails, the difference may come from DNS settings or rules in the configuration. If Proxy works but Direct fails, the local network's DNS may be returning an abnormal response for the domain. If all three modes fail, check the domain itself, the device network, and cached data. Reopen the browser tab after each switch and, if necessary, briefly change networks to prompt a new resolution process.

Check DNS and Host in Config

The General section of a .conf file can contain DNS settings, while the Host section can assign mappings for specific domains. An incorrect Host entry can keep a domain pointed to the wrong address even when external DNS works normally. First search the Host section for the failing domain, then check whether the DNS settings in General come from a trusted and currently reachable source. Do not add multiple resolution options whose purpose you do not understand.

[General]
dns-server = system

[Host]
router.example.com = 192.168.1.1

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

The example uses system as an explanatory setting and assigns an address to an example local-network domain. Real configurations should reflect your own network needs. Host mappings override other results explicitly, so an address change without a corresponding update produces a stable but incorrect result. When troubleshooting an unfamiliar configuration, save a copy first, then temporarily remove Host entries related to the failing domain and test again. For the structure of configuration sections, see General, Rule, Host, and URL Rewrite Explained.

Understand the order of domain and IP rules

DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD match domain names. IP-CIDR, IP-CIDR6, and GEOIP match destination addresses. When a domain rule matches, later IP rules usually do not determine the request. If no domain rule matches, the resolved IP may then be evaluated by GEOIP or IP-CIDR. Poor rule ordering can send a request to an unexpected policy, making the result look like an incorrect DNS response when the actual issue is an unexpected match.

When troubleshooting one domain, temporarily add an exact DOMAIN or suitable DOMAIN-SUFFIX rule near the top and assign it to a verified working policy. If the issue disappears, continue examining the original rule path. If it remains, check DNS and the destination connection. After testing, fold the temporary rule into the formal configuration or remove it so exceptions do not accumulate and override one another.

Clear caches in a controlled order

The system, browser, and apps may all cache DNS data. Refreshing immediately after changing DNS does not necessarily trigger a new lookup. Close the target app, disconnect Shadowrocket, toggle Airplane Mode once, reconnect, and test the same domain again. Do not restart the router, delete Config, change the server, and clear app data at the same time; even if service returns, you will not know why.

If resolution fails only on one Wi-Fi network, check the DNS assigned by the router, custom local-network resolution, and any invalid local-domain mappings. Cellular working provides a comparison but does not prove that Config is correct. If multiple networks return an abnormal result for the same domain, check Host, rules, and the domain itself. Recording the failed domain, matched policy, whether an IP was returned, and the network type is usually enough to locate the issue before, during, or after resolution.

8. Excessive battery use and issues after an App Store update

As a network extension, Shadowrocket continuously processes traffic while connected, so some battery use is normal. The issue to investigate is a sudden, noticeable increase in drain under the same usage conditions, persistent device heat, background traffic that does not decrease, or changed behavior in an existing configuration after an App Store update. Use system battery statistics, traffic activity in Data, network quality, and recent setting changes together rather than judging from one hour's percentage.

Separate client processing from app traffic

System battery statistics may attribute activity handled by the network extension to Shadowrocket, while the traffic may actually come from foreground video, cloud sync, photo uploads, or other background apps. First watch Data to see whether requests continue, then pause high-traffic apps one by one. If traffic and heat drop quickly after stopping a related app, focus on the traffic source instead of changing the protocol immediately.

Weak network signals increase retransmissions and radio activity. Weak cellular coverage, marginal Wi-Fi coverage, or frequent network changes can make the device repeatedly rebuild connections. Retest for a while on stable Wi-Fi using the same server and Config. If the issue disappears on a stable network, battery use is likely tied to the access environment. A server that consistently times out can also trigger retries, so switch first to an entry confirmed to work.

Check On Demand and high-frequency background activity

If On Demand conditions repeatedly become true and false, the connection may be established and closed frequently. Check whether the issue is concentrated after leaving a particular Wi-Fi network, locking and unlocking the device, or switching networks. Temporarily turn off On Demand and connect manually. If battery use and heat decrease, re-enable conditions one at a time. Conditions should be clear and non-conflicting; do not let the same network satisfy both connection and disconnection logic.

Automatic Subscribe updates, Connectivity Test, and many concurrent requests can also create short bursts of activity. Do not set an excessively frequent update interval or continuously test every server in the background. If Config contains complex scripted processing or many rules, retest with a simplified configuration to see whether the issue is tied to a particular processing chain. Keep a copy of the original before simplifying, then restore settings one at a time after verification.

After an update, verify that the configuration is still complete

The App Store is the only source for obtaining and updating Shadowrocket. If something changes after an update, do not delete all data first. Check in order that the intended server is still selected, Subscribe items still exist, Config still points to the configuration you used, Global Routing has not been left in a test mode, and On Demand conditions still match the current network. Interface locations may change; use the labels shown in the current app.

Next run a minimal test sequence: turn off On Demand, set Global Routing to Direct, and confirm the basic network; switch to Proxy and select a server with clear parameters; then restore Config. If Direct and Proxy work but Config fails, inspect configuration compatibility and rules. If Proxy fails, recheck server parameters. If the switch will not stay on, return to Section 2 and check system authorization and the VPN configuration. This sequence prevents one post-update change from being mistaken for total data corruption.

When to restart or recreate the configuration

If the system network extension has not settled correctly after an update, quitting the app normally and restarting the device can clear a temporary state. If the connection still cannot be established, consider recreating the system VPN configuration, but do not delete servers and subscriptions first. After recreating it, test under the simplest conditions and restore On Demand only after success. On a managed device, also confirm that the management policy did not change at the same time.

If battery drain can be reproduced only with a particular protocol, server, or network, hold those three conditions constant and compare before and after results. If every configuration remains abnormal across different networks, record the system battery-statistics period, Data activity, and reproduction steps, then wait for subsequent App Store update information. This site does not publish version numbers or release dates; see the App Store page for actual change details.

9. iPad-specific checks: split view, network switching, and restoring purchases

Shadowrocket on iPad uses the same core concepts as on iPhone, but landscape columns, multitasking, keyboard input, greater reliance on Wi-Fi, and background state can produce different symptoms. Do not copy iPhone tap locations blindly; use the current landscape or portrait layout to locate Home, Config, Settings, Data, and server details. Compatibility and system requirements are always as listed on the App Store page.

Confirm the purchase and app identity first

If Shadowrocket was purchased with the same Apple ID, find it in the iPad App Store purchase history and download it again. If the store status is unexpected, first verify the signed-in account, storefront region, developer Shadow Launch Technology Limited, and app ID 932747118. See iPad Acquisition Guide and Restore Purchases Guide for details.

Shadowrocket is a one-time purchase client, but a one-time app purchase does not include a service plan. Downloading the app again on iPad does not create server information automatically; you still need your own subscription or server information. If Config already exists on iPhone, migrate it using an import method supported by the app and check sensitive fields. Do not rely on a screenshot to re-enter everything, because long identity fields and protocol options are easy to omit.

Understand what landscape columns can make hard to find

In landscape orientation, the list and details may appear at the same time, with the selected item's content shown in the other column. If you tap Config or a server list and think nothing opened, check whether the details on the right have changed. In portrait orientation, the same content may open one level at a time, so the back path differs. If the layout does not update immediately after rotating, wait for it to reflow or close and reopen the app; deleting the configuration is unnecessary.

An external keyboard and trackpad do not change rule logic, but focus may remain in a search box or edit field, making scrolling and shortcuts behave unexpectedly. After editing server parameters, finish saving and return to the list, then confirm that the intended entry remains selected. The iPad can show more fields at once, which also makes it easier to mistake an old entry in the details column for the current one. Before testing, return to Home and verify the selected server name.

Handle Split View and background restoration

In Split View or another multitasking state, the app window changes size while the system continues managing the network extension. Shrinking the window does not directly disconnect it, but the target app entering the background, switching from Wi-Fi, or system resource reclamation may require an existing session to be rebuilt. If an app cannot access the internet in a split view, test both apps full-screen first, then restore the split view. If full-screen works but split view does not, focus on the target app's background and session restoration rather than changing Shadowrocket rules first.

After the iPad has been locked for a long time, the status bar may show an old state briefly before network recovery completes. Wait for the Wi-Fi icon and VPN status to stabilize before testing. If On Demand is enabled, check whether it connects under the current Wi-Fi condition. If it does not, temporarily turn off On Demand and enable the connection manually to distinguish condition evaluation from the connection itself. Frequent cover-induced lock and unlock cycles can also expose poorly designed conditions.

Check common iPad Wi-Fi scenarios

iPad is often used on one Wi-Fi network for long periods, so DHCP address changes, router restarts, local DNS caching, and local-device access issues can accumulate. Test the basic network with Shadowrocket off, use Direct to check the system connection, and finally use Proxy to check the server. If only a printer, file device, or router page is unreachable, confirm that the local IP-CIDR rule sends it to DIRECT rather than replacing the remote server.

On public Wi-Fi that requires a web login, turn off the connection first, complete the network's login process, and confirm that ordinary pages work before enabling Shadowrocket. Until the login page is completed, server tests commonly time out across the board, which can be mistaken for a subscription or protocol issue. If you move from one Wi-Fi network to another with the same name, On Demand may still process the name identically even though the environments differ; retest using both address and reachability.

Verify each layer after migrating Config

After importing Config from another Apple device, check [General], [Rule], [Host], and URL Rewrite against the iPad's current network. Fixed local-network addresses, DNS settings tied to a particular Wi-Fi network, or Host mappings that only fit the original network can behave differently on iPad. Do not enable every additional feature at once: verify the server first, then the basic rules, and finally restore Host and rewrite entries.

The full verification order remains Direct, Proxy, Config. If the browser works on iPad but one app in Split View does not, close and reopen that app so it creates a new connection. If every app fails, check whether Data shows requests and matched rules. If the connection switch turns off, check system authorization. If only domains fail, check DNS. For iPad redownload and layout differences, continue with iPad Redownload and Landscape Split View.

If this guide does not locate the issue, prepare reproducible steps: device type, network type, Global Routing, protocol name, whether only one server is affected, Connectivity Test results, matched rules, and the time the error occurred. When contacting your own service provider, provide only redacted information; do not share the complete subscription address, password, or identity fields.