maxRequestsPerSocket request-count recycling visibility gap

Fastify server options such as keepAliveTimeout and maxRequestsPerSocket inherit their default values and behavioral semantics from the underlying Node.js HTTP server, yet the framework does not expose per-socket timers or remaining request counts through its public API. This creates an observability gap when diagnosing intermittent connection-related issues, as socket reuse patterns and recycling thresholds remain inferable only from Node.js-level metrics or external monitoring tools. The gap affects deployments that rely on keep-alive connections under high request churn, where socket exhaustion may manifest as latency spikes or unexpected connection terminations without clear attribution to Fastify configuration. Given that Fastify core defers connection pooling to database plugins such as @fastify/postgres or @fastify/mysql, the discrepancy between server-level socket limits and plugin-level pool management further complicates root-cause analysis.

Which Node.js major release altered the default maxRequestsPerSocket value, and how does Fastify version alignment influence the inherited behavior? Can Fastify middleware or hooks intercept socket close events to surface per-connection request tallies without modifying core source? How do keep-alive socket timeouts interact with database plugin client pool recycling when both operate on the same underlying HTTP connection?