Migrating servers is a complex process that involves many moving parts. One of the most challenging aspects of server migration is dealing with DNS propagation. When you update your DNS records to point to a new server, it can take several hours for the changes to propagate globally. During this time, some users may still be directed to the old server, which can lead to issues with data consistency, ordering, and revenue loss.

A reverse proxy can help mitigate these issues by allowing you to control the exact moment when the new server starts serving all requests to your domain. In this article, we’ll explore how to set up a reverse proxy using Nginx or Apache, and discuss some additional considerations and alternatives.

What is a Reverse Proxy?

A reverse proxy is a server that receives requests from the internet, obtains the requested resource from the server it’s acting as a proxy for, and then returns that resource to the requester. This is different from a forward proxy, which is typically used to cache frequently requested resources or hide internal IP addresses.

You may have already used a reverse proxy in your setup, for example, by installing Nginx in front of Apache to take advantage of Nginx’s speed and caching capabilities.

How Can a Reverse Proxy Help with DNS Propagation?

A reverse proxy can’t speed up DNS propagation, but it can help mitigate the issues associated with waiting for it to happen. When you’re migrating a server, you can set up the old server as a reverse proxy for the new server. This way, even though some users may still be directed to the old server, the reverse proxy will ensure that all requests are served by the new server.

For example, suppose you’re moving a client’s eCommerce site from an old server to a new server at a different provider. You’ve set up everything on the new server and are ready to switch over the DNS. However, you realize that some users may still be directed to the old server until their local DNS cache is updated. By setting up the old server as a reverse proxy for the new server, you can ensure that all requests are served by the new server, even if some users are still being directed to the old server.

Proactively Shortening DNS Time-to-Live

While a reverse proxy mitigates the problem, you can proactively minimize the duration of the propagation window by adjusting your DNS Time-to-Live (TTL) settings.

The TTL is a value (usually measured in seconds) that tells recursive DNS servers and client machines how long to cache your domain’s IP address before requesting an update. Common TTL values range from 3600 seconds (1 hour) to 86400 seconds (24 hours).

To prepare for a migration:

1. Reduce the TTL: At least 24 hours before the migration, log into your DNS registrar or host and reduce the TTL for your A records to a very short value, such as 300 seconds or even 60 seconds.
2. Wait for the Old TTL to Expire: You must wait for your original, longer TTL to expire (e.g., if your old TTL was 24 hours, wait 24 hours) to ensure the low value has been cached everywhere.
3. Perform the Migration: Once the TTL is low, any DNS change you make will propagate and take effect much faster, minimizing the overlap time where users might be hitting the old server.
4. Restore the TTL: After the migration is complete and you are confident all traffic is hitting the new server, you can restore the TTL to a longer, more typical value (like 3600 seconds) to reduce load on your authoritative DNS servers.

By reducing the TTL, you drastically reduce the period during which a reverse proxy is necessary, making your migration cleaner and faster.

Check Your Host’s Recommendations

Your hosting provider may have specific recommendations and policies regarding reverse proxies. WP Engine, for example, generally doesn’t recommend using reverse proxies. There are certain situations where they support it, but it requires some additional configuration.

WP Engine already utilizes reverse proxy technology in their server setup, with Nginx serving as a traffic director and CDN services distributing static files globally. If you still need to use a reverse proxy, WP Engine recommends forwarding real IP addresses to ensure accurate identification of users and prevent potential security issues.

WP Engine allows two primary proxy configurations: hosting only a subdirectory and hosting both a subdirectory and top-level domain. Each of these has specific configuration instructions.

In addition to your host’s recommendations, there are some other things you should consider before going down this route. Using a reverse proxy can introduce additional latency and resource usage. Make sure to monitor your server’s performance and adjust your configuration accordingly. In addition, the reverse proxy will not proxy database connections, so you’ll need to update your database connection settings to point to the new server.

Using a reverse proxy introduces several security risks. It can become a single point of failure, and if not properly configured, it can expose vulnerabilities. Reverse proxies can store sensitive information like IP addresses and passwords, which can be problematic if managed by a malicious party. Additionally, they are susceptible to HTTP request smuggling attacks and can disrupt operations if they fail. Proper setup and ongoing management are crucial to mitigate these risks effectively.

Configuration and Security Planning

Before modifying any server configurations, it’s vital to address potential security and conflict issues that arise when using a reverse proxy.

• Prevent Configuration Conflicts: On the old server (the proxy), ensure your new proxy rules don’t conflict with existing virtual hosts or default server blocks. You may need to disable the original virtual host that was serving the website files. If you’re using Nginx, this often means removing or renaming the site’s configuration file from /etc/nginx/sites-enabled/. In Apache, you’ll use sudo a2dissite mydomain.com.conf. This guarantees that the server processes traffic using only the new proxy configuration.

• Secure Sensitive Files: The configuration steps require placing your SSL certificate and private key files on the old server (the proxy). While necessary for HTTPS traffic, ensure these files are stored outside of any publicly accessible web directory and protected with strict file permissions (e.g., owned by root, read-only by the web server user) to prevent unauthorized access.

