HAProxy: Complete Guide to Layer 7 Web Load Balancing on Ubuntu

Deploy HAProxy in 5 Minutes

If you need a traffic controller up and running quickly for testing, this is the fastest route. I often use this method to verify connectivity before diving into more complex configurations.

1. Installation

sudo apt update
sudo apt install haproxy -y

2. Basic Load Balancing Configuration

Open the configuration file using the command:

sudo nano /etc/haproxy/haproxy.cfg

Paste the following code at the end of the file. Don’t forget to replace the IPs 192.168.1.10 and 192.168.1.11 with the actual IP addresses of your backend nodes:

frontend http_front
    bind *:80
    default_backend web_servers

backend web_servers
    balance roundrobin
    server web1 192.168.1.10:80 check
    server web2 192.168.1.11:80 check

3. Enable the Service

sudo systemctl restart haproxy

Done! Now try accessing the HAProxy server’s IP. You will see traffic being distributed alternately between the two backend servers.

Why Choose HAProxy for Layer 7?

I used to wonder: if Nginx can also work as a Load Balancer, why install HAProxy? The answer lies in specialization. HAProxy is designed for one thing only: Orchestration. It can handle tens of thousands of concurrent connections while consuming very little CPU resources.

The Power of Layer 7 (Application Layer)

Think of HAProxy as an intelligent dispatcher. At Layer 4, it only knows IPs and Ports. But at Layer 7, it can inspect deep into the HTTP packet to understand what the client is requesting.

For example: You can route all image requests (.jpg, .png) to a dedicated storage server cluster, while heavy API calculation requests go to a cluster with more powerful CPUs. Layer 4 simply cannot do this.

The Three Pillars of Configuration

• Frontend: The entry point. Where you define the IP, Port, and SSL certificates.
• Backend: The service team. This is the group of actual servers handling application logic.
• ACL (Access Control List): The condition filter. Based on these rules, it decides which client goes to which backend.

Real-world Production Configuration

When deploying for a real system, the “Quick start” configuration above is not enough. You need monitoring tools so you don’t have to stay up all night babysitting the system.

1. Monitoring Dashboard (Stats)

HAProxy comes with a built-in visual dashboard. It shows you which servers are healthy, which are overloaded, or which have hung. Add this to your configuration file:

listen stats
    bind *:8080
    stats enable
    stats uri /stats
    stats refresh 30s
    stats auth admin:very_hard_password  # Please change this password immediately

Access http://YOUR_IP:8080/stats to monitor real-time charts.

2. Health Check: Ensuring Backend Integrity

Don’t just check if port 80 is open, because sometimes the web server is running but the application inside has crashed (500 error). I usually configure HAProxy to send an actual HTTP request for health checks:

backend web_servers
    balance leastconn # Route to the server with the fewest connections
    option httpchk GET /health_check.php
    http-check expect status 200
    server web1 192.168.1.10:80 check inter 2s fall 3 rise 2
    server web2 192.168.1.11:80 check inter 2s fall 3 rise 2

The inter 2s parameter means check every 2 seconds. If it fails 3 times (fall 3), HAProxy will remove that server from the active list to prevent users from encountering errors.

Common Issues and Solutions

Here are two classic mistakes that almost everyone makes when setting up HAProxy for the first time.

Losing the Client’s Real IP

By default, backend web servers only see the IP of the HAProxy instance. This makes traffic statistics or spam blocking meaningless. To fix this, add option forwardfor.

backend web_servers
    option forwardfor
    # Don't forget to configure real_ip on the Nginx/Apache backend side

Sticky Sessions: Retaining Users

If your application stores sessions on the server (instead of using Redis), a user logged into server 1 who gets pushed to server 2 will be immediately logged out. The simplest solution is to use an identifier cookie:

backend web_servers
    balance roundrobin
    cookie SERVERID insert indirect nocache
    server web1 192.168.1.10:80 check cookie s1
    server web2 192.168.1.11:80 check cookie s2

HAProxy will attach a small cookie to the browser to ensure that the next time the visitor returns, they are directed to the same server.

Conclusion

Deploying HAProxy isn’t too difficult; the challenge is configuring it for high load and stability. A quick tip: always run haproxy -c -f /etc/haproxy/haproxy.cfg to check for syntax errors before restarting. A single misplaced character can bring down your entire system!