HAProxy as a TCP/HTTP load balancer on Linux: config testing, seamless reload, and health checks

Goal

Put HAProxy in front of a set of backend servers, verify a new configuration before it takes traffic, reload without dropping connections, and have HAProxy stop sending traffic to a backend that has failed.

Prerequisites

HAProxy installed; at least two backend servers or ports to balance across; the existing configuration file backed up before editing.

Steps

1. Define a frontend binding the public address/port and a backend listing the servers, each server line ending in check to enable health checking. The check option enables health checks on a server; with nothing else configured, HAProxy considers a server available when it can establish a connection at the highest configured transport layer, and takes it out of rotation on failure. For an HTTP-level check add option httpchk to the backend (on 2.2 and later, http-check send meth GET uri /health and http-check expect status 200 refine it).
2. Before reloading, validate the file: haproxy -c -f /etc/haproxy/haproxy.cfg. The -c flag only performs a check of the configuration files and exits before trying to bind, returning a non-zero exit status on error — safe to run against a config that is not yet live.
3. Reload without a connection outage: systemctl reload haproxy (as root). Packaged units run HAProxy in master-worker mode (-Ws); the reload signals the master, which tries to seamlessly reload a new configuration in new worker processes while the old workers finish their existing connections before leaving. Most packaged units run the -c check first and keep the old workers if it fails.
4. Only when running HAProxy by hand without master-worker mode: start the new process with -sf <pid>..., so it sends the finish signal (SIGUSR1) to older processes after boot completion, asking them to finish what they are doing and leave.
5. Tune health-check timing per server as needed (inter, fall, rise; defaults 2s, 3 and 2) to match how quickly a failed backend should leave and return.
6. Watch the runtime state after a change: the stats socket or stats page shows each server's check status (UP/DOWN), so a reload's effect on backend health is visible immediately.

Expected result

haproxy -c -f <file> exits 0 before the running instance is ever reloaded; a reload shows no dropped client connections in the access log; stopping a backend process flips its status to DOWN in the stats output within the configured check interval, and traffic stops going to it.

Limits and test basis

-c validates syntax and internal consistency, not that backend addresses are reachable — a config can pass -c and still send traffic nowhere if a backend address or port is wrong. The graceful reload keeps old connections alive on the outgoing process but does not migrate them to the new configuration; a client mid-request during reload finishes under the old rules. Keep the last known-good config file to restore quickly if a new file passes -c but still misbehaves once live.