• Avoid Caching Issues: If the old server (proxy) uses any form of server-side caching (like Varnish or a built-in Nginx/Apache cache), you must ensure these caches are disabled or bypassed for the proxy traffic. If the proxy serves a cached page instead of forwarding the request to the new server, your efforts to ensure data consistency will fail.

Addressing these issues ensures that your migration is not only seamless for the user but also secure and stable during the entire DNS propagation window.

Setting up the Reverse Proxy

The original version of this article only included instructions for setting up a reverse proxy with Apache. We’ve updated those instructions, and added the process for using Nginx. You can skip to the Apache process here.

Setting up a Reverse Proxy Using Nginx

Create a new file in the /etc/nginx/conf.d/ directory, such as my-proxy.conf. This file will contain the configuration for your reverse proxy.

sudo nano /etc/nginx/conf.d/my-proxy

In the my-proxy file, add the following configuration for both HTTP and HTTPS traffic:

server {
    listen 80;
    server_name mydomain.com www.mydomain.com;

    error_log /var/log/nginx/proxy-error.log crit;
    access_log /var/log/nginx/proxy-access.log combined;

    location / {
        proxy_pass http://new-server-ip-address:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

server {
    listen 443 ssl;
    server_name mydomain.com www.mydomain.com;

    error_log /var/log/nginx/proxy-error.log crit;
    access_log /var/log/nginx/proxy-access.log combined;

    ssl_certificate /path/to/your/certificate.crt;
    ssl_certificate_key /path/to/your/private.key;

    location / {
        proxy_pass https://new-server-ip-address:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

Replace mydomain.com with your site’s domain name, new-server-ip-address with the IP address of your new server, and update the paths to your SSL certificate and private key files. Finally, restart Nginx to apply the new configuration:

sudo service nginx restart

Nginx Considerations

There are a couple of things you should keep in mind when setting up a reverse proxy with Nginx:

• Proxy Caching: Nginx has built-in support for proxy caching, which can help reduce the load on your origin server. You can enable proxy caching by adding the proxy_cache directive to your configuration.

• Buffering: Nginx can buffer responses from the origin server, which can help improve performance. You can enable buffering by adding the proxy_buffering directive to your configuration.

Setting up a Reverse Proxy Using Apache

To set up a reverse proxy using Apache, you’ll need to enable the proxy_http and ssl modules, and create a new virtual host configuration file. Here’s an example of how to do this on Ubuntu 22.04:

sudo a2enmod proxy proxy_http ssl
sudo nano /etc/apache2/sites-available/my-proxy.conf

In the my-proxy.conf file, add the following configuration:

<VirtualHost *:443>
    ServerName mydomain.com
    ServerAlias www.mydomain.com
    ErrorLog ${APACHE_LOG_DIR}/proxy-error.log
    CustomLog ${APACHE_LOG_DIR}/proxy-access.log combined

    SSLEngine on
    SSLCertificateFile /path/to/your/certificate.crt
    SSLCertificateKeyFile /path/to/your/private.key

    ProxyRequests Off
    ProxyPass / https://new-server-ip-address:8080/
    ProxyPassReverse / https://new-server-ip-address:8080/
    ProxySet Header Host $host
    ProxySet Header X-Real-IP $remote_addr
    ProxySet Header X-Forwarded-For $remote_addr
</VirtualHost>

Replace mydomain.com with your site’s domain name, new-server-ip-address with the IP address of your new server, and update the paths to your SSL certificate and private key files.

To enable the new configuration, run the following command:

sudo a2ensite my-proxy

Finally, restart Apache to apply the new configuration:

sudo service apache2 restart

Apache Considerations

There are a few things you should keep in mind when setting up a reverse proxy with Apache:

• SSL Configuration: Make sure to update the SSLCertificateFile and SSLCertificateKeyFile directives to match the paths to your SSL certificate and private key files.
• Server Aliases: Update the ServerName and ServerAlias directives to match your site’s domain name.
• Proxy Settings: Consider using a more secure way to store your SSL certificate and private key files, such as using a password-protected file or a secure keyring.

Configuring WordPress to Recognize the Real IP

While your reverse proxy is now configured to correctly forward the client’s real IP address using the X-Real-IP or X-Forwarded-For headers, WordPress does not automatically recognize these. By default, WordPress only reads the REMOTE_ADDR server variable, which now contains the IP address of the old server.

To ensure WordPress properly logs, analyzes, and enforces security rules based on the true client IP, you must add a small snippet to your wp-config.php file on the new server.

Place the following code snippet above the line that says /* That's all, stop editing!

<?php
// Set the client's real IP address when behind a reverse proxy
if (isset($_SERVER['HTTP_X_REAL_IP'])) {
    $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_REAL_IP'];
} elseif (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
    $ips = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']);
    // The first IP is the actual client IP
    $_SERVER['REMOTE_ADDR'] = trim($ips[0]);
}
?>

Wrapping Up

Using a reverse proxy can be a useful tool for mitigating the issues associated with DNS propagation, but it requires careful planning and configuration to ensure that it is implemented correctly. Make sure to look into your host’s recommendations before you begin, and be aware that there are security risks that come with implementing a reverse proxy.

A reverse proxy can be an incredibly powerful tool for routing traffic around and through tough situations, but there’s always more than one way to do it. What are your best tips for migrating servers or creative uses of the reverse proxy? Let us know in the comments!