Skip to content

Moving users to another domain

Your subscription domain gets blocked, or you simply move to a new one. Both cases are handled from the portal — you do not have to change anything in your panel, and users do not have to re-add their subscription.

Both rules are keyed on the domain the request arrived at, so you can run several at once — one per subdomain — and remove them individually.

Migration — new-domain

Open provider.smproxy.io/provider/domains, press Move next to a verified domain and pick:

  • From — *.example.com to move subscriptions from the whole domain including its subdomains, or a single host such as sub.example.com to move only that one.

  • To — the new host. It has to be verified in the same account, so nobody can point your users at a domain they do not own.

From then on, every subscription request that arrives at the old host gets a new-domain header, and the app rewrites the address itself. Each user keeps their own path and token:

old.example.com/sub/abc123  →  new.example.com/sub/abc123

⛔ Chains are refused. If b.example.com already has a migration of its own, you cannot make it the destination of another one — users would be handed an address that immediately moves again.

Backup hosts — fallback-domains

Press Backups next to a domain and list the hosts to fall back to, one per line. Every entry must be a verified domain of yours. The list is sent as fallback-domains for requests to that domain, and the app walks it in order if the main host stops answering.

Use a migration when you have actually moved; use backups when the main address may become unreachable and you want the app to find its own way through.

Two delivery channels

Both rules reach the app in two independent ways:

  • Subscription response headers — new-domain / fallback-domains, as described above. Requires the request to still reach one of your domains.

  • The app's own service channel — the app also picks up the new-domain / fallback-domains you configured for your domain over its own service connection, without fetching the subscription. They are applied on the next subscription refresh: new-domain re-points the stored URL permanently, backup hosts are saved and tried whenever the main host stops answering.

The second channel matters when your subscription domain is already unreachable: it runs over the app's own service endpoints, so existing users still receive the migration or the backup list even though they cannot fetch the subscription itself.

Requires an app build from late August 2026 or newer; older builds keep using headers only.