一个 IP 池同时喂新闻站、社媒、内容社区,能跑,但撑不过一个月。
这不是危言耸听。IP 在社媒被打上标记之后,新闻站和社区那边的信誉分也会跟着掉——公共黑名单是共享的,你以为这批 IP 只在一个平台"用坏"了,实际上它在别的平台也被记了一笔。等你发现成功率往下掉的时候,往往三个平台一起掉。
要解这个问题,加 IP 数量是没用的,你得改思路:代理池不是买得多就行,是得分开用。
问题的根不在 IP 数量,在于你把不同平台的采集需求混在一个池子里,等于让它们共用一份"信任余额",谁先把自己那份用完,剩下的人跟着倒霉。这篇就把分层配置的思路写一下,顺便把参数怎么定、怎么接入、出问题怎么查,一起讲了。
为什么一个池子不够用
舆情要采的东西,平台差别大得离谱。
新闻门户、资讯站这类,反爬其实挺松的,基本就是看看请求频率、UA 对不对。这种站可以往死里压并发,一个 IP 用几分钟拿个几十上百页毫无压力。
社媒和内容社区就是另一个世界了。请求指纹、行为链、IP 信誉库,一整套东西招呼你。同一个 IP 短时间怼同一个域名,分分钟进观察名单,进了之后你怎么换 UA 都没用,那个 IP 基本就废了。
第三种最麻烦,就是那种得登录才能看完整内容的——比如某些社区的评论区、视频站的完整数据。这类你不光要有 IP,还得让 IP 在一个会话里稳住,中途一换,登录态就掉了,前面白干。
你看这三类的诉求:
新闻站要的是"IP 换得快、量大管饱"
社媒要的是"每次请求都换,而且节奏慢下来"
登录态要的是"IP 一小时别动,稳"
三种诉求互相打架。你拿短效 IP 去跑登录态,登录一次掉一次;你拿长效 IP 去跑新闻站,IP 很快就被目标站记住脸了。所以一个池子跑三种,不管你偏向哪种,总有一类要吃亏。
结论就一句:必须分层。不是 IP 买得不够,是没分开用。
分几层,每层怎么配？
我们最后定下来是三层,跟前面三类平台一一对应。
第一层是新闻/资讯这种公开信息层。 用短效代理,IP 存活 1 到 5 分钟就行,一批拉出来用完就扔。并发可以放开,协议 HTTP/HTTPS 够用。逻辑很简单——反爬松、页面轻、量要大,那就用完就丢,别心疼。
第二层是社媒、内容社区这种强反爬层。 用隧道代理,每次请求换一个 IP,或者每几秒换一次。并发压低,请求节奏也压低,协议最好三个都能兼容(HTTP/HTTPS/SOCKS5),因为有些爬虫框架就认 SOCKS5。这一层的哲学是"打一枪换一个地方",隧道代理最舒服的一点是你不用自己维护 IP 列表,业务代码就对着一个入口发请求,换 IP 是云端的事。
第二层我们线上跑的是极安代理的隧道,之前对比过几家,最后留它主要是成功率稳。给个具体数,最近一轮压测的结果:带宽 4.23 Mbps,平均下载速度 533.6 KB/s,IP 请求传递成功率 98.93%,平均延迟 2633ms,最小延迟 205ms。最大延迟窜到过 14773ms,方差 2.1。
我知道 14 秒这个最大延迟数看着挺吓人的,但说实话第二层跑舆情根本不 care 这个。社媒本来就要压节奏,单请求慢十几秒有啥关系,上层重试兜一下就过去了。真正要盯的是成功率和方差。方差 2.1 说明绝大多数请求都挤在均值附近,只是偶尔有几个长尾,链路整体是稳的——这才是能不能长期跑的关键。
顺便说一句选型经验:别看宣传页那些"IP 池百万级""毫秒换 IP",没啥用。真正决定你半夜会不会被电话叫起来的,是成功率能不能稳在 98% 以上、延迟别乱飘、异常 IP 剔掉之后重试能不能兜住。这三个跑几天压测就露馅了,宣传页看不出来。
第三层是登录态层。 用长效或者独享代理,IP 存活按小时算,一个会话绑一个 IP,会话没结束别换。并发很低,基本一个账号一个 IP。这层单价贵、池子也不用大,但你要采账号后面的东西,躲不掉。
分层还有一个隐性好处经常被忽略:隔离性。第二层的 IP 被某个平台标了,不会影响第一层和第三层。以前混在一起用的时候,一处出事全线告警,现在至少能睡个安稳觉。
四个参数,每层都得单独定
分层框架搭好了,接下来是每层内部的参数。四个,按重要性排。
第一个是 IP 存活时长。 这个错得最多。逻辑其实很朴素,就看你采集节奏多快:
2-3 秒一个请求,选 1 分钟存活的,一个 IP 大概撑 20-30 个请求就该换
5-10 秒一个请求,但要连着跑几十分钟同一个域名,选 15 分钟的
要维持登录半小时以上,直接上小时级长效
存活时长设短了浪费(IP 还没热就扔),设长了 IP 早被标记了你还在用,成功率一路往下掉。
第二个是换 IP 的粒度。 三种粒度对应三种业务代码写法:按批次换的你得自己维护队列;按请求换的(就是隧道)你只对一个入口发请求,啥都不管;按会话换的最省事但也最不灵活。隧道接入成本最低,几乎不用改代码。
选型的时候,隧道产品重点看换 IP 生效速度、单入口默认 QPS、带宽、异常 IP 会不会自动剔;短效代理看存活档位有没有多档可选(1 分钟/5 分钟/15 分钟这种)、按 IP 数还是按流量收钱、日更新量够不够。这几项直接决定你后面算并发的时候数够不够用。
第三个是并发上限。 算法非常糙:
单目标域名 QPS × 存活时长 = 单 IP 承载请求数
总请求量 ÷ 单 IP 承载请求数 = 所需 IP 数量
举个数:新闻层想跑 50 QPS,单 IP 存活 1 分钟,单域名压到 20 请求/分钟(避免触发频控),那单 IP 承载 20 个请求。总量 3000/分钟,需要 150 个 IP 并发在线。然后这个数字要留 2-3 倍冗余,因为池子里总有一部分 IP 是刚拿到还没热、或者已经进入衰减期不太行了的。
第四个是协议兼容。 大部分场景 HTTP/HTTPS 够了。但两种情况必须 SOCKS5:走 UDP 的采集,还有一部分客户端方案/爬虫框架只吃 SOCKS5。选产品的时候把协议清单看全,别默认"HTTP 支持就行"。
接入就两种方式
分层和参数定完,接入其实翻来覆去就两种。
A. 隧道直连(第二层用这个)
代码里对接一个隧道入口,加个鉴权(白名单或者账密),每次请求都走这个入口,换 IP 是云端的事。
proxies = {
"http": "http://user:pass@tunnel.example.com:port",
"https": "http://user:pass@tunnel.example.com:port"
}
resp = requests.get(target_url, proxies=proxies, timeout=10)
一行 proxies 参数,业务代码几乎不用改。缺点是入口固定,隧道服务本身抖一下,业务跟着抖,所以选型的时候可用率这个数得看重。
B. API 拉 IP + 本地队列(第一层用这个)
定时调 API 拉一批 IP 进本地队列,业务从队列里拿,用完归还或者丢。
def refresh_pool():
ips = fetch_from_api(count=100)
ip_queue.put_many(ips)
def request_with_proxy(url):
proxy = ip_queue.get()
resp = requests.get(url, proxies={
"http": proxy, "https": proxy})
if resp.status_code == 200:
ip_queue.put(proxy)
return resp
灵活,能自己控生命周期,但要自己写健康度检测那套逻辑,活儿更多一点。
出问题了怎么排？
线上肯定会出问题,列几个我们经常遇到的:
成功率掉到 50% 以下。 先分清楚是所有目标域名一起掉,还是就一个域名掉。一起掉,大概率代理池自己出事了(比如 IP 段进了公共黑名单);单个域名掉,那是它自己反爬升级了,得调对应层的换 IP 频率。
隧道入口延迟突然飙。 先绕开代理,直连目标看看延迟,排除掉目标站自己的问题。确认是代理侧就切备用入口,或者找服务方。
短效 IP 拉不出来,或者拉出来立刻失效。 十有八九是提取频率超了套餐上限、或者白名单没配对。API 返回码看一下,厂商基本都会给明确错误码。
登录态老掉。 第三层的 IP 换得太勤了。检查是不是把短效误配到了长会话业务上,或者所谓"长效 IP"实际稳定性根本达不到宣称的时长——这个坑我们踩过。
最后
代理池这事,别再想着"多买点 IP 就好了",思路错了买多少都白搭。分层隔离,加参数匹配,才是正解。 三层对应三类平台,四个参数落到每层的具体规格上,接入方式二选一。分完之后每一层出问题都是独立的,能诊断、能修,整体健康度也就跟着可控了。
常见问题FAQ
Q：只采一个平台,还要分吗?
不用。单平台就选一种代理:高频用短效、强反爬用隧道、要登录用长效。分层是为了防止多平台相互污染,单平台没这个问题。
Q：全用隧道行不行?
能跑,但不划算。第一层用隧道浪费"每次换 IP"这个能力,而且换太勤反而让某些反爬松的站觉得你怪。第三层用隧道直接掉登录。
Q：池子买多大?
别看总量,看"并发在线 IP 数"。按上面参数三那个公式算一遍,留 2-3 倍冗余就够。国内中等规模的舆情团队,前两层加起来 500-2000 个并发在线 IP 基本够,不用堆百万级。
Q：怎么验证配置对不对?
上线前跑一次分层压测,每层小流量跑 24 小时,盯三个数:成功率、平均延迟、被限制 IP 占比。哪个数掉出预期区间,就是那层参数没配对,回去调存活时长或者换 IP 粒度。厂商基本都给试用额度,正式采购前先按这三个数跑一轮再决定。
