access.log 里 UA 出现 Baiduspider-render/2.0，一天请求数是普通 Baiduspider 的三成，这些请求都带着 Chrome 内核标识，服务端按老规则把它当成普通蜘蛛限制了并发。
一开始怀疑是「页面首屏依赖接口，接口对渲染 UA 返回了 401」，查了一圈，方向不对。
原因不止一个，得分开看。渲染型抓取需要执行 JS，服务器返回的骨架页让它拿不到正文。少数情况下是Nginx 里按 UA 精确匹配 Baiduspider，新 UA 落进了限流默认组。
少数情况下是渲染抓取对超时更敏感，接口慢 3 秒就被放弃。
上来先按 UA 分桶统计两类蜘蛛的请求量
awk -F'"' '{print $6}' access.log | grep -i baiduspider | sort | uniq -c | sort -rn随后把渲染 UA 加进放行规则而不是限流组
map $http_user_agent $bot_limit { default 0; ~*Baiduspider-render 0; ~*Baiduspider 1; }接着用渲染 UA 手工请求一次看首屏
curl -A 'Mozilla/5.0 (compatible; Baiduspider-render/2.0)' -s https://www.example.com/post/1024 | wc -c末了确认接口对这条 UA 不再返回 401
curl -A 'Baiduspider-render/2.0' -sI https://www.example.com/api/post/1024恢复的判定其实很直接。渲染 UA 的请求全部返回 200 且正文长度接近浏览器抓到的值，日志里这条 UA 的 5xx 归零，抓取频次当天回升一档。
补一句。渲染抓取和普通抓取要分开看，混在一个桶里统计会把渲染超时误判成整站变慢。报错文案容易误导，真正的原因往往在相邻那一层的日志里。