DDoS第一信号是网络接口吞吐量异常激增而非服务器宕机；需用nload、ip -s link、sar -n DEV实时比对历史基线；SYN_RECV堆积、SyncookiesSent上升、ss显示synrecv>1000提示TCP层攻击；tcpdump过滤抓包确诊协议特征。
看流量峰值是否远超基线
DDoS 的第一信号不是服务器宕机，而是网络接口吞吐量突然翻几倍甚至几十倍。关键不在于“高”，而在于“异常”——比如平时 eth0 RX 峰值 20Mbps，现在持续卡在 800Mbps，且无业务变更，这就是强提示。
- 用
nload -u M eth0看实时带宽（单位设为 MB/s 更直观）； - 用
ip -s link show eth0查看rx_packets和tx_packets计数器——1秒内增长数万包，基本可判定是洪泛类攻击； - 别只盯平均值：
sar -n DEV 1每秒采样一次，比vnstat这类分钟级统计更能抓到尖峰。
容易踩的坑：云服务器常有“弹性带宽”或“突发带宽”，误把平台限速释放当成攻击；要对比同一时段的历史 sar 数据，而非单看绝对值。
查连接状态是否失衡
SYN_RECV 堆积、ESTABLISHED 数暴增但实际业务连接数极少，是 TCP 层攻击（如 SYN Flood）的典型痕迹。Linux 内核不会无限排队，一旦 /proc/net/netstat 中 TcpExt:SyncookiesSent 开始上升，说明已触发防御机制。
- 快速筛查可疑 IP：
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20； - 看半开连接：
ss -s输出里的synrecv值若 > 1000，且持续不降，大概率被 SYN Flood； - 注意区分：Web 服务正常时也会有大量 TIME_WAIT，但 DDoS 下
ss -tan state syn-recv | wc -l会稳定在高位。
别直接信 netstat -an | grep :80 | wc -l——它包含所有状态，干扰大；ss 更轻量、更准，且默认不解析域名（加 -n 避免 DNS 查询拖慢响应）。
抓包确认协议与行为特征
流量和连接数只是“症状”，抓包才是确诊依据。重点不是抓全量包，而是用过滤表达式直击可疑模式，避免 pcap 文件过大导致分析卡死。
- 怀疑 SYN Flood：
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0' -c 1000 -w syn_flood.pcap； - 怀疑 UDP 小包洪泛（如 DNS/SSDP 反射）：
tcpdump -i eth0 'udp and (udp[4:2] ； - 抓完立刻用
tshark -r syn_flood.pcap -T fields -e ip.src | sort | uniq -c | sort -nr | head -5快速定位源 IP 分布。
常见错误：在高负载下用 tcpdump -w 写磁盘，IO 占满反而掩盖真实问题；建议先用 -c 限制包数，或写入 /dev/shm/（内存文件系统）。
交叉验证日志与系统表现
单看网络层可能误判——比如 CDN 回源失败、爬虫误配、监控探针暴增，都会模拟出类似 DDoS 的流量。必须结合应用日志与资源使用反推。
- 检查 Web 日志是否“有请求无业务”：
tail -n 1000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -3，如果 top3 IP 的请求全是GET /或GET /wp-login.php，且 User-Agent 是空或非常规字符串，大概率是应用层攻击； - 看 CPU 是否“空转”：
top中%sy（内核态）占比极高（>70%），而%us（用户态）很低，说明大量时间花在协议栈处理上，符合洪泛特征； - 留意
dmesg输出：dmesg -T | grep -i "nf_conntrack.*full"表示连接跟踪表溢出，是 Linux 主动丢包的明确证据。
最容易被忽略的一点：很多 DDoS 并非来自公网，而是内网扫描器误配、容器间调用风暴、或 Kubernetes Service ClusterIP 转发环路——所以别急着封外网 IP，先确认流量真实入口。
