http.Server.ErrorLog is nil in a reverse proxy and its TLS handshake errors never reach the structured sink. Why, and how do you fix it?

## Where a server's own diagnostics go A Go HTTP server produces two very different streams. One is whatever your handlers log, which you control. The other is the server's own commentary about connections that never became a successful request: TLS handshake failures, malformed request lines, oversized headers, superfluous `WriteHeader` calls, errors accepting connections. That second stream goes to `http.Server.ErrorLog`, a `*log.Logger` field. The documentation is explicit that when it is nil, logging is done via the log package's standard logger. That nil default is a trap in a service whose logging has moved to `log/slog`, because it is silent. Nothing warns you. The server keeps working, the lines keep being written, and they simply go somewhere your pipeline does not look - plain text on standard error while everything else in the process emits records with a level and a timestamp of the handler's choosing. ## Why handshake errors are the painful case A TLS handshake failure never produces a request, so there is no access-log line, no handler, no middleware, no status code and no latency metric. The only trace of it in the entire process is the string `http: TLS handshake error from <addr>: <cause>` on the error log. A proxy in front of an internal fleet can be rejecting a whole client's traffic for an expired client certificate or an unsupported cipher, and every dashboard will look healthy: the request count from that client is simply zero. The same silence covers a client sending a request line the parser rejects, or headers past `MaxHeaderBytes` - both are refused before your code sees them. ## The fix, and the level choice Give the field a logger that writes into your handler: ```go srv.ErrorLog = slog.NewLogLogger(slog.Default().Handler(), slog.LevelError) ``` `slog.NewLogLogger(h, level)` returns a `*log.Logger` whose every write becomes a record on `h` at that fixed level. Note what you are choosing here: **one level for the whole stream**, exactly as with the process-wide bridge, and the message stays a single formatted string. Error is the usual pick, but be honest about what you are promoting - a scanner probing your port will produce handshake errors continuously, so an alert wired directly to "any Error from this logger" will page on internet noise. Many teams pick Warn for the proxy edge and alert on rate rather than on presence. Also take the handler from your existing logger rather than building a second one, so the bridged records go to the same destination and carry the same handler configuration as everything else. ## The other fields with the same shape `http.Server.ErrorLog` is not the only one. `httputil.ReverseProxy` has its own `ErrorLog` field with the same nil-means-log-package default, and it is where proxy-side failures surface - a dial error to the backend, a copy that failed mid-body. If you wire only the server and not the proxy, half the edge stays invisible. `httputil.ReverseProxy` also has an `ErrorHandler` field, which is a better place to translate a backend failure into a structured record with attributes, since there you still have the `*http.Request` in hand and can attach the target, the method and the path as fields rather than as text. That contrast is worth stating in an interview: the `ErrorLog` bridge is a *capture* mechanism for diagnostics you cannot restructure, while an explicit hook like `ErrorHandler` is where you get real structure back. Bridge what you cannot reach; instrument properly what you can. ## Diagnosing it after the fact The symptom that leads here is usually indirect. Somebody reports a client failing while your metrics show nothing, or the ingest side reports a count of lines it could not parse - and sampling those lines back to their source finds `http: ...` text arriving on the container's error stream. The confirmation is cheap: `srv.ErrorLog == nil` in the code, or a deliberate handshake failure against the port to see where the message lands. A related check is that the server is your own `http.Server` value at all. Code that reaches for the package-level convenience helpers gets a server value it never named, and therefore never gets an `ErrorLog` set on it - constructing the `http.Server` explicitly is a precondition for configuring any of this. ## Summary of the answer Nil `ErrorLog` means the log package's standard logger; that is plain text on standard error outside your structured pipeline; handshake and parse failures exist nowhere else; fix it with `slog.NewLogLogger` on the same handler, choose the level knowing it applies to the whole stream, and remember `httputil.ReverseProxy.ErrorLog` separately.