Fastify keepAliveTimeout limits behind shorter upstream proxy idle timeouts

Configuring Fastify's keepAliveTimeout to reduce duplicate-write risk from retried non-idempotent requests behind a proxy requires a numeric trade-off. Fastify applies this server option to the underlying HTTP/HTTPS server and documents a default that differs from Node's shorter HTTP server default. The safe value depends on the smallest idle timeout in the network path: if Fastify's timeout exceeds an upstream proxy's idle limit, a client may retry on a socket the proxy has already closed, re-sending a request that already caused a side effect. If the timeout is too low, connection reuse is lost.

Fastify does not provide a built-in idempotency-key store or automatic retry deduplication. Timeout alignment alone cannot prevent duplicate writes; application-level idempotency keys, database constraints, or an upstream gateway are still required. Related options such as connectionTimeout, requestTimeout, and maxRequestsPerSocket also affect connection lifecycle and may need coordinated tuning. HTTP/1 and HTTP/2 have different timeout semantics, and defaults vary across versions.

Should keepAliveTimeout be set below the upstream proxy idle timeout, and how should the value be derived when multiple hops have different limits? Given that Fastify lacks built-in idempotency handling, what application-level patterns are appropriate for non-idempotent routes when a retry occurs after a handler side effect but before the client sees the response? In what way do connectionTimeout, requestTimeout, and maxRequestsPerSocket interact with keepAliveTimeout?