报错是这么冒出来的。上了云 WAF 之后 GSC 报 sitemap 无法读取，源站日志里对应请求是 403，WAF 事件显示命中目录遍历扫描规则，请求路径是 /sitemap_index.xml。
中间走过弯路，把「蜘蛛请求不带 Cookie，被判成无状态客户端」当成主因，改完现象没变。
原因不止一个，得分开看。规则按路径关键字匹配，sitemap_index 被当成扫描特征。还有一种是同一 IP 短时间多次请求 xml，触发频率阈值。
不容易想到的是，放行规则排在拦截规则之后，顺序上不生效。
第一件事是确认 403 来自哪一层
curl -sI https://www.example.com/sitemap_index.xml | grep -Ei 'HTTP/|server'然后在 WAF 日志里定位命中的规则
curl -s -H 'Authorization: Bearer $TOKEN' 'https://api.waf.example.com/logs?q=sitemap'为 sitemap 路径加放行并置于最前
curl -X POST https://api.waf.example.com/rules -d '{"path":"/sitemap*","action":"allow","priority":1}'末了用蜘蛛 UA 复测
curl -sI -A 'Googlebot' https://www.example.com/sitemap_index.xml别只看报错消失，验证要多做一步。sitemap 请求返回 200，GSC 重新提交后读取成功，WAF 事件里该规则不再命中 sitemap 路径。
提醒一点。放行规则的优先级比动作更重要，写在拦截之后等于没写，多数 WAF 都要看这一层顺序。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。