What Config, Proxy, and Direct Are Each Looking At

Global Routing sits high on Home, so it is often read as a “mode picker”: Config is normal, Proxy is faster, Direct is off. That reading sends troubleshooting the wrong way. The three options do not change a node’s latency, loss, or whether it is reset. They only change how many requests are sent to the current exit. Switching to Proxy makes more requests hit the same exit, more completely. It does not repair the exit.

It also does not replace a subscription or a config file. With no nodes, switching modes has no comparison value. With no active config, the Config setting has no decision to run. Connect the first two layers; then this row becomes a probe. How the three layers split: The app, the subscription, and the config are not one layer. How files and subscriptions split: A config file is not a subscription.

The product placement is on the home page. How to open this row is in Tutorial chapter 4. Below is only how to read results when you compare.

Config follows the current config file to decide direct or proxy. This is the daily mode. Local services, system updates, and apps that dislike a proxy should usually stay on the direct side. Everyday use should stay here. If it “only works” on Proxy, either the daily decisions do not match your targets, or you have not confirmed the exit itself works.

Proxy is close to “send whatever can go through the current node.” It is for a short question: if global works and rules do not, the problem is the config; if global also fails, the problem is usually the node, the subscription, or the system VPN—do not keep adding rule rows. Making it the default means giving up split routing, and giving up comparison.

Direct means not using the proxy for now. Use it to ask: with the tunnel off, does this site open on its own? If Direct also fails, do not blame Shadowrocket first. Check the local network, DNS, and the site itself. People keep swapping nodes while Direct is already failing because they never treated this setting as the switch that looks at the world without the app.

A useful comparison is: the same site, the same node, the same config, and only Global Routing changes. If you also swap the node and switch to Proxy, a better result does not tell you whether the exit was right or the mode simply bypassed the rules. Likewise, do not update a subscription or enable another remote config in the middle of a comparison.

A good order: watch the target under Config; if it fails, switch to Proxy; if Proxy still fails, switch to Direct. Write down all three results, then decide which layer to touch. Notes beat memory, because on screen these three states are only one changing row of text and are easy to mix up later.

When the comparison ends, switch back to Config. That is not politeness. It restores the daily decision. Leave it on Proxy, and two days later battery drain, heat, or a banking app failing will look like “the nodes went bad,” so you change subscriptions. The real cause is that the mode is still sitting on the probe.

Proxy also shoves requests into the tunnel that should not go there. System updates, local video apps, maps, and some logins all ride the current exit. Drain, slowness, and odd app failures become more common. It is a probe, not a “faster mode,” and not a “more stable mode.” No rule set is perfect, but dropping rules is not a fix.

Some people leave Proxy as the default, then complain that “local sites are slow with the proxy on.” That is not a weak node. It is the wrong mode. Buying a more expensive subscription then only sends more traffic that should stay direct into a costlier exit. Switch back to Config first, then decide whether to change the file.

Some people use Proxy to “avoid rule trouble.” That is fine for a short time. As a long-term policy it means not using Shadowrocket’s routing at all, only a global tunnel. That is still valid. It just costs you comparison: two of the three modes no longer differ.

Global Routing cannot tell you whether a subscription has expired. An empty list or a failed update belongs to the second layer. It also cannot tell you whether the system allowed the VPN. Switch on, no status-bar mark: go to Settings. And it cannot tell you whether you bought the wrong app. If the icon is wrong, no mode means anything.

A latency test is also not a mode test. Low latency only means the speed-test path is open. It does not mean your target site opens under a Config decision. Do not close with a single sentence like “latency is fine so it must be the rules” or “latency is fine so it cannot be the rules.” Use the three-row table above and fold the symptom into one judgment.

If the comparison points at the config, then edit the file or switch the remote config. If it points at the exit, update the subscription or change the node. If it points at the system, allow the VPN again. Fix only the layer that was pointed to. If the official client is not installed yet, finish the first layer first.

On Demand in Settings decides when the system is asked to connect or disconnect. It changes whether the tunnel is still there. It does not move among Config, Proxy, and Direct. If it drops overnight, check On Demand and the system VPN first. Do not spin Global Routing. Modes answer how traffic is routed. On Demand answers whether this VPN stays up.

Latency tests, the selected node, and backup/restore should not be tied to a mode switch in the same step either. Home is crowded; every row looks like a switch. Only the Global Routing row is fit for a three-way comparison. The other rows do their own jobs. Twist them as one set of knobs and the three modes lose their comparison value.