边缘层和应用层都能拦截请求，但如果各自维护一套相似条件，正常访问可能被连续拒绝，排查时也难以判断是哪条规则生效。做好Web应用防火墙与边缘防护的规则协作，重点不是把规则合并，而是明确每一层负责什么、怎样交接，以及如何验证改动。
先划分职责，再讨论规则顺序
边缘规则通常适合处理请求抵达应用前即可判断的条件，例如已知的恶意来源特征、明显异常的请求频率，或不对外开放的路径。Web应用防火墙则更适合检查请求内容、应用协议特征及常见攻击模式。具体能力取决于服务商产品和配置，不能假设不同平台有相同的执行顺序。
以登录页面为例：边缘层可以对短时间内反复提交的请求采取限速或验证措施；应用层继续检查提交内容，并保留针对注入、脚本等风险的检测。不要在两层都对同一类正常登录行为设置过于严格的计数门槛，否则共享网络、自动化客户端或重试请求都可能被重复拦截。
用规则清单消除重叠
把现有策略整理成一张清单，至少记录匹配条件、动作、优先级、例外范围、所属层、规则负责人和日志标识。发现两条规则都命中同一路径或同类请求时，先确认它们是否真的承担不同任务，再决定保留哪条作为主要拦截点。
| 场景 | 建议分工 | 需要核对 |
|---|---|---|
| 登录请求频率过高 | 边缘层限速，应用层保留内容检测 | 计数范围、重试行为、验证动作是否叠加 |
| 上传内容可疑 | 应用层检查内容与业务约束 | 边缘层是否误按文件类型或路径直接拒绝 |
| 已知无效路径被反复访问 | 边缘层提前拒绝 | 应用层是否还有重复规则及独立告警需求 |
表中的分工是通用思路，不代表所有产品都支持相同的匹配字段或处理动作。规则优先级、终止条件和覆盖关系，应以实际控制台说明及测试结果为准。
按可验证的步骤调整
- 盘点现行策略。导出或记录两层的启用规则，筛出条件相似、动作相同，或都指向同一业务路径的条目。
- 查看日志归因。在能看到规则名称、动作和请求标识的日志中，对照同一请求的处理记录。若日志无法关联请求，可先补齐追踪字段或记录各层的规则编号。
- 建立单一主拦截点。为每类风险指定主要执行层；另一层仅保留必要的补充检查、告警或明确例外，避免条件和动作机械复制。
- 先观察，再小范围启用。可先用记录或告警模式观察一段覆盖常见业务周期的时间；流量有明显周内差异时，观察周期可延长到一至两周。之后选择低风险范围逐步启用，并检查误拦截与漏检迹象。
- 准备回滚。记录改动前后的规则版本、启用时间和预期效果。若业务请求异常增加，先回退最近变更，再依据日志定位具体规则，不要同时修改多条策略。
避免例外规则变成长期漏洞
发生误拦截时，优先缩小规则范围：检查是否能限定到具体路径、请求方法或必要的业务条件，而不是直接关闭整组防护。例外应写明原因、负责人和复查时间；如果只是为了让某个测试请求通过，也要在测试结束后撤销。对于托管规则的单项调整，应核实是排除特定检测项，还是绕过整个规则组，两者影响范围可能不同。
这套Web应用防火墙与边缘防护的规则协作方法，核心是职责清晰、日志可追溯、变更可回退。规则调整后还要复测正常登录、失败登录和其他关键业务请求，并确认告警来源能区分边缘层与应用层，避免把一次拦截误认为两次独立攻击。
常见问题
两层检测到同一风险，一定要删掉一条吗？
不一定。可保留不同层的纵深检查，但应明确谁负责拦截、谁负责告警或补充检测，并验证动作不会重复影响用户。
日志显示拦截，却找不到是哪层处理的，怎么办？
分别检查两层的规则名称、动作和请求关联信息；缺少关联字段时，先完善日志记录，再调整策略，避免凭猜测关闭规则。
规则调整后多久复查？
应在变更后及时检查日志与业务请求，并覆盖常见流量周期。流量波动大时延长观察时间；发现异常则优先回滚，再逐项定位。
