记录一下那天晚上的排查过程。Bing 收录一周内从 1.2 万掉到 3000，源站日志里 bingbot 的请求只剩个位数，Cloudflare 防火墙事件里能看到大量 Browser Integrity Check 拦截，UA 正是 bingbot/2.0。
刚开始盯着「规则作用域写成全站，includes 里把根路径也包了进去」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。浏览器校验对不携带完整浏览器头的 UA 直接发挑战。少数情况下是Bingbot 不执行 JS 挑战页，拿到 403 后按退避策略降低抓取。
另外，自定义 WAF 按 UA 关键字匹配，误伤了官方爬虫。
先在防火墙事件里按 UA 过滤确认命中规则
curl -s -H 'Authorization: Bearer $CF_TOKEN' 'https://api.cloudflare.com/client/v4/zones/$ZONE/firewall/events?per_page=20'随后用官方 UA 直接打源站做对照
curl -sI -A 'Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)' https://www.example.com/为已验证爬虫建跳过规则
curl -X POST 'https://api.cloudflare.com/client/v4/zones/$ZONE/rulesets' -H 'Content-Type: application/json' -d '{"rules":[]}'等前面都确认过，再观察一周的抓取量变化
grep -c 'bingbot' /var/log/nginx/access.log改完先别撤，确认这几项。防火墙事件里 bingbot 的拦截归零，源站日志日请求量回到两千以上，Bing 收录两周后开始回升。
容易忽略的是，放行别只匹配 UA，配合 verified bot 标记和 rDNS 才可靠，UA 谁都能伪造。报错文案容易误导，真正的原因往往在相邻那一层的日志里。