一、OTA同一周集体换风控，我们的比价流水线先塌了
三月初那一周挺魔幻的。飞猪、同程几家OTA几乎同步把风控从小流量灰度切成了全量，端口没变、接口没变，但行为检测明显加严了。我们那条跑了半年的比价流水线，升级前单IP每秒3次请求，成功率稳在92%；升级后第二天掉到61%，第三天开始大量返回滑块页，日志里全是验证码标记。
我们的场景比一般爬虫麻烦。这是给旅游比价平台供价的业务，一次完整任务要同时向8家OTA发起查询，还要拿到同一家酒店在32个出发城市下的本地报价——一次任务就是256个请求起步。这里有两个硬约束：出口IP的城市必须跟出发城市对齐（用北京IP去问广州出发价，拿回来的数字是错的，价差能有几十块），以及并发得撑得住，否则比价结果还没拼出来，价格早变了。
所以问题很明确：不是IP不够用，是IP的地域属性和并发稳定性同时不达标。这也决定了后面所有选型动作的方向。
二、把“代理IP推荐”拆成四个能直接测的指标
我向来不太信那种十大代理IP推荐榜单，因为每个场景的瓶颈压根不一样。对我们这个业务，我把选型收敛成四个能跑数据验证的指标，而不是看谁的宣传页漂亮。
- 城市定向能力：能不能按城市维度单独提取IP，而不是给一个全国随机池让我们自己筛。32个城市至少要能精确命中30个。
- 并发承载：单账号连续跑1小时不报错的真实并发值，不是标称峰值。
- 延迟分布：均值参考意义不大，要看P95，因为比价有8秒的超时窗口，尾部请求拖垮整批任务。
- 计费模型：短任务高频场景下，按IP计费会被反复扣，按天/按通道计费更划算。
顺着这四个维度，我把市面上三种接入方式跑了一遍。结果和我最初的判断不太一样——我一开始笃定纯API提取最灵活，跑了一周数据才发现，拼接开销全压在业务代码里，反而最脆弱。
| 接入方式 | 城市定向 | 1小时稳定并发 | P95延迟 | 计费 |
|---|
| API提取（按IP） | 精确到城市 | 约180 | 312ms | 0.0022元/IP起 |
| 隧道代理（按天） | 需带城市参数 | 约400 | 118ms | 16元/天起 |
| 免费池 | 基本不可控 | 约20 | 超时率41% | 0 |
免费池那行数据不用细看，纯属给自己找罪受。真正的结论是：隧道代理扛主力并发，API提取补城市定向的缺口，两者按7:3混跑，而不是二选一。
三、部署实录：隧道打底 + 城市定向补位
主力通道走隧道，好处是连接复用、延迟低，实测P95能压到118ms，可用率在99.9%那条线上。城市定向的部分走API提取，按出发城市单独拉一个短效IP，用完即弃。控制逻辑大概是这样：
import aiohttp, asyncio
TUNNEL = "http://user:pass@tunnel-host:8080"
CITY_API = "https://api.example.com/get?city={city}&num=1"
async def get_city_proxy(session, city):
async with session.get(CITY_API.format(city=city)) as r:
data = await r.json()
return f"http://{data['ip']}:{data['port']}"
async def task(city, hotel_id, session):
proxy = await get_city_proxy(session, city) # 城市定向通道
url = build_url(hotel_id, city)
try:
async with session.get(url, proxy=proxy,
timeout=aiohttp.ClientTimeout(total=8)) as r:
return await r.text()
except asyncio.TimeoutError:
return await retry_via_tunnel(url, session) # 超时降级走隧道
结构不复杂，关键在降级路径——城市通道拿不到IP时自动切隧道，保证任务不整体失败。并发上限我卡在400，往上加到600时成功率反而从99.2%掉到96%左右，这个性能拐点建议自己压测确认，别照抄。
四、跑了两周，数据说话
迁移完成后连续跑了两周，日均请求量120万次。成功率回到98.7%，比风控升级前还高一点。城市命中率32个城市覆盖到31个，剩下那个小城市的池子太薄，我用相邻城市做了兜底。单位成本算下来，比纯API提取便宜大约三成，因为隧道把大批量请求的计费摊薄了。
有三次坑值得记一下。第一次是白名单认证在K8s里配不通，动态出口IP和对端白名单永远对不上，最后退回账密认证；第二次是城市参数拼错位置，导致所有请求悄悄走了全国池，价格全错，排查了半天；第三次是没限制重试次数，某家OTA短时限流时触发重试风暴，把整体成功率拖崩。
这套结构在我们日均百万级的量级够用，如果你跑到千万级，得把城市通道做成独立队列，不然调度会打架。选型上我的判断很直接：城市敏感 + 高并发，就隧道打底、API补位，别在免费池上浪费时间。像mayihttp.com这种支持按城市定向提取又提供隧道通道的，在这个组合场景里适配度比较高，值得放进候选名单实测一轮再定。