访问量突然上升，不一定就是攻击；但如果请求激增同时伴随错误率升高、延迟变长或源站资源耗尽，就应启动网站遭遇流量攻击后的应急处置流程。处理时先确认影响范围，再采取与团队能力相匹配的措施，避免误封正常用户或让故障扩大。
第一步：确认异常并划定影响范围
先查看云平台、负载均衡器、应用和主机监控，比较当前请求量、响应状态、带宽、连接数与平时基线。同步确认故障是全站不可用、部分功能变慢，还是个别来源访问异常。检查近期发布、配置变更和依赖服务状态，排除自身变更导致的问题。
记录开始时间、受影响服务、错误表现、告警截图和关键日志；日志时间最好统一时区。不要只看总流量：如果流量并未明显增大，但应用错误和数据库等待持续上升，也可能是请求集中消耗了特定资源。确认告警后指定一名负责人汇总判断，减少多人同时改配置造成的混乱。
第二步：中小团队先保住核心服务
人手有限时，优先执行可快速回退、影响可控的措施。若已使用 Cloudflare 等 CDN 或安全服务，可在控制台检查防护告警及相关规则；若服务部署在 AWS，可按已启用的 AWS Shield 等能力和服务商支持渠道处理。不同套餐、架构和配置可用功能不同，不要假设某项防护已经自动开启。
- 联系服务商。向云主机、CDN或网络服务商提交事件时间、受影响地址、监控现象和日志摘要，询问是否可提供上游缓解或流量清洗。
- 收紧入口。按路径、请求方法、来源信誉或访问频率调整现有防护规则；先对高风险请求采取挑战、限速或拒绝，再观察误伤情况。不要未经验证就封禁大段地址范围。
- 降低非关键负载。暂停耗资源的非核心任务，延长可缓存内容的缓存时间，必要时临时限制高成本功能，并在状态页或其他渠道说明受影响服务。
- 保留变更记录。每次调整记下时间、操作者、规则和回退办法；若新规则导致正常访问失败，及时撤销或缩小范围。
中小团队的重点是快速借助已有供应商能力，而非临时搭建复杂清洗系统。若攻击持续、源站已无法稳定响应，及时升级服务商工单或电话支持，不要把反复重启服务器当作主要对策。
第三步：大型平台并行缓解与分级调度
大型平台通常可以由事件指挥人员统筹，网络、安全、应用、运维和客服分别负责检测、缓解、恢复与对外沟通。把网站遭遇流量攻击后的应急处置流程拆成并行任务：网络团队判断流量入口及分布，安全团队调整边缘防护，应用团队保护关键依赖，业务团队确定服务优先级。
分层处置，避免牵连正常业务
先在边缘节点过滤明显异常请求，再针对受影响服务实施限速、缓存或临时降级。若攻击超过既有网络承载能力，应由网络团队与上游运营商、云服务商协调路由或清洗方案；切换前确认备用路径容量、健康检查和回切条件。必要时将非核心功能设为只读或暂时关闭，优先维持登录、支付等核心链路的可用性，具体顺序应依据平台自身业务风险制定。
大型平台还应将缓解规则按区域或小范围流量逐步上线，观察成功率、延迟和误拦截，再扩大范围。对重要变更设置审批与回滚机制，避免一条过宽规则影响多个产品。
第四步：确认恢复，再复盘改进
流量回落不等于事件结束。确认关键服务的成功率、延迟和资源消耗回到可接受区间，并持续观察一段时间；具体观察时长取决于攻击持续性和业务峰谷。逐步撤销临时限制，检查积压任务、数据一致性和用户投诉，再发布准确的恢复说明。
复盘应回答：哪些告警最早发现问题，哪项措施有效，哪些规则造成误伤，供应商响应是否顺畅。把结论落实为更新联系人、值班安排、容量预案、监控阈值与演练任务。这些记录能让下次网站遭遇流量攻击后的应急处置流程更快启动，而不是从头判断。
常见问题
流量增加就代表遭遇攻击吗？
不一定。促销、内容传播或正常业务增长也会带来访问上升，应结合错误率、请求特征、资源消耗及业务活动判断。
小团队没有安全工程师怎么办？
先联系已使用的云平台、CDN或主机服务商，提交时间范围、监控现象和受影响服务，并只修改自己理解且能回退的规则。
什么时候应考虑切换清洗或路由方案？
当现有入口防护无法维持服务，且上游服务商确认有可用方案时，由网络负责人评估容量、切换风险和回退条件后执行。
攻击缓解后要保留哪些资料？
保留告警、相关日志、配置变更、服务商沟通记录、影响范围和恢复时间，并注意遵守适用的数据保留与隐私要求。