View as Markdown

IP Blocked Recovery

Diagnose

Run from your own machine (no SSH needed):

meridian test 198.51.100.10

If the TCP check on port 443 fails from your network but works from elsewhere (another network, a VPN, the ping tool), the IP is most likely blocked. A TCP failure everywhere usually means a cloud firewall or a server that is down.

Immediate relief

If you deployed with a domain (--domain) and the record is proxied through Cloudflare, the XHTTP and WSS paths still work — they reach Cloudflare, not your blocked IP. Apps using the Xray JSON or Mihomo subscription switch over on their own; others can pick the XHTTP or WSS entry by hand.

If you have a relay, clients connecting through it are unaffected as long as the relay itself can still reach the exit.

Recovery options

Add a replacement exit

The fastest path, as long as your control-plane server (the one running the panel) is still reachable from your machine:

# 1. Get a new VPS from your provider (new IP)
# 2. Add it to the fleet
meridian node add 198.51.100.20 --name replacement

Clients keep their accounts. They receive the new exit on their next subscription refresh — ask them to refresh in their app if it doesn’t happen on its own.

Or move the blocked exit to a new server

node replace moves an exit to a fresh server, keeping its ID, keys, protocol paths, and relays, then cleans up the old server:

meridian node replace exit-1 198.51.100.20

Clients pick up the new address on their next subscription refresh. The control-plane server itself can’t be moved this way yet.

Add a domain for CDN fallback

If you weren’t using a domain, add one to the new exit:

meridian node add 198.51.100.20 --domain vpn.example.com

See Domain mode for the Cloudflare steps.

Add a relay

A relay on a domestic server gives users an entry point that stays reachable when foreign IPs are blocked:

meridian relay add 203.0.113.10 --exit 198.51.100.20

Moving an existing relay to a different exit isn’t available yet; deploy a new relay against the new exit instead.

If the control-plane server is lost

node add and relay add need the panel. If the server that hosted it is gone and cannot be restored, there is no automatic migration yet: deploy a fresh server with meridian deploy, then recreate each client with meridian client add. Each person gets a new link.

Managing from more than one machine

Everything Meridian knows about a fleet lives in ~/.config/meridian/ on the machine you deploy from. To manage the fleet from a second machine, copy that whole directory over, and copy it again after each change you make elsewhere.

You can’t accidentally undo another machine’s work. The control server keeps a small record of the last change applied (/var/lib/meridian/fence.json). Before changing anything, Meridian compares your copy with that record, and meridian plan warns ahead of time if an apply would be refused:

  • “Another machine changed this fleet”: your copy is out of date. Copy ~/.config/meridian/ from the machine that applied last, then run the command again.
  • “Another apply is running”: someone is changing the fleet right now. Wait for them to finish. If that run crashed, its claim expires within 30 minutes; a crashed run on your own machine doesn’t block you at all.
  • “This control server belongs to a different copy of the fleet”: this ~/.config/meridian/ was never copied from the machine that manages the fleet.

Prepare before a block

  1. Add a relay on a domestic server: meridian relay add RELAY_IP --exit EXIT_IP
  2. Use a domain for CDN fallback: deploy with --domain vpn.example.com
  3. Both — clients then have three ways in: relay (domestic), CDN (Cloudflare), and direct
  4. Back up ~/.config/meridian/ — it is what lets you manage the fleet from another machine

Keep the old server

Don’t tear down the blocked server right away — blocks are sometimes lifted after days or weeks. Check now and then:

meridian test 198.51.100.10

When you no longer need it, remove it with meridian node remove.

On this page