HAProxy Load Balancing: High Availability for Web Apps (2026)

Modern IT infrastructure constantly faces pressure to deliver high performance and availability. I personally managed a scenario where an e-commerce platform received 3,000 requests per second on a single backend server. The server was at 95% CPU utilization, and the risk of a service interruption was imminent. In such situations, a single point of failure is not an option. This is where load balancing solutions like HAProxy come into play, distributing traffic across multiple servers to ensure scalability and resilience. Implementing HAProxy with three backend servers and the leastconn algorithm reduced CPU utilization from 95% on a single node to 30% on each of the three nodes, with active health checks every two seconds and completely transparent failover for users. This article will explore how to configure HAProxy to achieve these goals, from basic setup to high availability with Keepalived.

Prerequisites / Test Environment

To follow this guide, you will need:

• Two or more Linux servers (e.g., Ubuntu 24.04 LTS, CentOS Stream 9) for application backends.
• A dedicated Linux server for HAProxy.
• An additional Linux server for Keepalived (if implementing high availability).
• sudo access on all servers.
• Basic knowledge of networking and Linux.

HAProxy vs. Nginx as a Load Balancer: A Practical Comparison

Both HAProxy and Nginx are excellent tools for load balancing, but they have different philosophies and strengths. The choice depends on the specific needs of your environment.

HAProxy (High Availability Proxy) is an extremely high-performance and robust TCP/HTTP load balancer and proxy. It is optimized for resilience and handling high traffic loads. Its strength lies in its ability to manage thousands of concurrent connections with a small memory footprint. It is often the preferred choice for critical scenarios where pure balancing performance and high availability are priorities.

Nginx is a web server, reverse proxy, HTTP cache, and also a load balancer. It is extremely versatile and can fulfill multiple roles. It excels at serving static content, caching, and as a general reverse proxy. As a load balancer, Nginx is very capable, but in extremely high-traffic scenarios with complex high availability requirements, HAProxy often offers an advantage in terms of performance and specific balancing features.

In summary: if your primary goal is high-performance load balancing and critical high availability, HAProxy is the better choice. If you need a reverse proxy with additional features like caching and static content serving, Nginx can be more versatile. In many enterprise environments, it’s common to find both, with HAProxy balancing Nginx, which in turn balances the application servers.

Installation and haproxy.cfg Structure

Installing HAProxy is straightforward on most Linux distributions.

sudo apt update
sudo apt install haproxy
sudo systemctl enable haproxy
sudo systemctl start haproxy

The main HAProxy configuration file is /etc/haproxy/haproxy.cfg. This file is divided into several sections:

• global: Global settings for the HAProxy process (e.g., logs, user/group, maximum number of connections).
• defaults: Default settings applied to all listen, frontend, and backend sections unless overridden.
• frontend: Defines how HAProxy listens for incoming connections (IP, port, protocol).
• backend: Defines the group of servers to which HAProxy forwards requests.
• listen: A combination of frontend and backend in a single section, useful for simple configurations.

After every modification to the haproxy.cfg file, it is crucial to verify the syntax and reload the service:

haproxy -c -f /etc/haproxy/haproxy.cfg
sudo systemctl reload haproxy

Frontend and Backend: Traffic Routing

The core of HAProxy configuration lies in the frontend and backend sections.

A frontend defines the public interface of HAProxy, specifying which IP and port to listen on and which rules to apply for routing traffic. A backend is a group of real servers (your web servers, application servers, databases) that HAProxy will use to distribute the load.

Here’s an example of a basic configuration:

# haproxy.cfg base
frontend http_front
    bind *:80
    mode http
    default_backend http_back

backend http_back
    mode http
    balance roundrobin
    server web1 192.168.1.10:80 check
    server web2 192.168.1.11:80 check
    server web3 192.168.1.12:80 check

In this example, frontend http_front listens on port 80 on all interfaces (*:80) and forwards all traffic to backend http_back. The backend http_back contains three servers (web1, web2, web3) with their respective IPs and ports. The mode http directive tells HAProxy to operate at Layer 7 (HTTP), enabling advanced features like HTTP header analysis. For Layer 4 (TCP) balancing, you would use mode tcp.

