Understanding TCP KeepAlive and HTTP Keep-Alive: Configuration and Troubleshooting in Nginx and Load Balancers

When a client accesses a service through an LVS VIP, the backend Nginx server may take longer than the default 90‑second TCP session timeout, causing the connection to be reset; similar issues also appear on commercial load balancers like F5.

The root cause is that LVS (and many load balancers) automatically close TCP sessions that have been idle for 90 seconds to conserve resources and protect back‑ends from excessive connections.

Enabling TCP KeepAlive on the server side allows the kernel to send probe packets after a configurable idle period, confirming that the peer is still reachable before the session is terminated.

Linux provides three sysctl parameters that control TCP KeepAlive behavior:

net.ipv4.tcpkeepaliveintvl = 75
net.ipv4.tcpkeepaliveprobes = 9
net.ipv4.tcpkeepalivetime = 7200

These values define the idle time before probing, the interval between probes, and the maximum number of probes.

Applications can also set socket‑level options via setsockopt to override the kernel defaults:

TCP_KEEPIDLE   // overrides tcpkeepalivetime
TCP_KEEPINTVL // overrides tcpkeepaliveintvl
TCP_KEEPCNT   // overrides tcpkeepaliveprobes

For example, setting TCP_KEEPIDLE to 60 seconds makes the kernel start probing after one minute of inactivity.

TCP KeepAlive is often confused with HTTP Keep‑Alive; they are distinct. TCP KeepAlive works at the transport layer, while HTTP Keep‑Alive (or the Connection: keep-alive header) allows multiple HTTP requests to reuse the same TCP connection, reducing the overhead of establishing new connections for each resource.

In Nginx, TCP KeepAlive can be configured using the listen directive’s so_keepalive option. The correct syntax is a single value, such as:

listen 80, so_keepalive=60s::;

This setting resolves the LVS session timeout problem by ensuring the TCP socket sends keepalive probes after 60 seconds of inactivity, preventing premature connection resets.

Understanding the difference between TCP KeepAlive and HTTP Keep‑Alive and applying the appropriate kernel or Nginx configuration eliminates resource waste and improves reliability of long‑running backend processes.