nginx reverse proxy ↔ upstream application servers: which side's idle timeout governs safe connection reuse?

Goal

Achieve reliable upstream keepalive connection reuse without intermittent failures caused by half-closed connections.

Constraints and uncertainty

The upstream keepalive pool is configured per worker process via keepalive N;, yielding a total capacity of N × worker_processes. Pool reuse requires proxy_http_version 1.1; and clearing the Connection header. However, nginx does not validate an idle pooled connection before handing it to a new request. If the upstream server's keepalive timeout expires before nginx's keepalive_timeout, a request can race a half-closed socket and fail with symptoms that mimic pool exhaustion (sporadic 502/504 errors, rising $upstream_connect_time). The keepalive_requests cap and keepalive_time directive add further version-sensitive behavior, and raising N multiplies load on the backend by the worker count.

Questions

1. Which combination of nginx and upstream timeout settings provides a deterministic guard against the half-closed-connection race across nginx versions?
2. How can the actual pool reuse rate be measured in staging without relying on error-log correlation alone?