A listening TCP socket separates incomplete handshakes from established connections waiting for accept(). The real setting is tcp_max_syn_backlog; this article retains its historical URL spelling. It concerns remembered incomplete requests, whereas the listen() backlog concerns the accept queue. Diagnose which stage is under pressure before choosing a remedy.

SYN cookies provide a fallback when normal handshake state cannot be retained. They do not make servers immune to overload, guarantee delivery, or remove the need to understand the SYN queue. Packet loss, filtering, allocation failures and accept-side pressure can still prevent connections with cookies enabled.

The SYN queue holds incomplete handshakes; the accept queue holds established connections awaiting accept(). With listen backlog configured as 8192 and somaxconn as 4096, the accept-side cap is 4096. Buffering more waiting work does not itself increase processing rate. The source article remains held/pending.
The SYN queue holds incomplete handshakes; the accept queue holds established connections awaiting accept(). With listen backlog configured as 8192 and somaxconn as 4096, the accept-side cap is 4096. Buffering more waiting work does not itself increase processing rate. The source article remains held/pending. Whole article remains held/pending; this diagram does not endorse its disputed claims.

The backlog argument is the accept queue

Linux changed the listen() backlog meaning in 2.2. Its configured value is capped by somaxconn; with arguments 8192 and 4096 respectively, that cap is 4096. This is a configuration example, not a measurement of exact admission count. Read the actual listener and namespace rather than assuming defaults or inferring capacity from a short burst.

Kernel documentation describes tcp_max_syn_backlog as a per-listener limit on remembered requests in SYN_RECV. Its initial value depends on memory and kernel implementation. Old man-page memory thresholds should not be treated as the current host’s configuration. Neither queue length alone identifies the application’s processing rate.

SYN cookies remain a fallback

With kernel support, tcp_syncookies=1 enables the overflow fallback; value 2 is a testing mode that sends cookies unconditionally. The listen manual’s statement that cookies remove the logical bound describes stateless admission beyond remembered requests. It does not mean unlimited memory, CPU, bandwidth or established sockets. The kernel documentation still recommends considering SYN-backlog tuning for legitimate overload, alongside the application’s ability to drain work.

Do not promise that every cookie connection loses SACK and window scaling. The pinned Linux v6.12 implementation can encode these options in timestamp bits when timestamps are negotiated. Which options survive depends on implementation and negotiation. That qualified behavior does not turn an emergency mechanism into a capacity plan, and disabling cookies is not a general fix.

The accept queue is where the pressure lands

Accept-side pressure can coexist with SYN-side pressure. In Linux v6.12’s ordinary handshake path, failure to create a child socket can reach an overflow branch: with tcp_abort_on_overflow disabled, the server can retain the request rather than immediately reset it. A client may already consider the connection established while application traffic stalls. This is a possible state mismatch, not a guarantee that every connect() succeeds.

A larger queue absorbs a finite burst and may increase waiting time. It does not establish higher steady-state service capacity. Measure arrival rate, accept latency and application completion together; there is no measured 20,000-connections-per-second result in this article.

When it breaks

Rising overflow counters justify investigation, but do not uniquely blame a worker thread. Accept-loop scheduling, resource exhaustion, other listeners in the same network namespace and a burst between samples can change the interpretation. Historical nonzero totals are not evidence of a current incident.

SYN loss also occurs with cookies enabled. Client retry timing depends on kernel version, retry settings, socket behavior and application deadlines; 67 or 131 seconds is not a universal timeout contract. A successful TCP connection likewise does not prove that the application request completed.

Check it quickly

Use the following observation exercise only on an authorized Linux system with an existing listener on port 8443, in its network namespace. It requires ss, nstat and sysctl already installed. Do not start listeners, generate overload, change settings or elevate privileges for this exercise. These commands were not run in this review.

ss -lnt 'sport = :8443'
nstat -az TcpExtListenOverflows TcpExtListenDrops TcpExtTCPReqQFullDrop TcpExtTCPReqQFullDoCookies
sysctl net.core.somaxconn net.ipv4.tcp_max_syn_backlog net.ipv4.tcp_syncookies net.ipv4.tcp_abort_on_overflow

Take two snapshots around an already-approved ordinary workload. For a listening TCP socket, Recv-Q reports queued established connections and Send-Q the effective backlog limit. Empty output means no matching visible listener, not a zero-length queue. A changed sysctl does not retroactively prove how an existing listener was configured.

nstat -az shows absolute counters, including zeros, and may update its local history; compare deltas over the interval. The named counters separate useful overflow, request-drop and cookie-fallback signals, but they are namespace-wide and are not mutually exclusive per-listener verdicts. Record kernel version, listener context and request outcomes before proposing tuning. Missing tools, access or an isolated test environment leave the runtime conclusion unresolved.

Sources