What is HAProxy?
Author: Domeny.ForSale editorial team Published
In brief: HAProxy is software that accepts network traffic and forwards it to selected servers running an application. It acts as a reverse proxy and load balancer: it intermediates connections and distributes traffic across service instances. It helps handle higher loads and bypass failed servers, but deploying HAProxy alone does not guarantee uninterrupted availability.
How HAProxy works between the user and the application
A reverse proxy accepts connections on behalf of application servers. The user connects to the service address backed by HAProxy, rather than directly to a particular backend server. HAProxy selects a destination and forwards traffic there, and the response returns through the same intermediary layer.
Load balancing means distributing traffic across available servers. It does not necessarily mean an exactly equal split: a more powerful machine may receive more work, while a server undergoing maintenance may be excluded from handling new requests.
There are two important concepts in HAProxy configuration. A frontend defines where the program accepts connections, for example on port 443 for HTTPS. A backend describes a group of destination servers and the rules for selecting them. One frontend can route traffic to different backends depending on the domain or URL path.
Handling TCP, HTTP and encryption
HAProxy can operate at different communication layers. In TCP mode, it forwards connections without making decisions based on the contents of HTTP requests. This approach is also useful for services other than websites, provided they use TCP.
In HTTP mode, HAProxy understands request elements such as the hostname, path and headers. It can therefore route traffic for /api to API servers and other requests to the application that serves the website. These rules are often expressed as ACLs: conditions that match traffic against specific rules.
With HTTPS, an important consideration is where TLS—the protocol that secures the connection—is terminated:
- TLS termination at HAProxy: the program handles the certificate and decrypts traffic, allowing it to inspect HTTP. The connection to the backend can be encrypted again.
- Passing through the encrypted connection: the destination server handles TLS. HAProxy then cannot see HTTP paths or headers, so it cannot use them for routing.
Terminating TLS at HAProxy does not automatically mean that the connection to the application is encrypted. That part of the connection must be configured separately, including verification of the destination server’s certificate.
How distributing traffic helps during failures
Imagine an online shop running on three application servers. HAProxy accepts customer requests and distributes them using round robin, which sends them to available servers in turn. An alternative is least connections, for example, which favours the server with fewer active connections; the choice of method depends on the nature of the traffic.
HAProxy can perform health checks: periodic tests of backend availability. When one server stops passing these checks, the program can stop assigning new traffic to it, leaving the remaining machines to handle requests. However, active connections to the failed server may be interrupted.
A test that simply checks whether a port is open does not confirm that the shop can process an order. An HTTP check of a dedicated application health endpoint that signals readiness is often more appropriate. The scope of the check needs to be chosen carefully: a check that is too superficial will miss a failure, while one that is too restrictive may unnecessarily take healthy instances out of service.
Distributing traffic also requires an appropriately designed application. If a customer’s basket is stored only in one server’s memory, a subsequent request sent to another machine may be unable to restore it. A shared session store helps; pinning a client to a server, known as sticky sessions, does not protect session data against that machine failing.
How HAProxy differs from a web server
HAProxy’s main task is to act as a communication intermediary and manage traffic, rather than perform typical tasks such as serving website files or running application code. In practice, it sits in front of web servers or application processes that generate responses. Nor does it replace a database or its replication mechanism.
NGINX and Apache HTTP Server can also act as reverse proxies while serving as web servers. The choice therefore does not come down to asking which tool is better overall. HAProxy is a reasonable candidate when you need a separate layer for TCP or HTTP load balancing, backend health checks and connection-routing rules.
For a single small website, an existing web server or a cloud provider’s load balancer may be sufficient. Adding HAProxy introduces another component that requires updates, monitoring and configuration maintenance.
What to check before deployment
A single HAProxy instance can become a single point of failure: if it becomes unavailable, users will lose access even to healthy application servers. A system that requires high availability also needs redundant proxy instances and a mechanism for switching traffic between them.
Before going live in production, check four things:
- Backend checks: do they detect when the application is not ready, rather than merely checking that a port is working?
- Limits and timeouts: how many connections will the system accept, and how long will it wait for a response?
- Client address: how will the application receive the real IP address, and which proxy headers can it trust?
- Observability: do logs and metrics allow you to identify errors, delays and overload?
Confirm feature availability and configuration syntax in the official documentation for the HAProxy version you use. Run your first test with two application instances: shut one down during controlled traffic and check both the proxy’s response and how user sessions behave.
See also: What is 2FA?
Read also
