直接检查/proc/net/snmp中TcpExt段的SynDrop（SYN队列满丢包数）和SynToOpen（超时转ESTABLISHED数），或用netstat -s | grep -i "listen overflows\|SYNs to LISTEN sockets dropped"查看内核累积丢包计数。
Linux怎么查 listen socket 的三次握手队列溢出（SYN queue overflow）？
根本不用“报警记录”——Linux 内核不会主动写日志或发告警，而是默默丢弃 SYN 包，并通过 netstat 或 /proc/net/snmp 等接口暴露统计计数。你要找的不是日志文件，是内核累积的丢包计数器。
最直接的证据在：/proc/net/snmp 中的 TcpExt 段，关键字段是 SynDrop 和 SynToOpen：
-
SynDrop：SYN 队列满时丢弃的 SYN 包数（即真正溢出） -
SynToOpen：SYN 队列未满但因tcp_synack_retries耗尽而超时、最终进入 ESTABLISHED 的连接数（说明有压力但没丢）
执行：
awk '/^TcpExt/ {for(i=1;i<=NF;i++) if($i=="SynDrop") print $(i+1)}' /proc/net/snmp
为什么 ss -lnt 显示 Recv-Q 一直为 0 却仍有溢出？
ss -lnt 的 Recv-Q 列显示的是已完成三次握手、等待被 accept() 取走的连接数（即 accept queue），不是 SYN queue。SYN queue 溢出完全不体现在这里。
真正影响 SYN queue 容量的，是以下两个值的较小者：
-
net.ipv4.tcp_max_syn_backlog（内核参数，全局上限） - 监听 socket 创建时传入的
backlog参数（如listen(sockfd, 128)），内核会按需取 min(该值,tcp_max_syn_backlog)
检查当前值：
sysctl net.ipv4.tcp_max_syn_backlog
查看某个端口监听的实际 backlog（需 root）：
ss -lnt -o | grep ':80'（注意
State 列为 LISTEN 的行，Recv-Q 和 Send-Q 这里都无意义，但可结合 -o 看 timer 状态辅助判断压力）
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
netstat -s | grep -i "listen overflows" 为什么有时查不到？
因为 netstat -s 解析的是 /proc/net/snmp，但它只显示部分字段；老版本 netstat（如 net-tools 1.60）可能根本不解析 SynDrop，只显示 ListenOverflows（这个其实是 accept queue 溢出，不是 SYN queue）——二者常被混淆。
务必区分：
-
ListenOverflows→ accept queue 满，accept()太慢 -
SynDrop→ SYN queue 满，客户端发来的 SYN 被内核静默丢弃
所以不要依赖 netstat -s 查 SYN 溢出，直接读 /proc/net/snmp 更可靠。
如何确认是 SYN queue 溢出而非其他丢包原因？
单靠计数器不能 100% 定位，需交叉验证：
- 用
tcpdump在服务端抓包：tcpdump -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and dst port 80'
，如果看到大量客户端 SYN 进来，但服务端没回 SYN+ACK，且SynDrop在涨 → 基本确定是 SYN queue 溢出 - 检查是否启用了
tcp_tw_reuse或tcp_fin_timeout过短，导致 TIME_WAIT 占用端口，间接加剧 backlog 压力（少见但存在） - 确认没有防火墙（如 iptables/nftables）规则 DROP SYN 包，否则
SynDrop也会增加（但这是策略丢包，非队列溢出）
真正麻烦的是：SYN queue 溢出通常发生在突发流量打穿初始 backlog 设置时，而它本身不记时间戳、不留 trace，只能靠实时监控 SynDrop 增量 + 抓包比对来确认。
