Network New Added 8 September 2026

Linux: possible SYN flooding on port X, sending cookies

The kernel's accept queue for a listening socket overflowed. Under a real flood that is the defence working, but far more often it is a healthy service whose application accepts connections more slowly than they arrive, and clients see stalls and resets rather than errors in the log.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix

# Is the queue overflowing right now?
ss -ltn                    # Recv-Q vs Send-Q on the listener
nstat -az TcpExtListenDrops TcpExtListenOverflows

# Raise the queue and the backlog together: the smaller one wins
sysctl -w net.core.somaxconn=4096
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
# nginx
listen 443 ssl backlog=4096;

# Containers inherit the host setting unless it is namespaced
# Real fix: find why accept() is slow, usually a blocked event loop or
# a worker pool saturated by slow upstream calls.

How to diagnose Network errors

Network errors are precise if you read them literally. Connection refused means a machine answered and actively rejected: nothing is listening on that port. Timeout means nothing answered at all, which points at a firewall silently dropping packets or a wrong address. Connection reset means the peer accepted then abruptly closed, often a proxy, a protocol mismatch, or an application crash. Distinguishing those three saves most of the debugging time.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

Test layer by layer: ping for reachability, nc -zv host port for the port, then the application protocol. Do not skip to the application layer.
Confirm what is listening locally with ss -tulpn. "Connection refused" on localhost almost always means the service bound to 127.0.0.1 when it needed 0.0.0.0, or vice versa.
Capture packets when the error is ambiguous: sudo tcpdump -ni any port 443 and host x.x.x.x. A RST is visible; a silent drop is visible as unanswered SYNs.
For intermittent failures under load, check ephemeral port exhaustion and conntrack table limits (ss -s, conntrack -S) before blaming the network.
Suspect MTU when small requests succeed and large ones hang. Test with ping -M do -s 1472 and reduce until packets pass.

Tools worth reaching for

ss -tulpn
nc -zv
tcpdump
mtr
curl --connect-timeout
iptables -L -n -v

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

kernel.org

Related Network errors

See all 35 Network errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.