Connected in the app, and VPN in the status bar, only mean the system lets this configuration take over traffic. They do not guarantee that the current node works, or that rules sent the domain you want to the right place. If you treat the VPN icon as “already online,” every later step looks unnecessary, and the layer that actually failed is never asked about.
A more useful check splits three things. Switch to a node that returns a latency reading and it works at once: that is the proxy service. Same node, rule mode fails and global works: rules misclassified the domain. Global fails too: look at the local network and the clock first, then whether the VPN configuration is still there. Do not change all three in the same minute.
Confirm the local network first
Wi-Fi that will not associate, cellular data turned off, or a badly wrong system clock can still leave the app showing Connected. Use Direct or turn the switch off and see whether ordinary pages load. If the local network is down, changing nodes does nothing. A wrong clock can fail certificate checks and look like “the site will not open,” with no relation to the node. Fix the local network and the time, then compare nodes, mode, and rules in the app.
A node that returns a latency reading is worth trying before one that only “looks online.” If latency cannot be measured, do not start editing rules. If latency is there and pages still fail, then look at the mode. Reverse that order and you will keep tuning rules on an expired subscription. You waste comparison rounds, and you waste the few nodes that still work.
Mode and rules can waste a good node
The node is fine, but rules mark the domain as Direct, and the browser still fails. The node is fine, but one app is set not to use the proxy, and that app still spins. On screen, this is almost impossible to tell from “the node is dead.” So keep rule mode as the daily default, and switch to global only while you debug: if global recovers, go back to the list and per-app settings; if global fails too, change nodes or check whether the subscription expired.
A changed DNS, a rule list that just auto-updated, or a keyword you added yourself can make a site that worked yesterday fail today. Remembering what you changed recently works better than changing three settings at once. Change one thing. Reload the same page. Then decide the next step.
Connected only answers whether the system allowed takeover. Whether pages load depends on the node, the mode, the rules, and the local network. Any one of those four can fail while the icon is still there.
When you should not reinstall first
Reinstalling wipes app data, including the information you were using to compare. Reinstall before you know whether it is the node, the mode, or the local network, and you get an empty client. The problem is often still there. Keep the configuration, then decide whether to reinstall. After an empty list comes back, you cannot even repeat the comparison you just did.
Also confirm you installed the genuine app. An unknown installer adds another layer of unknown behavior on top of Connected, and comparison gets harder. The developer should be Shadow Launch Technology Limited. The app ID should be 932747118. Check identity first, then talk about nodes and mode.
Use one page while you compare
Do not test this site today, another app tomorrow, and a speed-test page the day after. When the target changes, you cannot tell a site problem from a configuration change. Pick one address that opened yesterday and fails today. Move it among Direct, Rule, Global, and another node until one layer differs. When something differs, stop on that layer. You do not need to take the whole client apart.
If the same page opens in one mode and fails in another, that is already enough. Do not switch three browsers “to confirm.” A different browser also changes cache, DNS, and extensions, and the comparison is dirty again. Write down the mode and the node first. If you still need another app as a check, change only one thing at a time.
If the browser works and one app does not, look at per-app settings first, then that app’s own network permission. If the system turned off cellular or Wi-Fi for that app, a Shadowrocket connection will not help. Those permissions live in system Settings, not in the node list. Turn the system permission on, then look at mode in the app. Do not reverse the order.
Do not treat a certificate warning as a node problem first. A wrong system clock, a local capture certificate installed by mistake, or an expired site certificate can all show a similar prompt. Set the clock to automatic, then decide whether to change nodes. If every certificate warning means “change the line,” the comparison stays biased.
Step-by-step testing is in Connect and test latency. Symptom tables are in Connection issues. How to leave the mode set is in Why rule mode should be the daily default. If the list is empty after a device change, see Export a configuration before you switch devices.