DDoS攻击发生时最直接的表现不是带宽报表飙红，而是业务“看起来还活着，实际上已经死了”。用户能建立TCP连接，但登录接口反复超时；静态页面能打开，但搜索、支付、订单提交全部卡死；服务器CPU占用并不高，但连接表被打满，新的请求进不来。出现这些现象，基本可以判断业务正在遭受应用层或混合型DDoS攻击，而不是单纯的网络拥塞。此时第一件事不是重启服务器，也不是盲目封IP，而是先确认攻击类型和影响范围，再按顺序做流量清洗、业务降级、源站保护与事后复盘。
第一步：确认攻击是否真实存在，以及攻击发生在哪一层
很多运维团队一看到网站打不开就怀疑是DDoS，实际上可能是数据库连接池耗尽、代码发布导致的内存泄漏，或者某个接口被正常流量打满。登录服务器后先执行几条命令：查看当前TCP连接状态分布、统计单个源IP的连接数、观察网卡流量是否接近带宽上限。如果SYN_RECV状态连接数异常高，说明是SYN Flood；如果ESTABLISHED连接数正常但请求响应极慢，同时应用日志显示大量请求打到同一个URL，大概率是HTTP Flood或CC攻击。如果服务器根本无法登录，SSH连接超时，但同机房其他机器正常，说明攻击流量已经将带宽或连接表占满，需要联系机房或云服务商从上游确认流量特征。
第二步：立即启用外部流量清洗，不要把希望全放在本机防护上
本机iptables或nginx限流在攻击初期可以临时顶一下，但面对几十G甚至上百G的流量，本机防护没有任何意义，因为流量在到达服务器之前已经把带宽占满了。此时应第一时间联系IDC或云平台启用黑洞路由或流量清洗服务。如果是云服务器，通常在控制台开启DDoS防护并调整清洗阈值；如果是自建机房，需要通知上游运营商做流量牵引。清洗启动后，攻击流量会被引导到清洗设备，正常业务流量再回注到源站。这个过程中业务可能会有几分钟的间歇性中断，但比长时间不可用要好得多。
第三步：在清洗生效前，先做业务层面的紧急降级
等待清洗生效的窗口期，源站仍然会承受一部分攻击压力。此时应关闭非核心功能，把有限的资源留给关键业务。具体做法包括：下线搜索建议、推荐位、统计上报等非关键接口；关闭第三方登录、验证码服务等外部依赖；将动态页面临时切换为静态缓存页；对登录、注册、下单等核心接口启用严格的频率限制。如果攻击集中在某个具体URL，比如搜索接口或API接口，直接在负载均衡层将该URL指向一个静态提示页，避免请求继续穿透到后端。
第四步：在负载均衡和Web层做精细化过滤
外部清洗解决的是大流量问题，但应用层CC攻击往往藏在正常流量里，清洗设备不一定能完全识别。此时需要在Nginx或负载均衡层做进一步过滤。先分析访问日志，找出攻击特征：某个URL被大量请求、某个User-Agent出现频率异常、某个源IP段集中发起请求、请求参数带有明显扫描特征。根据这些特征配置规则。以下是一个Nginx针对CC攻击的基础限流配置示例：
# 在http块中定义限流区域
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/s;
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
# 在server块中对登录接口应用限流
location /login {
limit_req zone=login_limit burst=10 nodelay;
limit_conn conn_limit 10;
proxy_pass http://backend;
}
这个配置的含义是：每个源IP对登录接口的请求速率限制为每秒5次，允许突发10次，超过后直接返回503。同时限制单个IP的并发连接数为10。需要注意的是，限流阈值要根据业务正常峰值来设定，不能拍脑袋定一个很低的数字，否则正常用户也会被误伤。
第五步：检查源站资源状态，防止攻击引发次生故障
DDoS攻击往往不是单独出现的，很多攻击者会在流量攻击的同时尝试利用漏洞入侵服务器。在流量清洗和限流生效后，要立即检查服务器的连接表、内存、磁盘IO和进程状态。重点看是否存在异常进程、是否有新增的计划任务、是否有陌生账号登录记录。如果发现数据库连接数被攻击请求占满，需要临时调大连接池上限，同时重启被拖死的应用进程。如果服务器已经无法响应，通过带外管理或云控制台强制重启后，先不要立即接入流量，等防护策略全部就位后再恢复业务。
第六步：根据攻击特征调整防护策略，而不是一直被动挨打
攻击持续期间，攻击者会不断变换手法。第一波可能是UDP Flood，第二波就变成HTTP Flood，第三波可能是混合攻击。防护策略需要跟着变。如果发现攻击源IP集中在某个地区或某个运营商，可以在清洗设备上临时封禁该地区的流量；如果攻击请求带有明显的URL参数特征，可以在WAF上配置对应的规则；如果攻击者使用大量代理IP，可以启用浏览器验证或JS挑战，让攻击流量无法通过验证。这些操作需要在攻击过程中持续进行，而不是配置一次就完事。
第七步：与上游服务商保持实时沟通，获取攻击流量报告
大型DDoS攻击的流量峰值、攻击类型、持续时间等数据，只有上游服务商能完整掌握。攻击结束后，务必向云平台或IDC索取详细的攻击流量报告，包括攻击开始时间、峰值带宽、包速率、主要攻击类型、攻击源分布等。这些数据对后续的防护策略优化和溯源分析非常重要。如果攻击持续时间较长，还要确认清洗服务是否产生了额外费用，以及是否需要调整防护套餐的规格。
第八步：攻击结束后的业务恢复与数据核对
攻击停止不代表工作结束。首先要确认所有业务功能恢复正常，特别是支付回调、订单状态同步、消息推送等异步流程，这些环节在攻击期间可能因为超时或重试机制产生数据不一致。其次要检查是否有用户数据在攻击期间被异常篡改，尤其是涉及金额、库存、权限的字段。最后要对攻击期间产生的脏数据进行清理，比如重复提交的订单、异常的登录日志、被限流误伤的合法请求记录等。
第九步：复盘并建立常态化的DDoS应急响应机制
每次DDoS攻击都是一次检验应急能力的实战。攻击结束后要组织复盘，重点回答几个问题：攻击从发生到被发现花了多长时间？从发现到启动清洗花了多长时间？业务中断了多久？哪些防护手段有效，哪些无效？下次遇到同类攻击能否更快恢复？根据复盘结果，完善监控告警、应急预案、防护策略和人员分工。同时建议定期进行DDoS演练，模拟不同类型的攻击场景，确保团队成员熟悉处置流程，避免真正攻击时手忙脚乱。
DDoS防御的核心不是某台设备或某个软件，而是一套完整的流程：快速发现、快速清洗、业务降级、精细过滤、事后复盘。任何一个环节缺失，都会导致恢复时间大幅延长。对于业务方来说，平时就要做好资产梳理、接口分级、限流阈值设定和上游防护对接，攻击发生时才能有条不紊地执行处置步骤，把业务损失降到最低。
