Building a High-Availability Reverse Proxy with HAProxy and Keepalived: The Zero-Downtime Infrastructure Strategy for Critical Landing Pages

Introduction: The Cost of Downtime in the Conversion Funnel

In the digital economy, traffic is currency. When your enterprise launches a high-stakes marketing campaign, pushes a product announcement, or executes a global ad spend, the destination is almost always a dedicated landing page. However, many infrastructure architects overlook a critical vulnerability: the Single Point of Failure (SPOF).

Imagine thousands of concurrent prospects clicking your links, only to be met with a 502 Bad Gateway or a connection timeout because your standalone proxy server buckled under the load or suffered a hardware failure. The financial repercussions are immediate: wasted ad budget, skewed analytics, and damaged brand reputation. To safeguard your conversions, you must design for resilience. This technical guide explores how to configure a High-Availability (HA) Reverse Proxy architecture utilizing two industry-standard open-source tools: HAProxy and Keepalived. By deploying this dual-node infrastructure on Virtual Private Servers (VPS), you can guarantee zero-downtime availability for your business-critical landing pages.

Architectural Overview: Understanding the High-Availability Layer

Before diving into the configuration files, it is vital to understand the structural mechanics of a high-availability topology. A traditional architecture relies on a single reverse proxy routing traffic to multiple backend web servers. While this scales processing power, the proxy itself remains an SPOF. If that server fails, the entire application collapses.

The high-availability paradigm solves this by introducing redundancy at the routing layer. The infrastructure requires:

• Two Independent VPS Instances: Designated as the Primary (Master) node and the Secondary (Backup) node.
• Keepalived (VRRP Layer): A routing software based on the Virtual Router Redundancy Protocol (VRRP). It binds a single, public Virtual IP (VIP) to the Master node. If the Master fails, the VIP dynamically shifts to the Backup node within milliseconds.
• HAProxy (Load Balancing Layer): A high-performance, layer-4 and layer-7 load balancer that intercepts traffic arriving at the VIP and distributes it efficiently across your backend landing page application servers.

Under normal operating conditions, all inbound public traffic targets the VIP and is processed by the Master HAProxy node. The Backup node remains in a hot-standby state, continuously listening for health heartbeats from the Master. If the Master encounters a hardware breakdown, network disruption, or service failure, the Backup node claims the VIP instantly, maintaining uninterrupted user sessions.

Phase 1: Prerequisite Planning and Environmental Setup

To implement this blueprint, secure two Linux VPS instances within the same data center network (ideally supporting private IP routing) and a single unassigned Virtual IP/Floating IP provided by your infrastructure provider. For this guide, we assume a Debian/Ubuntu environment with the following network configurations:

• VPS-01 (Master Node): Public IP: 192.168.10.11 / Private IP: 10.0.0.11
• VPS-02 (Backup Node): Public IP: 192.168.10.12 / Private IP: 10.0.0.12
• Virtual IP (VIP): Public IP: 192.168.10.100
• Backend Application Servers: Web-01 (10.0.0.51) and Web-02 (10.0.0.52)

Begin by updating the package repositories and installing HAProxy and Keepalived on both nodes concurrently. Execute the following terminal commands:

sudo apt-get update
sudo apt-get install -y haproxy keepalived

System Optimization Note: To allow services to bind to the Virtual IP address before it is explicitly assigned to the physical network interface of a specific node, you must enable non-local binding in the Linux kernel parameters. Add the following line to /etc/sysctl.conf on both servers:
net.ipv4.ip_nonlocal_bind=1
Run sudo sysctl -p to apply the changes without rebooting.

Phase 2: Configuring Layer-7 Load Balancing with HAProxy

With the packages installed, we will first configure HAProxy to act as our intelligent reverse proxy layer. This configuration must be mirrored closely on both nodes to ensure consistent load-balancing algorithms and health checks.

Open the primary configuration file located at /etc/haproxy/haproxy.cfg and define the frontend and backend blocks as follows:

global
    log /dev/log local0
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    user haproxy
    group haproxy
    daemon

defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    timeout connect 5000ms
    timeout client  50000ms
    timeout server  50000ms

frontend landing_page_frontend
    bind 192.168.10.100:80
    bind 192.168.10.100:443 ssl crt /etc/ssl/certs/landingpage.pem
    mode http
    option forwardfor
    http-request set-header X-Forwarded-Proto https
    default_backend landing_page_backend

