防护规则越多，业务就一定越慢吗？不一定。关键在于把检查放在合适的位置，并让不同风险的请求经过不同流程。低延迟业务与攻击防护能力如何兼顾，首先要看清哪些请求值得在边缘直接处理，哪些必须交给源站完成。
先拆分请求，再安排防线
静态图片、样式文件等内容可以由内容分发网络（CDN）缓存，减少跨区域回源；登录、搜索和下单等动态操作通常仍需访问业务服务。若所有流量都经过同一套复杂检查，正常请求也可能增加等待时间。因此，应按内容类型、接口用途和风险等级分别设计规则。
常见攻击也要区别应对。大量连接或请求可能耗尽带宽、连接数或应用资源，适合由网络层清洗、CDN和边缘限流优先处理；针对特定接口的自动化请求，则更适合结合请求频率、会话状态及行为特征识别。WAF（Web 应用防火墙）能按规则检查 HTTP 请求，但规则配置并不等于能够阻断所有攻击。
把耗时控制在风险较高的请求上
优先做低成本拦截
在边缘节点拦截明显异常的请求，可以避免它们继续占用源站连接和计算资源。对公开读取的内容优先使用缓存；对短时间内重复访问同一接口的请求，可设置分用户、分接口的速率限制。限制不宜只按 IP 判断，因为共享网络可能让许多正常用户共用一个出口地址。
验证措施分级启用
对低风险浏览保持直达，对登录失败次数异常、请求频率突增或行为可疑的会话，再要求额外验证，例如验证码或一次性验证。验证码能增加自动化操作成本，却也会打断真实用户流程；应避免把它放在每次访问的必经路径上。对支付、密码修改等敏感操作，可以采用更严格的身份校验和频率控制。
用实测找到延迟与防护的平衡点
低延迟业务与攻击防护能力如何兼顾，不能只看页面平均响应时间。平均值可能掩盖少数用户明显变慢的情况，建议同时观察中位数和第 95 百分位延迟，并按地区、接口和缓存命中状态拆分。对比启用规则前后的结果时，应尽量使用相近的请求路径和业务负载。
- 建立基线：记录关键接口在正常流量下的响应时间、错误率、源站连接数和缓存命中情况。
- 逐条上线规则：先以记录或告警模式运行，检查哪些正常请求会被命中，再逐步切换为拦截。
- 检查误拦截：观察被拦请求的接口、地区和客户端特征；确认误判后再收窄规则，而不是整体关闭防护。
- 模拟变化并回滚：在可控测试环境或低风险时段验证配置，记录回滚方法；攻击期间也要持续关注正常用户的成功率。
缓存并非越多越好。个性化内容、账户信息及依赖实时状态的结果通常不应被不加区分地共享缓存；缓存键、有效期和清除机制都需要与数据特性匹配。对于动态接口，可缓存可安全复用的公共数据，同时限制回源并发，降低突发流量对后端的冲击。
按业务目标做取舍
若主要压力来自静态内容访问，缓存和边缘分发往往比给每个请求增加复杂校验更直接；若风险集中在登录等少数接口，精细限流和分级验证更合适。若请求必须实时读取源站数据，就不能单靠缓存解决问题，还要为源站预留处理能力，并设置超时、队列或熔断，避免故障时请求堆积。
最终，低延迟业务与攻击防护能力如何兼顾，依靠的不是单一产品，而是“边缘先筛、风险分级、关键路径少做额外工作、持续测量并及时修正规则”。把延迟预算和可接受误拦截范围明确下来，才能在防护强度与用户体验之间作出可验证的选择。
常见问题
开启 WAF 后一定会增加延迟吗？
不一定。影响取决于规则复杂度、部署位置和请求路径；应通过关键接口的前后对比确认实际变化。
限流只按 IP 设置可以吗？
通常不够。可结合账户、会话或接口设置限制，避免共享出口用户被一并限速，也减少攻击者更换地址后的绕过空间。
缓存能抵御所有流量攻击吗？
不能。缓存有助于减少可缓存内容的源站请求，但动态请求、带宽耗尽等情况仍需相应的网络防护和资源保护措施。