一天5000个关键词，报表出来后业务方炸了
去年Q4我接手一个跨境电商SEO项目。客户要求每天在30个城市维度上追踪5000+关键词的本地搜索排名，算下来每天15万次查询。第一版报表交付当天，业务方电话就过来了：同一个关键词、同一个城市，周一显示第3位，周三掉到第47位，周四又回到第4位。这种数据他们不敢拿去给运营做决策。
我第一反应是自己代码有bug，查了三天的日志才排掉这个怀疑。真正的问题是：我们请求时用的出口IP，在“城市”这一层是漂移的。搜索引擎返回的是基于请求方IP定位的本地化结果——你从上海发起请求，但出口IP落在杭州，拿到的就是杭州的排名。排名本身没有错，错的是我们以为自己在查上海。
这个坑不是换个服务商就能绕过去的，它牵扯到地域定位、会话粘性和并发调度三个层面。下面把我踩过的三处错配逐一拆开。
三个错配，一个比一个隐蔽
地域错配：宣称覆盖300城，精确到城市的只有六成
很多代理商都标榜覆盖365+城市，但IP库的定位精度参差不齐。我用ipip.net加上两个商业库交叉校验了一批IP，发现某家宣称覆盖300城的服务商，实际能精确到城市级的比例只有约六成，剩下的IP定位误差在50到300公里之间。对普通采集无所谓，对SEO地域排名来说，这50公里就是两个城市的结果。
会话错配：每请求轮换，验证码率飙到28%
第二个坑更隐蔽。一次排名查询不是单个请求，而是“搜索页→翻页→点击详情”一整条链。如果中途IP变了，搜索引擎会判定会话异常，直接甩验证码。我们最初图省事设成每请求轮换，跑了两天，验证码率冲到28%，几乎三分之一的样本是废的。
并发错配：单IP被短时打爆
5000关键词乘以30城市，如果无脑并发，同一个出口IP会在几秒内收到几十次同质请求。我们监控到某个IP在40秒内被打了60多次，之后连续15分钟返回空结果。这个坑我们前后踩了三次，每次都是换了一批新IP后忘了收紧并发。
方案对比：三档代理的实测账
我把当时试过的三类方案拉了个对比。测试环境固定：5000关键词、30城市、连续跑7天，统计验证码率和排名数据日间波动幅度。我一开始主观觉得住宅IP肯定最优，跑完一周数据才发现，综合性价比最高的其实是隧道代理做会话绑定、动态短效做补充的组合。
| 方案类型 | 会话时长 | 城市定位精度 | 验证码率 | 平均延迟 | 月成本估算 |
|---|
| 短效动态（每请求轮换） | 约1次 | 约62% | 28.0% | 180ms | 约1800元 |
| 长效住宅IP | 10分钟 | 约88% | 4.5% | 420ms | 约4200元 |
| 隧道代理+会话绑定 | 120秒 | 约85% | 1.2% | 210ms | 约1300元 |
关键不在于用哪种IP，而在于把“一个关键词+一个城市”绑定到一个确定会话上。我用requests的Session配合隧道代理的粘性参数，每个城市维度单独开一条隧道，代码大致是这样：
import requests
def query_rank(keyword, city, tunnel_port):
proxies = {
"http": f"http://user:pass@tunnel-{tunnel_port}.provider.com:8080",
"https": f"http://user:pass@tunnel-{tunnel_port}.provider.com:8080"
}
s = requests.Session()
s.proxies = proxies
# 会话粘性由隧道侧维持，这里只标记城市会话
for page in range(1, 4):
r = s.get(search_url(keyword, page, city), timeout=15)
parse(r.text)
s.close()
每个城市分配固定的隧道端口，会话的有效期设在120秒——够完成一次完整查询，又不会因为粘太久导致IP被单点针对。这个时长是我们反复调了三轮才定下来的：60秒会截断翻页，300秒则故障隔离变差。
验证效果与选型结论
方案上线后跑了两周，验证码率从28%降到1.2%，更重要的是排名数据的日间波动从±40位收敛到±3位以内。业务方终于敢拿这份报表去做排名趋势分析了。成本方面，每天15万次请求、隧道代理16元/天起的方案，加上动态IP做峰值补充，月账单稳定在1300元左右，比我最初迷信的纯住宅IP方案省了将近六成。
要说边界：这套方案在我们每天15万次这个量级够用。如果你一天要跑千万级查询，城市会话的调度层得单独抽出来做成有状态服务，否则端口数会成为瓶颈。另外别指望任何一家服务商的城市定位精度能上95%，剩下的误差只能靠交叉校验和历史排名平滑来兜。
选代理这件事，我现在的判断标准很朴素：先看城市级定位能不能被验证，再看会话粘性稳不稳，价格反倒排第三。我最近这个项目用的是蚂蚁代理的隧道方案，主要图它城市覆盖和延迟稳定，具体选哪家还是得结合你自己的查询量和城市粒度去压测，别人的报表参考价值有限——毕竟我前面那三家翻车，都是在别人推荐里看着数据最漂亮的那几家。