ss -s 是诊断 SYN Flood 攻击的关键命令，通过查看 synrecv 值判断半连接队列是否溢出：若持续高于 tcp_max_syn_backlog 或远超基线，且 estab 下降、listen 正常，则大概率存在 SYN Flood；启用 tcp_syncookies 后 synrecv 可能不飙升但 CPU 上升，需结合 sar 观察。
当 Linux 服务器正遭受大流量 DDoS（尤其是 SYN Flood 类攻击）时，ss -s 是一个轻量、快速、无需 root 权限即可执行的关键诊断命令，它能直接反映 TCP 协议栈当前的连接状态分布，特别适合第一时间评估半连接池（SYN queue）是否濒临溢出。
直接看 synrecv 状态数判断半连接压力
执行：
ss -s | grep -i "tcp:"
典型输出示例：
TCP: 1234 (estab) 567 (close_wait) 89 (fin_wait2) 210 (time_wait) 45 (synrecv) 12 (listen)
其中 synrecv 表示处于 SYN_RECV 状态的半开连接数——即客户端发来 SYN、服务端已回复 SYN-ACK、但尚未收到 ACK 完成三次握手的连接。这是 SYN Flood 攻击最直接的堆积指标。
- 若
synrecv值持续高于net.ipv4.tcp_max_syn_backlog（默认通常为 128 或 256），说明半连接队列已满，新 SYN 请求将被丢弃，表现为客户端连接超时或“Connection refused”。 - 若
synrecv远高于日常基线（如平时为 0–5，突增至 200+），且伴随listen数无明显增长（监听端口未失效），基本可判定存在异常 SYN 洪水。
结合 ss -s 其他字段交叉验证
不必只盯 synrecv，整体状态分布能揭示攻击特征和系统响应效果：
-
estab突降 +synrecv猛增 → 典型 SYN Flood，服务端来不及完成握手； -
time_wait异常高（如 >5000）→ 可能是攻击后大量连接快速断开，或正常业务突增，需结合时间窗口判断； -
listen数为 0 或远低于预期 → 需立即检查服务进程是否崩溃（如 nginx/apache 退出），而非单纯网络攻击； -
total中TCP:后总数远超物理连接能力（如 >65535）→ 可能存在连接泄漏或恶意扫描，但不一定是 DDoS 主因。
注意事项与实操建议
-
ss -s输出快、开销极低，适合高频轮询（如watch -n 0.5 'ss -s | grep -i tcp:'）； -
synrecv值受net.ipv4.tcp_syncookies=1影响：启用后，即使队列满，内核会启用 SYN Cookie 机制，synrecv可能不飙升，但 CPU 使用率会上升，此时应同步观察sar -u 1 5； - 不要混淆
synrecv和listen：listen是监听套接字数量（即服务端口数），synrecv才是待确认连接数； - 若
synrecv持续高位，配合sysctl -w net.ipv4.tcp_syncookies=1可临时缓解（需写入/etc/sysctl.conf持久化）。
不复杂但容易忽略
