DDoS 攻击应急响应封面图，服务器被防护盾保护

DDoS攻击应急响应指南：30分钟流程

作者

DDoS 攻击应急响应封面

网站突然打不开、后台登录很慢、客服连续收到“页面无法访问”的反馈时，中小企业常会先怀疑服务器宕机。但如果同一时间访问量异常放大、请求来源分散、正常用户被挤出服务范围，就要考虑 DDoS（分布式拒绝服务攻击）风险。本文是一份 DDoS 攻击应急响应指南，帮助你在前 30 分钟内完成判断、止损、沟通和记录。

先判断：是不是 DDoS 攻击，而不是普通故障

DDoS（分布式拒绝服务攻击）的目标通常不是进入后台，而是用大量请求、连接或流量占满资源，让真实访客打不开页面。它和程序报错、数据库卡顿都可能表现为“网站慢”，所以第一步要分层确认。

你可以从 3 个信号开始排查。第一，看访问量是否在 5 到 10 分钟内突然上涨，例如平时每分钟 200 次请求，短时间冲到 2 万次以上。第二，看来源是否异常分散，如果日志里出现大量不同 IP（网络地址）但请求路径高度相同，常见于首页、登录页、搜索页被集中打满。第三，看服务器资源是否呈现单点瓶颈，例如 CPU（中央处理器）不高但网络入站带宽（单位时间内可传输的数据量）被打满，或 Web 服务连接数迅速耗尽。

如果你使用 VPS（虚拟专用服务器）或独服（独立服务器）承载业务，可以先通过基础命令确认现场，判断“流量异常”“连接异常”还是“应用异常”：

uptime
ss -ant | awk '{print $1}' | sort | uniq -c
ss -ant | grep ':80\|:443' | wc -l
top -o %CPU

这里要避免一个常见误判：看到服务器负载高就直接重启。重启可能短暂释放连接，但攻击仍在时服务会再次被打满，还可能丢失现场证据。更稳妥的做法是先截图、导出 5 分钟日志，再进入限流和隔离步骤。关于服务器日常巡检，可结合 服务器运维相关内容 建立固定检查项。

攻击识别信号图

前 10 分钟：止损优先，先保护正常用户入口

确认疑似 DDoS 攻击后，前 10 分钟的目标不是追查攻击者，而是保护正常用户入口。中小企业网站通常没有完整安全团队，最现实的策略是先收窄攻击面，再按业务优先级恢复关键页面。

可以按下面顺序处理：

  1. 先把动态高消耗入口临时收紧，例如搜索页、登录页、评论接口、购物车接口，每个入口设置 30 到 60 秒的访问频率限制。
  2. 如果网站前面已有 CDN（内容分发网络），立即开启防护模式、缓存静态页面，并把首页、产品页、帮助页设置为更长缓存时间，例如 5 到 15 分钟。
  3. 对明显异常路径返回 403 或 429，尤其是同一 URL 每秒被请求数百次、但没有正常业务意义的路径。
  4. 保留管理员访问白名单，例如公司固定出口 IP（网络地址），避免应急期间自己也无法登录后台。

如果没有现成防护层，可以先在 Web 服务侧做低风险限流。以 Nginx 为例，可以把单个 IP（网络地址）访问速率限制在每秒 5 次，并设置一个小的突发队列：

limit_req_zone $binary_remote_addr zone=site_limit:10m rate=5r/s;

server {
    location / {
        limit_req zone=site_limit burst=20 nodelay;
        try_files $uri $uri/ /index.php?$args;
    }
}

这不是长期防护方案，因为分布式攻击会来自大量地址，单 IP（网络地址）限流只能缓解一部分压力。但在没有专用清洗服务时，它能降低动态应用压力，为后续升级防护争取时间。如果业务运行在 VPS（虚拟专用服务器） 环境，建议同时查看入站流量曲线，确认瓶颈是网络层、Web 层还是数据库层。

10 到 20 分钟：分清流量层、连接层和应用层

DDoS（分布式拒绝服务攻击）并不是一种固定形态。不同攻击类型对应的处置方式不同，混在一起处理容易浪费时间。中小企业可以先按“流量层、连接层、应用层”三类判断，不必一开始就追求完整安全分析报告。

流量层攻击通常表现为带宽（单位时间内可传输的数据量）被占满，服务器还没来得及处理请求，用户访问就已经超时。连接层攻击常见表现是 TCP 连接数暴涨，Web 服务可用 worker 被占住。应用层攻击更隐蔽，看起来像大量真实用户访问某个高消耗页面，例如站内搜索、筛选页、登录接口或未缓存的动态页面。

三类情况可以这样对应处理：

类型 典型信号 现场动作 验证指标
流量层 入站带宽（单位时间内可传输的数据量）接近上限 联系服务商开启流量清洗或临时封堵异常协议 入口流量下降、丢包减少
连接层 ESTABLISHED、SYN-RECV 数量异常 调整连接超时、启用 SYN 防护、限制单源连接 连接数回落到平时 2 倍以内
应用层 某些 URL 被高频请求 缓存页面、限制接口、临时关闭高消耗功能 PHP/数据库负载下降

无法判断类型时，先把访问日志按路径和状态码做一次粗统计：

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -nr

当某个路径占比超过 50%，优先按应用层处理；如果所有路径都打不开且流量曲线打满，优先联系机房或主机服务商做上游处理。这里不要把 CDN（内容分发网络）当成万能开关：如果源站真实 IP（网络地址）已经暴露，攻击者可能绕过 CDN（内容分发网络）直接打源站，所以源站防火墙和回源白名单也要检查。

