网站访问突然激增时，先要分清是真实用户变多，还是异常请求集中涌入。网站遭受流量攻击时的边缘分流方案，核心是让靠近用户的边缘节点先接收请求，再按缓存、访问规则和风险特征进行处理，尽量避免所有流量直接压向源站。它不能保证拦下每一种攻击，但能把过滤和吸收压力的位置前移。
边缘分流能做什么，不能做什么
边缘节点通常由 CDN 网络提供，分布在多个区域。对图片、样式文件、下载文件等适合缓存的内容，节点可直接返回副本；需要动态计算的请求，则经规则检查后转发到源站。这样既减少重复回源，也能在网络边缘执行 WAF（Web 应用防火墙）规则和速率限制。
Anycast 是一种常见的流量调度方式：多个节点对外公布同一服务地址，网络根据路由情况将用户请求引向较合适的接入点。它有助于分散流量，但不等于攻击自动消失。若源站地址仍可被直接访问，攻击者可能绕过边缘节点；应用层请求若伪装成正常访问，也仍需结合业务规则识别。
按顺序部署，避免只改入口不护源站
- 确认流量去向。查看源站连接数、带宽、响应时间和错误日志，区分静态资源、动态接口与管理入口。记录正常时的请求量和常见路径，作为后续比较基线；不要仅凭总流量判断攻击类型。
- 接入边缘网络。在服务商控制台配置站点和回源地址，再按其说明切换流量入口。先用测试域名或低风险路径核对页面、登录和接口是否正常，重点检查回源协议、主机名及证书配置。
- 设置缓存与转发规则。为不含用户隐私、内容变化较少的静态文件启用缓存；购物车、账户资料等个性化页面通常不应照搬静态缓存规则。动态请求保留回源，但可按路径、请求方法和访问特征设置校验与限速。
- 限制源站直连。在源站防火墙或访问控制层，只允许边缘服务所需的回源流量，并保留必要的运维入口。规则变更前确认有可靠的管理通道，避免误封导致无法维护。
- 监控并逐步收紧。对照边缘请求量、拦截原因、源站负载和真实用户反馈调整规则。先对异常明显的路径启用较严格限制，再逐步扩大范围；攻击减弱后，复查误拦截并恢复临时策略。
策略选择要看请求类型
缓存分流：适合重复访问多的内容
缓存能直接减少回源请求，适用于版本化图片、脚本和公开下载文件。内容更新频繁或因用户而异的页面，需要谨慎设置缓存条件；否则可能向用户展示过期内容，甚至暴露不该共享的数据。可先从静态目录开始，确认更新机制后再扩大范围。
规则分流：适合保护动态接口
WAF 和速率限制可以针对异常路径、请求频率或明显不合规的请求采取拦截、挑战或延迟处理。阈值应根据正常业务基线设置，而非套用统一数值：搜索、登录和提交接口的合理访问频率往往不同。阈值过低会误伤正常用户，过高则削弱防护效果。需要验证码或人工挑战时，也应评估其对无障碍访问和自动化客户端的影响。
排查时优先看这几项
- 源站仍然过载：检查是否存在绕过边缘的直连请求，以及缓存规则是否对静态资源生效。
- 用户频繁报错：查看拦截日志和具体路径，区分攻击流量与正常接口调用，避免全站一刀切。
- 边缘有流量但业务不可用：核对回源地址、应用连接容量和后端依赖。边缘分流只能分担入口压力，不能替代源站扩容或应用故障排查。
归根结底，网站遭受流量攻击时的边缘分流方案应同时覆盖入口调度、请求筛选和源站保护，并通过监控验证效果。先保护关键服务，再根据访问证据调整规则，比仓促封禁大量来源更稳妥。
常见问题
接入边缘节点后，源站会不会完全不受攻击？
不会。公开的源站入口若能被直接访问，可能被绕过；应用本身存在的资源消耗问题也仍需处理。应限制源站只接受获准的回源流量。
所有页面都应该开启缓存吗？
不应该。公开且变化少的静态文件通常适合缓存；账户、订单等个性化内容应按实际响应特征设置，不能与其他用户共享缓存副本。
分流规则应当一次性设得很严格吗？
不建议。先观察正常流量并从高风险路径开始调整，结合误拦截反馈逐步收紧，通常更容易兼顾防护与可用性。
边缘分流能代替应用层优化吗？
不能。它主要缓解入口流量和部分异常请求，数据库查询、接口逻辑或后端依赖造成的瓶颈仍需单独排查。
