看到/var/log/messages反复出现“possible syn flooding”是半连接队列溢出的明确告警，需立即验证：netstat -s查“syns to listen sockets dropped”是否持续增长、ss -s看synrecv是否长期超500、dmesg查警告频次；秒级止血启用tcp_syncookies=1；同步调大tcp_max_syn_backlog至65535并匹配somaxconn与应用层backlog；排除tcp_synack_retries过大、tcp_tw_recycle启用等误判干扰。
看到 /var/log/messages 里反复刷出 TCP: possible SYN flooding，说明内核已检测到半连接队列（SYN queue）持续溢出，这不是“疑似攻击”的提示，而是明确的资源告警——当前配置已无法承载入向连接请求压力，必须立即干预，否则新连接将被静默丢弃。
确认是否真有队列压满
先别急着改参数，快速验证问题根源：
- 执行
netstat -s | grep -i "syns to listen sockets dropped"，若输出数字持续增长（比如每秒+10），说明tcp_max_syn_backlog确实太小，连接正被丢弃； - 运行
ss -s查看synrecv数量，若长期高于 500，且伴随大量TIME_WAIT，说明连接建立和释放节奏失衡； - 用
dmesg -T | tail -20看最近警告的时间戳和频率，如果集中在某几分钟爆发，更可能是突发流量而非持续攻击。
立刻启用 SYN Cookie 防御兜底
这是唯一能“秒生效”的止血操作，不依赖队列扩容，直接绕过队列限制：
- 临时开启：
sysctl -w net.ipv4.tcp_syncookies=1； - 同时确保它已写入
/etc/sysctl.conf，避免重启失效； - 注意：SYN Cookie 是兜底机制，不是替代方案。它能防住大部分伪造源 IP 的洪水，但对真实高并发场景（如秒杀）不能降低延迟，仅保连接不断。
检查并扩容半连接队列
默认值（通常 1024 或 2048）在 Web 服务上极易打满：
- 查当前值：
sysctl net.ipv4.tcp_max_syn_backlog； - 合理值应 ≥
net.core.somaxconn（监听队列上限），建议设为65535； - 修改后执行
sysctl -p生效； - 若应用使用
listen()时传入的backlog参数较小（如 Nginx 默认 511），需同步调大该参数，否则内核仍按小值截断。
排除常见误判干扰
这个警告未必是攻击，也可能是配置或环境异常：
- 检查
net.ipv4.tcp_synack_retries是否被设得过大（如 10），导致半连接滞留时间过长，挤占队列——建议保持默认 5； - 确认未启用
tcp_tw_recycle（旧内核），它在 NAT 环境下会误判时间戳，造成大量合法连接失败，现象类似 SYN flood，必须关掉：sysctl -w net.ipv4.tcp_tw_recycle=0； - 观察是否伴随
arp_ignore或rp_filter异常日志，多网卡服务器若 ARP 响应错源，也可能触发连接异常重传，被误判为洪水。
