curl -A 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0.0.0' -I https://example.com/item/1 curl -s https://example.com/item/1 | grep -i 'x-cache'
同一个 UA 字符串连续用了 8 小时，第 9 小时所有请求返回 403，响应头多了 x-cache: BLOCKED，换一个 UA 立刻恢复 200。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，站点把 UA 和访问特征放在一起做指纹，同一个 UA 在几小时内打开几千个详情页，与真实浏览器的行为分布差太远。只看 UA 字符串替换没有用，服务端还会比对 UA 与 TLS 指纹、Accept 头是否自洽。
这次卡住的地方就在「爬虫 UA 识别」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。动手前把原文件复制一份带时间戳，出问题立刻换回去，比现场分析快得多。
一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。
处理上按这个顺序：准备一批真实浏览器 UA 按请求轮换；每个 UA 绑定固定的 Accept 和 Accept-Language；单 UA 每小时请求数控制在 200 以内；命中 403 时先换整组指纹而不是只换 UA。
改完只确认一件事：轮换后连续抓 6 小时没有出现 403，日志里 x-cache 只有 HIT 和 MISS，BLOCKED 一次没出现。