网站突然变慢或无法访问，先要判断拥塞发生在网络入口，还是请求已经到达服务器。网站遭遇流量型攻击的应急处置，不能只靠源站调高限流，也不能把所有问题都交给云端清洗：前者无法恢复已被塞满的接入链路，后者也未必能识别每一种合法业务请求。应按链路位置分工，先保可达，再保关键功能。
先看故障卡在哪一段
同步查看云平台流量图、负载均衡器状态、服务器连接数和应用日志。若入口带宽持续接近线路上限，且多类请求都超时，问题可能在到达源站之前；这时单纯限制源站请求，通常不能释放已经拥塞的线路。若入口流量并未明显增加，但应用线程、连接池或数据库连接耗尽，则更应检查请求是否集中冲击登录、搜索等动态功能。
同时对照平日基线，查看请求来源分布、访问路径、响应状态码及每秒请求变化。真实促销、新闻传播或产品发布也会带来访问激增，不能仅凭流量变大就封禁来源。保留带时间戳的监控截图、日志片段和故障起止时间，便于云服务商或网络运营方协助定位。
云端清洗先处理入口拥塞
当流量在网络入口处挤占带宽，优先联系云服务商或具备清洗能力的网络服务方，请其确认攻击流量是否已到达清洗节点、清洗是否生效，以及正常用户的回源路径是否可用。流量清洗适合处理源站之前的大规模异常流量；具体覆盖范围取决于服务接入方式、业务协议和线路部署，不能默认所有流量都会自动经过清洗。
若网站使用反向代理或边缘节点，检查域名解析与回源配置是否仍指向受保护的入口，并确认源站没有被外部直接访问绕过。涉及邮件、远程管理等其他业务时，应单独核对其网络路径，避免误把网站防护配置套到无关服务上。清洗期间同步观察正常请求成功率和延迟，不要只看攻击流量是否下降。
源站限流用于保护应用资源
当请求已到达负载均衡器或服务器，且应用资源被特定路径、会话或来源消耗时，源站限流可以快速降低压力。优点是能按业务规则精细控制；缺点是配置位置靠后，无法替代入口侧的流量清洗。对共享出口或大量用户共用地址的场景，直接按单一来源地址封禁，可能误伤正常访问。
按影响范围逐步调整
- 先保留管理通道。确认运维入口、健康检查和关键业务不受新规则影响，记录当前配置，准备回滚方式。
- 从高耗资源路径开始。对异常集中的搜索、验证码或登录请求设置并发、频率限制；阈值依据平时峰值、接口成本和服务器余量确定，不照搬固定数字。
- 分层实施拦截。优先使用现有负载均衡器或应用防火墙的规则，按路径、请求特征和来源信誉逐步收紧；观察错误率、响应时间及误拦投诉后再扩大范围。
- 验证恢复效果。确认关键页面和后台操作可用，持续关注回源带宽、连接数及应用资源。若入口链路仍拥塞，应升级云端清洗或联系线路服务方，而非继续叠加源站规则。
按链路分层协同，避免反复改规则
现场处置时指定一人协调云服务商、网络运营方与应用团队，统一记录操作时间和影响。云端清洗负责入口侧的流量筛除，源站限流负责保护主机与应用，应用团队则排查是否存在慢查询、重试风暴或配置异常。每次变更后都看同一组指标，避免多方同时调整造成原因难以追溯。
流量回落后，不要立刻撤掉全部防护。先确认正常访问稳定，再逐项恢复临时限制；复盘入口容量、清洗接入条件、源站直连暴露面和告警延迟。网站遭遇流量型攻击的应急处置，关键不是把规则设得越严越好，而是让每一层处理它能够控制的那段链路。
常见问题
源站限流能代替云端清洗吗？
不能完全代替。若接入链路已被流量占满，源站规则无法清除到达服务器之前的拥塞。
开启清洗后，为什么网站仍然变慢？
可能是清洗尚未覆盖相关流量、回源链路拥塞，或应用本身仍有资源瓶颈，应分别检查入口监控、回源状态和应用指标。
能否直接封禁流量最多的来源？
不宜只按流量排名封禁。共享地址可能承载正常用户，建议结合请求路径、访问行为和业务影响逐步限制。
何时可以撤销应急规则？
当流量和关键业务指标恢复稳定，并确认规则不会造成误拦后，按项回退临时措施，同时保留必要的常态防护。