Balancing Algorithms: roundrobin, leastconn, source

HAProxy offers several algorithms to distribute traffic. Choosing the right algorithm is crucial for optimizing performance and load equity.

• roundrobin: The default algorithm. Requests are distributed to servers sequentially. It is simple and effective for servers with similar capacities and homogeneous request durations.
• leastconn: Forwards the request to the server with the fewest active connections. Ideal for servers with variable processing times, as it tends to balance the load based on the actual activity of the servers. I used this algorithm in the e-commerce case to optimize load distribution across backend nodes.
• source: Uses the client’s IP address to determine which server to forward the request to. This ensures that a given client is always directed to the same server, useful for applications requiring “sticky sessions” without managing cookies.
• first: Forwards requests to the first available server in the list, moving to the next only if the first is inactive. Useful for active/passive scenarios.

The balance directive in the backend defines the algorithm. For example, balance leastconn.

Active and Passive Health Checks

Health checks are fundamental for high availability. HAProxy regularly verifies the status of backend servers and automatically removes unresponsive ones from the pool, preventing service disruptions. As soon as a server comes back online, it is reintegrated.

• Active checks: Specified with the check keyword next to the server definition. HAProxy sends specific requests (e.g., TCP connect, HTTP GET) to the servers and evaluates the response.

    server web1 192.168.1.10:80 check inter 2s fall 3 rise 2

Here, inter 2s indicates a 2-second interval between checks, fall 3 means the server will be marked down after 3 consecutive failures, and rise 2 means it will be reintegrated after 2 consecutive successes.

• Passive checks: HAProxy monitors server behavior based on real connections. If a server responds with too many errors or timeouts, it can be temporarily removed.

SSL Termination with Let’s Encrypt

Terminating SSL/TLS connections on HAProxy is a common practice. This reduces the load on backend servers, which no longer need to handle encryption, and simplifies certificate management by centralizing it at a single point. For certificates, Let’s Encrypt is a free and automated solution.

To enable SSL termination on HAProxy, you will need to:

1. Obtain a Let’s Encrypt certificate (e.g., with certbot).
2. Combine the certificate and private key into a single .pem file.
3. Configure the frontend to listen on port 443 and use the certificate.

# Example of SSL termination
frontend https_front
    bind *:443 ssl crt /etc/haproxy/certs/mydomain.pem
    mode http
    default_backend http_back

backend http_back
    # ... (backend servers)

The mydomain.pem file should contain the full certificate (domain certificate, intermediate certificates) and the private key, concatenated in that order.

Stats Page: Real-time Monitoring

HAProxy includes an integrated stats page that provides a real-time overview of the status of frontends, backends, and servers, including the number of connections, bytes transferred, errors, and health check status. It is an indispensable tool for troubleshooting and monitoring.

To enable it, add a specific listen section:

listen stats
    bind *:8080
    mode http
    stats enable
    stats uri /haproxy?stats
    stats realm Haproxy\ Statistics
    stats auth admin:password123
    stats refresh 10s

By accessing http://:8080/haproxy?stats and entering the credentials, you can view the data. For more granular monitoring or integration with external systems, you can query the HAProxy socket:

echo 'show stat' | socat stdio /var/run/haproxy/admin.sock | cut -d',' -f1,2,18

This command shows statistics, filtered by server and status, useful for automation scripts or integration with Grafana/Prometheus. I have often used this method to create custom dashboards in enterprise environments with hundreds of servers.

High Availability with Keepalived and VIP

To eliminate the single point of failure represented by HAProxy itself, it is essential to implement a high availability mechanism. Keepalived is the most common and robust solution for this purpose.

