HAProxy:
what reading the request really unlocks
Reading the request unlocks URL routing, encryption termination and a health check that finally checks something. In exchange you add a piece to the path of every request — and it has to be made redundant.
Table of contents
1. Two modes, and the choice is made early
HAProxy runs in TCP mode, relaying a connection without interpreting it, and in HTTP mode, where it reads and understands every request. This is not a configuration detail: the two modes do not offer the same functions, and changing your mind later means reworking the configuration.
TCP mode
Useful for everything that is not web: a database, a directory, a line-of-business service. You gain weighting and a health check finer than an open port — HAProxy can, for instance, open an application session to verify it answers. It is also the mode that lets you balance a database read stream when the application already separates its connections.
HTTP mode
The mode that really justifies HAProxy. The request is parsed, therefore usable as a criterion: URL, header, method, cookie. That is what allows routing, rewriting, filtering and measuring — at the cost of heavier processing and a configuration that lives.
2. What reading the request unlocks
- • Routing by URL. One entry point, several applications behind it:
/apito one group of servers,/staticto another. It is the most requested function, and it is structurally impossible at layer 4. - • Terminating encryption in one place. One set of certificates to renew instead of one per machine — an operational gain that compounds over time.
- • Rewriting and normalising. Adding the real client address in a header, forcing a redirect, stripping a header that says too much about the server version.
- • Observing. HAProxy exposes detailed per-target state: connections, errors, response times. It is often the first honest visibility a team gets on its own traffic.
3. The health check that actually checks
This is the most important difference from layer 4, and often the one that decides the move. A TCP check verifies that a port accepts connections. A server returning an error on every request passes it effortlessly, and the balancer dutifully keeps sending it traffic.
backend application
balance roundrobin
option httpchk GET /health
http-check expect status 200
# pulled after 3 failures, restored after 2 successes
default-server inter 3s fall 3 rise 2
server app1 10.0.0.11:8080 check weight 100
server app2 10.0.0.12:8080 check weight 50What belongs behind /health
An endpoint returning 200 without checking anything is worth no more than a port check. A good health check exercises the dependencies the application needs to work — its database, its cache, its storage — and fails if one is missing. It is a few lines of application work, and it is what gives everything else its value. Without it, you paid for layer 7 and got a layer-4 check.
4. Sticky sessions, if you really must
HAProxy can set a cookie so a client always lands on the same instance. It is the function people come for when an application keeps session state in local memory — and it is also the one you would rather not need.
What you accept by enabling it
- • Distribution becomes uneven: one instance can concentrate the long sessions
- • Losing one instance disconnects all its users while the service stays up
- • Updating a node means waiting for its sessions to expire, or sacrificing them
Our first proposal is always the same: move state out of the application, into a database or a shared cache, so any instance can serve any user. It is often modest work, and it removes the problem instead of relocating it. When that is not an option we add stickiness — knowing what we are buying.
5. Make HAProxy redundant, or nothing was gained
This is the point on which we do not compromise. A single HAProxy in front of six application servers does not improve availability: it has actually degraded it, since the service now depends on one more machine, and that one sits on the path of every request.
The standard design is therefore two HAProxy instances and a floating address, with a health check triggering failover if the process dies. You come back exactly to level 2 of our high-availability architectures: balancing rests on availability, it does not replace it.
What we monitor afterwards
A perfectly healthy balancer in front of two dead servers returns errors perfectly. The check that matters is therefore not "is HAProxy answering?" but "how many targets are still alive?". We track that number, the actual distribution across targets, and the gap between what the configuration intends and what happens.
Frequently asked questions
HAProxy or nginx for balancing?
Both can do it, and the choice mostly depends on what else the machine does. If it also serves files or hosts an application, nginx avoids adding a component. If its only job is balancing, HAProxy offers finer control over health checks, queueing and traffic observation — that is what it was built for.
Should TLS terminate on HAProxy or on the servers?
On HAProxy in the vast majority of cases: one place to renew certificates, and the ability to route by URL, which requires seeing the request in clear. You keep encryption all the way to the servers when a compliance requirement demands it — but then you accept losing URL routing, or re-encrypting behind.
What happens if every target fails its health check?
HAProxy returns an immediate error rather than making the client wait, which is the right behaviour: a clean failure beats a timeout. But it also means an over-strict health check can pull everyone and turn a partial incident into a total outage. Removal and restoration thresholds are tuned with that possibility in mind.
How much traffic can one HAProxy take?
Far more than most infrastructures send it — the limiting factor is almost always encryption, not balancing. In practice the question to ask is not raw capacity but behaviour when one of the two balancers is lost: the survivor has to take all of it, not half.
Is your balancer alone on the path?
A single HAProxy in front of six servers does not improve availability, it degrades it. We audit what you have and say so plainly.
Get a quote