backend landing_page_backend
    mode http
    balance roundrobin
    option httpchk GET /health-check.php HTTP/1.1\r\nHost:\ localhost
    default-server inter 3s fall 3 rise 2
    server web01 10.0.0.51:80 check
    server web02 10.0.0.52:80 check

listen stats
    bind 127.0.0.1:9000
    mode http
    stats enable
    stats uri /haproxy_stats
    stats auth admin:SecurePassword123

In this configuration, the frontend explicitly binds to the Virtual IP address (192.168.10.100) on ports 80 and 443. The backend section implements a round-robin load-balancing algorithm that routes incoming requests equally between your backend web nodes. Crucially, the option httpchk directive enforces synthetic health verification by polling a lightweight script (/health-check.php) on the backend web servers every three seconds. If a backend node fails two consecutive checks, HAProxy temporarily drains traffic away from it until it passes two consecutive successful checks.

Phase 3: Injecting Infrastructure Failover Redundancy via Keepalived

Now that HAProxy is configured to handle traffic arriving at the VIP, we must implement the automated failover mechanism using Keepalived. This service manages who owns the VIP based on a prioritized health score.

Step 1: Configuring the Master Node (VPS-01)

Create or overwrite the configuration file at /etc/keepalived/keepalived.conf on your primary VPS:

vrrp_script chk_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 SECRETPASS123
    }
    virtual_ipaddress {
        192.168.10.100
    }
    track_script {
        chk_haproxy
    }
}

Step 2: Configuring the Backup Node (VPS-02)

Next, configure the matching file on your secondary VPS, adjusting the state, priority, and weight parameters:

vrrp_script chk_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 SECRETPASS123
    }
    virtual_ipaddress {
        192.168.10.100
    }
    track_script {
        chk_haproxy
    }
}

Let us analyze the core settings of this logic engine:

• chk_haproxy Script: A proactive tracking script running a lightweight killall -0 haproxy command every 2 seconds. It checks if the daemon is alive. If the local HAProxy service crashes, Keepalived dynamically drops the node's routing priority score.
• virtual_router_id: A shared identifier (must be identical on both nodes) that forms the VRRP broadcast group.
• Priority: The node with the highest baseline priority owns the VIP. The Master node possesses a baseline of 101, while the Backup sits at 100. If the Master's HAProxy daemon stops, its priority falls below 100, prompting the Backup to instantly claim ownership of the VIP.

Phase 4: Executing System Tests and Validating Failover Mechanics

With both service layers defined, start and enable the systems on both servers:

sudo systemctl restart haproxy
sudo systemctl restart keepalived
sudo systemctl enable haproxy
sudo systemctl enable keepalived

To ensure your infrastructure handles real-world crashes seamlessly without degrading user experience, you must simulate failures. Execute the following validation protocols:

1. Initial VIP Allocation Verification

Run the command ip addr show eth0 on the Master server. You should observe the Virtual IP address 192.168.10.100 successfully assigned to the interface. Run the exact same command on the Backup server; the VIP should not be present.

2. Simulating a Service Outage

To simulate a application crash on the Master node, stop its HAProxy service explicitly:

sudo systemctl stop haproxy

Monitor the system syslog files on the Backup server simultaneously via sudo tail -f /var/log/syslog. You will see Keepalived register the Master's transition into a fault state. The output will show lines similar to:

Keepalived_vrrp[1234]: VRRP_Instance(VI_1) Entering MASTER STATE

Run ip addr show eth0 on the Backup server. The VIP has safely migrated to the secondary host. Perform an external curl test or refresh your landing page browser tab. You will find that traffic continues to serve effortlessly with absolute zero downtime.

Conclusion: Embracing High Availability for Business Growth

Architecting an HAProxy and Keepalived cluster transforms a fragile single-server setup into an enterprise-grade, highly resilient infrastructure. While it requires extra planning and minimal monthly overhead for an additional VPS node, the peace of mind it provides during major marketing campaigns is invaluable. By eliminating single points of failure at the edge layer, you ensure that every marketing dollar spent translates directly to functional web interactions, protecting your customer acquisition funnel and optimizing long-term digital ROI.