IP 定位不准？如何排查并纠正错误的地理位置

核心要点

• “位置不对”可能出自三个不同的来源：IP 地理位置数据库、浏览器 Geolocation API，或者网站早先存下的你的信息。改错了层，什么都不会变。
• 每个网站用的数据库各不相同，所以先看看你的 IP 在多家服务商那里分别是什么结果，并弄清出问题的网站用的是哪一家。
• 普通用户可以向各家服务商分别提交纠错；生效要等服务商的更新周期，通常需要数周。
• 掌握地址段的人可以发布 geofeed（RFC 8805），并在注册记录中引用它（RFC 9092）。这是唯一能把真实信息一次性推给所有使用方的办法。
• 移动运营商、企业与云出口、卫星链路，以及 VPN 或中继，都不是你能“纠正”的错误。

第 1 步：弄清是哪一层出了问题

人们说“我的 IP 位置不对”，其实可能指三件互不相干的事：

1. IP 地理位置数据库对你的 IP 怎么说。 这是服务器端的估算，不需要任何授权。本指南能改善的只有这一层。
2. 浏览器 Geolocation API 怎么说。 基于 GPS 或 Wi-Fi 定位，需要权限弹窗授权，通常很准。如果地图能精确到你所在的街道，来源是它，而不是你的 IP。
3. 网站存了你的什么信息。 账号所在地区、账单国家、保存的收货地址，或者上次访问时写入的 Cookie。即使你的 IP 早已不指向那座城市，网站仍可能显示旧城市。

如果只有登录后才显示错误位置，或者换了网络错误依旧，就怀疑第 3 层，去改账号或个人资料设置，任何数据库纠错都动不了它。第 1 层如何得出位置（注册机构分配、商业数据库、WHOIS、拓扑推断），请看 IP 地理位置的准确度；本文讲的是怎么做，而不是原理。

第 2 步：确定真实情况

打开 IP 情报查询，记下你的公网 IP 以及它对应的国家、地区和城市。然后再用两个以上相互独立的地理位置查询来对照。各家服务商的结果经常不一致，而网站只会查询其中一家。

你要看的是：

• 所有服务商一致且正确。 你的 IP 没问题，问题出在第 2 层或第 3 层。
• 所有服务商一致但错误。 很可能是注册机构或地址分配层面的问题，下面的 geofeed 路线最重要。
• 服务商之间不一致。 只有部分数据库已经过时。要先弄清出问题的网站用的是哪一家（通常能在其隐私政策里看到，或向客服询问），才谈得上修正。

也要看看你的 IP 最近是否变过。新地址可能继承上一个持有者的过时数据，参见为什么你的 IP 地址总在变。

第 3 步：向服务商提交纠错

对普通用户来说，现实可行的办法就是告诉数据库。多数主流地理位置服务商都有公开的纠错或“更新我的 IP 位置”表单，少数还接受网络运营方直接提交。这里不放链接，你可以搜索服务商名称加“correct IP location”。

需要有这些预期：

• 必须逐家通知。 在一家修正，不会传到其他家。
• 需要时间。 纠错随服务商的更新周期生效，通常是几天到几周，而不是几分钟。
• 说得具体。 提供 IP 或网段、你认为正确的位置，以及可供核实的依据，例如你的 ISP 名称和服务范围。
• 几周后复查，用当初显示错误的同一个查询。

如果地址由 ISP 分配，也请联系 ISP：服务商读取的注册数据掌握在他们手里，网络运营方提交的纠错比终端用户的更有分量。

第 4 步：发布 geofeed（如果你掌握该地址段）

如果你运营网络、托管服务，或拥有自己地址空间的企业，有一条权威途径。geofeed 是你自己发布的纯 CSV 文件，把你的网段映射到地理位置。RFC 8805 定义了格式：每行一个网段，以 # 开头的行是注释。

# prefix, country, region, city
192.0.2.0/24,US,US-CA,San Francisco
2001:db8::/32,DE,DE-BE,Berlin

