Linux系统大量SYN_RECV堆积表明TCP握手第二步阻塞，需分层排查：先用ss -n state syn-recv | wc -l确认实时数量＞50；再通过netstat -s查“SYNs to LISTEN sockets dropped”是否增长、ss -lnt看Recv-Q是否≥Send-Q、cat /proc/sys/net/nf_conntrack_count对比上限值，分别定位半连接队列溢出、accept队列拥塞或conntrack表耗尽三类根因。
Linux系统出现大量SYN_RECV连接堆积时，服务端新连接建立缓慢或直接失败，这不是应用层卡顿，而是TCP握手在第二步就被内核协议栈阻塞，必须分层定位真实瓶颈点。
确认是否真为SYN_RECV堆积而非误判
执行ss -n state syn-recv | wc -l获取实时数量，注意不能依赖ss -s汇总值——它存在数秒延迟，可能严重低估；若输出大于50，进入下一步排查。
运行netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'，重点看SYN_RECV与ESTABLISHED的比值；若前者占总连接数30%以上，基本可排除正常波动，进入异常路径。
分层验证三类溢出源头
第一步：查半连接队列是否丢包。执行netstat -s | grep -i "SYNs to LISTEN sockets dropped"，若该数值持续增长，说明内核已因SYN队列满而丢弃新SYN包；此时需立即检查/proc/sys/net/ipv4/tcp_syncookies是否为0——【为0时必须立刻设为1，否则后续所有调参无效】。
第二步：查全连接队列是否溢出。运行ss -lnt，观察目标端口行的Recv-Q（当前排队数）是否长期≥Send-Q（队列上限）；若成立，说明三次握手已完成但应用没及时accept()，问题不在SYN队列而在上层处理能力。
第三步：查conntrack表是否耗尽。执行cat /proc/sys/net/nf_conntrack_count并对比cat /proc/sys/net/nf_conntrack_max；若前者接近后者，且dmesg | grep "nf_conntrack: table full"有输出，则SYN包在进协议栈前就被丢弃，根本不会走到SYN_RECV状态。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
快速定位真实卡点的命令组合
方法一：用ss -ant sport = :80 | grep SYN\_RECV | head -20 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr查看源IP分布——若IP高度离散、无规律、TTL参差不齐，大概率是SYN Flood攻击。
方法二：执行cat /proc/net/netstat | grep -i "Syn"，重点关注SynRetrans（SYN-ACK重传次数）是否飙升；若该值远高于SynToOList，说明服务器发出了SYN-ACK但没收到ACK，问题在客户端网络路径而非本机参数。
方法三：抓包验证关键路径。在服务端执行tcpdump -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0 and port 80' -c 50，观察是否有大量SYN包进来、对应SYN-ACK发出、但无ACK返回——若有，说明客户端或中间设备丢弃了ACK。
针对性调整与验证
若确认是tcp_syncookies=0导致丢包：执行echo 1 > /proc/sys/net/ipv4/tcp_syncookies立即启用防护机制；该操作无需重启，生效后SYNs to LISTEN sockets dropped计数将停止增长。
若发现ss -lnt中Recv-Q持续非零：检查应用监听时传入的backlog值（如Nginx的listen ... backlog=1024），确保其未被net.core.somaxconn截断；临时调高后者：echo 2048 > /proc/sys/net/core/somaxconn，再重启服务进程使新backlog生效。
若nf_conntrack_count逼近上限：先扩大表容量echo 131072 > /proc/sys/net/nf_conntrack_max，再同步调整哈希桶数量echo 32768 > /proc/sys/net/nf_conntrack_buckets，避免哈希冲突引发性能雪崩。
