网站突然变慢或打不开，先别急着重启所有服务。正常活动带来的访问增长、程序故障和恶意请求，表现可能相似，但处置方式不同。网站遭遇流量攻击后的应急处置流程，应从确认影响范围开始：保留证据，联系相关服务方，再按风险采取限流或拦截措施。
先判断影响，再固定现场
记录故障开始时间、受影响的页面、用户所在区域和错误提示，同时查看服务器监控、访问日志及网络流量变化。重点比较请求量、来源分布、请求路径和响应状态：短时间内请求异常集中在少数接口，或大量请求重复访问同一路径，可能提示异常流量；但单凭访问量升高，不能断定是攻击。
如果只有个别页面报错，检查对应应用和依赖服务；如果全站都无法访问，联系主机或网络服务商确认链路状态。保存原始日志及时间信息，避免在排查前清空日志、重装系统或大幅改配置。若涉及账号泄露、数据异常等情况，限制受影响账号操作，并按组织内部的信息安全流程升级处理。
按顺序执行应急处置
- 确认责任边界。联系托管服务商、域名解析服务商或网络服务商，说明故障时间、受影响地址和已观察到的现象，请其核实是否存在上游异常或流量清洗措施。记录工单和沟通时间。
- 先保护关键服务。如管理后台、登录、搜索等非核心功能消耗明显，可临时关闭或限制这些功能，优先保留用户最需要的页面。避免未经评估就封禁整个地区或大量来源，可能误伤正常用户。
- 启用适合的流量防护。CDN可缓存静态内容并分担源站请求，适合静态资源较多的网站；WAF可按规则识别并拦截部分异常请求，适合针对特定路径或请求特征的防护。两者都不能保证拦截所有攻击，启用后应观察误拦截和源站负载。
- 调整限流与访问规则。对登录、搜索、提交表单等动态接口设置合理的请求频率限制；确认规则只作用于目标路径，并从少量规则开始测试。若异常流量来自明显重复的请求特征，可在防护设备上针对特征拦截，而非仅凭单一来源信息封锁。
- 分阶段恢复。流量回落后，先检查首页和关键业务流程，再逐步恢复临时关闭的功能。持续观察错误率、响应时间和资源使用情况；若问题复现，撤回最近一项变更，重新确认原因。
根据攻击表现选择措施
网络流量异常增大
如果外部请求压满网络链路，单靠应用内限流可能来不及生效。应尽快联系网络服务商确认能否在上游清洗或过滤，并核实域名解析和防护平台是否仍将流量正确导向服务。网站遭遇流量攻击后的应急处置流程中，上游协同尤其重要，因为源站本身无法处理尚未到达应用的流量。
请求集中但链路未满
若请求主要集中在少数动态页面，优先检查相关接口的访问模式和应用日志，再对具体路径设置限流或挑战规则。与直接增加服务器资源相比，针对异常请求采取措施更能避免资源被持续消耗；但规则过严可能影响真实用户，需要小范围验证。
恢复后做好复盘
服务恢复不代表事件结束。整理故障时间线、影响范围、采用的规则、误拦截情况以及恢复条件；检查应用和管理账号是否存在异常登录或配置变化。根据复盘结果补充监控告警、日志留存和联系人清单，并定期确认防护规则仍适用于当前网站。网站遭遇流量攻击后的应急处置流程应形成可执行的值班文档，写明谁负责判断、谁联系服务商、哪些措施需要审批。
常见问题
网站打不开，一定是流量攻击吗？
不一定。也可能是程序错误、配置变更、域名解析异常或服务商故障。先比对监控、日志和服务状态，再判断原因。
可以直接屏蔽所有陌生来源吗？
不建议。正常用户也可能来自陌生网络。应优先根据请求频率、路径和行为特征制定规则，并检查误拦截。
什么时候该联系服务商？
出现全站不可达、网络链路异常或流量超出自身处理能力时，应尽快联系托管或网络服务商，并提供故障时间、受影响页面和日志线索。
恢复后还要做什么？
复核关键业务、账号和配置，保存事件记录，并补齐监控与应急联系人。复盘结论应落实为具体规则和操作步骤。