Connected does not mean rules apply.

iOS asks to add a VPN configuration. After you allow it, Shadowrocket appears in Settings under VPN. That is the system authorizing a personal VPN, not a login to a node provider, and not an app account — there is no account system. If you deny it, the virtual interface is never created and the switch has nothing to attach to. Later, deleting that configuration in Settings, or blocking VPN via Screen Time / MDM, makes the switch fail again until you re-authorize. Reinstalling the app sometimes drops this system configuration. It looks like “it suddenly cannot connect”; the permission is gone, the record did not expire.

What you authorized is the on-device extension. Where traffic goes after that still depends on the highlighted record and the current policy. The App Store license only covers this layer: the app may request a system VPN. It does not include any exit. Check the developer and what the purchase covers on the Store page. Turning the switch on with no highlighted row is version-dependent. Do not rely on “it will connect without a selection.” The list needs a record that can be used as an exit; see Objects.

A VPN icon in the status bar and the switch sitting on mean the extension is running. A connection can still be judged DIRECT and leave on cellular or Wi-Fi, never touching the record you highlighted. So “already connected” is not “every request went through the node.” To see whether bytes entered the record, use Data’s two counters; to see whether rules left a host on direct, use Rules.

If the switch flickers and snaps back, the extension did not stay up. Common causes: the current record failed handshake (type, transport, certificate, or UUID does not match the remote), or there is no usable VPN configuration on the system. Before you swap records, confirm the policy is not Direct — under Direct the tunnel can stay on without ever handshaking the remote. Snap-back and “the node is dead” are two different failures. Policy and record are chosen separately. Changing a record does not change Config / Proxy / Direct; changing policy does not change the highlighted row. Both can be wrong while the screen still says connected.

Config / Proxy / Direct cover the whole current configuration and take priority over editing a single rule. They answer: after traffic is in the tunnel, should rules be asked. Config: every connection is handed to the current rule file; domain, IP, and GEOIP are evaluated here — this is everyday routing. Proxy: rules are skipped; outbound always goes to the highlighted record, which separates “the rule is wrong” from “this record cannot handshake or forward.” If Proxy works and Config does not, look at rules; if neither works, look at the record or the far end. Direct: rules are skipped; outbound always takes the system path. The VPN icon can stay on. Use it to separate “after forwarding is removed, does this device have a network at all.” Captive Portal, online banking, and LAN often need Direct first.

After a connection enters the tunnel, processing is roughly this order. If policy is Direct: send it back on the system path, skip rules, do not handshake the current record. If policy is Proxy: skip rules, send to the highlighted record; if that handshake fails, this step stops. If policy is Config: match the current configuration top to bottom and get DIRECT / PROXY / REJECT. DIRECT returns to the system path, REJECT is dropped, PROXY goes to the current record. If rewrite is on, URL or headers are changed after the request is already seen; see Rewrite. Rewrite does not go back and change the routing decision. When DNS runs relative to matching decides whether rules see a name or an address; see DNS.

UDP and TCP both enter the tunnel, but not every record type forwards UDP equally. If an app fails only on UDP (games, some calls), check whether the record claims support, then whether a port rule REJECT-ed it. Isolation must follow Direct → Proxy → Config, changing only policy each time. Editing FINAL under Config while also swapping records is not an isolation. The full write-up is in the manual’s Tunnel chapter.

“Connected” is also often read together with the list probe. A green probe makes people think “the whole path works”; a red probe makes people think “the device has no network.” Both are wrong. The probe only asks this hop. Under Direct, a page can still open on the system path with a red probe. Under Config, a host on DIRECT can open while the probe is red — that is normal. Split three sentences: is the tunnel up, does this hop probe, and which side did this visit take. The first is the switch, the second is the millisecond number, the third is Data. Rules enter only in the third sentence, and only when policy is Config. If Proxy is rising in that third sentence and the page still fails, the problem has left the tunnel layer — look at the far end, DNS, or that app’s own policy. If only Direct is rising, look back at whether policy is Direct or whether a rule wrote DIRECT first. The switch itself answers neither question.