DDoS 应急响应手册：从攻击识别到业务恢复

DDoS 应急响应不是等网站彻底打不开后才开始处理，而是在异常流量刚出现时就判断风险、分派职责、执行止损。本文会用一套可落地的流程，帮助站长和运维团队解决“看不清攻击、联系不上上游、恢复后又反复”的常见问题。

如果你负责企业官网、外贸站、会员系统或在线业务，DDoS（分布式拒绝服务）攻击带来的影响通常不是单点故障，而是访问失败、客服投诉、广告预算浪费和订单中断同时出现。与其临时翻聊天记录找命令，不如提前把识别、遏制、恢复和复盘写成一份应急手册。

先判断：这是不是一次 DDoS 攻击

DDoS（分布式拒绝服务）攻击的本质，是用大量分散来源的请求消耗目标资源。被消耗的资源可能是带宽（服务器与外部网络之间的数据传输容量上限）、连接数、CPU、内存，也可能是应用层接口的处理能力。判断时不要只看“网站打不开”，而要把网络、系统和业务三层证据放在一起。

网络层最直观的信号，是出口或入口流量在几分钟内突然放大，例如平时峰值只有 80Mbps，短时间内冲到 800Mbps，并伴随丢包率上升。系统层信号包括 TCP 连接数异常、SYN_RECV 状态堆积、Web 服务返回大量 502/503/504。业务层信号则是登录、支付、搜索等关键接口超时，且用户地域分布与平时不一致。

初步排查可以先用下面几条命令，不建议在高压状态下临时组合复杂脚本。命令只用于判断方向，真正封禁前还要确认是否会误伤正常用户。

# 查看当前连接总数
ss -ant | wc -l

# 查看 TCP 状态分布
ss -ant | awk 'NR>1 {print $1}' | sort | uniq -c | sort -rn

# 查看连接来源最多的 IP
ss -ntu | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# 抽样查看访问日志中的高频来源
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

如果你还需要进一步区分性能瓶颈和攻击流量，可以参考 TTFB 与主机性能优化指南中的响应时间排查思路，把正常慢请求和异常洪泛请求分开处理。

0 到 15 分钟：确认影响并启动响应

攻击刚出现的前 15 分钟，目标不是做完整根因分析，而是确认影响范围并让正确的人进入同一个处置通道。建议把沟通拆成三个角色：一人负责技术排查，一人负责联系机房、上游或防护服务，一人负责对业务方同步影响和恢复预期。这样可以避免所有人都盯着同一台服务器，却没人推进外部协同。

记录开始时间、受影响域名、业务接口和当前错误码，例如 503 比例是否超过 30%。
截图保存监控面板中的带宽（服务器与外部网络之间的数据传输容量上限）、连接数、CPU 和错误率曲线。
确认是否只有单个域名异常，还是同一服务器上的多个站点同时异常。
检查 DNS（域名系统）解析是否被篡改，避免把解析故障误判成攻击。
把处置过程写入共享文档，至少记录时间、动作、执行人和结果。

这一步还有一个常被忽略的细节：不要立刻重启所有服务。重启可能清空现场连接状态和日志，让后续分析变得困难。除非服务进程已经卡死，优先保留证据，并用限流、清洗和切流来降低压力。

15 到 30 分钟：先止损，再细化策略

确认攻击后，应急重点要从“找出全部攻击源”切换到“尽快恢复可用性”。如果攻击已经打满带宽（服务器与外部网络之间的数据传输容量上限），仅在服务器上加防火墙规则往往来不及，因为恶意流量已经到达你的线路。此时应优先联系上游服务商启用流量清洗，或把解析切换到具备防护能力的入口。

对于还没有打满线路、但应用层请求异常的场景，可以先在 Web 服务层设置保守限流。例如针对登录、搜索、评论提交这类接口，将单 IP 请求速率控制在一个业务可接受范围内，并观察 5 到 10 分钟错误率是否下降。

http {
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

    server {
        listen 80;

        location / {
            limit_req zone=req_limit burst=20 nodelay;
            limit_conn conn_limit 50;
        }
    }
}

如果攻击集中在 HTTP 层，还可以临时关闭高消耗接口、启用静态缓存、提高缓存命中率。WordPress 站点遇到访问洪峰时，除了限流，也可以结合 WordPress 运维与安全相关文章检查插件、登录页和评论接口是否被集中请求。

30 分钟以后：分析特征并恢复业务

