监控脚本按正则 Baiduspider 统计抓取，十月起日志里出现 bdspider/2.0 (compatible; Baiduspider/2.0) 这样的串，正则区分大小写，百度流量在日报里直接归零，WAF 那边同期多出一批 403。
一开始怀疑是「WAF 放行名单同样按旧写法配置，新 UA 被抓取防护挡在门外」，查了一圈，方向不对。
排查方向其实有限，先把可能性排一排。UA 前缀换成小写 bdspider，区分大小写的正则整条不命中。少数情况下是脚本里的匹配锚点写成 ^Baiduspider，前缀一变从头就失配。
还有一种情况，采集端把 UA 截断到 80 字符，关键字刚好落在截断之后。
动手时先看日志里真实的 UA 串
grep -io 'bdspider[^\"]*' access.log | sort | uniq -c | sort -rn | head再往下把匹配改成大小写不敏感
grep -ic 'baiduspider\|bdspider' access.log同步更新 WAF 放行规则
SecRule REQUEST_HEADERS:User-Agent "@rx (?i)(baiduspider|bdspider)" "id:1001,phase:1,pass,nolog"末了用抓取诊断复验一次
curl -sI -A 'bdspider/2.0' https://www.example.com/robots.txt恢复的判定其实很直接。改完后百度侧请求重新出现在日报里，抓取量和站长平台的频次曲线恢复同步，WAF 日志里不再出现针对该 UA 的 403。
提醒一点。UA 是对方随时能改的字符串，监控规则要写成宽松匹配，别把厂商名当成固定常量。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。