1. 问题复盘Scrapy定时任务半夜崩了第二天才知道少了一半数据先说个真实场景。你写好的Scrapy爬虫跑得好好的每天凌晨定时抓取某平台的数据结果某天早上打开监控面板发现任务在凌晨2点开始大面积报错整整4个小时的数据全是空。下载器返回的要么是Timeout要么是403 Forbidden重试机制像死循环一样反复请求同一批URLBroker里的任务堆积成山。最后你手动一查发现是代理IP那批货全挂了而你的爬虫代码里压根没有处理“代理失效”的逻辑。这个场景我敢说做爬虫的十个人里八个遇到过。标题里说的“Timeout_403大面积报错”本质上是同一个根因的两种表现代理IP失效后请求要么发不出去一直等到超时要么被目标网站识别为异常流量直接拒绝。你以为是反爬升级了其实搞了半天是代理服务商的IP池出了岔子。这篇文章我就把这套问题彻底拆开从根因分析到方案落地再到实战代码和排查技巧一步步说清楚重点讲怎么用代理池中间件让Scrapy具备自愈能力不再因为代理IP失效丢数据。适合谁来参考已经能写出基本Scrapy爬虫、但一上线就跑不稳定的朋友以及对代理IP管理、下载器中间件、反爬策略这些话题有进阶需求的人。新手也不会看不懂关键概念我会用大白话讲明白。2. 为什么代理IP一失效Scrapy就大面积翻车2.1 Scrapy请求生命周期里代理IP挂在哪个环节先把Scrapy的请求链路理顺。一个Request从调度器出来之后会依次经过下载器中间件Downloader Middleware最终交给Downloader去执行HTTP请求。代理IP的设置点就在这个过程里最常见的是在中间件的process_request方法中给Request的meta加上proxy字段。这里有个关键特性Scrapy默认情况下一个Request的生命周期里代理IP是“一次绑定、全程使用”的。也就是说某个Request从入队到出队到下载用的是同一个代理。如果这个代理在下载那一刻已经失效那么等待你的就是两种结果——连接超时或者被目标站拒绝。而且Scrapy自带的RetryMiddleware会对Timeout和403等状态码触发重试重试时默认还是用同一个Request对象也就意味着还是用同一个失效代理重试多少次都没用。我见过不少朋友在这里踩坑。他们把重试次数调到了5次、10次结果只是把同一个坏代理反复用了好几遍白白增加了请求延迟和对方服务器的压力没有带来任何成功率提升。这就是“大面积报错”看起来特别夸张的原因之一一个代理失效可能导致成百上千个Request同时开始重试日志刷屏任务堆积爬虫整体吞吐量暴跌。2.2 为什么代理失效的表现形式既有Timeout又有403这两种报错放在一起容易让人摸不着头脑其实分清场景就行Timeout多数发生在代理服务商的入口节点出现问题或者代理出口网络拥塞、目标站积极响应极慢的时候。此时TCP连接建立不了或者响应迟迟不返回Scrapy侧的表现就是twisted.web._newclient.ResponseNeverReceived或者ConnectTimeout之类的异常。403 Forbidden则说明请求已经到了目标服务器但对方根据你的出口IP、请求头、行为特征判断“你不是真人”于是拒绝服务。这里的出口IP十有八九就是代理IP。换个角度理解Timeout是“路堵了到不了”403是“人到了但被拦在门外”。代理IP失效时可能两种情况都有。另外提醒一点有些代理IP本身是可用的但被目标网站加入了黑名单。这种情况下请求返回的也是403但你换一个干净的代理IP马上就能恢复正常。所以处理403时思路不是“调UA、调Cookie”而是优先“换IP”必要的时候再配合其他反爬绕过的策略。2.3 代理IP失效的核心原因IP池生命周期管理没跟上市面上主流的代理服务商提供的IP大多是短时有效的。有的代理30秒一变有的1分钟一变有的则是“按量计费、用完即止”。如果你在代码里把代理IP硬编码成一个固定值或者写死在配置文件里那它迟早会挂。我把常见的失效原因分成三类时效到期代理IP有明确的存活时间到期后立刻无法使用这时候请求必然失败。并发超卖代理服务商卖给太多客户的IP某个出口IP被大量请求集中轰炸导致表现异常。被目标站封禁某个出口IP被目标网站检测到是代理行为返回403。这种情况不一定是代理商的问题但对你来说结果一样——这个IP废了。明白了这些原因解决思路就清晰了不能把代理IP当作“永久资源”而要当作“短期租赁资源”用完就换坏了就换而且要有一个自动化的代理IP池来管理整个生命周期。2.4 “丢数据”的真正源头重试机制和失效代理的组合陷阱Scrapy默认的RetryMiddleware会在遇到异常或指定状态码时重试默认重试次数是2RETRY_TIMES2。表面上看这是个兜底机制但结合“失效代理”这个场景它反而变成了丢数据的帮凶。为什么因为默认情况下重试时Request没有变化。你想同一个代理IP第一次超时了第二次还是它第三次还是它。除非这个IP恰好在你重试的过程中恢复了概率极低否则重试只是浪费时间。最终这个Request会达到最大重试次数被抛到spider_error或者直接丢弃数据就丢了。我见过一个更隐蔽的情况日志显示某条数据抓取失败但spider里并没有做后续处理于是这条数据就彻底消失在系统里。对于商业项目来说静默丢数据比直接报错更可怕因为你根本不知道丢了什么。所以这套组合陷阱的关键点是——要让代理IP失效之后重试的Request不再是同一个代理而是一个新的、可能有效的代理。这样一来重试机制才能真正起到兜底效果。3. 解决方案的整体设计代理池中间件 自愈式重试3.1 大方向选择自建代理池还是直接用服务商SDK面对代理失效问题第一个要决策的问题就是代理IP从哪来怎么管理市面上的方案主要分两类一类是代理服务商提供的API接口你每次请求前临时去拉一个IP出来用另一类是自建代理池自己写脚本从多个数据源采集IP清洗、验证、存储然后通过一个本地接口供爬虫调用。我个人的建议是分阶段看如果你只是个人学习、短期项目、对稳定性要求不高直接用服务商的API就行哪怕手动写个函数每次请求去拉IP都比你硬编码强很多。如果你做的是长期的、数据量大的商业化爬虫那就非常推荐自建代理池。虽然前期工作量多一点但可控性、稳定性、成本都会好很多。顺带说一句别觉得“自建代理池”很高大上。核心就三件事采集IP、验证IP、暴露接口。有一套开源方案叫ProxyPool用Python写的支持多数据源采集、异步验证、Flask提供API很多生产项目都直接拿它改改就能用省去造轮子的时间。3.2 为什么选择“请求级动态代理”模式爬虫和代理的关系我总结下来有两种模式“会话级固定代理”和“请求级动态代理”。会话级固定代理的意思是同一个爬虫进程或者同一个Spider实例在整个运行期间只用同一个代理。这种模式代码最简单但代理失效后整个爬虫就瘫了。请求级动态代理则是每一次请求来临前都从代理池接口获取一个“当前可用”的IP。这样即使某个IP下一秒就挂掉影响到的也只是一个Request而不会是整批任务。而且配合失败重试机制一个Request第一次用坏IP失败后第二次可以拿一个新IP重新发起成功率大幅提升。在生产环境里我强烈建议用请求级动态代理。代价是每次请求多一次HTTP调用去拿代理但这几百毫秒的延迟相比数据稳定性来说完全可以接受。3.3 中间件架构不侵入业务代码只改一个类Scrapy提供给我们的中间件机制非常灵活我们可以在DOWNLOADER_MIDDLEWARES里注册一个自定义的ProxyMiddleware在process_request阶段动态给Request绑定一个代理IP在process_exception阶段判断异常类型并决定是否更换代理重试。这个设计的最大优点是业务层的Spider代码完全不用动。你不用在每个spider里去获取代理、传meta、写重试逻辑只要在配置里注册中间件所有爬虫自动获得“代理自愈”能力。我这里画个流程大家感受一下Request进来process_request从代理池接口拿一个可用IP绑定到request.meta[proxy]。Downloader去请求目标网站。如果失败process_exception捕获异常标记当前代理失效换一个新代理重新发起请求。如果返回403也可以在process_response里判断把response.status403当作异常处理换IP重试。这个模式下重试不再是无脑循环而是每次重试都带着新的代理成功率自然就上去了。3.4 动态UA和Cookie的配合不要把所有锅甩给代理IP代理IP能解决大部分由IP引起的封禁问题但有些网站的封禁策略是多维度的。比如你的请求头长期不变、Cookie异常、请求频率过高即使IP是干净的也会被识别。所以方案里不能只盯着代理池至少要配上动态User-Agent。简单点可以在中间件里写一个UA列表每次请求随机取一个进阶点可以用fake-useragent库。难度不大但效果显著。再提一点如果目标网站要求登录才能访问数据那Cookie的管理也要考虑。频繁更换代理IP之后同一个账号的登录状态可能会被顶掉这时候可能需要维护一个Cookie池。不过这个话题展开就长了这篇文章聚焦代理IPCookie方面先点到为止。4. 实操环节从零搭建一个带代理池的Scrapy下载中间件4.1 扫盲Scrapy下载器中间件的执行顺序和钩子方法在写代码之前简单回顾一下下载器中间件的基本知识。Scrapy中间件的核心方法有四个process_request(request, spider)Request经过这里时被调用返回None则继续处理返回Response则直接跳过Downloader返回Request则把当前请求替换掉。process_response(request, response, spider)Downloader拿到Response后调用返回Response则传给Spider返回Request则触发重试。process_exception(request, exception, spider)Downloader处理过程中抛异常时调用返回Request则重试返回Response则作为结果返回None则继续抛给上层。from_crawler(cls, crawler)类方法用于读取配置或初始化资源。我们的核心逻辑就分布在前三个方法里。需要特别注意优先级数字数字越小的中间件越靠近下载器数字越大的越靠近引擎。自定义中间件建议把优先级设在 300~600 这个区间太靠近下载器可能覆盖了默认的Retry逻辑太靠近引擎则拿不到请求细节。4.2 代理池接口设计给Scrapy提供“随取随用”的IP要实现请求级动态代理第一步是确保本地有一个稳定的代理获取接口。最简单的设计是一个HTTP APIGET http://localhost:5010/get返回一个JSON里面包含一个可用代理IP。如果用的是开源ProxyPool方案它可以做得更完善包括失败自动删除、定时清理、统计可用率等功能。如果临时不想搭服务也可以写一个单机版的代理管理器思路是启动时从服务商API拉取一批IP。放入一个队列标记每个IP的过期时间。提供get_proxy()方法优先返回未过期的IP如果队列为空则重新拉取。提供remove_proxy(ip)方法外部标记某个IP失效后从队列中剔除。这样即使不用复杂的代理池框架也能在中小型项目里用得很舒服。后续的代码演示我按本地代理池接口已经就绪来写。你只需要把PROXY_POOL_URL换成你自己的代理池地址。4.3 核心代码实现获取代理、绑定请求、失效剔除下面这段代码是中间件的核心我带着完整注释贴出来然后逐段解释。import json import random import requests from scrapy.downloadermiddlewares.retry import RetryMiddleware from scrapy.utils.response import response_status_message class ProxyMiddleware: def __init__(self, proxy_pool_url, max_retry_per_request5): self.proxy_pool_url proxy_pool_url self.max_retry_per_request max_retry_per_request classmethod def from_crawler(cls, crawler): return cls( proxy_pool_urlcrawler.settings.get(PROXY_POOL_URL, http://localhost:5010/get), max_retry_per_requestcrawler.settings.get(MAX_RETRY_PER_REQUEST, 5) ) def get_proxy(self): try: resp requests.get(self.proxy_pool_url, timeout3) if resp.status_code 200: data resp.json() return data.get(proxy) except Exception: return None return None def process_request(self, request, spider): # 如果请求已经带了proxy绑定且是我们在重试逻辑里主动设置的则不重复取代理 if request.meta.get(proxy): return None proxy self.get_proxy() if proxy: request.meta[proxy] proxy return None def process_exception(self, request, exception, spider): # 捕获网络层面的异常此时说明当前代理不可用 current_proxy request.meta.get(proxy) if current_proxy: # 通知代理池标记这个IP失效 self.remove_proxy(current_proxy) # 判断重试次数是否超过阈值 retry_times request.meta.get(proxy_retry_times, 0) if retry_times self.max_retry_per_request: return None new_proxy self.get_proxy() if not new_proxy: return None request.meta[proxy_retry_times] retry_times 1 request.meta[proxy] new_proxy return request def process_response(self, request, response, spider): # 403也算代理有问题换IP重试 if response.status in [403, 429]: current_proxy request.meta.get(proxy) if current_proxy: self.remove_proxy(current_proxy) retry_times request.meta.get(proxy_retry_times, 0) if retry_times self.max_retry_per_request: new_proxy self.get_proxy() if new_proxy: request.meta[proxy_retry_times] retry_times 1 request.meta[proxy] new_proxy return request return response def remove_proxy(self, proxy): # 标记代理失效不同代理池接口不一样这里只做日志记录和请求通知 try: requests.get( http://localhost:5010/delete?proxy{}.format(proxy), timeout2 ) except Exception: pass这段代码的几个关键点我展开说一下。第一process_exception和process_response里的重试是手动实现的目的是保证每次重试都使用新代理。如果你直接调RetryMiddleware._retry方法它也会创建新Request并拷贝原meta但默认情况下拷贝的还是同一个代理所以我们必须自己控制meta更新。第二用request.meta[proxy_retry_times]来记录重试次数的原因是Scrapy默认的retry_times字段也会被使用但如果我们既用默认重试又手动控制次数会乱掉容易超出预期。用一个独立的字段更稳妥。第三process_response中只处理403和429。并不是所有非200响应都要换代理。有些网站会返回302跳转、404页面、500错误这些不一定是代理问题可能要交给其他中间件逻辑处理。别一股脑全换IP否则代理池消耗速度会非常快。4.4 settings.py里的配置优先级、重试次数、并发调整中间件写完之后必须在settings.py里注册并且根据项目情况调整几个关键参数。DOWNLOADER_MIDDLEWARES { myproject.middlewares.ProxyMiddleware: 543, scrapy.downloadermiddlewares.retry.RetryMiddleware: 550, } # 禁用默认的RetryMiddleware避免和自研的代理重试逻辑冲突 RETRY_ENABLED False # 或者在不禁用默认的情况下把默认重试次数调得很低 # RETRY_TIMES 1 # 代理池接口 PROXY_POOL_URL http://localhost:5010/get MAX_RETRY_PER_REQUEST 5 # 下载并发和超时 CONCURRENT_REQUESTS 32 DOWNLOAD_TIMEOUT 15 # 下载延迟单位秒 DOWNLOAD_DELAY 0.5 # 启用Twisted的线程池避免代理池HTTP请求阻塞事件循环 DOWNLOADER_CLIENT_TLS_CIPHERS DEFAULT这里有几个细节要细说。关于RETRY_ENABLEDFalse我的建议是你的项目里如果完全用自研的代理重试逻辑就把Scrapy默认重试禁掉否则两套逻辑叠加一个Request可能被重试十几次代理池压力大目标站压力也大很容易被识别为恶意攻击。如果你不想禁用默认重试那就要把默认的RETRY_TIMES设得很低比如1同时保证你的中间件优先级在默认RetryMiddleware之前数字更小让代理中间件先处理异常。关于DOWNLOAD_TIMEOUT我建议设15秒左右。太短会导致弱网环境下误判代理失效频繁换IP太长则会让爬虫整体速度拖慢。15秒是一个相对平衡的值你可以根据自己的网络环境微调。关于CONCURRENT_REQUESTS用了代理池之后并发不是越高越好尤其代理服务商对IP的带宽和连接数都有限制。我经验上先从16或32起步观察代理池的IP存活率和目标站的响应再逐步调整。4.5 动态User-Agent和请求头伪装别让IP背所有锅为了不让代理IP因为请求特征太明显被封动态UA这套必须做。我通常放在一个独立的UserAgentMiddleware里或者直接在ProxyMiddleware的process_request里设置。简单版的伪代码如下import random USER_AGENTS [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36, Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ] def process_request(self, request, spider): if User-Agent not in request.headers: request.headers[User-Agent] random.choice(USER_AGENTS) ...这里有个重要细节request.headers是大小写不敏感的所以不管原先设置的是user-agent还是User-Agent赋值之后都会被正确覆盖。我遇到过有些朋友写代码时判断条件写if user-agent not in request.headers结果UA没生效报了各种反爬错误排查半天才发现是大小写问题。另外在配置里可以加一条DEFAULT_REQUEST_HEADERS作为兜底比如Accept、Accept-Language、Accept-Encoding、Connection这些基础字段。目标网站如果做了很严格的HTTP头校验少了这些标准头很容易被识别。4.6 超时重试的并发陷阱Twisted线程池与requests调用的注意事项中间件的方法虽然写起来像同步代码但Scrapy的Downloader实际上是基于Twisted异步框架的。你在process_request里直接调用requests.get(proxy_pool_url)这是一个同步阻塞操作会卡住Twisted的事件循环。我一开始也踩过这个坑并发一高代理池接口响应稍慢一点整个爬虫就被拖住了吞吐量瞬间掉到个位数。后来我查了Scrapy源码才知道中间件的同步代码默认会在Twisted的线程池里执行但线程池的大小是有限的如果你频繁做HTTP调用线程池被占满还是会影响并发。解决思路有两个一是用scrapy.core.downloader.handlers.http11.TunnelingAgent这类异步代理获取逻辑这个比较高级适合对性能要求很高的场景自己动手改起来要小心。二是接受线程池方案但把代理获取接口做得快一点本机接口一般几个毫秒就返回了并且加上连接池和缓存减少重复创建连接的开销。我个人建议多数项目用第二个方案就行。本机代理池接口如果用的是Flask启动参数里开多线程模式同时在爬虫端用requests.Session复用连接能省掉不少握手时间。5. 避坑指南代理池落地中最容易踩的9个坑5.1 代理过期时间的缓存问题代理池接口返回的IP通常带着过期时间字段但有些代理池框架默认不会在返回前检查有效期导致返回一个已经过期但又没被清理的IP。这个问题的修复要在代理池那一侧做每次get接口被调用时先检查IP是否在有效期内过期则清除并重新选取。5.2 验证代理是否真的可用代理可用性验证是个活。我见过有人用socket.connect去测代理端口是否通但这只能证明IP地址和端口可达不代表能正常走HTTP请求。更靠谱的方式是拿一个稳定的测试URL比如http://httpbin.org/get去实际请求一次同时校验返回内容里的origin字段确实是代理IP而不是本地IP。这个过程可以在代理池的验证线程里定期执行保证池子里的IP新鲜程度。5.3 代理池接口并发压力过大当爬虫并发调到64甚至更高时每次请求都来代理池拿IP代理池接口本身可能成为瓶颈。如果用的是开源ProxyPool建议把Flask跑在Gunicorn后面多个worker处理请求同时在爬虫端对get_proxy()做一点本地缓存比如每秒钟最多请求一次代理池批量拿5个IP放到本地队列里慢慢用。这样做虽然各爬虫进程拿到的IP不是完全实时但整体性能会好很多。5.4 403不一定全是代理问题这句要反复强调。403可能因为UA不对、Cookie过期、请求参数缺失、签名算法没实现、甚至目标网站针对某些地区的IP做了地域封锁。所以设计中间件时不能一刀切把所有403都当作代理失效。我自己的做法是在中间件里给每个请求打一个标记记录第一次403时的响应头让蜘蛛能拿到一个response.meta[block_reason]之类的信息方便后续人工判断。你可以把403页面里的提示文字抓出来看看很多网站会明确告诉你“访问频繁”“缺少参数”“禁止的区域”。5.5 HTTPS代理的信任问题如果你的目标网站是HTTPS的代理隧道搭建涉及TLS握手。有些代理IP是纯HTTP代理走HTTPS流量时会遇到证书错误或隧道异常。在Scrapy中表现就是CERTIFICATE_VERIFY_FAILED或者Tunnel connection failed。处理这个问题可以临时设置request.meta[verify_ssl] False但更稳妥的是在代理池里只选支持CONNECT方法的HTTPS代理或者使用代理服务商提供的专属HTTPS出口。5.6 代理返回了但请求还是超时怎么定位代理池说这个IP可用不代表它对你当前的请求可用。有些IP只代理了HTTP端口443端口没开放有些IP运营商限制了很多目标网站。中间件里超时后换IP重试当然没错但如果你发现某一段时间成功率极低建议人工用curl测试一下代理和网络链路先排除是不是目标站对你本地出口IP做了限制。5.7 重试次数调太高导致的数据重复代理IP换了之后目标网站可能已经处理了第一次请求只是响应超时你重试后服务器又处理了一次。这时候如果目标站没有做幂等控制你的数据库里就可能出现重复数据。所以爬虫端尽量在Spider里对抓取结果做去重比如根据内容哈希或者唯一字段做增量更新。这个毛病查起来不好查只能靠数据处理时控制。5.8 代理池IP质量分层同一个代理池里IP质量差异很大。有的IP是数据中心IP很多网站直接一刀切有的是家庭带宽IP质量高但价格贵成本高还有的是移动4G动态IP稳定性差但穿透力强。我建议在代理池里给IP打上质量标签在中间件里可以设置一个期望的最低质量等级不要让好IP和坏IP混着用否则会有大量重试和消耗。5.9 本地代理池挂了爬虫该怎么办代理池服务不会永远不挂。如果代理池服务崩了爬虫端每次get_proxy()都会报错中间件返回None请求就裸奔出去用自己的IP访问目标站分分钟被封。我建议在settings里加一个开关PROXY_POOL_REQUIRED设为True时一旦代理池获取不到代理就直接丢弃Request并告警而不是裸奔。这个兜底策略在运维侧能省很多麻烦。6. 遇到常见报错的排查对照表报错表现可能原因处理方案twisted.web._newclient.ResponseNeverReceived连接建立了但响应超时代理出口拥堵或目标站拒绝换新代理重试调大DOWNLOAD_TIMEOUT到15~30秒ConnectTimeout/ConnectError代理IP本身连不上端口不通从代理池剔除该IP检查代理池验证逻辑403 ForbiddenIP被封、UA异常、请求参数缺失、地域限制优先换IP检查请求头和Cookie看响应体里的提示Tunnel connection failedHTTPS代理隧道建立失败换支持CONNECT的代理检查目标站证书策略CERTIFICATE_VERIFY_FAILEDSSL证书验证异常临时关闭verify_ssl或选取更稳定的HTTPS代理大量请求超时但代理池显示IP正常代理池IP验证方式太弱改进验证逻辑用真实请求测试代理出口这张表是我踩过坑后的经验汇总。不过要注意表格只是快速定位的方向实际项目里往往多个因素叠加需要结合完整日志才能精准判断。7. 进阶扩展当单机代理池不够用时怎么升级如果你要抓的数据量巨大单机爬虫本地代理池可能很快达到瓶颈。这里我简单说两个升级方向不做太深的展开。第一个方向是分布式爬虫。用Scrapy-Redis把Request队列集中到Redis里多台机器跑同一个爬虫每台机器连同一个代理池服务。代理池也要相应升级把IP来源分散到多个服务商按权重和成本动态分配。第二个方向是把代理的选择逻辑做成更智能的“感知式选择”。简单说就是根据目标站的反爬强度、抓取频率、时间段动态调整代理类型和更换频率。比如高峰期用更贵的家庭IP低峰期用普通数据中心IP这样成本和稳定性可以兼得。这两个方向都有不少文章能单独写这里先提个引子等大家基础方案稳定了再考虑进阶。实际上大多数中小型项目用好代理池中间件这套自愈逻辑已经足够解决“大面积报错Timeout/403”的问题了。8. 一些没有写进代码里的体会前面把方案和代码都讲完了最后聊几句我在实际项目中沉淀的感受。代理IP这块很多新手以为是个配置问题、代码问题觉得“加个代理不就行了”。真正跑一段时间你会发现代理IP管理更像是一个运营问题——IP池的健康度、IP更换的频率、不同目标站的容忍度、请求频率的阶梯控制这些都要根据实际反馈持续调整。代码是死的数据是活的你得每天开着监控盯成功率曲线发现异常及时调整参数。还有一点是关于排查问题的方法论的。遇到大面积报错先别急着改代码先明确“哪一层出了问题”。先看代理池的健康度再看目标站的响应最后再怀疑自己的代码逻辑。如果你一上来就对着代码改请求头、改中间件很可能方向就错了。我见过好几个项目排除了半天才发现是代理服务商跑路或者IP被清了代码一点问题没有。最后给个实用建议不管爬虫跑得多好数据落库之后一定要有校验和告警。比如每天统计抓取条数、成功率一旦低于阈值就发邮件或者企业微信通知。这样即使在半夜出了问题第二天一早上班也能立刻知道而不是等数据需求方找上门来才发现。代理IP失效这问题看起来烦人但摸透规律之后也就是一个中间件加一个代理池的事。希望这篇内容能帮你少走点弯路。