February 3 2023

How to deal with emergency site migrations without worrying about DNS propagation and live happily ever after.

Sometimes we come across situations in which the TTL of the DNS is set to one day or more. How to show the migrated site immediately?

In our past posts we have always given importance and emphasis on how important DNS services are and how it is essential to have a low TTL in order not to run into serious problems such as having to change an urgent IP and find yourself unable to perform fast propagation because the Time To Live (TTL) is set to one day or more.

You can find a in-depth article on DNS TTL in this post, however it is also true that often you are urgently involved in dangerous situations in which an immediate migration of a website from one server to another server is required and you realize that the owner, the webmaster or the previous system administrator has not set the TTL of the DNS to a suitable value such as for example 5, 15, 30 minutes or an hour at the most.

Perhaps the migration of the site and the database and the recreation of the environment can be done in 1 hour, but then we have to wait up to a day if we find a TTL of 86400 seconds set, and this in production environments with sites that make traffic can be deleterious and extremely harmful in terms of image, visibility, SEO, lost sales and turnover.

In this post, therefore, we are going to see how to behave in emergencies in which a site must be migrated from one server to another server, bypassing the DNS limits and making the new site "propagate" immediately.

Of course, root access to the source machine is required in order to run privileged commands.

Case 1: A server running a single site or multiple sites that need to be migrated in bulk to a second machine.

Let's imagine we have a server that contains 100 vhosts, which must be migrated en bloc to a second machine, of these 100 vhosts, of 50 we manage the DNS, and of the remaining 50 the respective clients, on different registrars such as Aruba , OVH, InternetBS, Register, Godaddy, and with the most disparate TTL values ​​ranging from 5 minutes to a week.

So how to manage this situation so that the migration goes through correctly and the data is updated avoiding having to make more migrations and align, for example, posts or orders and stocks of sites that continue to travel on the primary server instead of the secondary server?

In this case the most sensible option is to migrate files with rsync to a new server, the raw database to the new server, generate the PHP-FPM pools, Apache webserver configuration, SSL certificates and start the instances.


On the primary server, the one of origin, we are going to turn off the DB, PHP and Web services and at that point we will instruct the network-level iptables firewall to forward all traffic in and destined for the HTTP and HTTPS ports (that is, port 80 and port 443) to the respective ports on the new machine.

The syntax is very trivial and is as follows:

sysctl net.ipv4.ip_forward=1 iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination IPDESTINATION:80 iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination IPDESTINATION:443 iptables -t nat -A POSTROUTING -j MASQUERADE

Obviously the above example takes into account the desire to use Linux iptables as a port forwarder, perhaps for reasons related to disk failure, a boot with a live linux, or the like, but the underlying concept is applicable and can be proposed to any system operating with different software.

By doing so, we could immediately start using the web services that are already running on the new server and then calmly instruct the site owners to change the pointing of the DNS records to the new IP, giving, for example, a month's deadline. After a month we will switch off the origin server, having taken into account that the customers who independently managed their DNS zone have received the communication and have had more than enough time to make the changes.

Case 2: a server that manages multiple sites of which only some need to be migrated in bulk to a second machine.

The case study is similar to the previous one, the main and fundamental difference lies in the fact that not all sites need to be migrated to the second machine and therefore I cannot instruct the network firewall to do port forwarding of the entire HTTP and HTTPS traffic on the second car.

Instead I have to select which vhosts will go on the second machine and make sure that the vhosts of the first machine are instructed to fetch data and forward HTTP and HTTPS traffic from the second machine.

In this case instead of using port forwarding at the network level I'm going to use a Reverse Proxy.

Reverse Proxy

In computer networks a reverse proxies is a type of proxy that retrieves content on behalf of a client from one or more servers. This content is then transferred to the client as if it came from the same proxy, which then appears to the client as a server.

