HAProxy timeouts

What each timeout measures, what happens when it fires, and sensible values. Times are in milliseconds unless they carry a unit: 500ms, 5s, 1m, 1h, 1d. Put them in defaults and override per frontend or backend where needed.

Every timeout

Timeout	Section	Measures	When it fires	Web	WebSocket	TCP
`connect`	backend	Establishing the TCP connection to a server (per attempt; `retries` repeats it).	Retry, then `503`, state `sC`.	5s	5s	5s
`client`	frontend	Inactivity on the client side: waiting for the client to send, or to accept data.	Connection closed, state `c…` (e.g. `cD`).	30s	30s	1h
`server`	backend	Inactivity on the server side: waiting for the response or the next chunk of data.	`504` before headers (`sH`), cut transfer during data (`sD`).	30s–60s	30s	1h
`http-request`	frontend	Receiving the complete request headers (the body too with `option http-buffer-request`).	`408`, state `cR`. The main defence against Slowloris.	10s	10s	–
`http-keep-alive`	frontend	Idle time between requests on a kept-alive connection. Unset: `http-request` is used.	Idle connection closed quietly (nothing logged with `dontlognull`).	2s–10s	2s–10s	–
`queue`	backend	Waiting in a queue for a free server slot when `maxconn` is reached. Unset: `connect` is used.	`503`, state `sQ`.	30s	30s	30s
`tunnel`	backend	Inactivity in both directions once the connection is a tunnel: WebSocket after the upgrade, `CONNECT`, and TCP mode once no rule is still inspecting. Replaces `client` and `server` then.	Tunnel closed, state `cD`/`sD`.	–	1h	1h
`client-fin`	frontend	Inactivity on the client side after one side has closed (half-closed connection). Unset: `client`.	Frees connections from clients that vanished without closing.	5s	30s	30s
`server-fin`	backend	The same on the server side.	Frees half-closed server connections.	5s	30s	30s
`check`	backend	Extra read time for a health check once connected. The connect part uses `min(timeout connect, inter)`.	Check fails (Layer7 timeout); `fall` failures mark the server down.	2s–5s	2s–5s	2s–5s
`tarpit`	frontend / backend	How long `http-request tarpit` holds a request. Unset: `connect`.	Then the deny status is sent (state `PT`).	10s	10s	–

Web sites and APIs

defaults
    mode http
    timeout connect 5s
    timeout client 30s
    timeout server 30s
    timeout http-request 10s
    timeout http-keep-alive 5s
    timeout queue 30s
    timeout check 5s

Raise server in the one backend that runs slow reports or uploads instead of everywhere.

WebSockets and long polling

backend be_ws
    balance leastconn
    timeout client 30s
    timeout server 30s
    # After the Upgrade, only this one counts:
    timeout tunnel 1h
    timeout client-fin 30s
    timeout server-fin 30s

HAProxy needs no extra option for WebSockets in HTTP mode. Without timeout tunnel idle sockets are cut after timeout server; app-level pings every 20–30 s also keep them alive.

TCP: mail, SSH, databases

frontend fe_imaps
    mode tcp
    option tcplog
    bind :993
    timeout client 1h
    default_backend bk_imaps

backend bk_imaps
    mode tcp
    timeout connect 5s
    timeout server 1h
    server mail 10.0.0.30:993 check

IMAP IDLE and SSH sessions sit idle for many minutes; 30 s would cut them. With SNI routing, keep tcp-request inspect-delay short (5 s).

Rules of thumb

Always set connect, client and server; HAProxy warns at startup when they are missing, and a missing one means "wait forever".
client and server are usually equal: the shorter one decides how long a silent request can live.
http-request should be much shorter than client: it is the whole budget for the request headers.
A 504 with sH-- means the application was slower than timeout server; fix the app or raise it in that backend only.
Behind a cloud load balancer, keep HAProxy's client idle timeouts longer than the load balancer's, so the balancer closes first.
Read Tw and Tc in the log parser before tuning: queue time means too few slots, connect time means network or backlog trouble.