抓取脚本每 200 个请求里有 137 个返回 302，Location 指向 /login?redirect=，页面标题是「请登录」，池里 40 个账号只剩 3 个有效。乍看像缓存或者权限的锅，追下去往往不是。
r = s.get(url, allow_redirects=False, timeout=8)
print(r.status_code, r.headers.get('Location'))
追下去是这么回事：Cookie 池只按过期时间淘汰，服务端实际按最后活跃时间滑动续期，长时间没被取用的账号先失效。302 被 requests 自动跟随，最终拿到的登录页状态码还是 200，脚本以为采集成功。
「Cookie 池失效」相关的日志我一般连着看前后五分钟，单看一条报错经常判断不出是哪一步失败。测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。
线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。
具体做法是，请求时关闭自动重定向 allow_redirects=False；命中 302 就判定该账号掉线并剔除；每 10 分钟对池里账号做一次探活；探活通过的才允许参与轮换。
验收就看一点，302 比例从 68% 降到 0，池里可用账号稳定在 35 个以上，掉线账号在看到 302 的当次就被移出。