★ FEATURED ARTICLE 1. 免费代理池这件事到底值不值得自己动手做数据采集的朋友大概率都遇到过这样的场景目标站点请求频率一高IP 就被限流甚至封禁脚本跑着跑着就返回 403 或者验证码页面。这时候最直接的解法就是换 IP而免费代理池因为零成本成了很多人第一个想到的方案。我这次要聊的就是围绕公开代理列表站点做采集、清洗、验证最终搭出一个能用的国内高匿代理池的完整过程。先把话说在前头免费代理的可用率普遍很低公开列表里能直接拿来用的往往不到百分之几而且存活时间短、速度参差不齐。所以这套东西的定位不是生产级稳定方案而是低成本练手 应急补充 理解代理池运作原理的实践项目。如果你只是想快速拿到几个能用的 IP 跑个小任务或者想搞明白代理采集、验证、调度这一整套链路是怎么串起来的那这篇内容会非常对路。涉及的技术栈主要是 Python 的 requests、BeautifulSoup、多线程/异步验证以及一个简单的可用性打分机制。我踩过的坑基本都集中在采集容易、验证难、维护更难这三段上下面会把每一段的思路、代码和避坑经验都摊开讲。需要说明的是文中所有站点、接口、字段都以通用描述为主具体实现你可以替换成任意同类公开列表源逻辑是通用的。2. 整体方案设计与核心思路拆解2.1 为什么选采集 验证 打分三段式代理池的核心矛盾在于来源不可靠但你又需要相对可靠的出口。所以任何代理池系统本质上都在做三件事——获取候选、验证质量、按质量调度。我把整个流程拆成三段采集层从公开列表页抓取 IP、端口、匿名级别、协议类型等原始信息落库。验证层对每个候选代理发起真实请求判断它是否可用、是否真的高匿、响应速度如何。调度层给每个代理打分按分数排序对外提供取一个可用代理的接口。这个拆法的好处是各层解耦。采集挂了不影响验证验证策略改了不用动采集代码调度层可以随时换算法。很多人一上来就想搞个大而全的框架结果调试成本极高反而不如这种土办法跑得稳。2.2 匿名级别为什么必须验证不能只信列表标注公开列表页通常会标注高匿匿名透明三类但这个标注极不可信。原因很简单列表站自己也不一定验证过很多是爬来的二手数据标注早就过期了。判断匿名级别的原理其实很清晰靠的是看目标服务器能拿到多少你的真实信息。核心看两个请求头REMOTE_ADDR服务器看到的直接连接 IP。如果这个等于你的真实 IP说明代理根本没起作用透明代理会转发真实 IP。HTTP_VIA/HTTP_X_FORWARDED_FOR代理转发时附加的头部。高匿代理会把这两个头都清掉或伪造让服务器完全看不出你用了代理。所以验证逻辑就是找一个能回显请求头的接口通过代理访问它检查返回内容里有没有暴露你的真实 IP 或代理痕迹。只有REMOTE_ADDR是代理 IP、且没有VIA、X_FORWARDED_FOR泄露真实 IP 的才算真正的高匿。2.3 免费源的选择与取舍免费代理来源大致分几类公开列表站、GitHub 上的开源代理池项目、某些论坛的分享帖。我这次主要针对列表站做采集因为结构相对规整、更新频率尚可。选源时我关注三点页面结构是否稳定如果 DOM 结构天天变采集脚本就得天天改维护成本太高。是否分页且有总量分页能控制采集深度总量能估算候选规模。是否区分协议和匿名级别有分类的话采集时可以只取高匿 HTTP/HTTPS 的部分减少后续验证压力。提示不要一次性把某个站点的所有分页全爬完既给对方压力也容易触发封禁。控制并发、加延时是长期可用的前提。3. 采集层实现从列表页到结构化数据3.1 页面结构分析与字段提取假设列表页是一个表格每行代表一个代理列大致包含IP、端口、匿名度、类型、位置、响应时间、最后验证时间。用 requests 拿到 HTML 后用 BeautifulSoup 定位表格行即可。关键字段的提取逻辑IP 和端口通常在固定的td索引位置直接按位置取最稳比按 class 名取更抗改版。匿名度文本匹配高匿关键字。类型匹配HTTP或HTTPS。响应时间有些站会给有些没有没有的话后续自己测。我一般会先写个小脚本把某一页的td数量和内容打印出来确认列顺序后再写正式解析避免瞎猜索引。3.2 分页采集与去重落库分页采集的核心是构造 URL 规律。常见形式是?page1、/1.html之类。我会先探测总页数通常在分页控件里然后循环请求。去重我用的是内存 set 落库唯一索引双保险。内存 set 防止同一次运行内重复请求数据库唯一索引防止多次运行间重复。存储用 SQLite 就够了字段设计如下字段类型说明ipTEXT代理 IPportINTEGER端口anonymityTEXT匿名级别protocolTEXTHTTP/HTTPSsourceTEXT来源标识scoreINTEGER可用性评分默认 0last_checkTEXT最后验证时间statusINTEGER0 未验证 / 1 可用 / 2 失效score字段是调度层的核心后面会讲怎么算。3.3 请求头与反爬的基本应对采集列表页本身也可能被反爬。基础应对就三招带完整浏览器请求头User-Agent、Accept、Accept-Language 都补上别用默认的 python-requests。控制频率每请求一页 sleep 一到两秒别贪快。失败重试用 requests 的 Retry 适配器对 5xx 和超时做有限次重试。import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry session requests.Session() retry Retry(total3, backoff_factor1, status_forcelist[500, 502, 503, 504]) session.mount(http://, HTTPAdapter(max_retriesretry)) session.mount(https://, HTTPAdapter(max_retriesretry)) session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept: text/html,application/xhtmlxml, Accept-Language: zh-CN,zh;q0.9, })注意backoff_factor1意味着重试间隔按 1、2、4 秒递增别设太小否则等于变相高频请求。4. 验证层实现可用性与匿名度双重校验4.1 验证接口的选择与原理验证代理是否可用最直接的办法是让它去访问一个回显请求头的接口。这类接口会把服务器收到的所有头部原样返回我们就能判断代理是否真的生效、是否泄露真实 IP。选择验证接口时要注意接口本身要稳定、响应快、不封 IP。如果接口自己都不稳定验证结果就全是噪声。我一般准备两到三个备用接口轮换使用避免单一接口被限流导致误判。4.2 匿名度判定的具体逻辑拿到回显内容后判定逻辑分三步解析返回的REMOTE_ADDR或等价字段如果它等于你的真实公网 IP直接判定为透明代理丢弃。检查是否存在HTTP_VIA、HTTP_X_FORWARDED_FOR、HTTP_X_REAL_IP等头部。高匿代理这些头应该为空或不含真实 IP。如果REMOTE_ADDR是代理 IP且没有任何头部泄露真实 IP判定为高匿。这里有个细节有些代理会把X_FORWARDED_FOR设成随机值而不是清空这种情况严格来说不算高匿但比直接暴露真实 IP 好。我的做法是——只要不含真实 IP就归为匿名只有完全干净才标高匿。4.3 超时、并发与验证效率验证是整套流程里最耗时的环节。假设有 5000 个候选每个超时设 5 秒串行跑就是 7 小时完全不可接受。所以必须并发。我用的是concurrent.futures.ThreadPoolExecutor线程数控制在 50 到 100 之间。为什么不用更高因为免费代理本身质量差线程开太高大量请求卡在超时上反而拖慢整体而且线程太多对验证接口也不友好。超时设置上连接超时和读取超时要分开设。连接超时短一点3 秒读取超时长一点5 秒因为有些代理连接快但转发慢。import concurrent.futures def verify_one(proxy): try: resp requests.get( CHECK_URL, proxies{http: proxy, https: proxy}, timeout(3, 5), headerssession.headers, ) return judge(resp, proxy) except Exception: return None with concurrent.futures.ThreadPoolExecutor(max_workers80) as pool: results list(pool.map(verify_one, candidates))4.4 评分机制的设计验证通过不代表一直可用所以要打分。我的评分规则基础分 60 分验证通过即得。响应时间小于 1 秒加 20 分1 到 3 秒加 10 分超过 3 秒不加。连续多次验证通过每次累加 5 分上限 100。验证失败一次扣 30 分扣到 0 以下标记失效。调度时按分数降序取分数相同的随机打散避免总是用同几个 IP 导致它们被目标站封。5. 调度层与完整实操流程5.1 数据库表结构与状态流转调度层依赖数据库里的score和status字段。状态流转大致是新采集入库status0score0。验证通过status1score按规则更新。验证失败score扣减扣到阈值以下status2。定时任务定期把status2的记录重新拉出来验证给它们复活机会。这个复活机制很重要因为免费代理经常是时好时坏直接删掉太浪费。5.2 取用接口的实现对外提供一个简单的函数从status1的记录里按score降序取前 N 个随机返回一个。如果取不到就触发一次即时验证补充。import sqlite3, random def get_proxy(): conn sqlite3.connect(proxies.db) rows conn.execute( SELECT ip, port FROM proxies WHERE status1 ORDER BY score DESC LIMIT 50 ).fetchall() conn.close() if not rows: return None ip, port random.choice(rows) return fhttp://{ip}:{port}5.3 定时任务的编排我用的是最朴素的方案一个主循环每隔一段时间做一轮采集 验证 清理。间隔设 10 到 15 分钟比较合适太频繁没意义列表站更新没那么快太稀疏又跟不上失效速度。具体节奏每 15 分钟采集一次新列表入库。每 5 分钟对status0和status2的记录做一轮验证。每小时对status1的记录做一次抽检更新分数。5.4 完整流程串讲把上面几层串起来一次完整运行是这样的启动采集脚本抓取列表页解析出 IP、端口、匿名度、协议去重后写入数据库status0。启动验证脚本从数据库取status0的记录多线程并发验证。验证通过的更新status1并计算分数失败的更新status2。业务脚本调用get_proxy()取代理发起目标请求。定时任务周期性重复 1 到 3 步维持池子活性。6. 常见问题与排查技巧实录6.1 验证通过但实际用不了这是最典型的问题。原因通常是验证接口和目标站点的网络环境不同代理能通验证接口不代表能通目标站。解决办法是用目标站做二次验证或者至少用和目标站同类型的接口验证。6.2 采集到的全是失效代理免费列表的时效性极差很多 IP 在你采集时就已经死了。这不是脚本问题是数据源问题。应对办法是提高采集频率、扩大来源数量并且接受高淘汰率这个现实。6.3 并发验证时程序卡死多半是线程数开太高加上超时设置不合理导致大量线程堆积。把线程数降到 50 到 80超时设成(3, 5)基本能缓解。另外记得给每个请求加异常捕获别让单个异常拖垮整个线程池。6.4 常见问题速查表现象可能原因排查方向验证全失败验证接口挂了或被限流换备用接口降低并发代理时好时坏免费代理本身不稳定提高分数权重增加抽检频率采集页解析为空页面结构改版打印 HTML 确认列索引数据库膨胀失效记录未清理定期删除低分且长期失效的记录目标站仍封禁代理 IP 被目标站标记换源或降低单 IP 使用频率6.5 几个踩坑心得别迷信高匿标注一定要自己验证我遇到过标注高匿实际是透明的。验证接口要轮换单一接口被限流后验证结果会大面积误判。分数机制比可用/不可用二元判断好用得多能自然筛选出优质代理。免费代理池适合练手和应急真要做稳定采集还是得考虑付费方案或自建出口。7. 关于这套方案的边界与后续扩展我得诚实地说免费代理池的天花板很低。它的价值在于让你完整走一遍采集—验证—调度的链路理解代理池的运作原理这套思路换成付费代理源、自建代理集群逻辑是完全一样的。后续可以扩展的方向有几个一是把验证层做成可插拔的支持多种验证策略二是引入更细的评分模型比如按目标站点分别打分三是把调度层做成 HTTP 接口方便其他服务调用。我自己在实际使用中发现最有价值的其实不是那几百个免费 IP而是这套候选—验证—打分—调度的思维框架它在很多需要资源筛选的场景里都能复用。最后分享一个小技巧验证代理时把响应时间也记录下来长期统计你会发现响应时间稳定在 1 秒以内的代理存活率明显高于那些忽快忽慢的。所以我在评分里给响应时间加了不小的权重实测下来池子的整体可用率能提升一截。
阅读完成 · 觉得有帮助？
