Back to articles
Technology Insight

Building a Zero-Downtime Infrastructure: Configuring a High-Availability Reverse Proxy with HAProxy and Keepalived

May 25, 2026

Introduction: The Cost of Downtime and the High-Availability Imperative

In the modern digital landscape, website availability is not just a technical metric—it is a foundational pillar of business revenue and customer trust. Whether you are running a fast-growing e-commerce platform, a critical SaaS application, or an enterprise portal, unexpected downtime translates directly into financial loss and diminished brand equity. Standard single-server architectures, or even basic multi-server setups behind a single load balancer, possess a catastrophic vulnerability: a Single Point of Failure (SPOF).

If your primary load balancer crashes due to hardware failure, kernel panics, or sudden traffic spikes, your entire application goes dark, regardless of how many healthy backend application servers you have running. To eliminate this vulnerability, enterprise infrastructure teams deploy a High-Availability (HA) Reverse Proxy layer. By combining the high-performance load-balancing capabilities of HAProxy with the virtual IP failover redundancy of Keepalived, you can construct a resilient infrastructure that ensures your website remains accessible, even if an entire proxy node completely fails.

The Core Components: Understanding HAProxy and Keepalived

Before diving into the technical implementation, it is crucial to understand how these two open-source tools complement each other to create a seamless, self-healing entry point for your web traffic.

1. HAProxy (High Availability Proxy)

HAProxy is an industry-standard, layer 4 (TCP) and layer 7 (HTTP) load balancer and proxy server. It is renowned for its exceptional performance, low memory footprint, and advanced traffic-routing capabilities. In our architecture, HAProxy acts as the intelligent traffic cop. It terminates incoming client connections, inspects the application layer, and efficiently distributes requests across multiple backend application servers based on health checks and predefined algorithms (such as Round Robin or Least Connections).

2. Keepalived and VRRP

While HAProxy perfectly balances traffic across backend application servers, it cannot protect itself if the host it is running on fails. This is where Keepalived comes in. Keepalived is a routing software based on the Virtual Router Redundancy Protocol (VRRP). It allows two or more physical or virtual servers to share a single, floating Virtual IP (VIP) address.

Under normal operating conditions, the primary server (MASTER) holds the VIP and handles all incoming traffic. The secondary server (BACKUP) continuously listens for periodic "heartbeat" advertisements from the MASTER. If the MASTER fails to send these heartbeats within a specific timeframe, Keepalived automatically shifts the VIP to the BACKUP server, ensuring uninterrupted traffic flow.

Architectural Overview and Prerequisites

To implement this enterprise-grade solution, we will utilize a topology consisting of a Virtual IP, two dedicated VPS instances for the high-availability proxy layer, and at least two backend web servers.

  • Virtual IP (VIP): 192.168.1.100 (The public-facing IP pointing to your domain)
  • Load Balancer 1 (Primary/Master): 192.168.1.11
  • Load Balancer 2 (Secondary/Backup): 192.168.1.12
  • Backend Web Server 1: 192.168.1.21
  • Backend Web Server 2: 192.168.1.22
Note: Ensure that all servers are running a modern Linux distribution (such as Ubuntu 22.04 LTS or Debian 12) and are provisioned within the same private network or VPC that supports floating IPs / VRRP traffic.

Step-by-Step Configuration Guide

Step 1: Installing HAProxy and Keepalived

First, execute the system package updates and install both services on both Load Balancer 1 and Load Balancer 2:

sudo apt update
sudo apt install haproxy keepalived -y

Once installed, stop both services temporarily to prevent incomplete configurations from running actively: sudo systemctl stop haproxy keepalived.

Step 2: Configuring Keepalived for Virtual IP Failover

Next, we must configure Keepalived to manage our Virtual IP. Create and edit the configuration file on the primary node.

On Load Balancer 1 (MASTER), update /etc/keepalived/keepalived.conf:

vrrp_script check_haproxy {
    script "/usr/bin/killall -0 haproxy"
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass SecureClusterSecret
    }
    virtual_ipaddress {
        192.168.1.100
    }
    track_script {
        check_haproxy
    }
}

On Load Balancer 2 (BACKUP), the file must be slightly adjusted with a lower priority and backup state:

vrrp_script check_haproxy {
    script "/usr/bin/killall -0 haproxy"
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass SecureClusterSecret
    }
    virtual_ipaddress {
        192.168.1.100
    }
    track_script {
        check_haproxy
    }
}

The check_haproxy script is a critical optimization; it verifies that the HAProxy daemon is actually alive. If HAProxy dies on the MASTER node, Keepalived automatically lowers its priority, triggering an immediate failover to the BACKUP node even if the MASTER server itself remains powered on.

Step 3: Allowing Non-Local IP Binding

By default, the Linux kernel prevents applications from binding to an IP address that does not explicitly exist on the local network interface. Because the Virtual IP will only reside on one load balancer at a time, HAProxy on the backup node will fail to start unless we modify this kernel behavior. Run the following commands on both load balancers:

echo "net.ipv4.ip_nonlocal_bind=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Step 4: Configuring HAProxy for Load Balancing

Now, configure HAProxy to accept connections via the Virtual IP and distribute them to the backend web nodes. This configuration should be identical on both Load Balancer 1 and Load Balancer 2.

Edit /etc/haproxy/haproxy.cfg:

frontend http_front
    bind 192.168.1.100:80
    mode http
    default_backend web_servers

backend web_servers
    mode http
    balance roundrobin
    option httpchk GET /health HTTP/1.1\r\nHost:\ localhost
    default-server inter 3s fall 3 rise 2
    server web01 192.168.1.21:80 check
    server web02 192.168.1.22:80 check

In this setup, HAProxy monitors the health of your backend web servers every 3 seconds (inter 3s). If a backend server fails 3 consecutive health checks (fall 3), it is dynamically pulled out of rotation until it passes 2 consecutive successful checks (rise 2).

Step 5: Initialization and Validation Testing

Enable and start the services on both proxy nodes, beginning with the MASTER:

sudo systemctl enable keepalived haproxy
sudo systemctl start keepalived
sudo systemctl start haproxy

To verify that the Virtual IP has successfully bound to the MASTER server, run ip addr show eth0. You should see the VIP (192.168.1.100) listed along with the main interface IP. On the BACKUP node, running the same command should show only its native IP.

Simulating Failover: Testing the Redundancy

To guarantee that your high-availability cluster operates seamlessly during an actual production incident, you must perform validation testing. Execute a manual failover by stopping the HAProxy service on your MASTER load balancer:

sudo systemctl stop haproxy

Monitor the system log files on the BACKUP node using sudo tail -f /var/log/syslog. You will see Keepalived detect the MASTER's state change and instantly transition the BACKUP to the MASTER state, assuming ownership of the Virtual IP. Throughout this entire transition, external web clients executing requests will experience zero dropped packets or connection timeouts.

Conclusion: Embracing Continuous Availability

Deploying a High-Availability Reverse Proxy cluster using HAProxy and Keepalived is one of the most effective infrastructure investments a technology team can make. By abstracting your application nodes behind a resilient, redundant entry point managed by a Virtual IP, you effectively insulate your clients from system infrastructure volatility. Whether mitigating routine hardware maintenance or abrupt kernel faults, this setup ensures that your business stays online, user retention remains steady, and your operations achieve a robust, high-availability baseline.

Building a Zero-Downtime Infrastructure: Configuring a High-Availability Reverse Proxy with HAProxy and Keepalived | DPTCloud