To do this you will need to go to the respective webserver configuration files (let's imagine Apache 2.4 or NGINX for example) and specify a series of instructions so that you can reverse proxy the sites already hosted on the second machine.

Apache Reverse Proxy 2.4

Below we see a brief configuration of a reverse proxy in Apache 2.4 with specific directives both for forwarding HTTP and HTTPS as well as avoiding checking the HTTPS certificate on the second machine because perhaps we have not yet obtained an HTTPS certificate with Let's Encrypt or similar.

We will obviously not go into all the Apache directives or the fact that you need to insert modules to make reverse proxy work which can be done on Debian for example using : sudo a2enmod proxy && sudo a2enmod proxy_http && a2enmod ssl

ServerName fcnauticaweb.com ServerAlias ​​www.fcnauticaweb.com ProxyPass / http://80: ProxyPassReverse / http://80: ProxyRequests Off ServerName fcnauticaweb.com ServerAlias ​​www.fcnauticaweb.com SSLEngine on SSLProtocol All -SSLv80 -SSLv443 -TLSv2 -TLSv3 SSLCertificateFile /var/www/clients/client1/web1.1/ssl/fcnauticaweb.com-le.crt SSLCertificateKeyFile /var/www/clients/client0/web1/ssl/fcnauticaweb .com-le.key SSLProxyEngine On SSLProxyVerify none SSLProxyCheckPeerCN off SSLProxyCheckPeerName off ProxyPass / https://0:1/ ProxyPassReverse / ProxyRequests Off ProxyPreserveHost On

In the example above we are going to forward a vhost that responds to the domain name fcnauticaweb.com to a web server with IP, after which we will restart the apache web server using the apachectl restart command.

All HTTP and HTTPS traffic will be forwarded to the second machine with IP and then with "calm" we will worry about pointing the DNS record for the web domain to the desired IP address, considering that the current TTL is set to 86400 seconds (one day) and even an immediate modification would have resulted in a propagation time of up to 86400 seconds.


Reverse Proxy on NGINX.

In the previous example we used Apache because the original system used an ISPConfig panel based precisely on Apache 2.4, however we could have found another very popular web server lately as well as our favorite NGINX.

Also in this case the thing is very easy and simple considering that the syntax is similar and that NGINX unlike that crap Apache does not require additional modules to act as a reverse proxy, given that in NGINX the reverse proxy function is used almost more than that of web server.

NGINX Banners


So let's see how the same configuration would have looked in NGINX:

server { listen 80; server_name fcnauticaweb.com www.fcnauticaweb.com; rewrite ^ https://www.fcnauticaweb.com? permanent; } server { listen 443 ssl http2; server_name fcnauticaweb.com www.fcnauticaweb.com; root /home/mir-project/project/; ssl on; ssl_certificate /etc/letsencrypt/live/fcnauticaweb.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/fcnauticaweb.com/privkey.pem; ssl_session_timeout 5m; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHER-RSA -AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256; ssl_prefer_server_ciphers on; ssl_early_data on; ssl_dhparam /etc/ssl/certs/dhparam.pem; ssl_session_cache shared:SSL:10m; add_header Strict-Transport-Security "max-age=31536000; includeSubdomains"; ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/letsencrypt/live/fcnauticaweb.com/fullchain.pem; resolvers valid=300s; location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-ForwardedProto $scheme; proxy_pass; } }

By using these techniques described above you will not have to be at the mercy of other people's choices and influences, you will be able to reduce waiting times and go to operate urgently in the true sense of the word, i.e. receive requests and guarantee the solution within a specific time of one or two hours , once useful for the final client who is often non-technical, does not know how domain name resolution works, nor the technical limitations that they impose.

Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.


Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.


Managed Server Srl is a leading Italian player in providing advanced GNU/Linux system solutions oriented towards high performance. With a low-cost and predictable subscription model, we ensure that our customers have access to advanced technologies in hosting, dedicated servers and cloud services. In addition to this, we offer systems consultancy on Linux systems and specialized maintenance in DBMS, IT Security, Cloud and much more. We stand out for our expertise in hosting leading Open Source CMS such as WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart and Magento, supported by a high-level support and consultancy service suitable for Public Administration, SMEs and any size.

Red Hat, Inc. owns the rights to Red Hat®, RHEL®, RedHat Linux®, and CentOS®; AlmaLinux™ is a trademark of AlmaLinux OS Foundation; Rocky Linux® is a registered trademark of the Rocky Linux Foundation; SUSE® is a registered trademark of SUSE LLC; Canonical Ltd. owns the rights to Ubuntu®; Software in the Public Interest, Inc. holds the rights to Debian®; Linus Torvalds holds the rights to Linux®; FreeBSD® is a registered trademark of The FreeBSD Foundation; NetBSD® is a registered trademark of The NetBSD Foundation; OpenBSD® is a registered trademark of Theo de Raadt. Oracle Corporation owns the rights to Oracle®, MySQL®, and MyRocks®; Percona® is a registered trademark of Percona LLC; MariaDB® is a registered trademark of MariaDB Corporation Ab; REDIS® is a registered trademark of Redis Labs Ltd. F5 Networks, Inc. owns the rights to NGINX® and NGINX Plus®; Varnish® is a registered trademark of Varnish Software AB. Adobe Inc. holds the rights to Magento®; PrestaShop® is a registered trademark of PrestaShop SA; OpenCart® is a registered trademark of OpenCart Limited. Automattic Inc. owns the rights to WordPress®, WooCommerce®, and JetPack®; Open Source Matters, Inc. owns the rights to Joomla®; Dries Buytaert holds the rights to Drupal®. Amazon Web Services, Inc. holds the rights to AWS®; Google LLC holds the rights to Google Cloud™ and Chrome™; Microsoft Corporation holds the rights to Microsoft®, Azure®, and Internet Explorer®; Mozilla Foundation owns the rights to Firefox®. Apache® is a registered trademark of The Apache Software Foundation; PHP® is a registered trademark of the PHP Group. CloudFlare® is a registered trademark of Cloudflare, Inc.; NETSCOUT® is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, and Kibana® are registered trademarks of Elastic NV Hetzner Online GmbH owns the rights to Hetzner®; OVHcloud is a registered trademark of OVH Groupe SAS; cPanel®, LLC owns the rights to cPanel®; Plesk® is a registered trademark of Plesk International GmbH; Facebook, Inc. owns the rights to Facebook®. This site is not affiliated, sponsored or otherwise associated with any of the entities mentioned above and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. Any other trademarks mentioned belong to their registrants. MANAGED SERVER® is a trademark registered at European level by MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italy.

Back to top