The firewall attached to a cloud server (security group) also tracks connections, and tracking entries for idle connections expire after a set time. Even on servers that clients reach directly without a load balancer, players who sat idle can get disconnected.
Why The security group is set up so that it tracks game connections (only certain addresses allowed, restricted outbound rules, traffic through an NLB, and so on) → Effect The tracking entry for a connection that sat idle for a while expires, and the security group silently drops packets that arrive after that → On screen After being away, the player moves again, gets no response, then disconnects. The server program doesn’t notice for a long time
Primary owner Infra team (Server infrastructure) · Also Game team (Client development), Game team (Server development)
Game team action items
Client: send heartbeats at no more than half the shortest idle timeout (175 seconds or less for 350 seconds on TCP, 90 seconds or less for 180 seconds on UDP streams), reconnect automatically on disconnect. Server: respond to heartbeats and close the connection proactively if none arrive for a set time, resume the session with a session token.
Infra team action items
Check the instance’s connection tracking timeout (TcpEstablishedTimeout) and raise it if needed (UDP can’t be raised because 180 seconds is already the maximum), review a security group setup that creates no tracking (game ports open to all addresses, all outbound allowed; connections through an NLB are still tracked), run idle tests when moving to a new instance generation.
Ballpark numbers
On AWS, Nitro v6 instance types delete tracking entries for idle TCP connections after 350 seconds by default (5 days on other types). For UDP, the defaults are 180 seconds for flows with several request/response exchanges (streams) and 30 seconds for flows that went only one way or had a single request and response.
On the graph
Mass disconnect · Disconnects, idle time before disconnect
Where to look
Check the instance’s connection tracking timeout setting and the security group rules (whether the setup creates tracking), and collect the idle times of dropped connections. Right after a disconnect, use ss -tnoi on the server to see whether the connection stays ESTABLISHED with the retransmission timer (timer:(on,…)) running and backoff growing
Confirmed if
Idle times of dropped connections cluster just past 350 s for TCP, 180 s for UDP streams, or 30 s for one-way UDP, and the server-side socket stays ESTABLISHED without noticing the disconnect (if the server has data to send, it just keeps retransmitting)
Ruled out if
The security group setup doesn’t track (game ports open to all addresses, all outbound allowed, no NLB in the path): not this cause. Traffic goes through an NLB: compare the values with “Load balancer idle timeout”
Check with
Infra tools (no game code needed)
Sources
Amazon EC2 security group connection trackingAWS TCP idle tracking default 350 seconds (Nitro v6; 432,000 seconds = 5 days on others), UDP one-way 30 seconds and stream 180 seconds (180 max); rules that allow all addresses aren’t tracked; connections through an NLB are always tracked
ss(8) — Linux manual pageiproute2 In -o, timer:(on,…) is the retransmission timer; in -i, backoff is the number of times the retransmission wait has doubled