代理IP查到上海却在江苏？城市归属地不一致我怎么处理

上周一个做本地生活数据的朋友来找我，说他们明明选了上海的代理IP，接口返回里也写着上海，可拿IP去几个查询网站一看，归属地跳到了江苏。他第一反应是代理池在“假定位”，差点把套餐退了。我让他先别急，把请求参数、返回字段和目标站页面各截了一张图。第二天问题找到了，IP没骗人，是我们把三个不同层面的“城市”混在一起看了。

先弄清楚：你说的城市，是哪一层城市

我们平时说“上海代理IP”，至少可能指三件事。第一层是代理服务商的池子里，这条IP是从上海节点放出来的；第二层是运营商给这个IP段登记的实际归属；第三层是目标网站自己判断你在哪，它可能看IP，也可能看请求参数、账号资料、Cookie，甚至只看页面上的城市选择。

这三层经常对不上。代理池按城市调度，第三方IP库按自己的数据更新，目标站又可能用另一套商业IP库。你拿A数据库的结果去质问B池子，就像拿高德的位置去证明百度地图错了，能对上最好，对不上也不奇怪。

我自己碰到的三种情况

第一种是IP库更新慢。运营商新放出来的段、刚调整过的段，第三方库里还挂着旧城市。这种IP实际出口没问题，但你去查归属地，显示的是几个月前甚至几年前的信息。短效池里这种情况不算多，可一旦碰上，很容易被误判成“城市参数没生效”。

第二种是移动网络和骨干出口带来的偏差。有些IP从上海接入，出去的时候走的是江苏或浙江的骨干，查询库按出口段登记，就显示成了外省。做本地采集的人最容易被这个绕进去，因为手机端网络本来就没有固定“家门口出口”这回事。

第三种最常见：目标站根本没用IP判断城市。有的网站让你先选城市，然后把这个选择写进Cookie；有的接口要传city参数；还有的登录后按账号地址展示内容。你只换了IP，页面上的城市没换，看到的当然还是原来的结果。

别拿第三方查询网站当判决书

我现在的做法是先看代理接口自己的返回。比如带城市筛选提取时，把返回格式设成带省份、城市和运营商的字段，先确认池子确实按城市给了IP；然后用同一批IP去目标站做实际访问，看页面上的城市、价格、门店列表有没有变。第三方查询网站只当旁证，不当结论。

GET /Tools/IP.ashx?action=GetIP
    &OrderNumber=你的订单号
    &protocol=1
    &qty=20
    &city=上海
    &split=

# 记录每条IP返回的 province / city / isp
# 再用同一批IP访问目标页，确认页面城市是否真的变化

这里有个细节：不要只测一条IP。城市池里偶尔混进一两条归属地不准的，很正常；抽20到50条，看整体比例才有意义。我一般会要求目标页连续三次都命中目标城市，才算这个城市方案可用，单次成功可能只是缓存或巧合。

我是按这个顺序排查的

先固定样本：同一时间提取一批同城市IP，记录IP、运营商、返回城市和目标页结果。然后把请求里的城市参数、Cookie、登录态逐项对照，确认不是程序还在用上一次的会话。接着换一个不依赖登录的目标页复测，排除账号画像的干扰。最后才去比对第三方IP库，看看是单条偏差还是整批都偏。

如果整批IP在目标站都能正常显示目标城市，只是某个查询网站显示外省，我基本不会处理，任务能交差就行。反过来，如果目标站一直按另一个城市返回，那就要考虑是不是池子城市不够细，或者目标站压根不吃IP这一套，得改请求参数和会话逻辑。

什么情况下才值得换服务商

我的判断比较土：同一城市连续换几批IP，目标页还是稳定跑到别的城市，或者提取出来的IP大批连不上、运营商也和标注不符，这才说明池子质量有问题。只是查询网站写着另一个城市，先别折腾，采集结果比查询网站的脸色重要。

另外，做本地生活、区域价格、门店库存这类任务，城市IP只是其中一环。请求里最好明确带上城市参数，必要时把Cookie和页面上的地区选择一起处理。只换IP不改请求，很多时候等于白忙。

我现在用的配置

我平时用星月代理的城市池，全国300多个城市可以选，短效IP自动轮换，提取接口支持按城市和运营商筛，返回里能带省份、城市字段，白名单和API实时提取也都有。可用率标在90%以上，实际跑下来大部分时间够用。新用户可以先领免费试用IP，拿二三十条样本按上面的顺序测一遍，再决定要不要上量。

城市归属地对不上，不一定是代理的问题。先把池子、运营商出口和目标站定位分开看，再用目标页结果做判断，能少走很多弯路。

代理IP的城市不是一条绝对属性，池子出口、运营商登记和目标站定位各有各的口径。用同城样本加目标页实测，比盯着第三方查询结果反复换IP更靠谱。