当AI被DDoS了怎么解决？实战排障与修复全流程 🛡️

AI服务和传统网站不一样，被DDoS打一次的代价要大得多。传统网站挂了只是页面打不开，AI服务挂了意味着GPU空转、API调用链断裂、流式响应中断、用户会话丢失——损失的不只是流量，还有真金白银的算力成本。下面按照"发现→定位→止血→修复→加固"的完整链路，讲清楚每一步该怎么做。

一、快速发现：别等用户投诉才知道 🔍

AI服务被打的早期症状往往不是"完全挂掉"，而是"变慢"。模型推理响应时间从正常的两三秒突然飙到十几秒，SSE流式输出频繁断流，API返回502或504错误——这些都是信号。

第一步，看系统负载和网络连接：

# 一条命令同时查看CPU负载、内存和连接概况
uptime && free -h && ss -s

uptime 显示系统平均负载，如果1分钟负载值远超CPU核心数，说明服务器已经过载。free -h 以可读格式显示内存使用情况，AI服务对内存消耗敏感，耗尽则触发OOM。ss -s 输出TCP连接的总览统计，正常AI服务的并发连接一般在几百到低千级，如果TCP连接数突然冲到数万，基本可以确认遭遇攻击。

接着定位异常流量来源：

# 按连接数排序，列出前10个最活跃的远端IP
ss -ant state established | awk '{print $5}' | rev | cut -d: -f2- | rev | sort | uniq -c | sort -rn | head -10

这条命令只筛选已建立状态的连接，提取远端IP地址并统计连接数。正常用户与AI服务的连接通常不超过个位数，如果某个IP维持了几百个并发连接，大概率就是攻击源 😤

二、精准判断攻击类型 🧩

AI服务面临的DDoS攻击主要分两种，应对策略截然不同：

带宽型洪水攻击 —— 用海量垃圾流量塞满你的带宽管道。特征是网卡流量暴涨，但Nginx的请求日志增长并不多。用这条命令确认：

# 实时监控网卡每秒流量
sar -n DEV 1 5

sar -n DEV 1 5 每隔1秒采样一次网卡收发数据量，连续采样5次。如果 rxkB/s（每秒接收KB数）远超正常值飙到数百MB甚至GB级别，就是带宽型攻击，这种必须靠上游高防清洗解决，服务器本身扛不住。

CC攻击（应用层洪水） —— 模拟正常用户请求疯狂调用AI接口。特征是Nginx的access日志请求量暴增，每条请求看起来都像正常的API调用。检查方式：

# 统计最近1分钟内被请求最多的接口路径
awk -v d="$(date '+%d/%b/%Y:%H:%M' -d '1 min ago')" '$4 ~ d {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -5

这条命令从Nginx访问日志中筛选最近1分钟的记录，统计每个URL路径被请求的次数。如果 /v1/chat/completions 之类的AI推理接口请求量异常暴涨，就是典型的CC攻击。这种攻击对AI服务的杀伤力尤其大，因为每个请求都会触发模型推理，消耗昂贵的GPU算力。

三、紧急止血措施 🚧

确认攻击类型后，立即执行对应策略：

应对CC攻击：Nginx层面快速限流

# 在http块中定义限流区域
limit_req_zone $binary_remote_addr zone=ai_protect:30m rate=1r/s;
limit_conn_zone $binary_remote_addr zone=ai_conn:20m;

location /v1/ {
    # 每个IP每秒仅允许1次请求，突发上限3个
    limit_req zone=ai_protect burst=3 nodelay;
    
    # 每个IP最多同时2个连接（一般用户不会同时发起多轮对话）
    limit_conn ai_conn 2;
    
    # 超限返回429状态码而非默认503
    limit_req_status 429;
    limit_conn_status 429;
    
    proxy_pass http://ai_backend;
}

这段配置的核心思路是"按AI接口的实际使用场景设计限流"。正常用户与AI对话的频率很低——发一条消息，等几秒回复，再发下一条。rate=1r/s 每秒1次的速率限制完全够用，但对攻击脚本来说是致命的。limit_conn ai_conn 2 限制单IP最多2个并发连接，因为流式对话本身就是长连接，正常用户同一时刻不会开启太多会话。返回429状态码（Too Many Requests）而不是503，语义更准确，也便于客户端做重试策略判断。

应对带宽型攻击：快速切入流量清洗

修改DNS将域名CNAME到高防CDN节点，攻击流量会在边缘节点被清洗，只有干净请求回源到你的服务器。切换后执行验证：

# 确认DNS已生效
dig +short your-ai-domain.com

# 源站锁死，仅接受CDN回源流量
iptables -I INPUT -p tcp --dport 443 ! -s CDN回源IP段 -j DROP

dig 检查域名解析结果是否已指向CDN节点。iptables 规则中的 ! 取反操作表示"不是来自CDN回源IP段的流量全部丢弃"。这条规则简洁高效，一行命令就锁死了源站的入口，让绕过CDN直打源站的攻击完全失效 💪

四、恢复服务：处理攻击后遗症 🔧

攻击被遏制后，服务不一定能自动恢复正常。AI服务常见的"后遗症"需要逐项检查：

# 检查AI推理进程是否还活着
systemctl status your-ai-service

# 检查GPU状态是否正常
nvidia-smi

# 清理积压的僵死连接
ss -ant state time-wait | wc -l

systemctl status 确认AI服务主进程没有因为OOM被系统杀掉。nvidia-smi 查看GPU显存占用和温度，攻击期间密集的推理请求可能导致GPU显存泄漏或进程残留。最后统计TIME_WAIT连接数，如果数量过万，说明连接回收还在进行中，可以通过调整内核参数加速清理：

sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_fin_timeout=10

tcp_tw_reuse=1 允许复用处于TIME_WAIT状态的端口，加速端口资源回收。tcp_fin_timeout=10 将FIN等待超时从默认60秒缩短到10秒，让被攻击期间堆积的半关闭连接尽快释放。

五、长效加固：让同样的攻击不再奏效 📊

每次攻击都是一次"免费渗透测试"，关键是把教训转化为防护能力：

Token鉴权前置 —— 在请求进入推理引擎之前先验证身份。没有合法Token的请求直接在网关层拒绝，一行代码都不让它触碰到GPU。这是AI服务区别于普通Web站点最重要的防护逻辑——保护的不是带宽，是算力 🧠

请求特征画像 —— 记录攻击期间的TLS指纹（如JA4）、请求频率模式、Header特征等数据，提炼成拦截规则沉淀到防火墙中。攻击者换IP很容易，但换工具特征很难，指纹识别能让同一波攻击者"换马甲"也无法得逞。

弹性扩缩与熔断 —— 当流量突增时自动扩容网关节点分摊压力，同时设置熔断阈值——当QPS超过系统承载能力的80%时，自动对非VIP请求返回排队提示，确保付费用户的体验不受影响。

总结 ✅

AI被DDoS的解决思路可以浓缩为一句话：先判断攻击类型，再选择对应武器。带宽型洪水靠高防清洗扛，CC攻击靠精细限流挡，两者结合覆盖绝大多数场景。止血之后做好善后恢复和规则沉淀，把每次攻击变成防御体系升级的契机，才是长久之道。