必须在2分钟内确认是否正遭受DDoS攻击：先用nload和ip -s link查带宽与包量激增，再用ss -s看synrecv>1000及SyncookiesSent上升，接着用ss或/proc/net/nf_conntrack聚合攻击IP，最后tcpdump抓包分析协议特征。
当你发现服务器响应变慢、SSH连接卡顿、API超时率突增，且云防火墙告警激增但无业务变更时，必须在2分钟内确认是否正遭受DDoS攻击——这不是等监控告警的被动判断，而是靠终端命令直取内核指纹的主动穿透。
第一步：确认网络接口是否被洪泛冲击
运行 nload -u M eth0 查看实时带宽（单位设为 MB/s），若当前 RX 值持续高于历史基线3倍以上（例如平时20Mbps，现在稳定在800Mbps），立即进入下一步；云服务器需注意弹性带宽释放可能造成误判，务必用 sar -n DEV 1 每秒采样比对同一时段历史数据。
执行 ip -s link show eth0 | grep -A 3 "rx:"，观察 rx_packets 计数器1秒内是否增长数万包——这是UDP Flood或ICMP Flood最直接的物理层证据。
第二步：检查TCP连接状态是否失衡
运行 ss -s，重点关注输出中 【synrecv】 数值：若 > 1000 且持续不降，基本可判定正在遭受 SYN Flood 攻击；此时再查 cat /proc/net/netstat | grep -i "SyncookiesSent"，若该计数非零且每秒递增，说明内核已触发SYN Cookie防御机制，攻击真实存在。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
不要用 netstat -an | grep :80 | wc -l 统计连接数——它混入大量 TIME_WAIT 和无关端口，干扰严重；ss 更轻量、默认不解析域名，响应快47倍。
第三步：定位攻击源IP分布
方法一：快速聚合高频IPss -tan state syn-recv | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -15
这一步直接暴露正在发SYN包的IP列表，数值越大越可疑。
方法二：绕过连接表饱和干扰
当 conntrack -L 命令卡死或报错“table full”时，改用 cat /proc/net/nf_conntrack | head -500 | awk '{print $6}' | cut -d= -f2 | sort | uniq -c | sort -nr | head -10——它从原始连接跟踪缓冲区读取，不依赖用户态conntrack服务，即使连接表已满也能拿到前序攻击IP特征。
注意：【不要在高负载下直接运行 conntrack -L > all.log】，该操作会锁死连接跟踪子系统，导致新连接无法建立，业务雪崩。
第四步：用tcpdump抓包确诊协议类型
第一步：限制包数防IO打满
怀疑 SYN Flood：执行 tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0' -c 500 -w /dev/shm/syn.pcap
第二步：内存写入保速度/dev/shm/ 是tmpfs内存文件系统，避免磁盘IO成为瓶颈，也防止抓包过程拖垮系统。
第三步：快速提取源IP分布tshark -r /dev/shm/syn.pcap -T fields -e ip.src 2>/dev/null | sort | uniq -c | sort -nr | head -5
如果前5名IP出现大量不同端口、TTL值异常（如全为64或全为128）、且无对应HTTP User-Agent，基本可锁定为伪造源IP的反射型攻击。
