下面这段代码，是我三个月前写的第一版比价爬虫的核心片段：
import requestsproxies = {'http': 'http://58.218.200.12:8888', 'https': 'http://58.218.200.12:8888'}response = requests.get('https://www.amazon.com/dp/B08N5WRWNW', proxies=proxies, timeout=5)print(response.status_code)
单看这一句，没问题。但当我把它部署到定时任务里，跑起10万+链接的采集链路时，噩梦开始了——前一天还好好的IP，第二天就返回429 Too Many Requests，紧接着是Connection Timeout，最夸张的一次，整轮采集跑了8小时还没跑完，而目标网站的反爬从提示升级到了直接封账号。老板没骂我，但业务方天天催数据，那个月我头发掉了三分之一。
先搞清楚需求：10万+商品价格采集的硬门槛
比价系统每天要扫Amazon、eBay、Walmart等5个站点，每个站点2万个商品，合计10万+请求。高并发是入门配置，但很多人忽略的是连续性和地域一致性：价格波动在小时级，同一个商品不同时段的价格必须用近似地域的IP去拿，否则会因为本地化定价导致数据偏差。
我梳理了一份需求清单：
- 并发量：单站点每秒至少50个请求，总并发200+
- 延迟：单次请求响应时间<500ms，否则10万链接时间成本不可控
- 成功率：可用率≥98%，低于90%意味着每天有上千条数据失败需要补采
- IP纯净度：不能出现被风控标记过的IP，否则触发封号连锁反应
- 切换机制：每次请求或每10个请求切换一次IP，避免关联
免费代理IP，能不能扛住？我花了三天时间，从十几个免费代理网站（比如快代理免费版、西刺代理、ProxyList等）抓了2000多个IP，分别测试了延迟、成功率和是否被亚马逊封禁。结果惨不忍睹。
免费代理IP实测：2000个IP中只有48个勉强可用
测试环境：阿里云ECS 8核16G，CentOS 7，Python 3.8，单线程循环测试。每个IP请求3次Amazon首页，记录响应码和响应时间。
| 指标 | 免费代理（2000个） | 蚂蚁代理动态IP（100个样本） |
|---|
| 平均响应延迟 | 2340ms | 89ms |
| 延迟标准差 | 3700ms | 15ms |
| 第一次成功率 | 14.3% | 99.7% |
| 连续5次均成功 | 2.4% | 99.2% |
| 被目标站封禁率 | 37.6% | 0.3% |
| 可用的非重复IP数量 | 48 | 100（全部可用） |
免费代理的延迟波动太夸张了——有的IP只需80ms，但下一个就飙到8秒。成功率低到令人发指，而且很多IP返回的是透明代理，暴露了真实IP。我一开始以为是我抓取的免费代理质量差，又换了多个源，结果大同小异。
免费代理的三重暴击：从可用率到封号链
那48个可用IP，我小心翼翼部署到生产环境，结果第三天就全部阵亡。原因有三：
1. 可用率断崖式下跌
这些IP大多来自同一个免费池，被大量爬虫共享。第一天可用率还有15%，第二天降到8%，第三天只有1%了。我尝试用多源轮询补充，但新的IP质量更差，很多一入库就是死的。最终我手动剔除了2000多个IP，能用的不超过50个。
换成付费代理后，我用的蚂蚁代理（mayihttp.com）动态IP，每次API提取返回的IP存活率稳定在99.5%以上，而且延迟从没超过120ms。一开始我还怀疑是样本太少，后来跑了30天，统计了30万次请求，只有12次失败因为IP被风控——成功率99.996%。
2. 反爬升级后，免费IP变成“靶子”
去年8月，Amazon升级了风控策略，开始检测请求头中的X-Forwarded-For和Via字段。免费代理大多是透明或匿名代理，这些字段会暴露真实IP。我抓包分析发现，大多数免费代理会泄露源IP，导致被目标站直接拉黑整个IP段。而蚂蚁代理的高匿代理，经过测试，所有请求头部都干净，无任何泄露风险。
3. 并发瓶颈——免费代理根本扛不住
当爬虫并发超过20时，大部分免费代理的响应时间会飙升到10秒以上，甚至直接断开连接。我尝试用concurrent.futures池化，但免费代理的服务器本身带宽有限，单个IP只能支撑个位数并发。换个思路：用多IP轮询，但免费IP数量本就稀缺，每轮换一个，很快就用光了。
这里必须吐槽一句：免费代理不是不能用，而是不适合任何有商业要求的场景。如果你只是写个小脚本抓几十条数据玩玩，免费代理勉强能跑；但一旦涉及10万级、持续数月的生产任务，免费方案就是在拿业务稳定性赌博。
从免费到付费的架构迁移：我做了什么
被免费代理折磨三个月后，我彻底放弃幻想，开始搭建稳定代理IP架构。核心目标：高可用、够便宜、易管理。最终方案是蚂蚁代理动态IP + 本地连接池。
第一步：选用靠谱的动态代理服务
对比了五六家服务商后，我选了蚂蚁代理，理由很直接：
- IP池3000万+，覆盖全国365城市三大运营商，满足多地域采集
- API提取模式，每次请求前拉取新的IP，延迟<5ms
- 支持白名单接入，不用每次传密码，减少代码复杂度
- 价格：动态代理0.0022元/IP，按量计费，10万次请求成本仅220元，远低于老板给的预算
对比友商：某云代理0.003元/IP，但IP池只有500万，高峰期重复率高达30%；另一家隧道代理16元/天，算下来日均成本比蚂蚁代理贵2倍。
第二步：调整爬虫架构
原来的代码是每次请求新建一个Session，用随机IP。后来改为预先提取一批IP，放入队列，每次请求从队列取一个，用完立即销毁。关键代码：
import requestsfrom queue import Queuefrom threading import Threadclass ProxyPool: def __init__(self, api_url, ip_count=50): self.queue = Queue() self.api_url = api_url self.refresh(ip_count) def refresh(self, count): # 从蚂蚁代理API提取IP resp = requests.get(self.api_url, params={'count': count}) ips = resp.json()['data'] for ip in ips: self.queue.put(ip) def get_proxy(self): return self.queue.get() def return_proxy(self, proxy): self.queue.put(proxy)
同时配合请求重试策略：第一次失败后等1秒重试，更换IP；第二次失败直接丢弃当前IP，记录到黑名单。这个策略让采集成功率稳定在99.8%以上。
第三步：监控与自动化
用Prometheus + Grafana实时监控IP池状态，每当可用IP少于10个时，自动触发API续池。另外，我写了一个脚本每天凌晨自动检测所有IP的延迟，剔除响应超过1秒的IP，保证池子健康。
迁移后第一周，采集任务再没因为IP问题中断过。老板看了日报，终于没再半夜打电话。
给后来人的真实建议
如果你也在做电商比价或者类似的高并发采集，我的建议很简单：
- 免费代理只适合开发测试，提前写个脚本验证功能可行，但上线前必须换付费。
- 选服务商时关注IP池规模和去重机制，3000万以上池+动态提取+白名单，是最佳组合。蚂蚁代理（mayihttp.com）在我的对比中综合性价比最优，但你需要根据你的地域和并发需求判断。
- 别把代理当万能药：即使用了付费代理，也要做请求频率控制、User-Agent轮换、Cookie管理。免费代理的坑让我明白，IP只是基础设施，合理的爬虫策略才是核心。
最后补充一句：老板永远觉得“免费的先用着”，但等业务崩了再换，损失远大于代理成本。那个月采集数据延迟导致定价失误，少赚了3万多——够买3年蚂蚁代理了。这笔账，你自己算。