Investigation and Resolution of Intermittent Timeout Between Cloud Host A and Cloud Game Server B Caused by tcp_tw_recycle

A cloud host (A) intermittently timed out when accessing an interface on a cloud game server (B). Network layer checks were normal, but packet captures revealed that the B server did not respond to request packets.

The root cause was identified as the kernel parameter net.ipv4.tcp_tw_recycle being set to 1 on the server. This option makes the kernel verify the TCP timestamp of each incoming packet; if the timestamp is not monotonically increasing—often the case when traffic passes through a NAT gateway—the packet is dropped.

Detailed investigation steps included:

Confirming that the network path was healthy.

Deploying packet captures at four different points to reproduce the issue and locate the packet loss.

Observing that SYN packets sent to the B host were being dropped, with retransmission intervals following the exponential back‑off pattern.

The analysis showed that the SYN packets were not answered because the server’s tcp_tw_recycle check rejected them due to non‑incrementing timestamps caused by NAT.

To resolve the problem, the kernel parameter was disabled:

vi /etc/sysctl.conf # set net.ipv4.tcp_tw_recycle = 0

sysctl -p # apply the changes

After disabling tcp_tw_recycle , the intermittent timeout disappeared and the service operated normally.

Additional notes:

The TCP specification requires connections in TIME_WAIT to wait for 2 MSL. In Linux, enabling tcp_tw_recycle (deprecated since kernel 4.x) bypasses this wait to reuse TIME_WAIT sockets quickly.

While this can improve performance, it may cause new connections to receive stale data when multiple clients behind a NAT share the same public IP, because the kernel discards SYN packets with older timestamps.