Mastering HAProxy: Deep Dive into TCP/HTTP Load Balancing, Configuration & Debugging

Introduction

The session, presented by HAProxy veteran Godbach, covers HAProxy fundamentals, version information, core features, configuration patterns, and troubleshooting techniques.

HAProxy Versions

Current development version is 1.7, stable version 1.6. HAProxy operates at the application layer, supporting both IPv4 and IPv6. Access the official site via HTTPS.

Connection Modes and Closing Strategies

HAProxy handles each client request using two TCP connections. It offers five connection‑close modes:

keep‑alive (default): connections remain open after a request.

tunnel: only the first request/response is processed; the rest is forwarded directly.

passive: both sides add Connection: close header; the endpoint decides.

server‑close: response is sent, then the server side is closed while the client may stay alive.

force‑close: both client and server connections are actively terminated.

Server‑close and force‑close aim to quickly release backend real‑server resources.

Deployment Overview

The official HAProxy deployment diagram (image omitted) outlines typical architecture.

Key Features

Load‑balancing algorithms include: roundrobin (dynamic weight adjustment) static‑rr (static weight, highest performance) leastconn (suitable for long‑lived TCP connections like LDAP, SQL)

Various hash‑based methods (source IP, URI, URI parameters, arbitrary header) to ensure request affinity.

Persistence allows binding a client IP to a specific real server, optionally with timeout handling.

Cookie handling supports several modes:

cookie insert – inserts a cookie with the real‑server ID.

cookie prefix – adds the ID as a prefix for single‑cookie environments.

cookie rewrite – rewrites the cookie value to the real‑server ID.

Content Routing maps requests to different back‑ends (e.g., dynamic vs. static resources) using ACLs.

Header & URL rewriting can modify request/response headers, perform HTTP redirects, and rewrite URIs. A noted pitfall: sequential replace directives may fail if earlier replacements alter the ACL condition for later ones.

Configuration Examples

Five practical examples were demonstrated:

Typical configuration – defines global, defaults, frontend, and backend sections; multiple frontends can share backends; listen combines both.

Dynamic (hot) configuration – modifies HAProxy settings without restarting, using the doc/management.txt management interface to view sessions, memory usage, etc.

Multi‑process setup – each process handles the same workload (unlike Nginx master/worker). To avoid the epoll “thundering herd” problem, bind each process to a distinct socket, improving performance and reducing load.

HAProxy HA synchronization – persists stick‑table entries (e.g., source‑IP to real‑server mapping) across instances, enabling seamless failover.

Statistics page – a built‑in C‑generated HTML page that visualizes runtime metrics; useful for quick health checks.

Debugging & Management

The management.txt document (HAProxy 1.6) details start/stop commands, runtime inspection via Unix socket, and troubleshooting techniques such as packet capture. The mailing list remains an active support channel.

Live Q&A Highlights

HAProxy does not retry on HTTP 5xx/4xx errors after a successful TCP handshake.

HAProxy operates at layer 7; it is not a pure layer‑4 balancer.

Health checks are essential for backend reliability; file synchronization is better handled by distributed file systems or rsync, not HAProxy.

Multi‑process mode requires careful CPU‑map configuration; some features (stick tables, stats page) have limited multi‑process support.

Compared with Nginx, HAProxy generally offers superior raw performance, though recent Nginx improvements narrow the gap.

Conclusion

The session provided a thorough overview of HAProxy’s capabilities, from basic concepts to advanced configuration and debugging, equipping practitioners with practical knowledge to deploy and maintain high‑performance load‑balancing solutions.