代理池与 IP 资源管理

本文基于模型知识整理。代理是双刃剑：合法用于负载分散与地域需求，用于规避封禁做高频对抗既低效又触碰 kp-004 红线——本篇立场是「最后才用的工程资源」。

一句话定义

代理池是「可轮换出口 IP 的库存 + 验活 + 调度」系统；它的价值在于让多 IP 的合法分布式采集成为可能，而不是让单 IP 的违规高频变成可能。

为什么重要

规模化采集迟早遇到两类刚性需求：任务量大到单出口带宽/速率不够；或业务需要特定地域出口。此时代理是基础设施。但它排在「修好请求头、做好限速」之后——顺序错了，代理只会加速暴露。

前置知识

kp-016（知道代理对应第 3 层应对，且是高成本手段）。

核心概念

• 协议：HTTP(S) 代理、SOCKS5 代理。
• 匿名度：透明（暴露真实 IP）、匿名（隐藏但不声明）、高匿（既隐藏也不留痕迹）——采集需要高匿。
• 验活：用目标站点或通用探测页测「可用性 + 延迟 + 是否被识别」。
• 调度策略：轮询、随机、按成功率加权；失败即降权/剔除。
• 来源：付费代理商（API 取号）为主，免费代理仅可练手。

原理与机制

最小代理池的三个组件与数据流：

取号器(付费API/爬免费源) → 仓库(去重存储: ip:port, 协议, 评分)
     ↑                                    ↓
     └── 剔除/降权 ←── 验活器(每5分钟: 可达? 延迟? 匿名?) ←── 评分更新
                                    ↓
                          调度器(按评分加权轮询, 供请求方取用)

requests 侧的接法（含失败剔除）：

PROXIES = {"http": "http://user:pass@ip:port", "https": "http://user:pass@ip:port"}

def get_with_proxy(session, url):
    try:
        r = session.get(url, proxies=PROXIES, timeout=(5, 15))
        score_up(PROXIES)
        return r
    except requests.RequestException:
        score_down(PROXIES)            # 连续 N 次失败 → 从池中剔除
        raise

验活的三道判据：能连通（TCP+HTTP 成功）；延迟低于阈值（如 <2s）；匿名性达标（探测页看不到真实 IP、X-Forwarded-For 干净）。不验活的代理池等于运气池。

实例或案例

分布式价格监控（kp-022 的 3 个 worker）：为避免同一出口承担全部流量、并保证各地域看到的页面一致，按 worker 绑定不同地域出口。上线顺序先是「降并发 + AUTOTHROTTLE」，确实不够才引入代理——三个月后复盘，80% 的封禁都发生在代理刚上线、并发没降的阶段。

常见误区

• 误区一：免费代理上生产。 免费源可用率常低于 10%，且中间人风险真实存在（流量可被代理方窥探）；生产必须用信誉明确的付费源。
• 误区二：只存不验。 代理平均寿命以小时计；不验活的池子几天内全部失效而不自知。
• 误区三：把代理当反爬解药。 请求形态不对（缺头、指纹异常）时换 100 个 IP 也照拦；代理只解决「出口 IP」这一个变量。

自测题

1. 采集为什么必须高匿代理？

答：透明/普通匿名会透传真实 IP 或暴露代理特征，既达不到分散目的也易被识别。

1. 代理池三个必备组件？

答：取号入库、定期验活评分、按评分调度并在失败时降权剔除。

1. 什么时候才该考虑上代理？

答：修好请求头、做好限速与退避之后仍有明确的多出口/地域需求时；它是最后的工程资源。

与其他知识点的关系

kp-017 的限速在使用代理后依然必须执行；kp-022 的 worker 节点各自绑定代理出口；kp-004 决定了哪些对抗场景根本不该用代理。

延伸阅读

aiohttp/requests 官方文档的 proxy 一节；本库 kp-022（出口与 worker 的绑定实践）。