Scrapy工程师的1个反直觉发现：200状态码比403更危险

去年某电商数据团队有个诡异记录：爬虫成功率从92%断崖跌到17%，日志里却全是200 OK。他们花了3天才定位问题——目标网站根本没封IP，只是悄悄把商品页换成了验证码页。这种"影子封禁"比403更致命，因为Scrapy的默认重试逻辑完全不会触发。

这不是个例。在高并发采集场景里，IP被封只是基础课，真正的考题是：怎么让代理池学会"自我疗伤"。

大多数工程师的起点都一样：在Request的meta里硬塞代理地址。写几个蜘蛛还行，规模上来后，代码里到处都是代理切换的碎片逻辑——像极了早期把SQL语句直接写在PHP页面里的年代。技术债堆到某个临界点，维护成本会吃掉所有采集收益。

Scrapy的下载器中间件（Downloader Middleware）设计了一套钩子机制，但很多人只用到皮毛。process_request负责出征，process_exception处理明面上的失败，而process_response才是对付影子封禁的暗器。三者闭环，才能搭出一个有反馈能力的代理引擎。

代理池的"体检系统"长什么样

健康的代理池不能只进不出。我们需要给每个IP建立档案：最近10次请求的成功率、平均响应时间、触发验证码的次数。这些指标决定了下次选它出征的概率——有点像NBA教练根据球员状态调整首发名单。

代码层面，__init__里初始化一个stats字典，key是代理地址，value是一个轻量对象。每次process_response拦截到响应，更新对应代理的健康分。分数跌破阈值，直接送进"冷宫"冷却，而不是永久删除——毕竟IP资源也是花钱买的，彻底报废太奢侈。

加权选择算法比random.choice复杂一点，但回报显著。假设你有100个代理，其中30个刚被验证码击中，简单随机有30%概率踩雷。而按健康分加权，可以把踩雷概率压到5%以下。这个优化在百万级请求规模下，省下的重试时间就是真金白银。

200 OK里的陷阱：怎么识别影子封禁

目标网站的反爬工程师也不傻。他们知道Scrapy默认只重试非2xx状态码，所以故意返回200，把验证码塞进响应体。你的蜘蛛开开心心地把这个"成功响应"存进数据库，下游业务拿到一堆HTML结构的验证码截图，整个pipeline直接报废。

破解方法是在process_response里加一层"内容体检"。XPath定位关键词比如"CAPTCHA"、"验证"、"security check"，或者更隐蔽的——检测响应体长度是否异常偏离基准值。正常商品页80KB，突然变成3KB的精简HTML？大概率被套路了。

一旦识别出影子封禁，要做三件事：标记当前代理健康分暴跌、把请求塞回重试队列、换代理重新发起。这里有个细节：重试次数必须全局计数，而不是每个代理独立计数。否则坏代理轮流上，同一个请求被不同代理各试一次，很快就触达Scrapy的RETRY_TIMES上限，任务直接丢弃。

TLS指纹和请求头：代理的"身份证"不能穿帮

现代反爬系统已经不看IP了，它们看"人"。同一个IP，上午用Chrome 120的TLS指纹，下午变成curl的OpenSSL指纹，晚上又是Python requests的——这不像真人，像精神分裂。

代理中间件需要保证请求头和TLS上下文的一致性。如果你用HTTP代理，确保User-Agent、Accept-Language、甚至DNT（Do Not Track）标志都和该代理的历史行为匹配。更高级的做法是给代理分组，每组绑定固定的浏览器指纹配置，轮换时整组切换，而不是东拼西凑。

X-Proxy-ID这类自定义头在内部追踪很有用，但千万别发到目标服务器。process_request里设置完，记得在请求发出前清理掉。曾经有个团队因为这个细节暴露了自己的代理池规模——对方看到Proxy-ID从001递增到847，直接批量封禁了整个C段。

resilient系统的终极形态，是让失败成为输入而不是终点。

代理挂了？记录原因，更新权重，冷却处理。验证码出现了？解析类型，反馈给上游供应商，甚至自动触发打码平台API。每一次异常都应该让系统更聪明一点，而不是原地打转。

有个量化指标可以参考：代理池的"自愈周期"。从某个IP被标记为不可用，到重新进入候选队列，理想情况下应该控制在5-15分钟。太短了没冷却效果，太长了资源闲置。这个参数需要根据目标网站的封禁策略动态调整——对抗性博弈没有银弹。

回到开头那个电商团队。他们最终的解法是给process_response加了双层校验：状态码+内容指纹+响应时长三联检。影子封禁的识别率从0提升到94%，代理池的日均消耗量反而下降了60%——因为不再盲目烧毁IP去撞验证码墙。