Your Go http.Server's goroutine count climbs linearly under a slow-header probe while RPS stays flat — what is happening and which field fixes it?

## The shape of the signal Two lines on a dashboard tell the whole story: goroutine count rising in a straight line, request rate flat. Anything that rises with *load* would move both. A count that rises while throughput does not is counting something that is not requests — here, connections that never became requests. ## Why one connection costs one goroutine net/http's accept loop hands each accepted connection to a goroutine dedicated to serving it. That goroutine's first act is to read the request line and headers from the connection. Reading blocks. Until a complete header block arrives, there is no `http.Request`, no route match, no handler, and no request context. The goroutine sits in that read for exactly as long as the read deadline allows — and with no read deadline configured, that is forever. So the resources a stalled connection holds are: a goroutine with its stack, the buffered reader and writer attached to the connection, and a file descriptor. None of it is a leak in the sense of a bug; the runtime is doing precisely what it was configured to do. It is a leak in the sense that matters operationally, because nothing will ever release it. This is cheap to cause and expensive to absorb. A probe — or an unfriendly client — that opens connections and sends one header byte every few seconds keeps them all alive at almost no cost to itself. On a public endpoint exposed directly to untrusted clients, there is no reason to expect anything else. ## Why the obvious fixes do not apply **`WriteTimeout`** is reset whenever a new request's header is read. In this scenario no request's headers have ever finished being read, so no write deadline is ever armed for them. A server that sets only `WriteTimeout` is entirely unprotected here. **`IdleTimeout`** governs the wait for the *next* request on a connection that already completed one. These connections never completed one, so it does not apply to their initial stall — although you want it set anyway, for the phase it does cover. **Handler-side cancellation** — a `context.WithTimeout` at the top of the handler, or checking `r.Context()` — cannot help by construction. The handler never runs. Anything written inside `ServeHTTP` is downstream of the phase that is stuck. **A proxy in front** helps only if every path to the process goes through it. A public endpoint exposed directly does not have that property, and even where a proxy exists it is a mitigation you do not own rather than a bound on your own process. ## The fix Set `ReadHeaderTimeout` to a small number of seconds. Nothing legitimate needs longer to send headers, and this is the only field that bounds a connection before dispatch. Set `IdleTimeout` in the same change, because the two together are what bound a connection outside a request. If `ReadTimeout` is set and `ReadHeaderTimeout` is not, the header phase inherits `ReadTimeout` and you are already protected, just with a much looser number than the phase deserves. When the deadline expires, the read fails and the connection is closed. There is no status code — there is no request to answer — and the goroutine returns and is collected. That is the whole mechanism. ## Confirming it rather than guessing The goroutine profile is the direct evidence. With net/http/pprof registered, the goroutine profile lists every live goroutine grouped by stack; a stalled-connection incident shows thousands of identical stacks sitting in net/http's connection serve and header read path, with none of your own package's frames in them. That distinguishes this from the other reason goroutine counts climb — a handler leaking goroutines per request — whose stacks are unmistakably in your code, and which would climb with request rate rather than independently of it. A useful second signal is open file descriptors or established connections for the process, which should climb in lockstep with the goroutine count. If goroutines climb and connections do not, look at the handler instead. ## The follow-through The interesting part of this answer, for a senior chair, is not naming the field. It is that the probe should exist. A load test that only drives well-behaved fast clients will never surface this, because every request completes and the goroutine count sits flat under any configuration. A slow-header probe belongs in the same suite as the throughput test, with the goroutine count asserted as a bound rather than eyeballed, so the day someone constructs an `http.Server` without timeouts the suite says so rather than production doing.