做爬虫最烦的一件事就是目标网站把你的IP封了。明明代码逻辑没问题请求头也模拟得像模像样跑着跑着突然就开始返回验证码、出现403甚至直接拒绝服务。我刚开始接触爬虫的时候面对这种问题第一反应是降低请求频率实在不行就换IP接着跑但很快发现这只是治标不治本频率太低影响数据采集效率手动换IP更是杯水车薪。后来真正解决这类问题的思路是把“代理池”当成一个独立的服务来搭建——自动采集代理、自动校验可用性、按需调度再配合反反爬策略一起用整个爬虫项目的稳定性才能上来。这篇文章就是围绕这套方案来写的。核心内容包含代理池的架构设计、从零实现的完整代码、常见反爬策略的应对思路以及我在实际部署和运行过程中踩过的一些坑。无论你是刚入门Python爬虫还是已经在维护一个需要长期稳定运行的采集项目应该都能从里面找到能直接拿走用的东西。1. 先搞清楚你的爬虫为什么会被封1.1 封禁的判定逻辑其实不复杂很多时候我们觉得目标网站的封禁规则很神秘其实拆开来看服务端要判断某个请求是不是爬虫依据就那几个维度。第一个维度是请求频率。单个IP在单位时间内发出的请求数量一旦超过阈值不管你的请求头伪装得多完美都会被直接判定为异常。这个阈值有的网站是每秒几次有的严格到每分钟几十次取决于网站的防护级别和服务器压力。第二个维度是请求指纹。指纹包含的内容很广有User-Agent、Accept-Language、HTTP协议版本、TLS握手特征、浏览器Canvas指纹等。就算你换了IP如果指纹没有变化照样能被识别出来。第三个维度是行为路径。正常用户打开网页会先请求HTML然后加载CSS、JS、图片有先后顺序有停留时间。而爬虫往往只请求目标接口或者路径跳跃非常规律这种特征即使IP变了也抹不掉。所以说换IP本身只是应对封禁的第一步不是全部。这也是为什么我在这个项目里不单写代理池还要把反反爬策略一起梳理清楚。代理池解决的是“IP被限制”的问题而反反爬策略解决的是“请求看起来像不像真人”的问题两者配合才是一套完整的稳定性方案。1.2 代理池解决的到底是什么问题代理池不是简单的“一堆代理IP放那里随取随用”它的核心价值是自动化管理代理的生命周期。一个代理IP从采集下来开始到它失效被淘汰为止要经历采集、校验、入库、调度、更新、淘汰这些环节。如果每个环节都靠人肉操作产线一长就完全跑不动。举个例子假设你从免费代理网站上抓了500个代理IP实际能用的可能只有30%。这30%里面有的响应时间在3秒以上有的连接成功率不到50%有的一个小时之后就失效了。如果不做校验和筛选直接拿去用爬虫的请求会大量超时反而比不用代理更慢。更麻烦的是代理IP是有生命周期的你今天校验通过的代理明天可能就没了必须有一套机制持续地检查、补充、淘汰。所以代理池本质上是一个“自维护的资源管理器”它的目标就是保证池子里时刻有足够数量的可用代理供爬虫调用。明白了这一点后面的架构设计和代码实现就有了清晰的方向。2. 代理池整体架构设计与模块拆解2.1 四个核心模块的分工我把代理池拆成了四个模块采集器Crawler、校验器Validator、存储层Storage、调度接口API。采集器的职责是从各种代理源网站抓取代理IP列表。这里说的代理源包括免费代理网站、付费代理服务商的开放接口甚至自己可以通过SSH隧道或云主机部署的代理节点。采集器需要支持多源并发采集并且要能解析不同网站的不同HTML结构把IP和端口提取出来。校验器的职责是对采集到的代理进行可用性检测。检测的内容包括代理能否建立TCP连接、能否正常发起HTTP/HTTPS请求、请求目标网站后返回的状态码是什么、响应时间是多少、是不是匿名代理即目标服务器能不能看到真实IP。校验结果决定了代理能否进入可用池以及它的质量评分。存储层负责保存代理数据和它的状态。生产环境里我推荐用Redis因为可以用有序集合ZSet按分数存储代理分数可以是响应时间或可用性评分调度的适合直接按分数取效率很高。如果项目不大用SQLite或者直接用Python的字典也能顶一阵但功能和可维护性会差一些。调度接口则是对外暴露的HTTP接口爬虫通过它来获取一个可用代理。这个接口需要处理几个逻辑随机抽取还是按评分选取、要不要排除最近已经用过的代理、代理池不足时怎么办。接口的稳定性和响应速度直接影响爬虫的整体吞吐量。2.2 设计取舍与选型原因在设计这套架构时我重点考虑了几个问题。第一个是“校验和采集解耦”。很多初版代理池会把采集和校验混在一起采一个校验一个看起来很省事但实际上效率很低。因为采集是IO密集型的操作而校验需要真实发起请求也是IO密集型两者串行会互相拖慢。分开之后采集模块只关心“把IP抓下来”校验模块只关心“这批IP能不能用”各自可以独立扩展甚至能用不同的进程或机器来跑。第二个是“可用性和质量分并重”。一个代理能被连上不代表它适合你的爬虫。比如一个代理响应时间是8秒用它发请求哪怕成功了整个采集速度也会被拖垮。所以校验的时候我会记录响应时间在存储层把响应时间和成功率组合成分数调度的时优先返回分数高的代理。这个设计在代理数量大的时候效果特别明显。第三个是“对外接口保持简单”。代理池内部再怎么复杂给爬虫暴露的接口应该只有两个获取一个代理GET /proxy、报告代理失败POST /proxy/fail。保持简单的接口设计爬虫端的接入成本就很低代理池内部改版也不会影响调用方。这些取舍不是凭空想出来的是踩过坑之后总结的。早期我做的代理池没有评分机制结果生产环境的爬虫频繁超时排查了很久才发现是抽到了坏代理导致的。3. 核心代码实现从0到1搭建可用的代理池3.1 采集器实现多源解析与去重采集器的逻辑相对直接主要工作就是请求代理源网站的页面解析出IP:Port格式的数据。这里我以采集两个免费代理网站为例演示核心代码的写法。import requests from bs4 import BeautifulSoup class ProxyCrawler: def __init__(self): self.headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } self.sources [ https://www.free-proxy-list.net/, https://www.sslproxies.org/ ] def fetch_free_proxy_list(self): proxies [] response requests.get(self.sources[0], headersself.headers, timeout10) soup BeautifulSoup(response.text, html.parser) table soup.find(table, {id: proxylisttable}) if not table: return proxies for row in table.tbody.find_all(tr): tds row.find_all(td) if len(tds) 2: ip tds[0].text.strip() port tds[1].text.strip() proxies.append(f{ip}:{port}) return proxies def crawl_loop(self): all_proxies [] for source in self.sources: try: proxies self.fetch_free_proxy_list() if source self.sources[0] else self.fetch_ssl_proxies() all_proxies.extend(proxies) except Exception as e: print(f[采集失败] {source} - {e}) return list(set(all_proxies))这里有个细节需要注意不同代理源的HTML结构差异很大有的是表格有的是JSON接口。我特意在采集器里按来源区分了解析函数避免把所有解析逻辑塞到一个函数里。另外输出的代理列表要做一次去重因为不同源之间经常有重复数据。采集频率上免费代理网站一般建议5到10分钟采集一次即可。太频繁了容易被源网站封掉太慢了则代理池更新不及时。3.2 校验器实现并发检测与评分校验是整个代理池的核心环节。校验的结果直接决定代理能不能进可用池所以校验策略要细致。我采用的校验方式是对每个代理使用它去请求一个稳定的目标网站比如http://httpbin.org/ip如果请求成功并且解析出的IP和代理IP一致说明这个代理是生效的。同时记录响应时间和是否有异常状态码。import asyncio import aiohttp from datetime import datetime VALID_STATUS_CODES [200, 301, 302] async def check_proxy(proxy: str) - dict: result {proxy: proxy, ok: False, latency: 0, status: None} connector aiohttp.TCPConnector(sslFalse) timeout aiohttp.ClientTimeout(total8) try: async with aiohttp.ClientSession(connectorconnector, timeouttimeout) as session: start datetime.now() async with session.get( http://httpbin.org/ip, proxyfhttp://{proxy}, headers{User-Agent: Mozilla/5.0} ) as resp: latency (datetime.now() - start).total_seconds() * 1000 result[latency] round(latency, 2) result[status] resp.status if resp.status in VALID_STATUS_CODES: text await resp.text() if proxy.split(:)[0] in text: result[ok] True except Exception as e: result[status] str(e.__class__.__name__) return result async def run_validator(proxies: list) - list: tasks [check_proxy(p) for p in proxies] results await asyncio.gather(*tasks, return_exceptionsTrue) valid [r for r in results if isinstance(r, dict) and r[ok]] return valid校验器采用asyncio并发执行一次可以同时校验几十甚至上百个代理比串行校验快出好几倍。这里的校验目标选用httpbin.org是个经验之谈它响应稳定而且能在响应体里回显请求方的IP方便对比代理是否生效。需要特别说明的一点校验的并发数不能无脑调大。并发太高本机网卡和文件描述符会扛不住同时代理源的压力也会变大。我在实际运行中一般控制在100个并发左右这个数值需要根据你机器的网络环境调整。3.3 存储层实现Redis的ZSet用法存储层我选择了Redis的ZSet结构把代理IP作为成员member把质量分作为分数score。质量分越低代表代理越好比如响应时间越短这样调度的时候可以直接取分数最低的几个。import redis import random class ProxyPoolStorage: KEY proxy:available def __init__(self): self.client redis.Redis(hostlocalhost, port6379, db0, decode_responsesTrue) def add(self, proxy: str, score: float): self.client.zadd(self.KEY, {proxy: score}) def batch_add(self, proxies: list): if not proxies: return mapping {p[proxy]: p[latency] for p in proxies} self.client.zadd(self.KEY, mapping) def get_random(self): count self.client.zcard(self.KEY) if count 0: return None return self.client.zrandmember(self.KEY) def get_best(self): items self.client.zrange(self.KEY, 0, 0) return items[0] if items else None def remove(self, proxy: str): self.client.zrem(self.KEY, proxy) def all_proxies(self): return self.client.zrange(self.KEY, 0, -1)这里用zrandmember做随机抽取用zrange取响应时间最短的代理这两个逻辑有不同的应用场景。随机抽取适合对速度要求不高、但需要分散请求来源的场景取最优则适合对延迟敏感的任务。还有一种情况代理池里有高匿代理和透明代理之分。透明代理会把自己的真实IP通过X-Forwarded-For头传给目标服务器等于没有隐藏效果。如果在校验阶段发现这个特征我建议直接把这种代理标记为不可用避免误事。3.4 调度与协调定时任务怎么设计代理池不是一次性跑完就结束的程序它需要持续运行。我用schedule库 多线程来实现采集、校验、清理这三个循环任务。import schedule import time import threading def job_crawl(): crawler ProxyCrawler() proxies crawler.crawl_loop() storage.batch_add_unknown(proxies) # 先放进待校验池 def job_validate(): storage ProxyPoolStorage() pending storage.get_pending_proxies() if not pending: return valid asyncio.run(run_validator(pending)) storage.batch_add(valid) def job_cleanup(): storage.cleanup_expired(interval_minutes30) schedule.every(10).minutes.do(job_crawl) schedule.every(2).minutes.do(job_validate) schedule.every(5).minutes.do(job_cleanup) while True: schedule.run_pending() time.sleep(1)调度器的设计逻辑是采集线程先把代理放进一个“待校验池”校验线程从待校验池取数据做检测通过的进入可用池没有通过的直接丢弃。清理线程负责把可用池中长期未使用或者最近校验失败的代理移除。这里要注意一个问题schedule库本身不是线程安全的定时任务之间的执行顺序也需要规划。我一般会把采集任务和校验任务放在不同的线程里避免采集耗时过长导致校验任务排不上。如果项目复杂度更高可以考虑用Celery或者APScheduler来替换。4. 反反爬策略除了换IP还能做什么4.1 请求头伪装不等于只改User-Agent很多刚入门的朋友以为反爬就是改个User-Agent实际上这远远不够。目标网站识别爬虫时会综合检查多个请求头的组合是否合理。先看一个常见配置HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/avif,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8, Accept-Encoding: gzip, deflate, br, Connection: keep-alive, Referer: https://www.google.com/, Sec-Fetch-Dest: document, Sec-Fetch-Mode: navigate, Sec-Fetch-Site: cross-site, Sec-Fetch-User: ?1, Upgrade-Insecure-Requests: 1, }这里有个常见的错误做法把所有请求的Referer都设成同一个值。正常用户在浏览网站时不同页面的Referer是完全不同的如果全部相同反而暴露了脚本特征。我通常的做法是为每一个爬虫任务维护一个小的Referer候选列表请求时随机挑选。还有一个容易忽略的点是Accept-Encoding。如果你在代码里设置了gzip, deflate但实际没有对响应做解压那页面就会返回乱码或者直接报错。requests库会自动解压但scrapy和selenium的某些场景下需要手动处理。这个细节不难但坑过不少人。4.2 Cookie和Session模拟真实的会话链路Cookie策略是反反爬里一个容易被忽视的分支。很多网站的逻辑是你先访问首页服务端下发一个Cookie然后你带着这个Cookie去访问数据接口才能正常拿到数据。如果爬虫直接请求数据接口不带任何Cookie哪怕IP是干净的也可能返回异常。模拟真实会话链路的方法很简单import requests session requests.Session() session.headers.update(HEADERS) # 第一步访问首页拿到Cookie homepage session.get(https://example.com/, timeout10) # 第二步带着Cookie访问目标接口 api_url https://example.com/api/data response session.get(api_url, timeout10)这里为什么要用Session而不是直接requests.get因为Session对象会自动管理Cookie并在后续请求中自动携带。但要注意有些网站的反爬逻辑会校验Cookie的生成时间和访问接口的时间间隔如果间隔太短比如刚拿到Cookie就立刻访问接口也会判定为异常。我的经验是在请求之间加入2到3秒的延迟模拟真实用户的操作节奏。另外有些复杂场景下网站会使用JSESSIONID或者token做校验这时候需要配合selenium先渲染页面拿到有效的Cookie再切换到requests模式去请求接口这种混合模式在工程项目里非常实用。4.3 行为模拟随机延迟与自动化操作痕迹行为模拟的核心目标是让请求的时间分布和操作序列像一个真人而不是一个“每秒10个请求的机器人”。最简单的行为模拟是随机延迟。注意这里的“随机”不是均匀随机而是带有一定分布的随机。比如正常用户的点击间隔在3到10秒之间且更多集中在5秒左右那么可以用高斯分布来生成延迟import random import time def human_delay(mean5, std2): delay random.gauss(mean, std) if delay 1: delay 1 return delay # 在每次请求之间调用 time.sleep(human_delay())如果爬取的是需要点击、滚动才能加载更多数据的页面还需要模拟滚动行为。用selenium的时候可以通过execute_script执行window.scrollBy来实现渐变式滚动而不是一次性滚到页面的最底部。后者在很多网站上会被识别为自动操作。还有一个比较高阶的细节鼠标轨迹模拟。正常用户操作鼠标的轨迹不是直线而是带有一定的弧度和抖动。虽然检测鼠标轨迹的网站还不算多但一旦遇到这种级别的反爬处理起来非常棘手。目前ActionChains的move_to_element只能实现直线移动如果想要更接近真人可以自己写贝塞尔曲线的轨迹算法这个内容展开又是一大篇这里先提个头。4.4 Selenium与浏览器指纹的处理方向selenium本身自带特征就算用了代理IP如果指纹暴露了照样被封。这里有几个我自己测试过的处理思路第一隐藏navigator.webdriver属性。selenium驱动的浏览器navigator.webdriver的值是true目标网站的JS可以检测到这个标记并拦截。解决办法是在页面加载前通过add_script_tag注入一段修改属性的JS代码。第二统一浏览器配置文件。使用ChromeOptions加上user-data-dir参数指定一个真实的浏览器配置文件路径可以让浏览器界面与自动化脚本共享用户数据降低指纹差异。from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() options.add_argument(--disable-blink-featuresAutomationControlled) options.add_argument(user-data-dir/path/to/chrome/profile) driver webdriver.Chrome(optionsoptions) driver.execute_cdp_cmd(Page.addScriptToEvaluateOnNewDocument, { source: Object.defineProperty(navigator, webdriver, {get: () undefined}) })第三不要忽略浏览器版本与chromedriver版本的匹配。版本不匹配时selenium会报错退出更重要的是版本不一致的浏览器指纹在目标网站的检测库中很容易异常出现。第四如果目标网站的反爬强度很高selenium本身可能不够用这时候就要考虑playwright了。playwright在自动化指纹方面比selenium做得更干净启动的浏览器实例几乎没有自动化标记而且支持直接指定浏览器内核和用户代理配置。我在处理一些高防护网站时会优先考虑playwright。5. 常见问题与排查技巧实录5.1 代理池跑起来了但爬虫还是被检测到这种情况通常不是代理池的问题而是指纹特征没有处理干净。我遇到过好几个案例代理质量很好IP也是干净的但爬虫依然被封排查到最后发现是TLS指纹的问题。TLS指纹是什么概念呢当你的客户端和服务器建立HTTPS连接时TLS握手过程中客户端会发送ClientHello消息这个消息里包含了加密套件列表、TLS版本、扩展字段等信息。这些信息的组合方式就是TLS指纹。目标服务器可以把你的TLS指纹和真实浏览器的TLS指纹做对比如果不匹配即使你的IP干净、User-Agent伪装得再好也会被封。requests库使用的urllib3底层连接方式在TLS指纹上和真实浏览器有明显差异。解决思路有两个一是把请求库换成curl_cffi它可以直接模拟Chrome的TLS指纹二是用真实浏览器内核playwright或者selenium来避开这个问题。我目前生产环境里采用curl_cffi的方案因为它兼顾了速度和指纹真实性。from curl_cffi import requests as curl_requests response curl_requests.get(https://example.com, impersonatechrome)用impersonatechrome参数后请求的TLS指纹会和Chrome浏览器高度一致有效降低被动的封禁概率。5.2 代理池里IP很多可用率却一直上不去免费代理源的通病是存活率低我运营免费代理池时可用率一般在10%到30%之间浮动。如果你发现可用率长期偏低建议从两个方向优化。第一提高采集源的筛选标准。市场上有很多免费代理源质量参差不齐。通过分析采回来的历史数据你会发现某些来源的代理存活率明显高于其他来源那就只保留高质量来源。第二优化校验逻辑。我之前校验用的是单个稳定网站如httpbin.org但线上爬虫请求的目标网站和校验目标的网络路径差异可能很大。一个代理对httpbin.org请求很快不代表对你真正要爬的目标网站也快。更稳妥的做法是让校验器同时请求多个目标站取一个综合评分。我在实践中还发现免费代理适合用于对稳定性要求不高的场景比如非核心数据的采集、竞品监测的初步验证等。如果是核心业务的数据采集还是建议考虑付费代理服务质量高出一大截。5.3 代理请求超时和连接重置的排查思路代理请求超时是排查起来最让人头疼的问题之一因为它可能出在任意一个环节。我给一个排查顺序先确认本机网络是否正常能正常访问百度等网站排除本机断网的可能。然后检查代理服务器本身连通性用telnet ip port测试TCP层能否建立连接如果这一步就超时说明代理已失效或者IP:Port格式错误。确认TCP连接正常后再测试通过代理发起HTTP请求看是否报错、状态码是什么。最后排查代码里的超时参数设置是否合理——很多时候不是代理不能用而是你设置的timeout太短比如全局设了3秒但代理链路本身需要5秒才能完成响应。这种逐层排查的思路适用于绝大多数代理相关的问题。千万不要一上来就怀疑代理池逻辑有问题大概率是某个代理本身失效了或者网络链路有延迟波动。5.4 我踩过的几个坑和独家经验分享一下我在这个项目里踩过的一些坑。第一个坑是Redis连接池耗尽。早期我在校验任务里反复创建新的Redis连接短期看不出来问题但爬虫并发一上来大量连接同时建立Redis连接数飙升直接导致redis.exceptions.ConnectionError。后来改成全局复用连接池并且在batch_add等高频操作里批量执行命令问题就消失了。第二个坑是代理池里混入了失效的代理导致爬虫端的重试策略不断触发。我一开始没有在代理池外部做“失败代理标记”机制爬虫每次请求失败都会重新获取一个代理但如果这个代理其实已经在池子里被标记为失效了获取接口还是会把它返回。后来我在存储层加了一个黑名单队列被爬虫报告失败的代理直接进黑名单并且短时间内不再返回给调用方。第三个坑是异步校验时没有控制并发上限导致一次性发起几千个请求把本机的文件描述符打满进程直接崩溃。后来加了asyncio.Semaphore信号量控制并发数这才稳定下来。semaphore asyncio.Semaphore(100) async def limited_check(proxy): async with semaphore: return await check_proxy(proxy)第四个经验是代理池的对外接口一定要做好限流否则爬虫端在重试的时候可能会一秒钟请求几十次获取接口让代理池变成了新的瓶颈。我在对外接口上加了基于IP的限流逻辑同时给获取代理的接口设置较短的过期时间让爬虫端拿到的代理是有时效性的。6. 实际部署中的一些补充建议代理池跑起来之后部署方式也需要考虑。我的建议是独立部署成一个小服务而不是直接和爬虫跑在同一个进程里。这样做的原因有两个一是代理池的采集和校验任务消耗网络带宽和CPU如果和爬虫抢资源两边都会变慢二是代理池需要7×24小时持续运行如果混在爬虫进程里爬虫挂了代理池也得重建。生产环境下我用systemd来管理代理池的进程配置一个Restartalways的单元文件进程意外退出后能自动拉起来。[Unit] DescriptionProxy Pool Service Afternetwork.target redis.service [Service] ExecStart/usr/bin/python3 /opt/proxypool/main.py WorkingDirectory/opt/proxypool Restartalways RestartSec5 EnvironmentPYTHONUNBUFFERED1 [Install] WantedBymulti-user.target这里有个小细节WorkingDirectory一定要设置正确否则相对路径读取配置文件时容易出问题。别问我为什么强调这一点我连续被这个坑过两次。另外代理池的日志输出也要规范起来。我习惯把采集日志、校验日志、调度日志分开记录并且带上时间戳。排查问题的时候日志的完整度直接决定了定位速度。日志记录里至少要包含以下信息代理IP、校验结果、响应时间、错误类型、采集来源、入库/淘汰动作。还有个占比很大但容易被忽视的问题代理池的并发校验会消耗大量公网流量。如果你的服务器是走流量计费的模式每月会产生一笔不小的费用。我之前的服务器一个月跑了将近200GB的流量其中大部分是代理池的校验请求打出来的。后来我调低了校验频率并且只在代理池数量低于某个阈值时才启动全量校验才把流量浪费降下来。如果你打算长期维护代理池我建议把数据结构也提前设计好不只是Redis的ZSet还可以加一个Hash来存储每个代理的详细信息包括采集来源、最近校验时间、累计成功率、上次使用时间等。这些数据在后续分析代理质量、优化调度策略时非常有用。proxy:info:{ip:port} - { source: free-proxy-list.net, last_checked: 1700000000, success_count: 12, fail_count: 3, latency_avg: 2.31, created_at: 1690000000 }有了这些基础数据你甚至可以做简单的质量趋势分析提前预判一批代理是否会大面积失效从而提前补充新的代理源。还有一件事值得单独说一说尽量不要在爬虫的关键路径里同步等待代理池返回代理。也就是说不要每次都“先拿代理、再发请求”这样的链路对代理池的可用性要求太高。更好的做法是提前在本地维护一个小的代理缓存队列客户端从缓存队列里取代理然后异步向代理池补充缓存。这样即使代理池临时不可用已经拿到的代理还能继续用一段时间。如果用Python实现这个缓存队列可以用queue.Queue配合后台线程补充核心代码非常简单import queue import threading import time proxy_cache queue.Queue(maxsize50) def refill_cache(): while True: if proxy_cache.qsize() 20: proxies fetch_from_proxy_pool(30) for p in proxies: try: proxy_cache.put(p, timeout1) except queue.Full: break time.sleep(5) threading.Thread(targetrefill_cache, daemonTrue).start()这个模式我用了很久实测下来能显著降低爬虫端因为代理池调度延迟而出现空闲等待的概率。写在最后的一些体会代理池和反反爬这个方向看起来是一个技术问题但实际上是一个系统工程问题。单纯通过加代理、换UA来解决封禁往往只能应付最低级的防护。真正要做的是把你爬虫的每一个环节都向真实用户靠拢——网络链路用代理池保障TLS指纹和浏览器指纹保持一致请求节奏和浏览行为符合直觉Cookie链路完整无破绽。这些点全部串在一起才算是一个合格的反反爬方案。我自己在实践过程中的最大体会是不要追求“一套方案打天下”不同目标网站的防护逻辑差异很大拿代理池去处理简单站点是大炮打蚊子拿全套指纹伪装去处理一个只校验频率的站点又显得多余。先分析目标网站的封禁特征再有针对性地组合代理池和反反爬策略这才是性价比最高的做法。希望这篇文章能帮你少走一些弯路。
代理池从0到1：解决爬虫IP封禁与反反爬策略实战
做爬虫最烦的一件事就是目标网站把你的IP封了。明明代码逻辑没问题请求头也模拟得像模像样跑着跑着突然就开始返回验证码、出现403甚至直接拒绝服务。我刚开始接触爬虫的时候面对这种问题第一反应是降低请求频率实在不行就换IP接着跑但很快发现这只是治标不治本频率太低影响数据采集效率手动换IP更是杯水车薪。后来真正解决这类问题的思路是把“代理池”当成一个独立的服务来搭建——自动采集代理、自动校验可用性、按需调度再配合反反爬策略一起用整个爬虫项目的稳定性才能上来。这篇文章就是围绕这套方案来写的。核心内容包含代理池的架构设计、从零实现的完整代码、常见反爬策略的应对思路以及我在实际部署和运行过程中踩过的一些坑。无论你是刚入门Python爬虫还是已经在维护一个需要长期稳定运行的采集项目应该都能从里面找到能直接拿走用的东西。1. 先搞清楚你的爬虫为什么会被封1.1 封禁的判定逻辑其实不复杂很多时候我们觉得目标网站的封禁规则很神秘其实拆开来看服务端要判断某个请求是不是爬虫依据就那几个维度。第一个维度是请求频率。单个IP在单位时间内发出的请求数量一旦超过阈值不管你的请求头伪装得多完美都会被直接判定为异常。这个阈值有的网站是每秒几次有的严格到每分钟几十次取决于网站的防护级别和服务器压力。第二个维度是请求指纹。指纹包含的内容很广有User-Agent、Accept-Language、HTTP协议版本、TLS握手特征、浏览器Canvas指纹等。就算你换了IP如果指纹没有变化照样能被识别出来。第三个维度是行为路径。正常用户打开网页会先请求HTML然后加载CSS、JS、图片有先后顺序有停留时间。而爬虫往往只请求目标接口或者路径跳跃非常规律这种特征即使IP变了也抹不掉。所以说换IP本身只是应对封禁的第一步不是全部。这也是为什么我在这个项目里不单写代理池还要把反反爬策略一起梳理清楚。代理池解决的是“IP被限制”的问题而反反爬策略解决的是“请求看起来像不像真人”的问题两者配合才是一套完整的稳定性方案。1.2 代理池解决的到底是什么问题代理池不是简单的“一堆代理IP放那里随取随用”它的核心价值是自动化管理代理的生命周期。一个代理IP从采集下来开始到它失效被淘汰为止要经历采集、校验、入库、调度、更新、淘汰这些环节。如果每个环节都靠人肉操作产线一长就完全跑不动。举个例子假设你从免费代理网站上抓了500个代理IP实际能用的可能只有30%。这30%里面有的响应时间在3秒以上有的连接成功率不到50%有的一个小时之后就失效了。如果不做校验和筛选直接拿去用爬虫的请求会大量超时反而比不用代理更慢。更麻烦的是代理IP是有生命周期的你今天校验通过的代理明天可能就没了必须有一套机制持续地检查、补充、淘汰。所以代理池本质上是一个“自维护的资源管理器”它的目标就是保证池子里时刻有足够数量的可用代理供爬虫调用。明白了这一点后面的架构设计和代码实现就有了清晰的方向。2. 代理池整体架构设计与模块拆解2.1 四个核心模块的分工我把代理池拆成了四个模块采集器Crawler、校验器Validator、存储层Storage、调度接口API。采集器的职责是从各种代理源网站抓取代理IP列表。这里说的代理源包括免费代理网站、付费代理服务商的开放接口甚至自己可以通过SSH隧道或云主机部署的代理节点。采集器需要支持多源并发采集并且要能解析不同网站的不同HTML结构把IP和端口提取出来。校验器的职责是对采集到的代理进行可用性检测。检测的内容包括代理能否建立TCP连接、能否正常发起HTTP/HTTPS请求、请求目标网站后返回的状态码是什么、响应时间是多少、是不是匿名代理即目标服务器能不能看到真实IP。校验结果决定了代理能否进入可用池以及它的质量评分。存储层负责保存代理数据和它的状态。生产环境里我推荐用Redis因为可以用有序集合ZSet按分数存储代理分数可以是响应时间或可用性评分调度的适合直接按分数取效率很高。如果项目不大用SQLite或者直接用Python的字典也能顶一阵但功能和可维护性会差一些。调度接口则是对外暴露的HTTP接口爬虫通过它来获取一个可用代理。这个接口需要处理几个逻辑随机抽取还是按评分选取、要不要排除最近已经用过的代理、代理池不足时怎么办。接口的稳定性和响应速度直接影响爬虫的整体吞吐量。2.2 设计取舍与选型原因在设计这套架构时我重点考虑了几个问题。第一个是“校验和采集解耦”。很多初版代理池会把采集和校验混在一起采一个校验一个看起来很省事但实际上效率很低。因为采集是IO密集型的操作而校验需要真实发起请求也是IO密集型两者串行会互相拖慢。分开之后采集模块只关心“把IP抓下来”校验模块只关心“这批IP能不能用”各自可以独立扩展甚至能用不同的进程或机器来跑。第二个是“可用性和质量分并重”。一个代理能被连上不代表它适合你的爬虫。比如一个代理响应时间是8秒用它发请求哪怕成功了整个采集速度也会被拖垮。所以校验的时候我会记录响应时间在存储层把响应时间和成功率组合成分数调度的时优先返回分数高的代理。这个设计在代理数量大的时候效果特别明显。第三个是“对外接口保持简单”。代理池内部再怎么复杂给爬虫暴露的接口应该只有两个获取一个代理GET /proxy、报告代理失败POST /proxy/fail。保持简单的接口设计爬虫端的接入成本就很低代理池内部改版也不会影响调用方。这些取舍不是凭空想出来的是踩过坑之后总结的。早期我做的代理池没有评分机制结果生产环境的爬虫频繁超时排查了很久才发现是抽到了坏代理导致的。3. 核心代码实现从0到1搭建可用的代理池3.1 采集器实现多源解析与去重采集器的逻辑相对直接主要工作就是请求代理源网站的页面解析出IP:Port格式的数据。这里我以采集两个免费代理网站为例演示核心代码的写法。import requests from bs4 import BeautifulSoup class ProxyCrawler: def __init__(self): self.headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } self.sources [ https://www.free-proxy-list.net/, https://www.sslproxies.org/ ] def fetch_free_proxy_list(self): proxies [] response requests.get(self.sources[0], headersself.headers, timeout10) soup BeautifulSoup(response.text, html.parser) table soup.find(table, {id: proxylisttable}) if not table: return proxies for row in table.tbody.find_all(tr): tds row.find_all(td) if len(tds) 2: ip tds[0].text.strip() port tds[1].text.strip() proxies.append(f{ip}:{port}) return proxies def crawl_loop(self): all_proxies [] for source in self.sources: try: proxies self.fetch_free_proxy_list() if source self.sources[0] else self.fetch_ssl_proxies() all_proxies.extend(proxies) except Exception as e: print(f[采集失败] {source} - {e}) return list(set(all_proxies))这里有个细节需要注意不同代理源的HTML结构差异很大有的是表格有的是JSON接口。我特意在采集器里按来源区分了解析函数避免把所有解析逻辑塞到一个函数里。另外输出的代理列表要做一次去重因为不同源之间经常有重复数据。采集频率上免费代理网站一般建议5到10分钟采集一次即可。太频繁了容易被源网站封掉太慢了则代理池更新不及时。3.2 校验器实现并发检测与评分校验是整个代理池的核心环节。校验的结果直接决定代理能不能进可用池所以校验策略要细致。我采用的校验方式是对每个代理使用它去请求一个稳定的目标网站比如http://httpbin.org/ip如果请求成功并且解析出的IP和代理IP一致说明这个代理是生效的。同时记录响应时间和是否有异常状态码。import asyncio import aiohttp from datetime import datetime VALID_STATUS_CODES [200, 301, 302] async def check_proxy(proxy: str) - dict: result {proxy: proxy, ok: False, latency: 0, status: None} connector aiohttp.TCPConnector(sslFalse) timeout aiohttp.ClientTimeout(total8) try: async with aiohttp.ClientSession(connectorconnector, timeouttimeout) as session: start datetime.now() async with session.get( http://httpbin.org/ip, proxyfhttp://{proxy}, headers{User-Agent: Mozilla/5.0} ) as resp: latency (datetime.now() - start).total_seconds() * 1000 result[latency] round(latency, 2) result[status] resp.status if resp.status in VALID_STATUS_CODES: text await resp.text() if proxy.split(:)[0] in text: result[ok] True except Exception as e: result[status] str(e.__class__.__name__) return result async def run_validator(proxies: list) - list: tasks [check_proxy(p) for p in proxies] results await asyncio.gather(*tasks, return_exceptionsTrue) valid [r for r in results if isinstance(r, dict) and r[ok]] return valid校验器采用asyncio并发执行一次可以同时校验几十甚至上百个代理比串行校验快出好几倍。这里的校验目标选用httpbin.org是个经验之谈它响应稳定而且能在响应体里回显请求方的IP方便对比代理是否生效。需要特别说明的一点校验的并发数不能无脑调大。并发太高本机网卡和文件描述符会扛不住同时代理源的压力也会变大。我在实际运行中一般控制在100个并发左右这个数值需要根据你机器的网络环境调整。3.3 存储层实现Redis的ZSet用法存储层我选择了Redis的ZSet结构把代理IP作为成员member把质量分作为分数score。质量分越低代表代理越好比如响应时间越短这样调度的时候可以直接取分数最低的几个。import redis import random class ProxyPoolStorage: KEY proxy:available def __init__(self): self.client redis.Redis(hostlocalhost, port6379, db0, decode_responsesTrue) def add(self, proxy: str, score: float): self.client.zadd(self.KEY, {proxy: score}) def batch_add(self, proxies: list): if not proxies: return mapping {p[proxy]: p[latency] for p in proxies} self.client.zadd(self.KEY, mapping) def get_random(self): count self.client.zcard(self.KEY) if count 0: return None return self.client.zrandmember(self.KEY) def get_best(self): items self.client.zrange(self.KEY, 0, 0) return items[0] if items else None def remove(self, proxy: str): self.client.zrem(self.KEY, proxy) def all_proxies(self): return self.client.zrange(self.KEY, 0, -1)这里用zrandmember做随机抽取用zrange取响应时间最短的代理这两个逻辑有不同的应用场景。随机抽取适合对速度要求不高、但需要分散请求来源的场景取最优则适合对延迟敏感的任务。还有一种情况代理池里有高匿代理和透明代理之分。透明代理会把自己的真实IP通过X-Forwarded-For头传给目标服务器等于没有隐藏效果。如果在校验阶段发现这个特征我建议直接把这种代理标记为不可用避免误事。3.4 调度与协调定时任务怎么设计代理池不是一次性跑完就结束的程序它需要持续运行。我用schedule库 多线程来实现采集、校验、清理这三个循环任务。import schedule import time import threading def job_crawl(): crawler ProxyCrawler() proxies crawler.crawl_loop() storage.batch_add_unknown(proxies) # 先放进待校验池 def job_validate(): storage ProxyPoolStorage() pending storage.get_pending_proxies() if not pending: return valid asyncio.run(run_validator(pending)) storage.batch_add(valid) def job_cleanup(): storage.cleanup_expired(interval_minutes30) schedule.every(10).minutes.do(job_crawl) schedule.every(2).minutes.do(job_validate) schedule.every(5).minutes.do(job_cleanup) while True: schedule.run_pending() time.sleep(1)调度器的设计逻辑是采集线程先把代理放进一个“待校验池”校验线程从待校验池取数据做检测通过的进入可用池没有通过的直接丢弃。清理线程负责把可用池中长期未使用或者最近校验失败的代理移除。这里要注意一个问题schedule库本身不是线程安全的定时任务之间的执行顺序也需要规划。我一般会把采集任务和校验任务放在不同的线程里避免采集耗时过长导致校验任务排不上。如果项目复杂度更高可以考虑用Celery或者APScheduler来替换。4. 反反爬策略除了换IP还能做什么4.1 请求头伪装不等于只改User-Agent很多刚入门的朋友以为反爬就是改个User-Agent实际上这远远不够。目标网站识别爬虫时会综合检查多个请求头的组合是否合理。先看一个常见配置HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/avif,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8, Accept-Encoding: gzip, deflate, br, Connection: keep-alive, Referer: https://www.google.com/, Sec-Fetch-Dest: document, Sec-Fetch-Mode: navigate, Sec-Fetch-Site: cross-site, Sec-Fetch-User: ?1, Upgrade-Insecure-Requests: 1, }这里有个常见的错误做法把所有请求的Referer都设成同一个值。正常用户在浏览网站时不同页面的Referer是完全不同的如果全部相同反而暴露了脚本特征。我通常的做法是为每一个爬虫任务维护一个小的Referer候选列表请求时随机挑选。还有一个容易忽略的点是Accept-Encoding。如果你在代码里设置了gzip, deflate但实际没有对响应做解压那页面就会返回乱码或者直接报错。requests库会自动解压但scrapy和selenium的某些场景下需要手动处理。这个细节不难但坑过不少人。4.2 Cookie和Session模拟真实的会话链路Cookie策略是反反爬里一个容易被忽视的分支。很多网站的逻辑是你先访问首页服务端下发一个Cookie然后你带着这个Cookie去访问数据接口才能正常拿到数据。如果爬虫直接请求数据接口不带任何Cookie哪怕IP是干净的也可能返回异常。模拟真实会话链路的方法很简单import requests session requests.Session() session.headers.update(HEADERS) # 第一步访问首页拿到Cookie homepage session.get(https://example.com/, timeout10) # 第二步带着Cookie访问目标接口 api_url https://example.com/api/data response session.get(api_url, timeout10)这里为什么要用Session而不是直接requests.get因为Session对象会自动管理Cookie并在后续请求中自动携带。但要注意有些网站的反爬逻辑会校验Cookie的生成时间和访问接口的时间间隔如果间隔太短比如刚拿到Cookie就立刻访问接口也会判定为异常。我的经验是在请求之间加入2到3秒的延迟模拟真实用户的操作节奏。另外有些复杂场景下网站会使用JSESSIONID或者token做校验这时候需要配合selenium先渲染页面拿到有效的Cookie再切换到requests模式去请求接口这种混合模式在工程项目里非常实用。4.3 行为模拟随机延迟与自动化操作痕迹行为模拟的核心目标是让请求的时间分布和操作序列像一个真人而不是一个“每秒10个请求的机器人”。最简单的行为模拟是随机延迟。注意这里的“随机”不是均匀随机而是带有一定分布的随机。比如正常用户的点击间隔在3到10秒之间且更多集中在5秒左右那么可以用高斯分布来生成延迟import random import time def human_delay(mean5, std2): delay random.gauss(mean, std) if delay 1: delay 1 return delay # 在每次请求之间调用 time.sleep(human_delay())如果爬取的是需要点击、滚动才能加载更多数据的页面还需要模拟滚动行为。用selenium的时候可以通过execute_script执行window.scrollBy来实现渐变式滚动而不是一次性滚到页面的最底部。后者在很多网站上会被识别为自动操作。还有一个比较高阶的细节鼠标轨迹模拟。正常用户操作鼠标的轨迹不是直线而是带有一定的弧度和抖动。虽然检测鼠标轨迹的网站还不算多但一旦遇到这种级别的反爬处理起来非常棘手。目前ActionChains的move_to_element只能实现直线移动如果想要更接近真人可以自己写贝塞尔曲线的轨迹算法这个内容展开又是一大篇这里先提个头。4.4 Selenium与浏览器指纹的处理方向selenium本身自带特征就算用了代理IP如果指纹暴露了照样被封。这里有几个我自己测试过的处理思路第一隐藏navigator.webdriver属性。selenium驱动的浏览器navigator.webdriver的值是true目标网站的JS可以检测到这个标记并拦截。解决办法是在页面加载前通过add_script_tag注入一段修改属性的JS代码。第二统一浏览器配置文件。使用ChromeOptions加上user-data-dir参数指定一个真实的浏览器配置文件路径可以让浏览器界面与自动化脚本共享用户数据降低指纹差异。from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() options.add_argument(--disable-blink-featuresAutomationControlled) options.add_argument(user-data-dir/path/to/chrome/profile) driver webdriver.Chrome(optionsoptions) driver.execute_cdp_cmd(Page.addScriptToEvaluateOnNewDocument, { source: Object.defineProperty(navigator, webdriver, {get: () undefined}) })第三不要忽略浏览器版本与chromedriver版本的匹配。版本不匹配时selenium会报错退出更重要的是版本不一致的浏览器指纹在目标网站的检测库中很容易异常出现。第四如果目标网站的反爬强度很高selenium本身可能不够用这时候就要考虑playwright了。playwright在自动化指纹方面比selenium做得更干净启动的浏览器实例几乎没有自动化标记而且支持直接指定浏览器内核和用户代理配置。我在处理一些高防护网站时会优先考虑playwright。5. 常见问题与排查技巧实录5.1 代理池跑起来了但爬虫还是被检测到这种情况通常不是代理池的问题而是指纹特征没有处理干净。我遇到过好几个案例代理质量很好IP也是干净的但爬虫依然被封排查到最后发现是TLS指纹的问题。TLS指纹是什么概念呢当你的客户端和服务器建立HTTPS连接时TLS握手过程中客户端会发送ClientHello消息这个消息里包含了加密套件列表、TLS版本、扩展字段等信息。这些信息的组合方式就是TLS指纹。目标服务器可以把你的TLS指纹和真实浏览器的TLS指纹做对比如果不匹配即使你的IP干净、User-Agent伪装得再好也会被封。requests库使用的urllib3底层连接方式在TLS指纹上和真实浏览器有明显差异。解决思路有两个一是把请求库换成curl_cffi它可以直接模拟Chrome的TLS指纹二是用真实浏览器内核playwright或者selenium来避开这个问题。我目前生产环境里采用curl_cffi的方案因为它兼顾了速度和指纹真实性。from curl_cffi import requests as curl_requests response curl_requests.get(https://example.com, impersonatechrome)用impersonatechrome参数后请求的TLS指纹会和Chrome浏览器高度一致有效降低被动的封禁概率。5.2 代理池里IP很多可用率却一直上不去免费代理源的通病是存活率低我运营免费代理池时可用率一般在10%到30%之间浮动。如果你发现可用率长期偏低建议从两个方向优化。第一提高采集源的筛选标准。市场上有很多免费代理源质量参差不齐。通过分析采回来的历史数据你会发现某些来源的代理存活率明显高于其他来源那就只保留高质量来源。第二优化校验逻辑。我之前校验用的是单个稳定网站如httpbin.org但线上爬虫请求的目标网站和校验目标的网络路径差异可能很大。一个代理对httpbin.org请求很快不代表对你真正要爬的目标网站也快。更稳妥的做法是让校验器同时请求多个目标站取一个综合评分。我在实践中还发现免费代理适合用于对稳定性要求不高的场景比如非核心数据的采集、竞品监测的初步验证等。如果是核心业务的数据采集还是建议考虑付费代理服务质量高出一大截。5.3 代理请求超时和连接重置的排查思路代理请求超时是排查起来最让人头疼的问题之一因为它可能出在任意一个环节。我给一个排查顺序先确认本机网络是否正常能正常访问百度等网站排除本机断网的可能。然后检查代理服务器本身连通性用telnet ip port测试TCP层能否建立连接如果这一步就超时说明代理已失效或者IP:Port格式错误。确认TCP连接正常后再测试通过代理发起HTTP请求看是否报错、状态码是什么。最后排查代码里的超时参数设置是否合理——很多时候不是代理不能用而是你设置的timeout太短比如全局设了3秒但代理链路本身需要5秒才能完成响应。这种逐层排查的思路适用于绝大多数代理相关的问题。千万不要一上来就怀疑代理池逻辑有问题大概率是某个代理本身失效了或者网络链路有延迟波动。5.4 我踩过的几个坑和独家经验分享一下我在这个项目里踩过的一些坑。第一个坑是Redis连接池耗尽。早期我在校验任务里反复创建新的Redis连接短期看不出来问题但爬虫并发一上来大量连接同时建立Redis连接数飙升直接导致redis.exceptions.ConnectionError。后来改成全局复用连接池并且在batch_add等高频操作里批量执行命令问题就消失了。第二个坑是代理池里混入了失效的代理导致爬虫端的重试策略不断触发。我一开始没有在代理池外部做“失败代理标记”机制爬虫每次请求失败都会重新获取一个代理但如果这个代理其实已经在池子里被标记为失效了获取接口还是会把它返回。后来我在存储层加了一个黑名单队列被爬虫报告失败的代理直接进黑名单并且短时间内不再返回给调用方。第三个坑是异步校验时没有控制并发上限导致一次性发起几千个请求把本机的文件描述符打满进程直接崩溃。后来加了asyncio.Semaphore信号量控制并发数这才稳定下来。semaphore asyncio.Semaphore(100) async def limited_check(proxy): async with semaphore: return await check_proxy(proxy)第四个经验是代理池的对外接口一定要做好限流否则爬虫端在重试的时候可能会一秒钟请求几十次获取接口让代理池变成了新的瓶颈。我在对外接口上加了基于IP的限流逻辑同时给获取代理的接口设置较短的过期时间让爬虫端拿到的代理是有时效性的。6. 实际部署中的一些补充建议代理池跑起来之后部署方式也需要考虑。我的建议是独立部署成一个小服务而不是直接和爬虫跑在同一个进程里。这样做的原因有两个一是代理池的采集和校验任务消耗网络带宽和CPU如果和爬虫抢资源两边都会变慢二是代理池需要7×24小时持续运行如果混在爬虫进程里爬虫挂了代理池也得重建。生产环境下我用systemd来管理代理池的进程配置一个Restartalways的单元文件进程意外退出后能自动拉起来。[Unit] DescriptionProxy Pool Service Afternetwork.target redis.service [Service] ExecStart/usr/bin/python3 /opt/proxypool/main.py WorkingDirectory/opt/proxypool Restartalways RestartSec5 EnvironmentPYTHONUNBUFFERED1 [Install] WantedBymulti-user.target这里有个小细节WorkingDirectory一定要设置正确否则相对路径读取配置文件时容易出问题。别问我为什么强调这一点我连续被这个坑过两次。另外代理池的日志输出也要规范起来。我习惯把采集日志、校验日志、调度日志分开记录并且带上时间戳。排查问题的时候日志的完整度直接决定了定位速度。日志记录里至少要包含以下信息代理IP、校验结果、响应时间、错误类型、采集来源、入库/淘汰动作。还有个占比很大但容易被忽视的问题代理池的并发校验会消耗大量公网流量。如果你的服务器是走流量计费的模式每月会产生一笔不小的费用。我之前的服务器一个月跑了将近200GB的流量其中大部分是代理池的校验请求打出来的。后来我调低了校验频率并且只在代理池数量低于某个阈值时才启动全量校验才把流量浪费降下来。如果你打算长期维护代理池我建议把数据结构也提前设计好不只是Redis的ZSet还可以加一个Hash来存储每个代理的详细信息包括采集来源、最近校验时间、累计成功率、上次使用时间等。这些数据在后续分析代理质量、优化调度策略时非常有用。proxy:info:{ip:port} - { source: free-proxy-list.net, last_checked: 1700000000, success_count: 12, fail_count: 3, latency_avg: 2.31, created_at: 1690000000 }有了这些基础数据你甚至可以做简单的质量趋势分析提前预判一批代理是否会大面积失效从而提前补充新的代理源。还有一件事值得单独说一说尽量不要在爬虫的关键路径里同步等待代理池返回代理。也就是说不要每次都“先拿代理、再发请求”这样的链路对代理池的可用性要求太高。更好的做法是提前在本地维护一个小的代理缓存队列客户端从缓存队列里取代理然后异步向代理池补充缓存。这样即使代理池临时不可用已经拿到的代理还能继续用一段时间。如果用Python实现这个缓存队列可以用queue.Queue配合后台线程补充核心代码非常简单import queue import threading import time proxy_cache queue.Queue(maxsize50) def refill_cache(): while True: if proxy_cache.qsize() 20: proxies fetch_from_proxy_pool(30) for p in proxies: try: proxy_cache.put(p, timeout1) except queue.Full: break time.sleep(5) threading.Thread(targetrefill_cache, daemonTrue).start()这个模式我用了很久实测下来能显著降低爬虫端因为代理池调度延迟而出现空闲等待的概率。写在最后的一些体会代理池和反反爬这个方向看起来是一个技术问题但实际上是一个系统工程问题。单纯通过加代理、换UA来解决封禁往往只能应付最低级的防护。真正要做的是把你爬虫的每一个环节都向真实用户靠拢——网络链路用代理池保障TLS指纹和浏览器指纹保持一致请求节奏和浏览行为符合直觉Cookie链路完整无破绽。这些点全部串在一起才算是一个合格的反反爬方案。我自己在实践过程中的最大体会是不要追求“一套方案打天下”不同目标网站的防护逻辑差异很大拿代理池去处理简单站点是大炮打蚊子拿全套指纹伪装去处理一个只校验频率的站点又显得多余。先分析目标网站的封禁特征再有针对性地组合代理池和反反爬策略这才是性价比最高的做法。希望这篇文章能帮你少走一些弯路。
