Why TIME-WAIT sockets pile up: TCP's 2×MSL, Linux's 60 seconds, and what tcp_fin_timeout doesn't change

Thousands of sockets in TIME-WAIT can look like a leak, but usually they’re just TCP following its specification. The rules are in RFC 9293, the TCP standard; how long a system actually waits is up to the implementation. Linux behaviour below comes from the kernel v7.2 source, and defaults from the kernel’s ip-sysctl documentation page (no version number) as checked on 6 October 2026.

It stays on the side that closed first

In a normal close, the side that closes first, A, sends a FIN and gets it acknowledged. When the other side, B, sends its own FIN, A acknowledges it and enters TIME-WAIT. B becomes CLOSED as soon as it receives that last ACK. RFC 9293 says the side that closed actively must stay in TIME-WAIT for 2×MSL.

Figure: a normal FIN close where the two sides don’t close at the same moment. Time runs from top to bottom.

So in a normal FIN close where the two sides don’t close at the same moment, one TIME-WAIT socket remains on the side that closed first. Whether that side is the server or the client doesn’t matter.

Why wait at all

RFC 9293 gives two reasons. One is to wait until the other side can be assumed to have received the ACK of its FIN. If that ACK is lost, the other side resends its FIN, and the side in TIME-WAIT acknowledges it again and restarts the timer. The other is to keep delayed segments from an earlier connection out of a new one. A connection is identified by the addresses and ports at both ends, so reopening the same combination straight away could let old segments slip in.

MSL (Maximum Segment Lifetime) is how long a segment can exist in the network, and RFC 9293 takes it to be 2 minutes. That makes 2×MSL 4 minutes. The spec also notes that this value is an engineering choice and may change.

Linux fixes it at 60 seconds

In Linux v7.2, include/net/tcp.h defines TCP_TIMEWAIT_LEN as 60*HZ (about 60 seconds), and tcp_time_wait() in net/ipv4/tcp_minisocks.c uses that constant as the timeout when a socket enters TIME-WAIT. That’s shorter than the spec’s 4 minutes, and none of the ip-sysctl entries that mention TIME-WAIT change this length.

The setting people tend to reach for is tcp_fin_timeout. According to the documentation, it’s how long an orphaned connection (one no longer referenced by any application) stays in FIN_WAIT_2, and its default of 60 seconds happens to equal the TIME-WAIT length. But for the TIME-WAIT state, tcp_time_wait() uses TCP_TIMEWAIT_LEN regardless of the value it was given, so lowering tcp_fin_timeout doesn’t shorten TIME-WAIT.

tcp_tw_reuse lets a TIME-WAIT socket be reused for a new connection when that’s safe from a protocol point of view. 0 disables it, 1 enables it globally, and 2 enables it for loopback traffic only; the default is 2. The documentation says not to change it without advice from technical experts.

How many ports does that leave?

If the client closes first and keeps opening short connections to the same destination, the ephemeral-port pool can become the bottleneck. The default ip_local_port_range is 32768 to 60999, or 28,232 ports. With each port held for 60 seconds, 28,232 ÷ 60 gives roughly 470 new connections per second as a rough steady-state estimate. That isn’t a TCP ceiling. It assumes one source IP and network namespace, the default port range unchanged, no reserved ports, normal automatic port allocation, one fixed destination address and port, and no applicable TIME-WAIT reuse.

With a pattern like that, check whether connections can be reused, so fewer are closed in the first place, before touching any sysctl.

Sources

• RFC 9293 Transmission Control Protocol (TCP): Sections 3.3.2, 3.4.1, 3.4.2, 3.6, 3.6.1 and 3.10.7.4
• Linux v7.2 include/net/tcp.h: TCP_TIMEWAIT_LEN
• Linux v7.2 net/ipv4/tcp_minisocks.c: tcp_time_wait()
• Linux kernel documentation, IP Sysctl: tcp_fin_timeout, tcp_tw_reuse, ip_local_port_range, ip_local_reserved_ports

Links and content checked October 6, 2026.