报错是这么冒出来的。新上的 CC 防护按单 IP 每分钟 60 次请求拦截，上线第二天抓取量掉了七成，日志里同一个 IP 在第 61 次请求开始全部 403，而那个段正是必应的抓取节点。
中间走过弯路，把「规则命中后封禁时长设成了 24 小时」当成主因，改完现象没变。
原因不止一个，得分开看。CC 规则按 IP 计数，没有区分已验证的蜘蛛。少数情况下是蜘蛛会集中抓取列表页，单 IP 短时间内请求密集。
另外，回源 IP 经过 NAT，多个蜘蛛共用同一个出口。
先统计被拦 IP 的请求频率和 UA
awk '{print $1, $12}' access.log | grep 403 | sort | uniq -c | sort -rn | head然后对验证过的蜘蛛 UA 跳过 CC 计数
SecRule REQUEST_HEADERS:User-Agent "@rx (Baiduspider|bingbot)" "id:1001,phase:1,pass,nolog,ctl:ruleRemoveById=9001"接着把封禁时长降到十分钟并加白名单
curl -s -X POST 'http://127.0.0.1:9000/api/cc/config' -d 'ban_time=600'剩下的就是观察恢复后的单 IP 请求曲线
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head别只看报错消失，验证要多做一步。蜘蛛 IP 不再进入封禁列表，单 IP 请求量回到每分钟百次以上且状态码为 200，抓取量当天回升。
这里还有个坑。反向验证 UA 只能挡低端伪造，真正的蜘蛛 IP 段要做反向解析，两条一起用才稳。这类问题最好一次改到位，反复小改反而容易把原因搅混。