爬虫为什么突然开始被封了
跑了三周好好的，现在全是 403。多数时候问题不在代理。这里是五个原因，按值得排查的顺序排列。
你这边什么都没改，现在每条请求都返回 403。第一反应是怪代理，然后去买更好的。在花钱之前，先把这份清单过一遍。它大致是按「最后查出来是谁的锅」的频率排序的。
1. 你的请求频率悄悄上去了
这是最常见的原因，而且遥遥领先。可能是你加了并发，可能是目标站的页面变慢了导致你的工作池开始重叠，也可能是某个重试逻辑在悄悄地对每个 URL 发三次。
去实测一下你对目标站的每分钟请求数，别信你设定的那个值。如果它爬上去了，就降下来，看看封锁是不是停了。
2. 你的指纹把你暴露了
如果从住宅 IP 发出去的请求一看就是自动化的，那这个住宅 IP 也救不了你。网站越来越多地会检查：
- TLS 指纹（JA3/JA4）。 Python 的
requests有一套很有辨识度的 TLS 握手。真实的 Chrome 不长那样。curl_cffi这类库存在的意义就是解决这件事。 - 请求头的顺序和大小写。 真实浏览器会按特定顺序发送一组特定的头。多数 HTTP 库不会。
- 缺失的请求头。 没有
Accept-Language、没有Sec-Ch-Ua、点进来的页面却没有Referer。
如果问题出在指纹上，那么从数据中心升级到住宅帮不上忙。你只会为每一次被封付更多钱。
3. 网站那边上线了新东西
网站是会变的。新的 WAF、新的反爬服务商，或者在原有基础上收紧了规则。这种变化通常表现为一刀切式的断崖：周二还好好的，周三全是 403，中间没有过渡。
用真实浏览器、从一个住宅 IP 手动测一次。如果正常浏览器也被拦，那就是他们的问题，不是你的。
4. 粘性会话保持得太久
如果你把一个 IP 长时间攥在手里，往里灌一千条请求，那这个 IP 现在看起来就跟机房 IP 没两样，不管它实际在哪。粘性会话是用来维持登录状态的，不是用来跑量的。
把会话时间缩短，或者对那些不需要连续性的部分改成逐条请求轮换。
5. IP 被烧了
这种情况是有的，值得认真确认一下，别想当然。先确认这个 IP 是不是你付钱买的那种类型，自己查 IP 类型那篇讲了怎么查。然后做一个快速测试：把同一条请求换一个服务商的新 IP 跑一遍，或者干脆走你自己家的宽带。如果你自己的连接畅通无阻而代理不行，那这个池子在这个目标站上有问题。
告诉你的服务商。一家像样的服务商是想知道的，因为被烧掉的 IP 对他们的损失比对你更大。
花钱的顺序
- 降速。免费。
- 修指纹。免费，几个小时的活。
- 缩短粘性会话。免费。
- 从数据中心换到住宅。每个活儿花得更多，因为住宅按 GB 计费。
多数人直接跳到第四步，而其中相当一部分人从头到尾问题都在第一步。
测试期间
在我们按 GB 计量的表上，没从网站拿回任何东西的请求（超时、连接重置、我们自己网关的错误）计零，并且照样在日志里标为免费。网站发回来的东西就不一样了：429、5xx、403 或验证码页都带着正文回来，这些字节和任何响应一样都是流量。所以撞墙的诊断跑很便宜，但不是免费的，最省钱的诊断是规模小的诊断。怎么及早收手，见重试不烧流量。
计量规则的原文在实话实说页。
五条都试过还是卡住？带上状态码和一份响应样本来 Discord。通常都有人撞过同一堵墙。