waf必须依托负载均衡器（lb）协同部署，lb作为流量入口承担ssl卸载与转发，waf基于域名匹配执行应用层检测；新建waf需先创建lb并开启waf开关，绑定全局配置组，且lb规格须支持≥20000最大连接数以保障性能。
负载均衡器与 WAF 是协同工作的安全组合，不是独立部署的两个模块。WAF 本身不直接对外提供服务，必须依托负载均衡器作为流量入口和代理枢纽，才能实现对 HTTP/HTTPS 请求的深度解析与策略执行。构建高可用的 WAF 流量过滤策略，关键在于把负载均衡的分发能力、WAF 的应用层检测能力、以及策略的分级响应机制三者有机融合。
负载均衡是 WAF 的前置承载底座
新建 WAF 必须先创建负载均衡器，并在创建时开启 WAF 开关——这一步决定了整个防护链路的起点。系统会要求绑定一个全局配置组，且明确提示：开启 WAF 需额外计算资源，最大连接数建议不低于 20000。这意味着不能用小规格 LB 应付高并发业务，否则 WAF 规则加载、协议解析、日志写入等操作会成为瓶颈，反而拖慢整体响应。
- 负载均衡器承担 SSL 卸载、请求转发、健康检查等基础功能，为 WAF 腾出资源专注做应用层分析
- WAF 不处理原始 TCP 连接，而是接收 LB 解密并标准化后的 HTTP/HTTPS 报文，确保字段完整（如 Host、Referer、Cookie、X-Forwarded-For）
- 所有监听器（HTTP/HTTPS）必须建在该 LB 上，WAF 才能对其流量生效；不同协议、端口、域名的策略需通过监听器+域名防护策略联动控制
以域名为粒度的防护策略是核心控制单元
WAF 的策略生效逻辑基于域名匹配：收到请求后，先查 Host 头是否落在已配置的“域名防护策略组”中，命中才触发后续规则引擎。因此，域名配置必须与后端真实服务一致，例如后端服务响应 Host 为 api.example.com，WAF 策略中就不能只填 example.com 或漏掉子域名。
- 支持通配符匹配，如 *.example.com 可覆盖所有二级域名，但不匹配三级域名（如 a.b.example.com）
- 行为设置决定处置方式：默认“执行规则内容”即按规则定义动作阻断；选“仅报告”则是旁路观察模式，只记录日志不干预流量，适合上线初期灰度验证
- 策略组内自动加载平台维护的默认规则库（OWASP Top 10 类型），无需手动导入，但可叠加自定义规则增强针对性
精准规则配置要兼顾语法识别与业务语义
默认规则靠特征签名（如匹配 <script></script>、union select）起效，但面对混淆编码、慢速 CC、伪造 UA 的攻击容易失效。真正提升拦截精度的方式，是结合业务接口特点配置自定义规则，并分阶段启用。
- 新增规则初始必须设为“观察模式”，持续采集 3–7 天日志，确认无误报后再切为“阻断模式”
- 一条规则最多检查 5 个协议变量（如 URI、GET 参数、POST body、User-Agent、Referer），避免过度宽松或过严
- 对登录、支付等高敏接口，可启用基于语法的 SQL/XSS 防护，并先设为“仅记录”，观察合法提交是否被误判
- 针对 CC 攻击，不能只依赖单 IP QPS 限流，应组合使用：路径特征（如高频访问 /login.php）、参数熵值、User-Agent 分布异常等多维条件
高可用不止靠集群，更靠配置同步与故障兜底
单台 WAF 实例存在单点风险，但高可用不只是堆机器——主从节点间配置不同步、规则版本不一致，会导致防护能力断层。雷池等主流 WAF 支持主从自动同步，涵盖网站配置、黑白名单、人机验证、引擎规则等全部项，同步延迟控制在 1–2 分钟内。
- 主节点负责策略编辑与下发，从节点只读同步，故障时自动接管流量，业务无感知
- 黑白名单需全局生效，若仅在某节点添加 IP 黑名单，其余节点仍放行，形同虚设
- 建议将 DNS 解析指向 LB 的 VIP（而非某台 WAF 实例 IP），由 LB 层做健康探测与流量分发，进一步解耦网络层与应用层故障
