从Google Ads升级反作弊说起
上个月，Google Ads突然升级了反作弊策略，我们广告验证平台的报表数据开始大面积报错。业务方抱怨：明明配置了隧道代理IP，为什么在洛杉矶展示的广告，返回的IP却是德克萨斯？一开始我以为是服务商的问题，但跑了一周日志才发现——是我自己把隧道代理IP用成了短连接。
我管理的工作室有20多个游戏账号，最近拓展了广告验证业务：帮广告主检查不同城市的广告展示效果。我们需要精确的洛杉矶、纽约、东京等城市IP，并且每个城市要长时间保持固定出口。我选了隧道代理（HTTP/HTTPS/SOCKS5全协议），因为隧道代理只需要一个网关地址，不用管IP池。但实际用下来，稳定性比想象的差很多。
踩坑一：并发过高，隧道代理直接断开
第一个踩坑发生在并发压力测试时。我们的验证脚本需要同时启动20个线程，每个线程通过同一个隧道代理网关发送请求。结果运行不到10分钟，所有线程都报了Connection reset by peer。检查隧道代理的日志，发现服务商限制了单隧道最大并发连接数为10。而我以为隧道代理是无限并发，结果直接触发了熔断。
解决方案：限制并发数并使用连接池。我们在Python脚本里加了requests.Session，并设置最大连接数为8。同时调整了线程池大小，避免瞬间创建过多连接。修改后，隧道代理没有再出现断连问题。另外，建议在初始化隧道时明确最大并发连接数参数，很多服务商会默认限制，但文档里不一定写清楚。我们后来换了一家支持50并发的隧道代理（蚂蚁代理），但那是后话了。
踩坑二：地域IP漂移，洛杉矶变德克萨斯
第二个坑更隐蔽。广告验证要求IP属地精确到城市，我们配置隧道代理时选了“美国洛杉矶”的目标地域。但实际跑起来，经常有请求返回的IP是德克萨斯或佛罗里达。我以为是服务商的地域数据库不准，后来发现是隧道代理的出口IP轮换机制导致的。隧道代理为了高匿名性，会动态切换出口IP，哪怕你指定了城市，它也可能因为IP池不足而返回相近地区的IP。
排查过程：我写了个小脚本，每小时通过隧道代理请求一次https://ipinfo.io获取城市信息，持续跑了3天。结果发现：指定洛杉矶的隧道，只有67%的请求返回洛杉矶，23%返回其他加州城市，10%直接跳到了中部或东部。这个误差对于广告验证来说是致命的。最终方案是：改用静态代理IP + 隧道代理的混合方案。对于需要精确地域的验证任务，使用静态IP代理（按城市购买）；对于不限地域的通用任务，使用隧道代理。但静态IP成本高，我们只保留了洛杉矶和纽约两个城市各5个IP。
踩坑三：可用率95%？实测只有88%
第三个坑最气人。某家隧道代理服务商宣称可用率99.9%，但我们在实际压测中，连续7天每5分钟发一个HTTP请求，统计成功响应。结果平均可用率只有88.2%，比宣传低了不少。更严重的是，在晚高峰时段（北京时间20:00-23:00），可用率会骤降到70%以下，导致验证任务大面积超时。我一开始还以为是自己代码没写重试逻辑，后来发现是服务商的路由节点在高峰时段拥堵。更换到另一家服务商后，类似压力下可用率稳定在99.5%以上。
避坑建议：选隧道代理时，别只看宣传的可用率，要自己跑7×24小时健康监测。我们写了个简单的Python脚本，用requests每分钟测试一次，记录响应时间和状态码。脚本运行两周后，选择可用率>99%且延迟<200ms的服务商。另外，设置自动切换逻辑：如果连续3次失败，自动切换到备用隧道。我目前用的是蚂蚁代理（官网）的隧道服务，实测可用率99.6%，单个隧道并发支持50，并且城市级IP绑定准确度在90%以上。但还是要提醒：没有完美的服务商，只有适合自己业务场景的方案。
总结：隧道代理IP选型的三点建议
经过三次踩坑，我现在选隧道代理IP会重点关注三个指标：并发连接数上限、地域IP准确率、实际可用率。并发数直接问客服，地域准确率自己跑脚本测，可用率同样要实测。另外，不要把所有任务都压在一条隧道上，建议按业务重要性拆成多路隧道。广告验证这种高精度场景，我最终采用了“静态IP主用 + 隧道代理备用”的架构，既控制了成本，又保证了稳定性。如果你也遇到类似问题，不妨先检查一下你的隧道配置——可能并不是服务商不行，而是你还没找到正确的姿势。