iOS leaves one slot for personal VPN.

When another VPN app is connected, iOS usually will not hand traffic to Shadowrocket. This app’s switch can still be on while bytes never enter this extension, and both Data counters stay still. When isolating a failure, look first at which VPN is active in system Settings — not at swapping records. Treating “the switch is on” as “bytes entered this app” sends you to the wrong next step: editing FINAL, refreshing a container, doubting a UUID, while the system is handing traffic to another extension.

Some system processes and some apps detect “VPN is connected” or use their own path. The client cannot force every binary into the virtual interface, and cannot change other apps. The pattern: Data is rising, one App still fails. If other clients work under Proxy and only this one fails, that App is likely refusing the tunnel; the record is not unavailable. On consumer devices a personal VPN is usually whole-device, not “proxy only this App.” There is no general switch in Shadowrocket that lets the system split by app icon. Splitting by domain is the rule engine; see Rules.

Low Power Mode, turning off Background App Refresh, Airplane Mode, and Wi-Fi / cellular handoff all pause or exit the extension. Afterward you flip the switch again, or wait for the system to bring it up on demand. Reinstalling the app does not fix this; a reinstall cannot restore a session the system already reclaimed. On managed devices MDM can forbid personal VPN. Screen Time can restrict VPN too. In both cases, no amount of flipping the in-app switch will make the system create the extension. Denying the permission prompt, or later deleting the Shadowrocket VPN configuration in Settings, has the same effect: the switch has nothing to attach to.

Refreshing a container or rules in the background depends on the system still allowing this app to run in the background. After Background App Refresh is off, a fetch happens only when you bring the app to the foreground. Low Power Mode tightens this further. Before you treat “the list did not update” as a dead URL, see whether the system let it run. Hotels, airports, and campus networks often show a login page first. Until that page is finished, the device has no real outbound. With the switch on and policy Proxy, the login page may not open, auth never completes, and the tunnel has no network to forward. Use Direct, or turn the switch off, let the system open the login page, then start the tunnel.

If system time is not set automatically, TLS fails in batches. The switch looks wrong on every record, and probes fail with it. That is not about one row; turn on Set Automatically first. When the destination is IPv6 and rules only list IPv4 CIDRs, the request falls to FINAL and looks like a rule that sometimes works; see DNS. These sit on top of “the switch is on” and are easy to collapse into “the node is bad.”

Routing, browsing, and calling APIs do not depend on HTTPS decryption. Rules look at hostname and destination address; they do not need to open encrypted content. Rewrite that only touches a URL or a cleartext header does not always need decryption either. You need it only to inspect or rewrite HTTPS bodies, and it installs a user profile. That weakens the device default of trusting only system roots. Remove the profile when you are done. Do not leave a decryption certificate on a daily driver, or on a device that holds banking and passwords. If the certificate is missing, expired, or untrusted, hosts on the decrypt list fail handshake and look like a dead record. Turn decryption off and isolate: if other visits recover, the problem is the certificate, not the exit. Details in System and Rewrite.

The app cannot extend a URL’s lifetime, pay a server bill, turn a failed handshake into a working record, or override a carrier or a site’s own access policy. Connection quality is jointly decided by the local network, the remote behind that record, and the far-end service. There is no official Android, Windows, or macOS client. Software on other systems that can fill the same protocol fields is still not Shadowrocket, and a rule file is not guaranteed to open there. This site does not host those installers.

Configuration lives on the device, optionally synced to your own iCloud. There is no account system; the developer does not hold your list. Export files contain credentials; treat them as secrets. The VPN configuration prompt on first connect is not a login. The one-time purchase covers the client license; see Store and Config. Treating a platform limit as “a hidden switch you missed” produces a lot of useless edits on records and rules.

A taken slot, an extension the system tore down, and an App that refuses the tunnel share one trait: you will not find a matching “bad row” in Shadowrocket’s list. Swapping records, swapping rules, or reinstalling will not turn iOS’s one VPN slot into two, and will not make a process that bypasses the virtual interface change its mind. What you can do: see which VPN is active in system Settings, see whether Background App Refresh and Low Power Mode reclaimed the extension, and try the same host in another client under Proxy to confirm a single-app behavior. Only after those three, look at record fields and rule order. The manual puts objects in Objects and limits in System; do not merge the two chapters into one “full sweep” that changes everything at once.