A config directory holds plenty of files, and most of them rebuild themselves. Not knowing which ones you wrote turns backup into hauling a whole folder around and hoping it fits.

Four things worth keeping

  • The subscription URL. A link with a token in it; lose it and you are back in the provider dashboard.
  • Your Merge and Script overrides: added rules, group ordering, port changes.
  • Any hand-written YAML — the setup where you skip subscriptions and keep the node list yourself.
  • Client settings: ports, the TUN toggle, launch at login, the secret for external-controller. None of it lives in the profile.

The generated profile is not worth saving: it is the subscription plus your overrides, already computed. Keep the first two and the next update rebuilds it identically. A saved copy mostly gives you a way to restore stale nodes by accident.

SponsoredWhere does the subscription link come from?Our partner provider gives you 1 GB of high-speed Hong Kong data at signup — import it in one click.Get high-speed nodes

The built-in WebDAV backup

  1. Find the entry labelled Backup in settings; every client puts it somewhere different.
  2. The server address must point at a specific directory, not the provider's home page. Most serve WebDAV on a separate hostname, listed in your account settings.
  3. The password field wants an app-specific password, not your login password. Many providers accept nothing else over WebDAV and just return an auth failure.
  4. Back up once by hand and check the list for a new entry with a timestamp — that is the only proof it connected. Export your current config before restoring anything.

The archive carries your subscription URL and your secret — credentials, sitting on someone else's storage. Use your own server, or a provider you would trust with a password.

Manual export and a Git repo

Most clients have an Open Config Directory entry. Copying that folder is least effort, but its layout tracks the client version, so restoring across versions is not guaranteed. The durable habit is keeping override snippets as separate files in your own Git repo — plain text, portable across clients and platforms:

prepend-rules:
  - PROCESS-NAME,ssh,DIRECT
  - DOMAIN-SUFFIX,intranet.example.com,DIRECT
append-rules:
  - GEOIP,CN,DIRECT,no-resolve

Strip the subscription URL and the secret before committing. A private repo is not enough; you may open it up later. Git keeps history too: commit a credential, delete it, and it still sits in the earlier commit. Then it is rewrite history, or reset the link at the source.

After the move to the second machine

  • Do not carry the TUN toggle over. Each machine needs its own service install and its own authorisation.
  • Re-check mixed-port. Something else may hold that port on the new machine, and the client will refuse to start or fail quietly.
  • Everything path-shaped changes: rule-providers with local files, log directories, external resource folders. Windows and macOS differ here.
  • Give each machine its own secret rather than copying one with the backup.
A restored config is not a working setup. The TUN helper service, the macOS network permission, the firewall exception all live on the system side and none of it returns in a backup. A node list reappearing looks like the finish line; it rarely is.