突发访问量上升，不一定代表正常用户变多。网站被恶意流量压垮时的防护方案，关键是先判断压力落在哪一层，再采取与故障相匹配的措施：盲目扩容可能增加成本，却不能解决持续请求或应用资源被耗尽的问题。
一、先监测：确认流量和故障类型
处置前先对照网站、主机和应用监控，记录异常开始时间，并查看每分钟请求量、响应时间、错误率、CPU、内存、连接数及带宽使用情况。重点检查哪些页面或接口请求骤增，以及错误是集中在 4xx、5xx，还是超时。
如果静态文件正常、登录或搜索接口变慢，问题可能集中在动态处理；如果多个页面都无法访问，则还要排查网络入口、代理或源站容量。将当前数据与平日同一时段比较，避免把正常活动高峰误判为攻击。不要只凭单一告警下结论。
二、先限流：降低源站承受的请求压力
确认异常后，优先保护仍可用的核心功能。限流是在入口处控制请求速度或并发量；它适合快速止损，但阈值过严也会挡住正常用户。可按以下顺序操作：
列出必须优先保留的页面和接口，以及可以暂时关闭的非关键功能，例如高成本的批量查询。
在反向代理或应用入口，为高负载接口设置请求速率、并发数或排队上限，并监控拒绝请求的比例。Nginx 的 limit_req 模块可用于按请求速率实施限制；具体值应依据正常流量、接口耗时和服务器余量调整，不宜照抄固定参数。
对被限制的请求返回明确状态和简短提示，避免客户端无间隔重试；同时测试登录、提交等关键操作，确认正常用户仍能完成任务。
若网站已接入 CDN，可先检查静态资源是否命中缓存，并将可缓存内容交由边缘节点响应，减少源站重复工作。CDN 能缓解部分源站压力，但对必须实时执行的动态请求，不能代替应用层限流。
三、再清洗：拦截异常请求并保护源站
限流仍不足以恢复时，可使用云端流量清洗或 WAF（Web 应用防火墙）处理。前者适合入口处出现大规模异常流量、网络链路受到挤压的情况；WAF 更适合依据请求特征限制针对网页和接口的异常访问。两者的能力和覆盖位置不同，启用前应确认流量是否确实经过对应服务。
查看清洗或 WAF 控制台提供的请求分类、拦截记录和源站健康状态，确认规则是否命中目标页面。
先采用观察模式或较窄的规则范围验证影响；若业务正在中断，再逐步扩大拦截范围，并持续检查误拦截和错误率。
确认代理链路已生效后，限制源站只接受预期入口转发的访问。否则攻击流量可能绕过边缘防护直达源站。调整入口访问策略前，先保留管理和故障恢复通道。
网站被恶意流量压垮时的防护方案不应等同于“一键封禁”：过宽规则可能误伤搜索、支付或登录等正常功能。每次调整都记录时间、规则范围和回退方式，便于快速撤销有问题的变更。
四、恢复后复盘：把临时措施变成预案
服务恢复后，不要立即撤掉所有限制。分阶段放宽规则，观察响应时间、错误率和源站资源是否稳定；同时保存告警、访问日志、WAF 记录及配置变更。复盘应回答三个问题：最先耗尽的资源是什么，哪项措施最快缓解，哪些正常请求受到影响？
据此更新容量告警、接口限额、缓存策略和应急联系人，并安排一次可控的预案演练。网站被恶意流量压垮时的防护方案只有落实到监控指标、执行权限和回退步骤，才便于下一次按顺序处置。
常见问题
限流和 WAF 可以互相替代吗？
不能。限流控制请求速度或并发，WAF 根据规则识别并处理特定请求；严重冲击可能还需要上游清洗。
接入 CDN 就能避免源站被打垮吗？
不能保证。静态内容较容易缓存，动态请求仍可能到达源站；还需检查缓存配置、入口保护和应用限额。
何时可以解除临时限制？
当错误率、响应时间及源站资源连续恢复稳定，并确认正常业务可用后，再分阶段放宽，避免一次性撤销全部措施。
