Seeing a large number of SYN_RECV connections on a Linux server does not automatically mean the server is under attack. It means the server has received TCP SYN packets, replied with SYN-ACK packets, and is still waiting for the final ACK that completes the three-way handshake. A short-lived increase can be normal during a traffic spike. A count that remains high, grows continuously, or coincides with connection timeouts requires a structured investigation.
This tutorial explains how to identify the affected listening service, group connection sources, check kernel counters, distinguish legitimate traffic from packet loss or a SYN flood, and verify relevant application, proxy, firewall, and Linux kernel settings.
What Does SYN_RECV Mean?
A TCP server normally establishes a connection in three steps:
The client sends a SYN packet.
The server replies with SYN-ACK and temporarily records the half-open connection.
The client returns an ACK, after which the connection becomes
ESTABLISHED.
SYN_RECV is the state between steps two and three. The entry remains in the SYN backlog until the final ACK arrives or the kernel gives up after retransmissions. Therefore, a high count can be caused by real users arriving at once, lost return packets, asymmetric routing, a firewall or load balancer dropping ACKs, an application accepting connections too slowly, or intentionally incomplete handshakes from a SYN flood.
Start With the Overall TCP Picture
First check the summary instead of reacting to a single snapshot:
ss -s
Then list current half-open connections and count them:
ss -tan state syn-recv ss -Htan state syn-recv | wc -l
Watch the count for several minutes to determine whether it is a brief spike or a sustained condition:
watch -n 2 'ss -Htan state syn-recv | wc -l'
Compare the result with application latency, load balancer metrics, firewall counters, CPU usage, packet loss, and traffic volume from the same time window. A count without a baseline is not enough to diagnose the cause.
Identify the Affected Port and Service
List listening sockets and their owning processes:
ss -lntp
Pay attention to the local port in the SYN_RECV output. If most entries target port 443, investigate the HTTPS listener, reverse proxy, and upstream load balancer. If they target a database or custom application port, verify that the service should be reachable from those networks at all.
Also check the backlog shown by the listening socket. The configured application backlog may be capped by net.core.somaxconn, while incomplete TCP handshakes use the SYN backlog governed by TCP-specific behavior and net.ipv4.tcp_max_syn_backlog. These queues are related but not identical.
Group Connections by Source Address
The following command provides a quick IPv4-oriented summary of remote addresses:
ss -Htan state syn-recv | awk '{print $5}' | sed 's/:.*//' | sort | uniq -c | sort -nr | headBe careful with IPv6 because splitting on the first colon produces incorrect results. For mixed IPv4 and IPv6 environments, use structured socket telemetry, firewall logs, flow logs, or a parser that understands bracketed IPv6 addresses.
A small number of sources generating most half-open connections is suspicious, but it is not proof of abuse. Large NAT gateways, carrier networks, monitoring systems, and corporate proxies can place many legitimate users behind one public address. Do not block an address solely because it ranks first.
Check Backlog Overflows, Drops, and SYN Cookies
Kernel counters are more useful than the live count when you need to know whether the server is actually dropping connection attempts:
nstat -az | grep -E 'ListenOverflows|ListenDrops|Syncookies' netstat -s | grep -i -E 'listen|overflow|drop|syn'
Interpret changes over time rather than treating cumulative counters as current rates:
ListenOverflowsandListenDropsincreasing during the incident indicate pressure around listening queues or connection acceptance.Increasing SYN cookie counters indicate that the kernel is using SYN cookies under backlog pressure.
Stable counters with high
SYN_RECVmay point toward delayed ACKs, network-path problems, or a workload that is elevated but still within capacity.
Inspect the Relevant Kernel Settings
Read the current values before making any changes:
sysctl net.core.somaxconn sysctl net.ipv4.tcp_max_syn_backlog sysctl net.ipv4.tcp_syncookies
net.core.somaxconn
somaxconn limits the maximum backlog that applications can request for listening sockets. Raising it cannot help if the application itself requests a smaller backlog, the service is not accepting connections fast enough, or the bottleneck is elsewhere.
net.ipv4.tcp_max_syn_backlog
tcp_max_syn_backlog controls how many incomplete connection requests can be remembered per listener under normal SYN queue handling. A larger value may absorb a legitimate burst, but it also consumes memory and does not fix packet loss, an undersized proxy, or a malicious traffic source.
net.ipv4.tcp_syncookies
SYN cookies let Linux respond to severe SYN backlog pressure without retaining the usual amount of per-connection state. They are a protection mechanism, not a general capacity-tuning shortcut. Keep them enabled according to the current kernel guidance, but investigate why the backlog is under pressure when cookie counters rise.
Rule Out Network and Infrastructure Problems
If clients send SYN packets but their final ACK packets never reach the server, examine every hop that can modify or filter the flow:
Cloud firewall and security-group rules
Host firewall and connection-tracking limits
Load balancer health, capacity, idle timeouts, and source-preservation behavior
NAT gateways and port capacity
Asymmetric routing between inbound and outbound paths
Packet loss, MTU problems, and congested links
A packet capture can confirm the handshake sequence:
sudo tcpdump -ni any 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0 and port 443'
Use a narrow interface, port, host, and time window whenever possible. Packet captures may contain client addresses and other sensitive metadata, so store and share them according to your privacy and security policies.
Check the Application and Reverse Proxy
A healthy kernel cannot compensate indefinitely for an application that accepts connections too slowly. Check worker limits, open-file limits, event-loop stalls, CPU throttling, process restarts, TLS handshake load, and upstream dependency delays.
For NGINX, review the listen directive backlog configuration together with operating-system limits. Also verify worker connections, worker processes, file-descriptor limits, and whether a load balancer in front of NGINX is experiencing its own queue pressure. Change one layer at a time so the result remains measurable.
How to Distinguish a Traffic Spike From a SYN Flood
| Signal | Legitimate spike | Possible SYN flood |
|---|---|---|
| Source distribution | Often follows known users, campaigns, or regions | May be widely distributed or heavily concentrated |
| Completed connections | ESTABLISHED sessions and application requests also rise | Many SYNs produce few completed sessions |
| Backlog counters | May rise briefly and recover | Drops or SYN cookies may continue increasing |
| Business metrics | Requests, logins, or downloads increase | Little useful application traffic accompanies the load |
| Duration | Usually matches a known event or demand curve | May persist or arrive in repeated waves |
No single signal is conclusive. Correlate socket states, packet rates, completed handshakes, application access logs, infrastructure telemetry, and business traffic before declaring an attack.
A Safe Troubleshooting Order
Record the current
SYN_RECVcount and its trend.Identify the destination port, listener, and process.
Group sources without immediately blocking them.
Check overflow, drop, and SYN cookie counter changes.
Compare completed connections and real application requests.
Inspect packet flow across the firewall, load balancer, NAT, and server.
Review application backlog and accept-rate limits.
Only then consider measured kernel or service tuning.
Repeat the same measurements after each change.
Changes to Avoid
Do not blindly increase every TCP queue parameter.
Do not disable SYN cookies merely to simplify testing.
Do not copy kernel values from a much larger server without capacity testing.
Do not block high-volume IP addresses without checking NAT and proxy behavior.
Do not treat a low
SYN_RECVcount after tuning as proof that users can connect successfully.
How to Verify the Fix
After remediation, observe at least one representative traffic cycle. Confirm that SYN_RECV returns to its normal range, overflow and drop counters stop rising unexpectedly, completed connections increase normally, application latency improves, and error rates fall. Also verify that memory use, CPU load, firewall connection tracking, and load balancer health remain stable.
Frequently Asked Questions
Does a high SYN_RECV count always mean a DDoS attack?
No. Legitimate bursts, packet loss, asymmetric routing, firewall behavior, load balancer problems, and slow connection acceptance can produce the same state.
Should I increase tcp_max_syn_backlog immediately?
Not before checking counter trends and the network path. Increasing it may provide headroom for legitimate bursts, but it can hide the symptom without fixing the cause.
What is the difference between somaxconn and tcp_max_syn_backlog?
somaxconn caps the listen backlog requested by applications, while tcp_max_syn_backlog relates to incomplete TCP handshakes. Both may matter, but they protect different stages of connection establishment.
Can I simply block the top source IPs?
Only after validation. A top address may represent a legitimate NAT gateway, proxy, monitor, or major customer. Prefer rate-based protection and upstream filtering when the evidence shows abusive traffic.
Conclusion
Too many SYN_RECV connections should be treated as a symptom, not a diagnosis. Begin with socket-state trends, identify the affected listener, examine kernel drop and SYN cookie counters, and correlate the results with completed connections and real application traffic. Then check the network path and application acceptance capacity before changing kernel values. This approach reduces the risk of masking packet loss, misclassifying legitimate users, or moving the bottleneck to another layer.
References
References checked on August 28, 2026.
