亚马逊云成品号 AWS WAF 拦截正常业务请求？日志分析与规则误杀排查
亚马逊云成品号 AWS WAF 拦截正常业务请求时，最怕的不是规则多，而是不知道哪一条在误杀。先看日志，再看请求复现，最后再决定是改规则、加白名单，还是把某个业务路径单独拆出来。下面按排障顺序讲，尽量让你能直接照着做。
AWS WAF 拦截正常业务请求？先从日志里找证据
亚马逊云成品号 很多人一看到业务报错，就想先把整条规则关掉。实际处理里，这通常是最容易把问题扩大的一步。正确做法是先确认拦截发生在什么位置、哪条规则命中、命中的是哪类字段，再决定要不要放行。
先看这几个字段，别只看拦截结果
- terminatingRuleId：最后真正拦住请求的规则，通常是定位入口。
- action：是 Block、Count 还是 Allow，先确认是不是被终止执行。
- ruleGroupList：如果命中的是托管规则组，要继续往下看具体子规则。
- matchedData：常见于 SQL 注入、XSS、大小限制等误杀排查。
- httpRequest.path、method、headers、queryString、body：看请求到底在哪个位置触发了规则。
- labels：有些规则不是直接拦截，而是先打标签，再由后续规则处理。
如果你能把一次被拦请求完整复现出来，排查速度会快很多。最有用的做法是保留浏览器请求、curl 请求和 WAF 日志三份材料，三者对得上，问题通常就能缩小到某个字段或某条规则。
日志里常见的三种结果
| 日志表现 | 常见原因 | 建议动作 |
|---|---|---|
| 命中托管规则组后直接 Block | 正文、参数名、Header 触发了误判 | 先改成 Count，确认是哪条子规则误伤 |
| Rate-based 触发 | 登录、搜索、抢购、接口重试过于集中 | 按路径、方法、IP 段缩小范围，再调阈值 |
| Geo 或 IP reputation 命中 | 海外用户、代理出口、云厂商出口 IP 被误判 | 不要全局放开，优先对白名单路径单独处理 |
最容易误杀的规则，不是你以为的那一条
实际排查里，误杀经常不是发生在最显眼的规则上，而是某个看起来正常的托管规则、速率规则，或者你们自己写的正则表达式。
常见误杀来源
- 托管规则组：对参数名、参数值、编码方式更敏感，尤其是后台系统、营销活动页、富文本提交场景。
- SQLi 和 XSS 相关规则：用户搜索词、商品标题、备注字段里带特殊符号时，很容易被误判。
- Size constraint：移动端提交、文件上传、长文本评论、表单附件，超出预期长度就会被截断或拦截。
- Regex 规则：自定义正则写得过宽，常把合法参数值一起匹配进去。
- Rate-based 规则：促销、登录重试、接口轮询、支付回调重试，都会让真实流量看起来像异常流量。
- Bot 或匿名代理相关规则：海外出口、企业代理、移动网络切换时，正常用户也可能像机器流量。
按业务场景排查，更容易找到误杀点
登录和注册：最常见的问题是用户名、密码、验证码、设备指纹、登录重试次数一起触发。尤其是移动端和第三方登录回调，Header 变化大，容易被认为是不一致请求。
支付回调：回调接口通常需要固定路径、固定方法、固定来源。很多误杀来自 IP 白名单没同步、签名参数被改写、回调重试被 Rate-based 拦住。
文件上传和富文本：上传图片、PDF、合同、HTML 片段时，正文内容、文件名、编码方式都可能碰到规则。这个场景最适合先在测试环境做样本回放。
海外用户访问：跨境业务经常遇到代理出口、动态 IP、时区和地区不稳定的问题。不要只看国家维度，最好结合 ASN、路径、方法和来源网段一起判断。
API 和移动端：很多 API 请求头比较少，甚至会被网关统一改写。如果你们依赖自定义 Header 做鉴权，先确认这些 Header 是否在经过 CDN、ALB、API Gateway 后还保留。
怎么改规则，才能既放行又不失控
排查误杀时，最稳的思路不是直接放行，而是先把规则从拦截改成观察，再逐步收窄范围。这样既能恢复业务，也能保留后续回溯能力。
- 先用 Count 模式观察几次真实请求，确认是不是同一类请求反复触发。
- 如果只是一条业务路径有问题，优先用 scope-down 只缩小到该路径、方法或 Host。
- 如果是某个参数或 Header 触发误判，优先做字段级排除，而不是关闭整组规则。
- 对支付回调、登录回调、Webhook 这类接口，尽量做单独规则或单独 Web ACL，不要和普通页面混在一起。
- 如果业务有明确来源 IP，白名单只放到最必要的接口，不要整站放开。
- 改完规则后，一定要用真实业务样本回放，而不是只看控制台里的测试请求。
不要一上来就把整组规则关闭。先缩小范围，再改判定条件，最后才考虑全局放行。
如果你还在处理账号、支付和风控，先把前置条件理顺
亚马逊云成品号 很多团队是在 AWS 账号刚开通、企业资料刚补齐、支付方式刚绑好之后，才开始正式上 WAF。这个阶段最容易忽略的，不是规则本身，而是账号权限、账单校验、风控审核和资源限制。
- 账号开通和实名认证：如果是公司主体开通，建议把主体信息、账单联系人、税务资料和实际业务主体保持一致。信息不一致时，后面改支付方式或补充材料会更费时间。
- 企业认证：团队常见的问题不是“能不能开”，而是“谁有权限改 WAF、看日志、改账单”。建议一开始就把 IAM 权限和账单权限分开设计。
- 支付方式：国际云账号通常依赖信用卡或企业账单方式。若卡片额度紧、账单地址不一致、银行风控拦截，后续开日志、加规则、扩资源都可能卡住。
- 风控审核：新账号、异地登录、频繁切换 IP、短时间内大批量创建资源，都可能触发额外审核。排障期间最好避免一边改账单一边大规模改规则。
- 资源限制：Web ACL、规则组、日志存储、受保护资源数量都有配额。多环境、多站点、多个国家站并行时，先确认限额，别等业务恢复时才发现规则建不进去。
- 成本控制：WAF 本身、日志采集、日志存储、后续查询都会产生费用。排障期如果把所有请求都开高粒度日志，短时间内可能把成本抬高。建议先对问题路径开日志，确认后再扩大范围。
如果你们是跨境业务，建议在正式上线前就把账号开通、支付、权限、日志和预算一起梳理，而不是等线上被拦后再补。这样排查时不会出现“规则能改，但日志看不到”“想放行，但权限不够”“要开新规则，但配额满了”这种连锁问题。
常见错误：很多误杀排查都是这样被拖慢的
- 只看前端报错，不看 WAF 日志和原始请求。
- 一上来就关掉整条托管规则组，结果把真正的异常流量也放进来了。
- 只做 IP 白名单，却忽略路径、方法、Header 的差异。
- 没有先做 Count 和样本回放，直接在生产环境改成 Allow。
- 忽略 CDN、负载均衡、网关层的改写，导致 WAF 看到的请求和应用看到的请求不是同一份。
- 排查时没留变更记录，过几天又不知道是哪次调整让业务恢复的。
亚马逊云成品号 FAQ
为什么我已经加了白名单，还是被 AWS WAF 拦截？
常见原因是白名单只放到了某一层，或者放行条件太宽，结果被后面的规则再次拦住。先确认请求是否经过了多个规则组，再看白名单是否只作用于指定路径、方法和来源。
日志里看不到具体命中规则，怎么排？
先确认相关日志是否真的开启，样本请求是否被完整记录。很多时候不是没有命中，而是日志粒度不够。可以先对问题路径临时提高日志覆盖范围，再回放一次真实请求。
登录、支付、回调这类接口，应该优先怎么处理？
优先分路径处理，不要和普通页面共用一套宽泛规则。登录看重频率和设备变化，支付回调看重来源和签名，Webhook 看重固定来源和方法。三类接口的放行逻辑通常不能混用。
如何控制排查期间的成本？
只对问题路径开日志，先用 Count 观察，再扩展到整站。日志保留时间别一开始就拉太长，确认问题后再决定是否长期保留。对多环境项目，测试环境先验证规则，再同步到生产。
最后怎么决策：该改规则，还是该改业务流程
如果误杀只发生在少数路径，优先改规则；如果某类请求本身就变化很大，比如富文本、文件上传、海外移动端访问，建议把这类接口单独拆出来；如果是支付回调、登录回调、Webhook，最好从业务流程上固定请求格式、来源和签名方式，再配合 WAF 做收口。
简单说，真正稳妥的做法不是追求“全部放行”，而是让 WAF 只拦该拦的请求，把正常业务留在可控范围内。这样后面不管是扩账号、加支付方式、做企业认证，还是控制预算和资源限制，运维压力都会小很多。
