In HAProxy, a backend contains the line `server app1 10.0.0.1:8080 check`. What does the `check` keyword probe on its own, and how do `option httpchk` and `http-check expect` change what HAProxy accepts as a healthy server?

## What `check` alone actually does In HAProxy, health checking is opt-in per server. A `server` line without `check` is never probed at all — HAProxy assumes it is up forever and will happily keep dispatching to a dead machine until the connection attempt fails at request time. Adding `check` enables a *layer-4* probe. HAProxy periodically opens a TCP connection to the server's address and port, and if the handshake completes it closes the connection and records a success. That is the entire test. The check status you see in the stats page for this mode is `L4OK`, or `L4CON` / `L4TOUT` when the connection is refused or times out. ```haproxy backend web server app1 10.0.0.1:8080 check ``` A layer-4 check answers exactly one question: is something accepting connections on that port? It does not know whether the application behind the socket can reach its database, has deadlocked its thread pool, or is returning 500 to every request. This is why a TCP-only check is the single most common reason a load balancer keeps traffic on a broken node. ## Upgrading to an HTTP check `option httpchk`, declared in the backend (or in `defaults`), turns the probe into a real HTTP request over that same connection. ```haproxy backend web option httpchk http-check send meth GET uri /healthz ver HTTP/1.1 hdr Host app.example.com http-check expect status 200 server app1 10.0.0.1:8080 check ``` With `option httpchk` and nothing else, HAProxy sends `OPTIONS / HTTP/1.0` — a deliberately cheap request that most servers answer without executing application code. On HAProxy 2.2 and later, `http-check send` is the supported way to describe the request: `meth` sets the method, `uri` the path, `ver` the HTTP version, and `hdr` adds header lines. The older single-line form, `option httpchk GET /healthz`, still parses but is superseded. One subtlety catches nearly everyone: `HTTP/1.0` requests carry no `Host` header by default. If the backend serves several name-based virtual hosts, the probe lands on whatever the default vhost is — frequently producing a 400, a 301 to canonical HTTPS, or the wrong application entirely. Either send `ver HTTP/1.1` with an explicit `hdr Host ...`, or make sure the probe target answers correctly without a host name. ## What counts as healthy If you declare no expectation, HAProxy's rule is simple: **2xx and 3xx are healthy; everything else is a failure.** That is often too loose. A service that returns `200 {"status":"degraded"}` passes, and so does a `302` to a login page from a misrouted probe. `http-check expect` replaces that default with something you chose: ```haproxy http-check expect status 200 http-check expect rstatus ^2[0-9][0-9]$ http-check expect string "\"status\":\"ok\"" http-check expect ! rstring (degraded|draining) ``` `status` matches an exact code, `rstatus` a regular expression over the status line, `string` a literal substring of the response body, and `rstring` a regex over it. Prefixing with `!` inverts the match, which is how you express "healthy unless the body says otherwise". Body matching only inspects what fits in the check buffer — the first `tune.chksize` bytes, 16 KB by default — so keep health responses small and put the verdict near the top. A related keyword, `http-check disable-on-404`, is worth knowing: when the probe returns 404 the server moves to NOLB rather than DOWN, meaning it stops receiving *new* load-balanced sessions while still serving requests that carry persistence. That is a graceful-shutdown signal the application itself can raise. ## Where the probe goes By default the check targets the same address and port as production traffic, which is what you want — it exercises the same listener. The server keywords `port` and `addr` override that: ```haproxy server app1 10.0.0.1:8080 check port 9000 ``` This is useful when the app exposes a dedicated management port, but it weakens the signal: the admin port can answer perfectly while the traffic port is wedged. Prefer checking what clients actually use unless you have a concrete reason not to. ## Practical shape of a good check Make the endpoint cheap enough to survive being called every couple of seconds by every proxy in the fleet, make it return a machine-readable status you can pin with `http-check expect`, and make sure it fails for reasons that traffic would also fail for. A probe that only proves the HTTP listener is alive has recreated the layer-4 check with more moving parts.