I have a web server that hosts 200+ domains but it needs to be moved to another data center and get a new IP address. But since all DNS settings have to be updated manually, I thought about whether you could set up some kind of transparent proxy at the old IP address that forwards all http/https traffic to the new IP. So visitors do not discover the move to the DNS is being corrected.

My first thought was to use nginx for it, but thinking it will cause problems with SSL certificates on the domains. Is there a good way to solve the problem?

  • 2
    How many IP addresses do we talk about? One? And why did you not use a CNAME for that so that a simple change would redirect all domains?
    – TomTom
    Jul 10, 2021 at 21:55
  • 1
    at first reduce the ttl of any record to a minimum, after that wait for 3-5 days, verify that. make an initial sync of your old to new server. set local a domain name to the new IP via hosts look for any errors. it will usually not make any issue to have the same certificate on 2 server simultaneously. verify, and if it's OK you can change the real entry's, remind to Remove the hosts entry
    – djdomi
    Jul 10, 2021 at 22:02
  • 2
    Assuming your server runs linux, you don't even need to run nginx. Just run something like socat -T 900 TCP-LISTEN:443,reuseaddr,fork TCP-CONNECT:newserver:443 on the old server (make sure it restarts, survives reboots, ...). That'll forward the connection on a TCP basis and save you the headache of configuring nginx right. Jul 11, 2021 at 7:10

3 Answers 3


I use the following migration process in these cases:

  1. Change DNS TTL to minimum value
  2. Wait for DNS TTL to update
  3. Copy keys / certificates to new server
  4. Put site to maintenance mode
  5. Synchronise files/database to new server
  6. Set up reverse proxy from old server to new server
  7. Remove maintenance mode on new server
  8. Change DNS entries to point to new server

Step 6 ensures that end users don't end up to the old server even though their DNS has resolved to the old server IP.

After this, keep monitoring the old server logs to see when traffic has stopped there. Then you can dismantle the old setup.

Reverse proxy is set up using proxy_pass directive. If end user IP address is important information, you need to add it into HTTP headers on the old server -> new server requests, and tell new server to use the header value as the IP address.

  • It was also a bit in the direction I had thought, but did not really think I can find a way to handle the https part without having to install all the SSL certificates on the proxy server as it somewhere does not really need the data but only must receive and forward data. It must be both 80/HTTP and 443/HTTPS traffic. Jul 11, 2021 at 11:14
  • You might be able to use nginx stream module to forward the TCP connection as-is to the new server. In that case only new server would need all the certificates. Jul 11, 2021 at 12:36

You may first want to decide (or estimate) what you want to sacrifice when you are moving:

  1. Ease of the transition (if a lot of the points below are important, the transition will be a project instead of a task, you may as well not have the expertise needed available)
  2. Downtime (is it possible to execute the whole transition at night or whenever your users' activity is minimal?)
  3. The consistency of the access logs (it may be quite important and the http or tcp proxy will mask the remote IP addresses)
  4. The consistency of the data shown to the users (is it acceptable some of the users to see stale data?)
  5. The possibility of content updates for a while
  6. The data safety (in quite a few cases it is important to keep the data absolutely safe from corruption and/or leaks even if this means some downtime)
  7. The time available (your hosting contract running out)
  8. The user session consistency (this is formally included in point 4 but deserves additional consideration because of the differnt possible mitigations)

Depending on the combination of the above, you may want to use one or more of these:

  • TCP proxy (like socat)
  • HTTP proxy (nginx, squid, etc...)
  • A complex routing/VPN solution to allow a single server to respond to requests on 2 IP adresses
  • Database replication
  • Virtual machine migration

The things you will want no matter of the strategy chosen, are:

  1. DNS TTL lowering (you may increase it back after everything is ready)
  2. A Backup - yes, bad things do happen during transitions and migrations.
  3. A plan
  4. A plan for going back if the transition plan fails.
  • +1 for mentioning the issue of migrating the live database (or VM). This is the hard part of migrating a site without bothering users and risking data loss. I have good experiences with MySQL and circular replication for this. If done correctly there is also no need to rush any of the steps.
    – mvds
    Jul 12, 2021 at 6:19
  • One more for the list: user session consistency. If sessions are stored in the database this is covered, but e.g. file/redis based sessions need their own migration or any active user will find its session killed the instant they start talking to the new host.
    – mvds
    Jul 12, 2021 at 6:22

Another alternative is to use a combination of NAT, a VPN and policy routing.

You set up a VPN between the servers in the old and new locations, on the server in the old location you use destination NAT to redirect incoming traffic down the VPN. On the server in the new location you use policy routing to ensure that replies to traffic that came from the VPN goes back down the VPN.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.