国家用 ISO 3166-1 alpha-2 代码，地区用 ISO 3166-2 代码，城市写普通名称；如果只想提供国家级数据，后面的字段可以留空。（示例网段是保留的文档用地址。）

单独一个文件只是一份声明，使用方需要找到它，并确认它来自地址持有者。RFC 9092 规定了做法（后来由 RFC 9632 更新，思路不变）：把 geofeed 的 URL 挂在该地址段的注册记录上，即在区域注册机构的 whois/RPSL 数据里加一个 geofeed: 属性或一行 remarks: Geofeed。支持 geofeed 的服务商会顺着注册记录里的引用去抓取文件。由于只有该地址段的维护者才能编辑注册记录，这个指针本身就能证明文件出自谁手；RFC 还定义了可选的 RPKI 签名，供希望把文件与地址持有者做密码学绑定的运营方使用。

意义在于：这是唯一能把真实信息一次推给所有使用方的机制，而不是一张纠错表单一张表单地填。需要如实说明的限制是：是否采用由各服务商自行决定，所以生效既不是即时的，也没有保证；当你迁移或重新编号网段时，geofeed 也必须同步更新。引用之前，请先检查文件的语法错误。

第 5 步：无法修正的情况

有些“错误”位置其实是网络按设计在运行，追着改只是浪费时间：

• 移动网络与运营商级 NAT。 你的流量从区域汇聚点出去，那里可能在另一个城市或省份。
• 企业、高校与云出口。 你显示在总部或数据中心所在区域，而不是你的工位。
• 卫星链路。 一个地面站可能覆盖极大的范围。
• 刚被重新分配的地址段。 数据库有滞后，只有上面的纠错和 geofeed 路线能缩短它。

各自的原因请看 IP 地理位置的准确度。如果问题出在移动运营商，实际的做法是：凡是需要你真实位置的场景，都依赖浏览器基于授权的定位。

第 6 步：VPN 或中继正在做它该做的事

如果你在用 VPN、代理，或 iCloud 专用代理这类隐私中继，显示的不是你的真实位置，恰恰说明它在正常工作，参见隐私工具对比。在提交任何纠错之前，先断开连接，再运行一次 IP 查询。

还有一点要知道：只有 IP 变了时，浏览器仍会报告你真实的时区和语言。它们与 IP 所在地对不上，本身就是一个检测信号，参见时区与语言泄漏和网站如何检测 VPN。所以纠错的目标是让你真实的连接得到准确的位置，而不是换成另一个。

从头到尾的检查清单

1. 判断是哪一层出错：数据库、浏览器 Geolocation API，还是账号中存的数据。
2. 如果是存储的数据，修改账号或资料设置，到此为止。
3. 断开任何 VPN、代理或中继，打开 IP 情报查询，读取你的 IP 和显示的位置。
4. 与另外两个地理位置查询对照，记下哪些是错的。
5. 弄清受影响的网站用的是哪个数据库。
6. 向每个出错的服务商提交纠错，附上网段和可核实的位置。
7. 如果你掌握该地址段，发布 RFC 8805 格式的 geofeed，并在注册记录中引用它（RFC 9092 / RFC 9632）。
8. 排除 CGNAT、企业或云出口以及卫星链路；如果属于其中之一，就别再纠错了。
9. 等几周，用同样的查询复查。

常见问题

纠正后的 IP 位置要多久才会显示？

通常是几天到几周，取决于各服务商的更新周期。每家服务商都要单独纠正，所以不同网站的更新时间也不同。

为什么手机和笔记本显示的城市不一样？

手机可能走的是移动运营商网络，流量经区域网关转发，而笔记本用的是家庭宽带。两个地址各自被定位，运营商的地址常常指向网关所在的城市。

我能自己改变 IP 位置吗？

对于数据库里错误的条目，你可以通过服务商表单或 geofeed 来纠正。本指南不涉及让网站相信你在别处；VPN 或中继是公开地做这件事，代价见上文。

浏览器定位和我的 IP 位置是一回事吗？

不是。浏览器 Geolocation API 在你授权后使用 GPS 或 Wi-Fi，通常很准。IP 位置是无需授权的估算，最多精确到城市。