当主要压力被清洗、限流或切流缓解后，团队需要从“止血”进入“稳定恢复”。这时不要急着撤掉所有防护策略，因为 DDoS（分布式拒绝服务）攻击经常分波次出现。建议至少持续观察 24 小时，把攻击峰值、来源分布、请求路径、User-Agent、状态码和防护动作整理成一份事件记录。

恢复业务时可以采用分层验证：先确认域名解析正常，再确认首页可访问，然后测试登录、下单、搜索、后台管理等关键路径。每恢复一个模块，都记录响应时间和错误率。对于对外服务较多的网站，还应从不同地域的探测点测试访问，避免本地看起来恢复、海外用户仍然访问失败。

检查对象	建议指标	通过判断
域名解析	DNS（域名系统）返回值	解析到预期入口，无异常跳转
站点访问	HTTP 状态码	首页和核心页面返回 200 或 301
业务接口	错误率	连续 10 分钟低于平时告警阈值
服务器资源	连接数与负载	回落到正常峰值的 1.5 倍以内

如果你使用 [VPS](https://cn.hostease.com/vps/)（Virtual Private Server，[虚拟专用服务器](https://cn.hostease.com/vps/)）承载业务，攻击后还应检查系统参数和服务配置是否适合当前流量规模。相关优化可以延伸阅读 VPS（Virtual Private Server，虚拟专用服务器）相关教程，重点关注连接队列、缓存、日志轮转和备份策略。

复盘：把一次事故变成下一次的预案

DDoS（分布式拒绝服务）攻击结束后，复盘的价值不在于追责，而是把临时动作固化成下一次可以复用的流程。复盘至少应覆盖四个问题：攻击何时开始、谁在什么时间采取了什么动作、哪个动作真正降低了错误率、哪些沟通或权限卡住了处置速度。

建议把复盘结果整理成一页应急卡片，放在团队都能访问的位置。卡片里写清楚上游服务商联系方式、防护开关位置、DNS（域名系统）切换步骤、SSL（安全套接层，用于加密网站访问）证书注意事项、业务降级开关和负责人电话。真正发生攻击时，越少依赖个人记忆，恢复速度越稳定。

架构层面也要同步加固。对高访问量网站，可以将静态资源放在 CDN（内容分发网络）后方，源站只暴露必要端口；对交易或会员业务，应准备备用入口和只读降级页面；对重要数据，要确保备份不与被攻击站点放在同一单点环境。使用服务器运维与选型相关文章时，也应关注线路冗余、防护能力和故障响应流程，而不只看单项配置。

日常防护建议

真正有效的 DDoS 应急响应，依赖平时的准备。建议每季度做一次 30 分钟桌面演练：假设首页不可访问、登录接口超时、带宽（服务器与外部网络之间的数据传输容量上限）升高到平时峰值 10 倍，让团队按预案走一遍通知、排查、切流和恢复流程。演练中发现的权限、联系人和命令问题，比攻击当天才发现要容易修正得多。

监控上至少覆盖流量、连接数、HTTP 错误率、核心接口响应时间这 4 类指标。
告警阈值要区分普通高峰和异常高峰，例如连续 5 分钟超过历史峰值 3 倍才升级。
防火墙、Web 限流、缓存降级和上游清洗都要提前测试，避免临场改配置。
关键业务建议准备备用页面或只读模式，让用户知道服务正在恢复。
日志保留周期不要低于 30 天，便于追踪慢性探测和多轮攻击。

如果你的业务已经出现过攻击、广告投放期间访问波动明显，或当前服务器没有清晰的防护入口，可以考虑选择带基础防护和中文支持的主机方案。Hostease 可为不同规模网站提供 VPS（Virtual Private Server，虚拟[专用服务器](https://cn.hostease.com/dedicated-server/)）、[独立服务器](https://cn.hostease.com/dedicated-server/)和相关托管方案，但具体配置仍应结合业务访问量、预算和恢复时间目标来评估。

总结与行动建议

DDoS 应急响应的关键，不是掌握某一条封禁命令，而是在识别、止损、恢复、复盘之间建立稳定流程。建议你现在就完成三件事：整理一份应急联系人清单，确认 DNS（域名系统）和防护入口的操作权限，按本文检查监控指标是否覆盖流量、连接数、错误率和业务接口。这样下次异常发生时，团队可以把时间用在恢复服务上，而不是临时确认谁能操作、该看哪份文档。