Configure HAProxy for L4 TCP & L7 HTTP Load Balancing

Load balancing is a core component of high‑availability architectures. Whether you serve static sites, APIs, or complex web applications, spreading traffic across multiple backend servers improves performance, resilience, and scalability. HAProxy is a proven, open‑source solution that handles both Layer 4 (TCP) and Layer 7 (HTTP) traffic with minimal overhead. This guide walks through installing HAProxy, configuring TCP and HTTP load balancing, and verifying that traffic is correctly distributed across two web‑server pools.

1. Install HAProxy

HAProxy is included in the default repositories of most Linux distributions. Follow the steps that match the operating system of your AtoZNode VPS or dedicated server.

Debian / Ubuntu (apt)

# Refresh the local package index
sudo apt update

# Install HAProxy and its dependencies
sudo apt install -y haproxy

# Show the installed version
haproxy -v

What each command does:

• apt update – updates the local list of available packages.
• apt install haproxy – installs the HAProxy binary, systemd unit, and required libraries.
• haproxy -v – prints the HAProxy version, confirming a successful installation.

AlmaLinux / Rocky Linux / RHEL (dnf)

# Enable the EPEL repository (contains HAProxy)
sudo dnf install -y epel-release

# Install HAProxy
sudo dnf install -y haproxy

# Verify the installation
haproxy -v

Explanation:

• dnf install epel-release – adds the Extra Packages for Enterprise Linux repository, which provides HAProxy.
• dnf install haproxy – installs the HAProxy package and its service files.
• haproxy -v – displays the installed version.

2. HAProxy Configuration Overview

The main configuration file is /etc/haproxy/haproxy.cfg. It is divided into four sections:

1. global – process‑wide settings (user, max connections, logging).
2. defaults – default values inherited by all frontend and backend blocks.
3. frontend – defines where HAProxy listens for client connections.
4. backend – defines the pool of servers that will handle the traffic.

The following minimal global and defaults blocks work for both TCP and HTTP use cases.

# /etc/haproxy/haproxy.cfg
global
    log /dev/log    local0
    log /dev/log    local1 notice
    daemon
    maxconn 2000
    user haproxy
    group haproxy

defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    timeout connect 5s
    timeout client  30s
    timeout server  30s
    retries 3

The mode http setting in defaults can be overridden per‑frontend with mode tcp when you need Layer 4 load balancing.

3. Layer 4 TCP Load Balancing

TCP load balancing is ideal for services such as MySQL, PostgreSQL, SMTP, or any custom protocol that does not require HTTP inspection. The example below balances MySQL traffic on port 3306 across two backend servers.

Frontend (TCP)

frontend mysql_frontend
    bind *:3306
    mode tcp
    default_backend mysql_back

Backend Pool

backend mysql_back
    mode tcp
    balance roundrobin
    option tcp-check
    server db1 10.0.1.11:3306 check fall 3 rise 2
    server db2 10.0.1.12:3306 check fall 3 rise 2

Key directives explained:

• bind *:3306 – HAProxy listens on all interfaces for TCP port 3306.
• mode tcp – disables HTTP parsing; traffic is treated as raw TCP.
• balance roundrobin – distributes connections evenly across servers.
• option tcp-check – performs a simple TCP connect test to verify backend health.
• check fall 3 rise 2 – marks a server down after three consecutive failures and up after two successes.

4. Layer 7 HTTP Load Balancing

For web traffic HAProxy can inspect HTTP headers, route based on URL paths, and optionally terminate SSL. The configuration below sets up an HTTP load balancer on port 80 that directs general web requests to one pool and API requests to another.

Frontend (HTTP)

frontend http_frontend
    bind *:80
    mode http
    acl is_api path_beg /api
    use_backend api_back if is_api
    default_backend web_back

Backend – General Web Traffic

backend web_back
    mode http
    balance leastconn
    option httpchk GET /health
    server web1 10.0.2.21:80 check
    server web2 10.0.2.22:80 check

Backend – API Requests

backend api_back
    mode http
    balance roundrobin
    option httpchk GET /api/health
    server api1 10.0.3.31:80 check
    server api2 10.0.3.32:80 check

Explanation of the HTTP blocks:

• acl is_api path_beg /api – creates an access‑control list that matches any URL beginning with /api.
• use_backend api_back if is_api – routes matching requests to the API pool.
• balance leastconn – sends new connections to the server with the fewest active sessions, suitable for typical web pages.
• option httpchk GET /health – issues an HTTP GET request to /health on each backend; a 2xx response marks the server as healthy.

5. Enable and Test the Configuration

Validate the syntax

# Run on both Debian/Ubuntu and AlmaLinux/Rocky
sudo haproxy -c -f /etc/haproxy/haproxy.cfg

If the output reads Configuration file is valid, you can proceed.

Restart the service

# Systemd‑based systems (both families)
sudo systemctl restart haproxy
sudo systemctl enable haproxy   # start automatically on boot

Test TCP balancing

From a client machine, connect to the HAProxy host:

telnet your-haproxy-ip 3306

Repeated connections should alternate between the two backend IPs (check MySQL logs or run netstat -tnp on the HAProxy host to verify).

Test HTTP balancing

Use a browser or curl:

curl http://your-haproxy-ip/
curl http://your-haproxy-ip/api/status

Inspect the response or add a custom header (e.g., X-Backend: web1) on each web server to confirm which backend served the request.

6. Optional Enhancements

• SSL termination – add bind *:443 ssl crt /etc/ssl/haproxy.pem to the HTTP frontend and keep backend connections on plain HTTP.
• Sticky sessions – for stateful applications, include cookie SERVERID insert indirect nocache in the backend and cookie SERVERID on each server line.
• Health‑check tuning – adjust inter, fall, and rise values to match your application’s response characteristics.
• Logging – configure rsyslog or the systemd journal to capture HAProxy logs for troubleshooting.

Conclusion

HAProxy offers a flexible, high‑performance platform for both Layer 4 TCP and Layer 7 HTTP load balancing. By installing the package from the native repositories, defining clear frontend and backend sections, and using appropriate health checks, you can build a resilient front‑end for any web‑server pool hosted on AtoZNode. The same configuration works on Debian/Ubuntu and AlmaLinux/Rocky systems, keeping your infrastructure consistent across different VPS or dedicated‑server deployments.