简介Python爬虫开发中频繁访问目标站容易导致IP被封合理使用代理IP是提升爬虫生存能力的有效手段。这份PDF资源面向有一定Python基础、希望突破反爬限制的爬虫开发者系统讲解了代理IP的获取、配置与实务要点。资源为单个PDF文档约79KB篇幅精炼适合按步骤查阅。内容不仅演示了Urllib中ProxyHandler与build_opener的代理设置方法也给出了Requests库通过proxies参数直接配置的示例还介绍了Selenium浏览器环境下指定代理服务器的写法同时讲解了如何对接本地代理池接口动态更换IP以及超时、连接异常等情况下的处理思路。文档还提醒了遵守robots.txt与爬取频率规范帮助开发者在提升抓取稳定性的同时规避风险。目前已有3516人学习过这份资源如果你正在被IP封禁问题困扰这份资料能提供清晰可直接落地的代码参考。1. 爬虫被限制之后代理IP才是能让你继续往下跑的那道闸门大多数爬虫工程师第一次接触代理IP并不是因为想去隐藏什么而是因为请求发着发着一觉睡醒返回码变成403、429甚至直接连接被重置。这个过程往往没有任何预兆白天还在正常抓取傍晚开始出现零星的超时深夜就会变成大规模的IP封禁。代理IP解决的本质问题是让爬虫的请求来源不会被目标服务器一击致命——你的本机IP有固定的地理属性和历史请求特征目标站点很容易通过频次、路径、Headers 的组合把它识别出来。而代理IP替换的是请求的出口地址相当于每次请求都以一个“陌生访客”的身份出现把本机身份隔离在目标站点的访问记录之外。这篇文章面向的是已经用 requests 或者 httpx 写过爬虫、但还没有系统处理过反爬措施的读者。可以用 requests 在五分钟内跑通一个最小代理请求也可以把它扩展成一个带代理池、轮换策略、淘汰机制的完整抓取方案。文章不会绕开细节代理IP有哪些形态、requests 里proxies的传参方式有什么坑、为什么代理“能用”和“好用”完全是两回事、以及并发场景下代理池该怎么设计。这些都是实际跑生产爬虫时会遇到的分岔路提前搞清楚后面省掉的不只是调试时间。2. 代理IP的两种形态以及 requests 里配置代理的核心机制2.1 代理IP的分类透明、匿名和高匿抓取时怎么选代理IP按照对目标服务器隐藏客户端真实IP的程度分为透明代理、普匿代理和高匿代理三个级别。透明代理会在请求头里带上Via字段服务器能从请求链路中反查到发起方IP普匿代理会隐藏本机IP但服务器仍然知道你用了代理高匿代理则完全不暴露“这是一个代理请求”的特征。爬虫场景里绝大多数情况下应该选高匿代理。目标站点的反爬系统如果识别出请求来自代理IP一样会触发验证码或封禁策略只有高匿代理能在这个圈子里存活得更久。另外一个维度是代理IP的来源形态一种是长期固定、几乎不变化的静态代理IP另一种是从代理服务商API动态获取、每次请求都可能更换IP的动态代理IP。动态代理适合目标站点对单IP频次非常敏感的抓取场景比如搜索结果页、价格页而静态代理适合登录态保持、会话关联的采集任务。后文会展开说明两者对应的代码写法差异。判断一个代理IP是否“高匿”无法靠代理服务商自述来判断可以自己验证通过代理发送一个请求到https://httpbin.org/ip观察返回的origin字段是否只包含代理IP地址以及响应头里是否出现Via、X-Forwarded-For之类的字段。没有这些附加头才说明代理在高匿性上没有明显破绽。2.2 requests 代理参数的本质不是“设置代理”而是“替换连接出口”requests 库中用代理的标准写法是构造一个proxies字典传入requests.get()或requests.post()。这个字典的 key 是协议名http或httpsvalue 是代理服务器的完整地址。一个最常见的代码写法如下import requests proxies { http: http://127.0.0.1:7890, https: http://127.0.0.1:7890, } resp requests.get( https://httpbin.org/ip, proxiesproxies, timeout10, ) print(resp.json())这里把两个协议都映射到同一个本地代理地址上是一个实践中的常见用法http://开头的目标页面走http配置项https://开头的目标页面走https配置项。但如果只希望 HTTPS 请求走代理可以只写https这个 keyHTTP 请求则直连本地网络。有一个容易忽略的点requests 遇到 HTTPS 目标时会先和代理服务器建立 CONNECT 隧道代理再与目标站点做 TLS 握手。所以当你抓取的是 HTTPS 站点proxies[https]这个配置是必须的否则请求会拿到连接错误。这段代码里timeout10既作用于连接代理的过程也作用于目标服务器返回响应的过程。假如代理服务器本身响应慢10秒内没建立连接requests 会抛出requests.exceptions.ConnectTimeout。这个参数必须显式设置它决定了代理出故障时脚本是快速失败还是卡死在那里不动。2.3 为什么 requests 的 Session 和 proxies 一起用才接近生产环境单次请求直接传proxies没问题但是同一个目标站点的采集通常需要连续发起几十个、上百个请求。用requests.Session()可以把proxies挂在 session 对象上确保所有经过该 session 的请求都自动使用代理同时 session 还承担了连接复用的职责——它内部维护了一个 urllib3 的连接池在代理不变的情况下TCP 连接可以复用不需要每次请求都重新握手一次import requests session requests.Session() session.proxies.update({ http: http://127.0.0.1:8000, https: http://127.0.0.1:8000, }) resp session.get(https://httpbin.org/ip, timeout10) print(resp.status_code, resp.text)session 这个对象解决的不只是代理配置的重复劳动更重要的是它把 TCP 连接、Cookie 和默认请求头都收拢到一个上下文里。这在高频采集中会直接反映为请求的成功率与稳定性的提升连接不用反复重建服务器端的限流判定也会把你归为“同一个用户会话”而不是“不同来源的陌生人”。需要注意的是session.proxies.update()之后如果某一次请求希望临时绕过代理不能简单传一个空字典而是需要把该次请求的proxies参数设为{http: None, https: None}。requests 的高优先级逻辑是单次请求传入的proxies会完全覆盖 session 里的设置而不是做 key 级别的合并。3. 代理IP获取与动态轮换把“一个代理请求”变成“一套能跑的代理机制”3.1 代理IP格式与渠道免费的代理IP列表为什么总是踩坑代理IP的几种常见渠道对比如下渠道类型典型获取方式可用率稳定性获取成本免费代理网站从网页表格里直接抓取低普遍不到20%差存活时间以分钟计几乎为零自建代理池爬取免费代理后自己验证存活经过验证后可达40%左右仍然受上游免费源影响需要开发与维护成本企业级代理API通过HTTP接口批量提取高通常90%以上好有短效和长效之分按量计费免费代理网站列表手动也能填写IP:端口但实际跑起来会发现一个现象验证的瞬间是活的真正发请求时却超时或者同一批代理里只有一两个能用其余全是“隧道可以连通但目标是错的”。原因在于免费代理里大量混杂着低质量匿名度的透明代理和已被封禁的失效IP。把它们作为生产采集的代理基础设施效果不如不加代理——因为代理只在反爬层面有用而不是用来加速的。3.1.1 用 requests 从代理API拉取动态代理IP很多代理服务商提供了动态代理IP的提取接口返回的是文本格式的IP:端口列表。用一个简单的函数把代理从接口拉回来做一遍存活验证再放进队列里供后续请求使用import requests import re def fetch_proxy_from_api(api_url: str) - list: resp requests.get(api_url, timeout5) text resp.text.strip() # 典型的返回格式: 120.24.65.1:8080\n120.24.65.2:8080 proxy_list re.findall(r\d\.\d\.\d\.\d:\d, text) return proxy_list proxies_from_api fetch_proxy_from_api(https://your_proxy_api.com/get?num20) print(proxies_from_api)这种接口拿到的代理会带有时效参数例如“5分钟有效”或“会话保持”有效期内重复使用同一个IP不会变时间到了或请求次数超了就会被代理服务商回收。拿到 IP 列表后不能直接塞进 requests因为没有验证过的代理会让日志里充满了连接错误调试成本反而更高。3.2 代理存活验证最小可用验证函数与判定标准验证代理是否可用用 httpbin 或目标站点都行。目标站点更接近真实网络路径但缺点是验证请求也会被计数、消耗抓取配额。通用的做法是向一个稳定、无强反爬的检测站发请求比如https://httpbin.org/ip验证通过后再投入实战import requests from concurrent.futures import ThreadPoolExecutor def validate_proxy(proxy: str) - bool: test_url https://httpbin.org/ip proxies {http: fhttp://{proxy}, https: fhttp://{proxy}} try: resp requests.get(test_url, proxiesproxies, timeout5) if resp.status_code 200: # 响应里的 origin 应等于代理IP而不是本机IP return proxy.split(:)[0] resp.json().get(origin, ) except Exception: pass return False all_proxies [120.24.65.1:8080, 120.24.65.2:8080] with ThreadPoolExecutor(max_workers10) as executor: results list(executor.map(validate_proxy, all_proxies)) valid_proxies [p for p, ok in zip(all_proxies, results) if ok]validate_proxy里做了两层校验一是网络层能不能连通、有没有正常返回200二是响应里的origin字段是否等于代理IP这层判断能把透明代理和端口转发类异常筛掉。用线程池并发验证是必要的因为每个代理验证要等待网络往返串行验证100个代理可能耗时好几分钟并发10个线程能把时间压缩到可接受的范围。验证结果要动态维护。一个代理刚验证通过不代表30秒后仍然有效。代理池的维护程序一般会定期比如每30秒到1分钟抽样回流验证一次把失效的剔除、把新拉到的加进来。验证和抓取需要解耦抓取进程从队列里获取代理验证进程从队列里拿走代理再放回验证结果。后文的进阶章节会给出并发分配的具体代码。3.3 动态换IP的爬虫循环把换代理落实为每个请求独立选取在抓取循环里每次请求前从代理列表里随机选一个作为出口是最简单的动态换IP写法import random import requests proxy_pool [ 120.24.65.1:8080, 120.24.65.2:8080, # 更多已验证可用的代理 ] def fetch_with_random_proxy(url: str): proxy random.choice(proxy_pool) proxies { http: fhttp://{proxy}, https: fhttp://{proxy}, } try: resp requests.get(url, proxiesproxies, timeout10) resp.raise_for_status() return resp.text except requests.exceptions.RequestException: # 当前代理失败从池中移除 proxy_pool.remove(proxy) raise html fetch_with_random_proxy(https://example.com/page/1)这段代码的关键在random.choice上每次请求独立挑选代理保证同一个目标站点的连续请求来自不同IP而不是一个代理反复被用到触发频率限制。异常处理里会把失败的代理从池子里剔除避免下一次再被选中。如果池子被清空的频率高于新代理进入的速度抓取就会大面积失败这时需要结合3.2节的验证逻辑做自动补充。动态换IP的粒度需要根据目标站点的反爬策略来调整如果站点限制的是“同一IP每秒请求数”那么每次请求换IP即可如果限制的是“同一IP会话内的行为特征”则一次会话周期保持同一个代理、周期结束后换新的——这个差异是初学和进阶之间非常显著的一道分水岭。4. 代理IP在并发爬虫中的正确组织方式队列、Session 与轮换策略4.1 为什么 requests.Session 不能直接用在多线程代理爬虫里把单个 requests.Session 放在多线程环境下共享代理IP会全部串到同一条连接上。看起来好像没问题但实际处理的时候会踩中一个痛点Session 的连接池是按 (scheme, host, port) 缓存的代理变了连接未必跟着变——requests 对同一个代理域名的连接会被复用新的代理设置要等连接池里的旧连接失效才生效。这说明什么呢说明如果要用 Session 做代理切换绝不能在多线程里共享同一个 Session 实例而应该让每个线程持有自己的 Session或者每次更换代理后显式调用session.close()再重建。一个更直观的问题Session 里保存的 Cookie 是跨请求共享的。如果本次请求用了代理A、下次请求用了代理B而两个请求都共享着同一份 Cookie目标站点很容易发现“同一个会话来自两个不同IP”反爬的直接反应就是让这个会话失效。所以Session 和代理绑定必须是一对一的关系。每拿到一个代理IP就创建一个新 Session这个 Session 只在这个代理存活期间使用代理失效Session 一并抛弃。没有代理切换时Session 帮助复用连接代理切换时Session 反而会成为串身份的来源。4.2 基于 queue 的代理分配器实现一个不重复、不串味的代理队列在一个稍微完整的抓取框架里代理和请求之间往往由一个队列来调度。这里的队列有两种设计思路一种是“代理池共享每次随机取”另一种是“分配制代理绑线程”。分配制更适合登录态、搜索翻页这一类对会话连续性有要求的场景。下面这个最小实现展示了一个带代理解绑的请求分配器import queue import requests import threading class ProxySessionManager: def __init__(self, proxy_list: list): self._proxy_queue queue.Queue() for proxy in proxy_list: self._proxy_queue.put(proxy) def get_session(self) - (requests.Session, str): # 从队列中取一个代理并绑定到一个新Session proxy self._proxy_queue.get(timeout5) session requests.Session() session.proxies.update({ http: fhttp://{proxy}, https: fhttp://{proxy}, }) return session, proxy def release_session(self, session: requests.Session, proxy: str): session.close() # 代理用完了放回队列允许下个请求继续使用 self._proxy_queue.put(proxy) manager ProxySessionManager([120.24.65.1:8080, 120.24.65.2:8080]) session, proxy manager.get_session() try: resp session.get(https://example.com, timeout10) print(resp.status_code) finally: manager.release_session(session, proxy)队列的作用是保证同一时刻一个代理最多只被一个线程占用避免两种局面一是多个线程同时使用同一个代理IP请求目标站点导致单IP的请求频次瞬间飙高二是代理被并发用完出现资源竞争日志里全是代理连不上的报错。release_session把代理放回队列是一个“用完即还”的模式防止代理池越用越少。4.3 针对目标站点反爬的轮换策略按错误码、按频次、按时间换IP不是一个“随机切换”的动作就够了还需要有策略性的触发条件。判断一个代理是否需要切换通常参考以下三个维度。第一是按状态码切换。403、429 这一类响应说明当前代理IP已经被目标站点拒绝即使继续用下去也大概率什么都拿不到。第二是按异常类型切换。ConnectionError、ProxyError、ConnectTimeout这类异常说明代理解析出错或代理服务器本身已经失联需要立刻切换。第三是按时间切换。有些代理服务商出售的IP是“寿命型”的比如5分钟有效到期后无论当前请求是否完结都要主动换掉。在实际代码中这三类判断可以收敛成should_switch_proxy(exception, response)这样一个策略函数import requests def should_switch_proxy(exception: Exception, response: requests.Response None) - bool: if exception is not None: # 代理服务器本身不可达切换 return isinstance(exception, ( requests.exceptions.ProxyError, requests.exceptions.ConnectTimeout, requests.exceptions.ConnectionError, )) if response is not None: # HTTP层明确拒绝切换 if response.status_code in (403, 429): return True # 页面内容里出现验证码或封禁提示切换 if captcha in response.text.lower() or blocked in response.text.lower(): return True return False这里需要理解一个关键点换IP不是代替重试而是让重试变得有意义。同一个代理IP被目标站点拒绝后如果继续重试同一请求、还是同一个代理结果必然是再次失败。只有“换IP 重试”的组合才可能跳过反爬的封禁状态。策略函数把请求异常、响应状态码、页面内容三者统一到一个出口让调用方只需要在获取内容失败时执行一段“取代理 → 重发 → 判断失败 → 换代理”的循环即可。4.4 带 IP 轮换和重试上限的完整抓取函数把前面的队列、Session绑定、策略判断合在一起就是一个可直接用于生产的抓取函数def fetch_with_proxy_pool(url: str, manager: ProxySessionManager, max_retry: int 3): last_exception None for attempt in range(max_retry): session, proxy manager.get_session() try: resp session.get(url, timeout10) if should_switch_proxy(None, resp): raise requests.exceptions.HTTPError( fproxy {proxy} blocked with status {resp.status_code} ) return resp.text except Exception as exc: last_exception exc # 基于策略决定换代理继续重试 finally: manager.release_session(session, proxy) raise last_exception重试上限max_retry的作用是把错误控制在可控范围内目标是追求“最终能拿到数据”而不是无限重试直到把整个代理池消耗干净。每个代理在finally里都会被归还即使请求失败也不会让代理从池中永久丢失。这种设计的代价是边界情况需要留一个出口如果这个代理池里全是失效IP上面的函数会重试到max_retry次后抛出最后一次的异常这个异常需要被上层捕获并记录日志而不是让主流程被打断。5. 代理池的健康度评分与淘汰机制让采集任务从“能用”到“稳定”代理池光有“放入、取出、验证”还不够要想长期稳定跑采集必须给池里的每个代理做健康度评分。这个评分机制很像一个简易版负载均衡每个代理都有一个分数请求成功后加分请求失败后扣分分数掉到阈值以下就移出池子。爬虫开始时池子里是几十个代理跑几小时后存活的代理越来越稳定采集的成功率也随之上升。实现上可以给每个代理维护一个状态对象class ProxyScore: def __init__(self, proxy: str): self.proxy proxy self.success_count 0 self.fail_count 0 self.score 100 def record_success(self): self.success_count 1 self.score min(100, self.score 1) def record_fail(self): self.fail_count 1 self.score - 10 property def is_alive(self) - bool: return self.score 20评分逻辑里失败扣10分、成功加1分不是对称的。原因是失效代理的破坏性远大于正常代理的贡献一个失效代理被选中一次就会导致当前请求失败并触发重试循环一个正常代理多服务几次的收益远远抵不过一个坏代理带来的失败成本。is_alive的判断阈值设为20分意味着连续失败8次左右就会被淘汰出池。这个数字并不是固定的如果目标站点反爬较强可以适当提高失败扣分如果代理质量整体偏低则可以把淘汰阈值调低让代理有更多机会。健康度评分与本文第3节的验证逻辑各司其职验证逻辑是代理进入池子之前的“初筛”健康度评分是代理在池子内部持续使用过程中的“动态评估”。把两者结合才能形成一个完整的代理池管理系统。脚本启动时拉取一批代理验证后放入池中每完成一个请求按结果对代理做评分分数见底即移除池子空了再回到API拉新的一批。这个循环不需要额外引入框架requests和queue已经足够实现更大的规模才需要考虑引入 Redis 之类的共享存储做跨进程代理池那个话题已经超出本文标题的范畴。代理IP在爬虫中的价值不在于它的数量有多少也不在于IP是不是“动态”的而在于围绕它建立的这套管理逻辑用验证保证质量、用队列避免冲突、用评分实现自愈。把这些机制缝进 requests 的请求流程里代理IP才能真正从“偶尔能用的工具”变成“持续可用的基础设施”。本文还有配套的精品资源点击获取 爬虫代理IP实战：requests配置、动态轮换与代理池设计
简介Python爬虫开发中频繁访问目标站容易导致IP被封合理使用代理IP是提升爬虫生存能力的有效手段。这份PDF资源面向有一定Python基础、希望突破反爬限制的爬虫开发者系统讲解了代理IP的获取、配置与实务要点。资源为单个PDF文档约79KB篇幅精炼适合按步骤查阅。内容不仅演示了Urllib中ProxyHandler与build_opener的代理设置方法也给出了Requests库通过proxies参数直接配置的示例还介绍了Selenium浏览器环境下指定代理服务器的写法同时讲解了如何对接本地代理池接口动态更换IP以及超时、连接异常等情况下的处理思路。文档还提醒了遵守robots.txt与爬取频率规范帮助开发者在提升抓取稳定性的同时规避风险。目前已有3516人学习过这份资源如果你正在被IP封禁问题困扰这份资料能提供清晰可直接落地的代码参考。1. 爬虫被限制之后代理IP才是能让你继续往下跑的那道闸门大多数爬虫工程师第一次接触代理IP并不是因为想去隐藏什么而是因为请求发着发着一觉睡醒返回码变成403、429甚至直接连接被重置。这个过程往往没有任何预兆白天还在正常抓取傍晚开始出现零星的超时深夜就会变成大规模的IP封禁。代理IP解决的本质问题是让爬虫的请求来源不会被目标服务器一击致命——你的本机IP有固定的地理属性和历史请求特征目标站点很容易通过频次、路径、Headers 的组合把它识别出来。而代理IP替换的是请求的出口地址相当于每次请求都以一个“陌生访客”的身份出现把本机身份隔离在目标站点的访问记录之外。这篇文章面向的是已经用 requests 或者 httpx 写过爬虫、但还没有系统处理过反爬措施的读者。可以用 requests 在五分钟内跑通一个最小代理请求也可以把它扩展成一个带代理池、轮换策略、淘汰机制的完整抓取方案。文章不会绕开细节代理IP有哪些形态、requests 里proxies的传参方式有什么坑、为什么代理“能用”和“好用”完全是两回事、以及并发场景下代理池该怎么设计。这些都是实际跑生产爬虫时会遇到的分岔路提前搞清楚后面省掉的不只是调试时间。2. 代理IP的两种形态以及 requests 里配置代理的核心机制2.1 代理IP的分类透明、匿名和高匿抓取时怎么选代理IP按照对目标服务器隐藏客户端真实IP的程度分为透明代理、普匿代理和高匿代理三个级别。透明代理会在请求头里带上Via字段服务器能从请求链路中反查到发起方IP普匿代理会隐藏本机IP但服务器仍然知道你用了代理高匿代理则完全不暴露“这是一个代理请求”的特征。爬虫场景里绝大多数情况下应该选高匿代理。目标站点的反爬系统如果识别出请求来自代理IP一样会触发验证码或封禁策略只有高匿代理能在这个圈子里存活得更久。另外一个维度是代理IP的来源形态一种是长期固定、几乎不变化的静态代理IP另一种是从代理服务商API动态获取、每次请求都可能更换IP的动态代理IP。动态代理适合目标站点对单IP频次非常敏感的抓取场景比如搜索结果页、价格页而静态代理适合登录态保持、会话关联的采集任务。后文会展开说明两者对应的代码写法差异。判断一个代理IP是否“高匿”无法靠代理服务商自述来判断可以自己验证通过代理发送一个请求到https://httpbin.org/ip观察返回的origin字段是否只包含代理IP地址以及响应头里是否出现Via、X-Forwarded-For之类的字段。没有这些附加头才说明代理在高匿性上没有明显破绽。2.2 requests 代理参数的本质不是“设置代理”而是“替换连接出口”requests 库中用代理的标准写法是构造一个proxies字典传入requests.get()或requests.post()。这个字典的 key 是协议名http或httpsvalue 是代理服务器的完整地址。一个最常见的代码写法如下import requests proxies { http: http://127.0.0.1:7890, https: http://127.0.0.1:7890, } resp requests.get( https://httpbin.org/ip, proxiesproxies, timeout10, ) print(resp.json())这里把两个协议都映射到同一个本地代理地址上是一个实践中的常见用法http://开头的目标页面走http配置项https://开头的目标页面走https配置项。但如果只希望 HTTPS 请求走代理可以只写https这个 keyHTTP 请求则直连本地网络。有一个容易忽略的点requests 遇到 HTTPS 目标时会先和代理服务器建立 CONNECT 隧道代理再与目标站点做 TLS 握手。所以当你抓取的是 HTTPS 站点proxies[https]这个配置是必须的否则请求会拿到连接错误。这段代码里timeout10既作用于连接代理的过程也作用于目标服务器返回响应的过程。假如代理服务器本身响应慢10秒内没建立连接requests 会抛出requests.exceptions.ConnectTimeout。这个参数必须显式设置它决定了代理出故障时脚本是快速失败还是卡死在那里不动。2.3 为什么 requests 的 Session 和 proxies 一起用才接近生产环境单次请求直接传proxies没问题但是同一个目标站点的采集通常需要连续发起几十个、上百个请求。用requests.Session()可以把proxies挂在 session 对象上确保所有经过该 session 的请求都自动使用代理同时 session 还承担了连接复用的职责——它内部维护了一个 urllib3 的连接池在代理不变的情况下TCP 连接可以复用不需要每次请求都重新握手一次import requests session requests.Session() session.proxies.update({ http: http://127.0.0.1:8000, https: http://127.0.0.1:8000, }) resp session.get(https://httpbin.org/ip, timeout10) print(resp.status_code, resp.text)session 这个对象解决的不只是代理配置的重复劳动更重要的是它把 TCP 连接、Cookie 和默认请求头都收拢到一个上下文里。这在高频采集中会直接反映为请求的成功率与稳定性的提升连接不用反复重建服务器端的限流判定也会把你归为“同一个用户会话”而不是“不同来源的陌生人”。需要注意的是session.proxies.update()之后如果某一次请求希望临时绕过代理不能简单传一个空字典而是需要把该次请求的proxies参数设为{http: None, https: None}。requests 的高优先级逻辑是单次请求传入的proxies会完全覆盖 session 里的设置而不是做 key 级别的合并。3. 代理IP获取与动态轮换把“一个代理请求”变成“一套能跑的代理机制”3.1 代理IP格式与渠道免费的代理IP列表为什么总是踩坑代理IP的几种常见渠道对比如下渠道类型典型获取方式可用率稳定性获取成本免费代理网站从网页表格里直接抓取低普遍不到20%差存活时间以分钟计几乎为零自建代理池爬取免费代理后自己验证存活经过验证后可达40%左右仍然受上游免费源影响需要开发与维护成本企业级代理API通过HTTP接口批量提取高通常90%以上好有短效和长效之分按量计费免费代理网站列表手动也能填写IP:端口但实际跑起来会发现一个现象验证的瞬间是活的真正发请求时却超时或者同一批代理里只有一两个能用其余全是“隧道可以连通但目标是错的”。原因在于免费代理里大量混杂着低质量匿名度的透明代理和已被封禁的失效IP。把它们作为生产采集的代理基础设施效果不如不加代理——因为代理只在反爬层面有用而不是用来加速的。3.1.1 用 requests 从代理API拉取动态代理IP很多代理服务商提供了动态代理IP的提取接口返回的是文本格式的IP:端口列表。用一个简单的函数把代理从接口拉回来做一遍存活验证再放进队列里供后续请求使用import requests import re def fetch_proxy_from_api(api_url: str) - list: resp requests.get(api_url, timeout5) text resp.text.strip() # 典型的返回格式: 120.24.65.1:8080\n120.24.65.2:8080 proxy_list re.findall(r\d\.\d\.\d\.\d:\d, text) return proxy_list proxies_from_api fetch_proxy_from_api(https://your_proxy_api.com/get?num20) print(proxies_from_api)这种接口拿到的代理会带有时效参数例如“5分钟有效”或“会话保持”有效期内重复使用同一个IP不会变时间到了或请求次数超了就会被代理服务商回收。拿到 IP 列表后不能直接塞进 requests因为没有验证过的代理会让日志里充满了连接错误调试成本反而更高。3.2 代理存活验证最小可用验证函数与判定标准验证代理是否可用用 httpbin 或目标站点都行。目标站点更接近真实网络路径但缺点是验证请求也会被计数、消耗抓取配额。通用的做法是向一个稳定、无强反爬的检测站发请求比如https://httpbin.org/ip验证通过后再投入实战import requests from concurrent.futures import ThreadPoolExecutor def validate_proxy(proxy: str) - bool: test_url https://httpbin.org/ip proxies {http: fhttp://{proxy}, https: fhttp://{proxy}} try: resp requests.get(test_url, proxiesproxies, timeout5) if resp.status_code 200: # 响应里的 origin 应等于代理IP而不是本机IP return proxy.split(:)[0] resp.json().get(origin, ) except Exception: pass return False all_proxies [120.24.65.1:8080, 120.24.65.2:8080] with ThreadPoolExecutor(max_workers10) as executor: results list(executor.map(validate_proxy, all_proxies)) valid_proxies [p for p, ok in zip(all_proxies, results) if ok]validate_proxy里做了两层校验一是网络层能不能连通、有没有正常返回200二是响应里的origin字段是否等于代理IP这层判断能把透明代理和端口转发类异常筛掉。用线程池并发验证是必要的因为每个代理验证要等待网络往返串行验证100个代理可能耗时好几分钟并发10个线程能把时间压缩到可接受的范围。验证结果要动态维护。一个代理刚验证通过不代表30秒后仍然有效。代理池的维护程序一般会定期比如每30秒到1分钟抽样回流验证一次把失效的剔除、把新拉到的加进来。验证和抓取需要解耦抓取进程从队列里获取代理验证进程从队列里拿走代理再放回验证结果。后文的进阶章节会给出并发分配的具体代码。3.3 动态换IP的爬虫循环把换代理落实为每个请求独立选取在抓取循环里每次请求前从代理列表里随机选一个作为出口是最简单的动态换IP写法import random import requests proxy_pool [ 120.24.65.1:8080, 120.24.65.2:8080, # 更多已验证可用的代理 ] def fetch_with_random_proxy(url: str): proxy random.choice(proxy_pool) proxies { http: fhttp://{proxy}, https: fhttp://{proxy}, } try: resp requests.get(url, proxiesproxies, timeout10) resp.raise_for_status() return resp.text except requests.exceptions.RequestException: # 当前代理失败从池中移除 proxy_pool.remove(proxy) raise html fetch_with_random_proxy(https://example.com/page/1)这段代码的关键在random.choice上每次请求独立挑选代理保证同一个目标站点的连续请求来自不同IP而不是一个代理反复被用到触发频率限制。异常处理里会把失败的代理从池子里剔除避免下一次再被选中。如果池子被清空的频率高于新代理进入的速度抓取就会大面积失败这时需要结合3.2节的验证逻辑做自动补充。动态换IP的粒度需要根据目标站点的反爬策略来调整如果站点限制的是“同一IP每秒请求数”那么每次请求换IP即可如果限制的是“同一IP会话内的行为特征”则一次会话周期保持同一个代理、周期结束后换新的——这个差异是初学和进阶之间非常显著的一道分水岭。4. 代理IP在并发爬虫中的正确组织方式队列、Session 与轮换策略4.1 为什么 requests.Session 不能直接用在多线程代理爬虫里把单个 requests.Session 放在多线程环境下共享代理IP会全部串到同一条连接上。看起来好像没问题但实际处理的时候会踩中一个痛点Session 的连接池是按 (scheme, host, port) 缓存的代理变了连接未必跟着变——requests 对同一个代理域名的连接会被复用新的代理设置要等连接池里的旧连接失效才生效。这说明什么呢说明如果要用 Session 做代理切换绝不能在多线程里共享同一个 Session 实例而应该让每个线程持有自己的 Session或者每次更换代理后显式调用session.close()再重建。一个更直观的问题Session 里保存的 Cookie 是跨请求共享的。如果本次请求用了代理A、下次请求用了代理B而两个请求都共享着同一份 Cookie目标站点很容易发现“同一个会话来自两个不同IP”反爬的直接反应就是让这个会话失效。所以Session 和代理绑定必须是一对一的关系。每拿到一个代理IP就创建一个新 Session这个 Session 只在这个代理存活期间使用代理失效Session 一并抛弃。没有代理切换时Session 帮助复用连接代理切换时Session 反而会成为串身份的来源。4.2 基于 queue 的代理分配器实现一个不重复、不串味的代理队列在一个稍微完整的抓取框架里代理和请求之间往往由一个队列来调度。这里的队列有两种设计思路一种是“代理池共享每次随机取”另一种是“分配制代理绑线程”。分配制更适合登录态、搜索翻页这一类对会话连续性有要求的场景。下面这个最小实现展示了一个带代理解绑的请求分配器import queue import requests import threading class ProxySessionManager: def __init__(self, proxy_list: list): self._proxy_queue queue.Queue() for proxy in proxy_list: self._proxy_queue.put(proxy) def get_session(self) - (requests.Session, str): # 从队列中取一个代理并绑定到一个新Session proxy self._proxy_queue.get(timeout5) session requests.Session() session.proxies.update({ http: fhttp://{proxy}, https: fhttp://{proxy}, }) return session, proxy def release_session(self, session: requests.Session, proxy: str): session.close() # 代理用完了放回队列允许下个请求继续使用 self._proxy_queue.put(proxy) manager ProxySessionManager([120.24.65.1:8080, 120.24.65.2:8080]) session, proxy manager.get_session() try: resp session.get(https://example.com, timeout10) print(resp.status_code) finally: manager.release_session(session, proxy)队列的作用是保证同一时刻一个代理最多只被一个线程占用避免两种局面一是多个线程同时使用同一个代理IP请求目标站点导致单IP的请求频次瞬间飙高二是代理被并发用完出现资源竞争日志里全是代理连不上的报错。release_session把代理放回队列是一个“用完即还”的模式防止代理池越用越少。4.3 针对目标站点反爬的轮换策略按错误码、按频次、按时间换IP不是一个“随机切换”的动作就够了还需要有策略性的触发条件。判断一个代理是否需要切换通常参考以下三个维度。第一是按状态码切换。403、429 这一类响应说明当前代理IP已经被目标站点拒绝即使继续用下去也大概率什么都拿不到。第二是按异常类型切换。ConnectionError、ProxyError、ConnectTimeout这类异常说明代理解析出错或代理服务器本身已经失联需要立刻切换。第三是按时间切换。有些代理服务商出售的IP是“寿命型”的比如5分钟有效到期后无论当前请求是否完结都要主动换掉。在实际代码中这三类判断可以收敛成should_switch_proxy(exception, response)这样一个策略函数import requests def should_switch_proxy(exception: Exception, response: requests.Response None) - bool: if exception is not None: # 代理服务器本身不可达切换 return isinstance(exception, ( requests.exceptions.ProxyError, requests.exceptions.ConnectTimeout, requests.exceptions.ConnectionError, )) if response is not None: # HTTP层明确拒绝切换 if response.status_code in (403, 429): return True # 页面内容里出现验证码或封禁提示切换 if captcha in response.text.lower() or blocked in response.text.lower(): return True return False这里需要理解一个关键点换IP不是代替重试而是让重试变得有意义。同一个代理IP被目标站点拒绝后如果继续重试同一请求、还是同一个代理结果必然是再次失败。只有“换IP 重试”的组合才可能跳过反爬的封禁状态。策略函数把请求异常、响应状态码、页面内容三者统一到一个出口让调用方只需要在获取内容失败时执行一段“取代理 → 重发 → 判断失败 → 换代理”的循环即可。4.4 带 IP 轮换和重试上限的完整抓取函数把前面的队列、Session绑定、策略判断合在一起就是一个可直接用于生产的抓取函数def fetch_with_proxy_pool(url: str, manager: ProxySessionManager, max_retry: int 3): last_exception None for attempt in range(max_retry): session, proxy manager.get_session() try: resp session.get(url, timeout10) if should_switch_proxy(None, resp): raise requests.exceptions.HTTPError( fproxy {proxy} blocked with status {resp.status_code} ) return resp.text except Exception as exc: last_exception exc # 基于策略决定换代理继续重试 finally: manager.release_session(session, proxy) raise last_exception重试上限max_retry的作用是把错误控制在可控范围内目标是追求“最终能拿到数据”而不是无限重试直到把整个代理池消耗干净。每个代理在finally里都会被归还即使请求失败也不会让代理从池中永久丢失。这种设计的代价是边界情况需要留一个出口如果这个代理池里全是失效IP上面的函数会重试到max_retry次后抛出最后一次的异常这个异常需要被上层捕获并记录日志而不是让主流程被打断。5. 代理池的健康度评分与淘汰机制让采集任务从“能用”到“稳定”代理池光有“放入、取出、验证”还不够要想长期稳定跑采集必须给池里的每个代理做健康度评分。这个评分机制很像一个简易版负载均衡每个代理都有一个分数请求成功后加分请求失败后扣分分数掉到阈值以下就移出池子。爬虫开始时池子里是几十个代理跑几小时后存活的代理越来越稳定采集的成功率也随之上升。实现上可以给每个代理维护一个状态对象class ProxyScore: def __init__(self, proxy: str): self.proxy proxy self.success_count 0 self.fail_count 0 self.score 100 def record_success(self): self.success_count 1 self.score min(100, self.score 1) def record_fail(self): self.fail_count 1 self.score - 10 property def is_alive(self) - bool: return self.score 20评分逻辑里失败扣10分、成功加1分不是对称的。原因是失效代理的破坏性远大于正常代理的贡献一个失效代理被选中一次就会导致当前请求失败并触发重试循环一个正常代理多服务几次的收益远远抵不过一个坏代理带来的失败成本。is_alive的判断阈值设为20分意味着连续失败8次左右就会被淘汰出池。这个数字并不是固定的如果目标站点反爬较强可以适当提高失败扣分如果代理质量整体偏低则可以把淘汰阈值调低让代理有更多机会。健康度评分与本文第3节的验证逻辑各司其职验证逻辑是代理进入池子之前的“初筛”健康度评分是代理在池子内部持续使用过程中的“动态评估”。把两者结合才能形成一个完整的代理池管理系统。脚本启动时拉取一批代理验证后放入池中每完成一个请求按结果对代理做评分分数见底即移除池子空了再回到API拉新的一批。这个循环不需要额外引入框架requests和queue已经足够实现更大的规模才需要考虑引入 Redis 之类的共享存储做跨进程代理池那个话题已经超出本文标题的范畴。代理IP在爬虫中的价值不在于它的数量有多少也不在于IP是不是“动态”的而在于围绕它建立的这套管理逻辑用验证保证质量、用队列避免冲突、用评分实现自愈。把这些机制缝进 requests 的请求流程里代理IP才能真正从“偶尔能用的工具”变成“持续可用的基础设施”。本文还有配套的精品资源点击获取