三类攻击处置对比

20 到 30 分钟：沟通、升级和证据留存

技术止损之外，沟通也会影响恢复效率。很多中小企业在攻击发生时只有站长或开发人员在线，如果没有明确分工，就会出现“客服不知道怎么解释、技术人员被消息打断”的情况。建议同步建立事件记录。

记录内容不用复杂，但要固定字段：事件开始时间、影响域名、受影响功能、当前可访问状态、已采取动作、下一次更新时间。例如“17:05 首页异常；17:18 限制搜索接口”。这种记录能让客服、运营和管理层用同一版本信息沟通。

同时准备给服务商的证据包，包含 4 类信息：

  1. 受影响域名和服务器公网 IP（网络地址），精确到业务所在主机，不要只说“网站打不开”。
  2. 攻击开始时间和时区，例如 2026-08-06 14:20 UTC+8，便于匹配网络侧流量曲线。
  3. 5 到 10 分钟访问日志样本，压缩后提供，不要把整台服务器备份直接发出。
  4. 当前已采取的限流、缓存、防火墙规则，避免服务商重复建议你已经执行过的动作。

如果攻击已经影响付款、询盘或登录等关键业务，升级顺序应高于普通页面恢复：先保证静态公告页可访问，再恢复产品页和联系表单，最后恢复搜索、评论、筛选等高消耗功能。WordPress 网站可参考 WordPress 运维与优化文章，提前整理插件、缓存和安全规则。

恢复后 24 小时：不要只看“网站能打开了”

攻击缓解后，网站能打开只是第一步。接下来 24 小时要确认没有隐藏损伤，例如缓存规则过宽导致会员页被缓存、临时封禁误伤正常地区用户、日志分区被写满、数据库慢查询堆积。恢复检查建议分 3 轮：攻击停止后 30 分钟、2 小时、24 小时各检查一次。

第一轮看可用性：主页、产品页、登录页、表单提交、支付或询盘链路是否正常。第二轮看资源：CPU（中央处理器）、内存、磁盘、带宽（单位时间内可传输的数据量）曲线是否回到平时范围。第三轮看业务：搜索引擎抓取、广告落地页、客服反馈、订单或询盘数据是否恢复。

这一步还要把临时策略逐项回收。比如接口频率限制到每分钟 3 次，恢复后可能影响真实用户批量提交；缓存延长到 30 分钟，也可能让公告更新不及时。建议把临时变更写进“回滚清单”，每项包含配置文件、修改时间、负责人和验证方式。

对于承载核心业务的网站，我们建议把 DDoS（分布式拒绝服务攻击）应急纳入季度演练。一次轻量演练可以只花 40 分钟：确认监控入口、模拟客服话术、检查 CDN（内容分发网络）和防火墙规则、更新联系人与升级路径。这样真正遇到攻击时，团队不会从零开始找账号、日志和负责人。

恢复后复盘检查

平时怎么降低下一次攻击的影响

DDoS（分布式拒绝服务攻击）不能只靠事发当天处理。更现实的目标是让攻击来临时“可发现、可切换、可恢复”。对中小企业来说，平时投入不一定很高，但关键点要做扎实。

可以从 5 个基础动作开始：

  1. 监控设置两条线：页面可用性每 1 分钟探测一次，服务器资源每 30 秒到 60 秒采集一次，避免只靠用户反馈发现故障。
  2. 源站只允许必要端口开放，例如 80、443、22，并把后台管理入口限制到固定 IP（网络地址）或 VPN（虚拟专用网络）。
  3. 静态资源尽量前置缓存，图片、CSS、JS 设置合理缓存时间，减少源站在攻击时承担的请求量。
  4. 每周导出一次核心配置，包括 Nginx、数据库、DNS（域名系统）解析、SSL（安全传输协议）证书和防火墙规则。
  5. 给关键业务准备降级页面，例如只保留联系方式、订单查询或公告说明，确保主站异常时仍有沟通入口。

主机方案也会影响应急空间。虚拟主机（共享服务器资源的建站方案）适合轻量站点，但遇到持续攻击时可调参数较少；VPS（虚拟专用服务器）能自主管理防火墙、Web 服务和缓存策略；独服（独立服务器）在资源隔离和网络策略上更灵活。如果你正在评估关键业务基础设施，可以结合 独服（独立服务器）相关方案 和现有流量规模判断。

总结：把 DDoS 应急做成流程，而不是临场反应

DDoS（分布式拒绝服务攻击）发生时，最容易浪费时间的不是某个命令不会用，而是没有明确顺序：先怀疑程序、再重启服务器、再翻聊天记录、最后才联系服务商。更推荐的做法是固定 30 分钟流程：前 10 分钟确认信号并止损，10 到 20 分钟区分攻击类型，20 到 30 分钟完成沟通升级和证据留存，恢复后 24 小时再做回滚与复盘。

如果你需要为企业网站建立更稳的防护基础，可以考虑从监控、缓存、源站隔离和主机资源四个方面同步改进。Hostease 在主机、VPS（虚拟专用服务器）和独服（独立服务器）等场景中提供不同承载选择，但具体方案仍应结合网站流量、业务高峰、运维能力和预算来评估。真正有价值的安全建设，不是承诺永远不出问题，而是在问题出现时让团队知道下一步该做什么。

发表评论