Set HAProxy timeouts and connection limits

The fix/etc/haproxy/haproxy.cfg

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

global
    maxconn 20000

Why this is rated low

Because it is availability, not compromise. Nothing here stops an intrusion or protects data — a proxy that falls over under a slowloris attack is an outage, and outages are recoverable in a way that a breach is not. It sits at the bottom of the checklist for that reason, and the pages above it are worth doing first.

That said, it is genuinely cheap, and the one timeout that matters most is frequently missing.

timeout http-request is the one to check

timeout http-request limits how long a client may take to send its complete request headers. It is the direct answer to slowloris-style attacks: opening many connections and dribbling headers a byte at a time, holding a slot open on the proxy indefinitely.

It is distinct from timeout client, which governs inactivity on an established connection and is usually set generously to accommodate slow uploads and long polls. A generous timeout client with no timeout http-request leaves the header-reading phase effectively unbounded.

Ten seconds is ample for a real client, which sends its headers in one burst.

The others, briefly

Timeout	Bounds
connect	Waiting for a backend server to accept the TCP connection
client	Client-side inactivity once the connection is established
server	Waiting for the backend to respond
http-keep-alive	Idle time between requests on a kept-alive connection
queue	How long a request waits for a free server slot before failing

Omitting timeout client or timeout server in defaults produces a warning at startup, because a connection with no timeout on either side can be held until the process restarts.

maxconn is a decision, not a default

maxconn caps concurrent connections process-wide. Left unset it takes a value derived from the file descriptor limit, which means your capacity ceiling is whatever ulimit -n happened to be — a number nobody chose.

Set it explicitly, below what the host can actually sustain in memory. HAProxy queues beyond the limit rather than crashing, which is the behaviour you want: predictable refusal instead of the machine going down. Per-backend maxconn on server lines is separate and protects the backend from being overwhelmed while HAProxy absorbs the queue.

backend app
    server app1 10.0.1.10:8080 check maxconn 200

Verify it worked

Confirm the values the running process resolved, which is not always what the file says:

echo "show info" | sudo socat stdio /run/haproxy/admin.sock | grep -E 'Maxconn|CurrConns|MaxConnRate'

Check every timeout is set, including in defaults:

grep -nE '^\s*timeout' /etc/haproxy/haproxy.cfg

http-request is the one most likely to be absent.

Startup warnings name any that are missing:

haproxy -c -f /etc/haproxy/haproxy.cfg

Then test the header timeout is real, by opening a connection and sending an incomplete request:

printf 'GET / HTTP/1.1\r\nHost: your-site.example\r\n' | nc your-site.example 80

The connection should close after roughly your timeout http-request. If it hangs indefinitely, the timeout is not in effect on that frontend.

Before you apply this

Timeouts that are too short break legitimate slow traffic, and the failures look like application bugs rather than proxy configuration:

• timeout server shorter than your slowest endpoint returns 504s on reports, exports and any long-running query. Measure before choosing:

  awk '{print $(NF-1)}' /var/log/haproxy.log | sort -n | tail -20

• timeout client too short breaks large uploads and WebSocket or server-sent-event connections, which are idle by design. Those backends need their own longer values rather than a raised global default:

  backend websockets
      timeout server 3600s
      timeout tunnel 3600s

• maxconn set too low turns a traffic spike into queuing and then refusals. Watch the current peak before capping:

  echo "show info" | sudo socat stdio /run/haproxy/admin.sock | grep -E 'CumConns|CurrConns'

Raising maxconn above what file descriptors allow does nothing useful — the limits have to move together, and on systemd that means LimitNOFILE in the unit, not just ulimit in a shell.

sudo haproxy -c -f /etc/haproxy/haproxy.cfg && sudo systemctl reload haproxy

Related

• Request smuggling — the other consequence of how request framing is handled.
• nginx rate limiting — the same availability question on a different proxy.