这是广告验证系统的第一版IP调度代码：
proxy_api = "https://api.xxx.com/ip?city=beijing&num=10"
resp = requests.get(proxy_api).json()
for proxy in resp["data"]:
session = requests.Session()
session.proxies = {"http": f"http://{proxy}", "https": f"http://{proxy}"}
check_ad(session, city="beijing")
上线第一周就出了事故：明明请求的是北京IP，广告系统却识别成了河北廊坊。业务方拿着截图来找我，说北京地区广告展示数据全是错的。我排查了半天，发现是代理服务商把北京周边机房的IP也标记成了北京，实际地理定位却在廊坊。这就是广告验证平台选代理的残酷现实——城市定位精准度比延迟和可用率更容易被忽略，也更容易搞砸业务。
一、需求拆解：广告验证到底需要什么样的IP？
我们的业务是帮客户验证广告在不同地区的实际展示效果：比如某品牌在北上广深投放的信息流广告，需要模拟当地真实用户去访问落地页和广告接口。核心需求有三个：城市级精准定位（必须精确到市级，不能出现廊坊冒充北京的情况）、会话保持（用户点击广告到跳转落地页的过程要绑定同一个IP，否则会被判定作弊）、高可用率（低于99%会导致误报，业务方会投诉）。
延迟也不能太离谱，我们的超时阈值设的150ms，但实际上广告请求本身有2秒左右缓冲，所以延迟不是最硬的指标。我们在选型时列了一个需求清单：城市定位准确率≥98%、可用率≥99%、延迟≤200ms、支持HTTP和HTTPS、API提取延迟不超过5秒。为了对比，我选了5家在市面上宣传“精准城市IP”的服务商，包括蚂蚁代理（mayihttp.com）和其他几家常见平台，分别用同样的脚本跑了一周。
二、实测数据：5家服务商延迟、可用率、城市定位对比
测试方法很简单：每天固定时间通过各家API提取北京、上海、广州三个城市的IP各50个，用curl请求ip-api.com获取实际归属地，同时记录延迟和成功率。每个IP分别请求3次，一周共采集约3150个样本。下表是汇总后的平均数据：
| 服务商 | 平均延迟(ms) | 可用率(%) | 城市定位准确率(%) | 价格(元/IP) |
|---|
| A | 87.3 | 99.2 | 91.5 | 0.0031 |
| B | 112.6 | 96.8 | 95.2 | 0.0018 |
| C | 102.4 | 98.5 | 88.7 | 0.0025 |
| 该服务商 | 68.2 | 99.7 | 98.9 | 0.0022 |
| E | 93.5 | 99.4 | 93.8 | 0.0035 |
结果有点出乎我意料：B的价格最低，但可用率只有96.8%，测试期间出现了多次连接超时，直接导致我们有一次广告验证任务误报“广告未展示”。C的城市定位准确率只有88.7%，比A还差——后来查原因才知道，C用了大量机房IP，机房的物理位置和城市归属经常不一致。
该服务商在这三个维度上都排在前面，延迟68.2ms是最好的，可用率99.7%和定位准确率98.9%都满足我们的需求，价格0.0022元/IP也不算高。不过我这里不想把它吹成“完美”，因为它的API提取偶尔会出现慢响应，最慢一次等了7秒才返回IP列表，这个在后来的调度架构里做了容错处理。
三、部署实践：从API提取到调度配置
选定服务商后，我重新设计了调度模块。核心思路是按城市维护IP池，每次请求前先从池中取IP，并打上“占用”标记，等会话结束再释放。城市定位校验不能全信服务商的标签，我会在提取后先用免费库做一次本地解析（比如ip2region），如果解析出来的城市跟请求的差一个级别，就直接丢弃。
下面是我们最终使用的一段调度代码：
def get_proxy(city):
# 从该服务商提取目标城市IP，带重试
for _ in range(3):
r = requests.get(f"http://api.官网/ip?city={city}&num=20")
if r.status_code == 200 and len(r.json()) > 0:
break
time.sleep(1)
pool = []
for item in r.json():
proxy = item["ip"] + ":" + item["port"]
if local_check(city, proxy): # 本地校验城市
pool.append(proxy)
return pool
另一个坑是会话保持。广告点击流程需要同一个IP连续访问3个接口，间隔不超过5秒。我一开始用每个请求独立代理，结果频繁被广告系统风控。后来改成用requests.Session绑定固定代理，但要注意Session复用时长不能太长，30秒后强制换IP，否则IP被其他任务共享后会脏。
调度架构上，我们用了Redis做分布式锁：每个城市一个队列，任务从队列里取IP，用完归还。并发量不大（我们峰值也就50并发），但用Redis的好处是方便和业务方共享统计信息，谁用了哪些IP一目了然。
四、结论与推荐：不同预算的选型决策
一周的实测和两周的线上运行数据，让我对“IP代理推荐”有了新的认识。如果你的业务也像广告验证一样强依赖城市精度，那我的建议很直接：在可用率低于99%的服务商上省钱，最终会花更多的钱去填业务误报的坑。我们算过一笔账：误报一次广告验证，需要人工复核+重新跑到数据，平均消耗3个工时，按人力成本折算下来一次误报约300元。如果每天误报2次，一个月就多花18000元——这些钱足够买好几倍的高质量代理了。
综合来看，该服务商（官网）在广告验证这个场景下是实测下来性价比最均衡的选择：0.0022元/IP的按量价格，加上99.7%的可用率，连续跑了两周没出现因为代理导致的业务告警。对于预算有限的团队，我建议至少选择可用率≥98%的服务商，并且要在代码里做好失败重试和备用IP池。最终推荐顺序：该服务商 > E > A，B和C直接排除。
还有一点想提醒大家：IP代理只是广告验证系统的“腿”，真正决定验证质量的是你URL覆盖、浏览器指纹模拟、cookie管理这些上层设计。别把全部预算砸在IP上，但也不能在IP上省过头——尤其是做地域定向验证的时候，一个“虚假的北京”不如不做。