Keepalived uses the Virtual Router Redundancy Protocol (VRRP) to assign a Virtual IP (VIP) to a cluster of servers. One server is the MASTER, the others are BACKUP. If the MASTER fails, the BACKUP takes its place and assumes the VIP, ensuring HAProxy is always available. This is a fundamental requirement for NIS2, which emphasizes the resilience of critical systems. According to the Verizon DBIR 2025, unplanned downtime costs businesses millions of euros annually; preventing these scenarios is an indispensable investment.

Keepalived installation:

sudo apt install keepalived

Example configuration (/etc/keepalived/keepalived.conf) on the MASTER node:

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass mysecretkey
    }
    virtual_ipaddress {
        192.168.1.200/24
    }
    track_script {
        chk_haproxy
    }
}

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

On the BACKUP node, the configuration will be similar, but with state BACKUP and a lower priority (e.g., 90). The virtual_ipaddress is the VIP that clients will use to connect to HAProxy. The track_script chk_haproxy ensures that Keepalived monitors the HAProxy process: if HAProxy fails, Keepalived demotes the node, allowing the backup to take over.

Common Errors and Troubleshooting

• haproxy -c -f /etc/haproxy/haproxy.cfg fails: Carefully check the syntax. Often, these are typos, extra spaces, or misplaced directives. The error message is almost always very specific.
• Backend server unreachable: Verify that the IPs and ports of the servers in the backend are correct and that there are no firewalls (on the HAProxy server or the backends) blocking connections. Use telnet IP PORT from the HAProxy server to test connectivity.
• SSL handshake failed: Ensure that the .pem file contains the full certificate (domain + intermediates) and the private key, in the correct order. Check HAProxy logs for specific errors.
• Keepalived issues: Check Keepalived logs (journalctl -u keepalived) on both nodes. Ensure that the virtual_router_id is the same, the auth_pass matches, and priorities are configured correctly (MASTER > BACKUP). A common error is the VIP not being assigned correctly due to IP conflicts or firewalls.

FAQ — Frequently Asked Questions

What is the main difference between mode http and mode tcp in HAProxy?

mode http operates at Layer 7 (application) of the OSI model, allowing HAProxy to inspect and manipulate HTTP headers, manage cookies, terminate SSL, and apply routing rules based on request content. mode tcp operates at Layer 4 (transport), balancing TCP connections without inspecting content. It is faster but less flexible, ideal for databases or other non-HTTP services.

How can I add new backend servers without downtime?

HAProxy supports configuration reloading without service interruption (sudo systemctl reload haproxy). You can add or remove servers in the haproxy.cfg file and then reload. HAProxy will transparently manage existing connections and start balancing new requests with the updated configuration. For more granular control, HAProxy Enterprise offers dynamic backend management features.

Can HAProxy be used to balance databases like PostgreSQL or MySQL?

Yes, absolutely. To balance databases, you would use mode tcp and an algorithm like leastconn or roundrobin. It is crucial to configure specific health checks for databases, such as verifying connectivity to the database port or executing a basic query, to ensure the database is truly operational and not just listening on the port.

What is the impact of HAProxy on overall performance?

HAProxy is extremely performant, and its overhead is minimal. In typical scenarios, the latency impact is in the order of microseconds. Its efficiency is one reason it is chosen in very high-traffic environments. The benefit of better load distribution and high availability far outweighs the small overhead introduced.

Conclusions with Operational Takeaways

HAProxy is an indispensable tool for any IT environment requiring scalability, performance, and high availability for web applications. Its configuration, though detailed, offers granular control over traffic flow and backend server management. I have seen firsthand how correct HAProxy implementation can transform fragile infrastructure into a robust and resilient system, capable of handling unexpected traffic spikes without service disruptions. Always remember to verify the configuration, monitor statistics, and test failovers. High availability is not a cost, but an essential investment for business continuity.

Read also: Docker Production Security: 10 Overlooked Best Practices (2026)

Read also: Linux Performance Monitoring: 8 Essential Tools Compared

Read also: Cisco IOS Troubleshooting: Metodología y Comandos para Redes (2026)

For further details on advanced configuration and features, consult the official HAProxy documentation.

Updated: July 2026