查半连接队列长度用 ss -tn state syn-recv | wc -l，最轻量可靠；溢出判断看 /proc/net/snmp 中 SynsToListenDrops 是否增长（tcp_syncookies=0 时有效），并比对 tcp_max_syn_backlog；异常堆积可结合 dmesg 日志、ss -s 统计及 tcp_syncookies 状态交叉验证。
查当前半连接队列长度
执行 ss -tn state syn-recv | wc -l，输出数字即为当前处于 SYN_RECV 状态的连接数。
这一步最轻量、最可靠，【ss 直接读内核 socket 表，不依赖 /proc/net/tcp 解析，万级连接下也不会卡住】。
若只关心某端口（如 80），加过滤： ss -tn state syn-recv sport :80 | wc -l。
别用 netstat -an | grep SYN_RECV——它在高并发时解析慢，且 IPv6 地址格式（如 [::ffff:192.168.1.1]:80）会导致漏统计。
查半连接队列是否已溢出
执行 awk '/^TcpExt/ {print ,}' /proc/net/snmp | grep SynsToListenDrops，查看输出值是否持续增长。
该值代表内核因半连接队列满而丢弃的 SYN 包数量，是判断溢出的直接指标。
【注意：此计数仅在 tcp_syncookies = 0 时可靠；若启用了 SYN Cookie（默认常为 1），该值可能不涨，但实际已发生隐性丢包】。
配合验证：运行 cat /proc/sys/net/ipv4/tcp_max_syn_backlog 获取队列上限，再比对当前 ss -tn state syn-recv | wc -l 结果。若后者长期接近或等于前者，说明队列已满。
交叉印证是否存在异常堆积
方法一：检查内核日志是否有防护触发记录
执行 dmesg | grep -i "possible SYN flooding"，若输出非空，说明内核检测到半连接异常堆积并启动了防护机制。
方法二：用 ss 查全局 socket 统计
执行 ss -s，重点关注输出中 SYN-RECV 与 ESTAB 的比例。若 SYN-RECV 数量远高于 ESTAB，且持续不降，表明半连接无法及时转入全连接状态，极可能是 accept() 太慢或全连接队列也已瓶颈。
方法三：确认 tcp_syncookies 是否启用
执行 cat /proc/sys/net/ipv4/tcp_syncookies，输出为 1 表示开启，此时 SynsToListenDrops 不增长不等于没溢出，只是内核改用 cookie 缓解。
