A configuration is a document. A record is an exit. They are not one paste.

A configuration file is an on-device document. Typical contents: general options (DNS, IPv6, ports), the rule list, sometimes rewrite and decrypt-host lists. Server records may appear in the file, or live only in the app’s server list — depending on how you imported. Do not assume “installing the app includes a working exit”: the Store license does not include a server.

In a handwritten or imported file, rule-section syntax is in Rules. The rewrite section is in Rewrite. DNS-related options are in DNS. The three sit in one document and remain three mechanisms at runtime: route first, rewrite as needed, DNS policy throughout.

Pasting a whole ss:// line into “configuration URL,” or a configuration file into “server address,” puts the object in the wrong field. It can save; the failure that follows cannot be explained as “the node is bad.”

The app lets you save several configurations, each with its own name. Switching the current configuration replaces the whole list and options together. It is not two FINALs stacked, and not “GEOIP from this file for one region, domain lines from that file for another” auto-merged.

Switching configuration does not change: the highlighted record, whether the switch is on, or the numbers in the Data counters. So you may see “I already switched to the new list, the page looks the same” — policy is actually on Proxy, and the engine never read the new file. Look at policy first, then at which file is selected.

When two configurations subscribe to the same source and only differ by refresh time, the list looks like two “almost the same” files. The checked one is what counts. Editing one does not write into the other, unless they actually point at the same subscription URL and the next refresh overwrites local edits.

Import is usually a file, the clipboard, or a URL. A URL configuration is like a server container: what you save is the address; a successful fetch replaces the local document with remote content. On failure the last successful file is kept; rules are not wiped because a fetch failed.

Update on open and background update both repeat this fetch. Background still depends on the system allowing this app to refresh in the background; see System. The refresh follows the network path of that moment: if the switch is sitting on a dead record, the configuration subscription itself can fail. Switching policy to Direct, or turning the switch off, isolates the path.

An export is a document that contains rules, options, and any credentials you wrote into the file. Treat it as a secret. Before you send it to another device, assume it has passwords and UUIDs.

For an imported list, read FINAL and GEOIP before you decide to use it. The author wrote for their own exit. A list written for a node in one place, used with a node in another, sends a mass of unrelated requests into the node — or sends unnamed traffic all direct. See the “Imported files” section on the Rules page.

There is no account system. Developer servers do not host your list. With iCloud allowed, devices under the same Apple ID can sync configurations and records; that is Apple-account sync, not a Shadowrocket account.

On a sync conflict, do not heavily edit the same subscribed configuration on two devices at once — the next refresh still takes the URL’s return value, and local edits are overwritten. To freeze a list, export it as a non-subscribed local file, then edit that.

Turning iCloud off or changing Apple ID does not “log you out” with the developer, because there was never an account. On-device files remain until you delete the app or clear the documents. Deleting the app takes unbacked-up configurations with it. Reinstalling from the Store does not bring nodes back unless iCloud or your own export is still there.