Both addresses may start with https, and a provider may send both at once. They do not belong on the same tab.
A subscription answers: which exits exist now, and which one you select. The result appears under SERVER on Home. A config answers: should this request go direct, or through the current exit. The result appears in Config, where the active filename is marked—often default.conf. Merge those into one sentence—“I imported it”—and you get a typical illusion: many nodes, traffic that never matches expectation, then a guess that the app is broken.
When Global Routing stays on Config, what actually applies is this file—not the node names in the subscription, and not the lowest latency you just measured. Extra nodes will not open a site if the rule sends the request to DIRECT. The other way around, if rules send banking, maps, or other traffic that should stay off the tunnel into the proxy, it feels like “everything got slower after I turned it on.” Neither case is fixed by buying another subscription.
This is the third of three layers. The first is the client; the second is the exit. If those are still mixed together, read The app, the subscription, and the config are not one layer first. If the second-layer entry was wrong, read Subscribe is not Add Server. Below is only the file layer.
Providers often send a “subscription URL” and a “config URL” together. Both are long, both look like ordinary web links, and they sometimes sit in the same note. Recipients remember only “copy this.” Shadowrocket puts them on two tabs: one under Type on Home, one under Add in Config. After a swap, one outcome is an empty list; the other is nodes present and routing wrong. Neither pops up “you pasted this in the wrong place.”
Paste a config URL into Subscribe and the app fetches it as a subscription. What comes back is not a node list: the update fails, or you get a row that will not expand. Import a subscription URL as a config and parsing fails, or you get a file with no rules. Home can look fine while routing is completely off. Keep these two failures separate. Do not answer both with “import it again.”
Some people also mix a local config backup with a subscription backup inside Data import/export. Being able to export does not mean the two can be fed back into each other. Export is for a new device and for emergencies, not for welding the two layers into one file. On a new device you need both. Missing one restores only half.
Hosts, ports, and remaining traffic in the list may change. Routing logic usually does not. If sites that should stay direct suddenly slow down, do not blame “the subscription update broke it” first. Ask which config is active.
The node list usually stays. What changes is what goes through the proxy. People switch a remote config and think they “changed providers.” The exits are the same. Only the decisions changed.
After a fresh install, Config usually already has a default file. It is not a blank draft, and not a placeholder that means “you cannot use the app yet.” With no remote config, you can start with it and leave Global Routing on Config. Many people feel they must import a “more professional” file before setup is finished. That complicates the third layer too early and hides a second layer that is still missing.
The default file’s job is to keep traffic that should not use the proxy on DIRECT—local services, system updates, and whatever your rules mark as direct—and send requests that need a proxy through the current node. It cannot match every site preference. When one site misbehaves, compare the three modes first and confirm the problem is really in the rules before you replace the file or edit rows. Replacing the whole file immediately destroys the baseline: you can no longer say whether the default already failed, or the file you dropped in failed.
If the provider also gave a config URL, add the remote file in Config and enable it. Enable means “decide from this file starting now.” The old file stays in the list. If something breaks you can switch back to default.conf, which is easier to judge than delete-and-start-over. Do not paste a remote config into Subscribe, and do not assume enabling a new file will swap in a new set of nodes.
Meet these conditions before you touch this layer: the app is the official copy; Home has a selected node; the status bar shows VPN; and at least some sites work under one of the modes. If every node times out, or the system never allowed the VPN, editing the config is turning valves on an empty pipe.
Typical signals that the config should change: Proxy can open a site and Config cannot, or under Config, sites that should stay direct are clearly pushed into the tunnel. The first means the exit works and the decision left the target on DIRECT or an unusable policy. The second means the decision is too wide. Both point at the file, not at “add another subscription.”
Signals that you should not touch the config: the same site also fails on Direct; every mode fails; Home is empty. Those belong to the local network, the exit, or a missing import. Adding rows to default.conf only adds noise.
Some remote configs update on a schedule. That updates decisions only. It does not keep subscription nodes alive. Some subscriptions update on a schedule. That updates exits only. It does not keep your rules fit for new targets. Turn both auto-updates on and failures become hard to trace. A safer habit: know which file is changing by itself, and keep a local baseline you have already confirmed.
A backup in Data keeps nodes and files together, and leaks less than copying URLs by hand. A backup is not a troubleshooting tool. When something breaks, compare first. Do not roll the whole thing back unless you just edited the file and clearly want to undo that step.
For the comparison method see the three modes. Enabling a remote config and inspecting default.conf is in Tutorial chapter 4. If you do not have the client yet, go through the store. Do not look for an installer to “get the config on first”—without the official app, the file has nowhere to live.