人在上海，IP 查询却显示另一座城市；两个网站查询同一个地址，一个给出美国，另一个显示加拿大。看到这类结果，直觉上会觉得“总有一个数据库错了”。但在比较数据库之前，值得先确认：你比较的是同一个地址、同一种位置，还是几个名称相近、含义不同的字段？
IP 定位是对网络地址位置的估计，不是设备定位。不同平台使用的数据来源、更新时间和位置粒度可能不同；位置不一致，应先核对地址与字段，再判断是否需要纠错。
这个顺序很重要。否则，你可能把网络出口的位置当成自己的位置，也可能拿注册机构所在地去反驳城市级定位，最后给错误的地方提交修改请求。
“归属地”这个词，可能包含四种不同信息
许多查询页面只写“国家”“地区”或“归属地”，没有直接说明数据含义。实际上，下面这些信息不能相互替代。
你看到的信息 | 它描述的对象 | 比较时应注意什么 |
|---|---|---|
IP 地理定位 | 数据库估计的地址使用位置或网络出口位置 | 是否有定位范围、置信度和更新时间 |
资源注册信息 | IP 地址资源及相关组织的注册记录 | 注册信息不等于终端设备的位置证明 |
浏览器或设备定位 | 获得相应权限后取得的设备位置 | 可能使用 GPS 等设备能力，并非只查 IP |
网站提供的本地内容 | 服务根据自身逻辑选择的地区内容 | 还可能受到账号设置、语言或历史偏好的影响 |
ARIN 对 Whois/RDAP 的介绍解释了注册信息的查询用途。它与地理数据库估计“这个地址现在在哪里使用”，属于不同的数据层。
MDN 的 Geolocation API 文档则说明，网站在取得用户授权后，可以通过设备可用的定位能力获取位置。因此，地图应用知道你在哪条街，并不表示另一家 IP 查询网站也应该给出同样的精度。
为什么同一个地址会对应不同的定位结果？
地址的使用情况变了，数据库不一定同时更新
地址资源可能被重新分配、转租或用于新的网络出口。定位服务发现变化、核实变化和发布更新，需要各自的流程；使用离线数据库的网站，还需要把新版本实际部署到自己的系统中。
因此，“数据提供方已经修正”与“所有使用这份数据的网站都已更新”，是两件事。持续看到旧结果，可能发生在数据提供方，也可能发生在使用方的本地数据库或缓存环节。
这里没有一个适用于所有平台的固定更新时间。不能因为等了一天还没变化，就断言提交无效；也不能承诺改完一处，其他平台会在同一时间同步。
网络出口不一定就在用户附近
移动网络、企业网络和 VPN 等环境，会让设备所在位置与公网出口位置分离。地理数据库有时能够较好地判断出口位置，却无法据此定位使用这个出口的人。
MaxMind 的定位精度说明专门讨论了移动网络和隐私网络等场景，并明确指出，IP 地理数据不足以识别某个具体家庭、个人或街道地址。
所以，人在 A 城而出口被定位到 B 城，不一定是线路异常。应先弄清你希望查询的是设备位置，还是外部服务看到的网络位置。
两个平台提供的精度不同
一个平台给出国家，另一个给出城市，不代表后者一定更准确。更细的字段，可能只是一个范围中的代表点；页面没有展示定位半径，也不意味着这个半径不存在。
即使地图标记看起来落在某栋楼上，也不能据此推断服务器或用户就在那栋楼里。经纬度保留更多小数，只增加显示精度，不会自动增加数据准确度。
如果数据源提供定位范围，应把点和范围一起阅读。如果没有，则应避免把一个城市名理解为经过现场核实的位置。
同名网络，不代表每个地址的用途和位置相同
一个运营组织可以在多地开展业务。同一个 ASN 之下，也可能包含不同地区、不同用途的地址段。
组织名称和 ASN 有助于核对网络背景，但不能单独把整个网络中的地址定位到一个城市。反向 DNS 中带有某座城市的缩写，也只能作为线索；主机名可能沿用旧命名，不能取代其他证据。
排查之前，先把“同一个 IP”确认清楚
最常见的比较错误，往往不在数据库里，而在查询对象上。
先复制完整的公网地址，不要只记住国家和运营商。特别要确认，两个页面是否分别展示了 IPv4 和 IPv6：它们不是同一个地址，不应该直接拿来衡量两家数据库是否一致。
同时记录查询时间，并确认网络设置没有在中途变化。代理自动选择线路、移动网络重连，或者浏览器与其他应用使用不同的代理规则，都可能改变被观察到的出口。
可以先通过 CHA.LA IP 查询记录当前结果，再把同一个地址作为明确的查询对象进行比对。如果你输入的是域名，还要留意它可能解析到多个地址；比较域名返回的不同服务器，并不等于比较同一个 IP。
如何把定位差异整理成可处理的问题？
把截图堆在一起说“你们不准”，通常不如下面这组信息有用。
完整的被查询 IP，以及 IPv4 或 IPv6 类型。
查询时间和时区，避免把不同时间的结果当成同时观测。
每个结果的字段名称：注册国家、定位国家、城市，还是其他位置。
数据来源、版本或更新时间；无法获取时如实标注未提供。
你认为哪里有误，以及支持这一判断的材料。
例如，“两个平台对同一个 IPv4 的定位国家不同”比“两个网站的归属地不一样”更具体；“新分配给我们的网段仍显示以前的城市”则更接近一个能由网络提供方与数据维护方核实的问题。
材料也有强弱之分。服务合同中的交付地区、网络运营方的说明和可核实的资源使用信息，通常比服务器操作系统设置的时区更能说明问题。时区可以修改，不能靠它证明物理位置。
纠错应该找谁，而不是向所有网站重复提交
你是普通宽带或移动网络用户
先问运营商是否存在集中出口、跨地区网关或近期地址分配调整。如果网络出口本来就在其他地区，修改地理数据库也不能把实际路径变成本地出口。
如果只有某个应用的内容地区不符合预期，而多家 IP 数据库的结果一致，还应检查该应用的位置权限和账号地区设置。此时，问题未必出在 IP 数据库。
你租用了代理、VPS 或固定公网地址
请提供方说明实际交付方式和地区，并核实地址是否刚迁移或重新分配。不要仅以销售页面上的地区选项作为最终位置证据。
如果纠错涉及整个前缀，由控制该资源的网络运营方统一处理通常更合适。Geofeed 可以帮助网络运营方发布前缀地理信息，但 RFC 8805也明确保留了使用方进行权威性与准确性核实的空间；发布一份文件不是对所有数据库的强制更新指令。
你已经明确知道出错的数据来源
使用该数据源的官方渠道。例如，MaxMind 在其文档中提供了地理数据纠错入口。按要求提交能够核实的事实，而不是要求它把地址改成你希望显示的地区。
纠错是让数据接近真实使用情况，不是用来制造某个国家或城市的虚假归属。提交时也不需要公开家庭精确地址、账号密码或管理后台截图；只向可信的受理方提供必要资料。
修正之后，如何确认问题真的解决了？
保留提交前的记录，等维护方确认处理后，再查询同一个地址、同一个字段，并检查原先受到影响的网站是否也采用了新结果。两者可能并不同步。
如果 IP 数据已经变化，但某个服务仍显示旧地区，应把问题转向服务使用方：它是否使用其他数据源，是否保留了缓存，是否还有账号层面的地区设置？继续修改已经正确的数据，往往没有帮助。
至于服务能否使用，需要通过场景检测和正常的实际访问另行验证。定位正确，不等于服务一定开放；服务可访问，也不能反过来证明城市定位正确。
IP 地理信息适合帮助你理解网络背景、发现明显偏差和发起纠错。把它当作一个带有来源与精度边界的判断，而不是一张精确到街道的地址证明，才更接近它真正的用途。
定位国家不同的跨国网络：注册国家、Anycast 与出口位置
先看一个假设场景：某跨国服务商把地址资源登记在加拿大，实际服务部署在美国，商业定位库与登记查询因此显示不同国家。这里不需要假设 Anycast，也不能仅靠国别差异确定任播。应先区分读到的是注册国家、商业位置估计，还是某次请求实际观察到的服务节点；它们描述不同事实，无法只靠“两个国家不一致”判断谁错了。
注册国家源自 RDAP 或 Whois 数据库中的资源注册记录，描述的是地址块的行政管理归属，而非终端设备所在地区。例如，一个注册在加拿大、但长期由美国数据中心使用的地址段，地理数据库可能给出美国城市；而注册国家仍显示加拿大。两者属于不同字段，不应直接比较。在查看多个查询结果时，应先确认页面标注的是“国家”（country）、“注册国家”（registered country）还是“位置”（location）。
Anycast 是另一种需要独立证据的可能性。同一服务地址可由多个位置提供服务，路由策略决定当前请求到达的实例，但不保证选中物理最近的节点。只有运营方说明、多位置测量或实例识别等证据支持时，才适合讨论任播对定位的影响。两个商业库显示不同国家，本身既不能证明 Anycast，也不能排除数据库陈旧、分配变化或普通跨国部署。
核对时，先查看 RDAP 的组织、范围和事件，再把 BGP 观测作为路由背景。单个 ASN 可覆盖多国，同前缀出现多个起源 ASN 也有多种解释，都不能单独确定服务所在城市。若能取得运营方区域说明、受维护的 Geofeed 或多点测量，应注明各自的时间与范围，逐步缩小判断，而不是用登记国家直接否定商业定位。
排查时，应先记录完整 IPv4/IPv6 地址、查询时间以及每一家平台给出的字段名称。如果某个地址属于 Anycast 或跨国云网络，不要急于提交纠错，而是查看该前缀的路由宣告和网络运营方公开文档。任何“这里肯定错了”的判断，都需要结合注册信息、BGP 观察和实际出口证据才能形成。更多关于 RDAP、ASN、BGP 与位置证据的关系，可阅读 IP 证据与定位指北。
纠错申请：证据层次、时间记录与传播边界
纠错材料要与具体字段匹配。运营方针对该地址范围的部署说明、受维护的 Geofeed 和服务交付地区，可提供使用位置线索；延迟、traceroute、反向 DNS 则提供辅助观测。BGP 控制平面记录不会直接给出服务器物理位置，不能把它列为确定机房所在地的证据。各类材料都应核对真实性、更新日期、适用范围和是否针对当前地址，而非设一个放之四海而皆准的权威排序。
较弱但可参考的材料包括：用户报告、服务器操作系统时区设置、网站内容语言等。操作系统时区可以随意修改，不能证明设备物理位置；网站语言或账号地区设置更可能反映内容偏好，而不是 IP 归属。提交纠错时，不要上传家庭精确地址、账号密码或管理后台截图；应提供足以让数据维护方判断地址使用位置的公开或运营侧资料。
每次查询都应记录时间戳和时区。以下是假设案例：某地址在 2024 年 3 月被重新分配给新地区，但到了 5 月，地理数据库仍未更新。如果提交纠错时引用的是 1 月的旧截图，维护方可能认为材料已经过时。记录同一地址在不同日期的查询结果，还能帮助区分单一来源突然更新与多个来源逐渐传播的变化。提交“旧记录”与“新记录”的时间线，并注明每份结果的数据来源，可以帮助维护方核对材料；这不代表纠错一定获批，也不保证处理时间。
数据提供方和网站使用方是不同的更新环节。MaxMind、IP2Location 等数据源可能先更新自己的数据库，但使用这些数据的网站还需要下载、部署并可能设置缓存。因此，数据源显示新结果而某个网站仍显示旧结果，并不一定是数据源没改。遇到这种情况，应分别确认：数据源是否已修正；该网站使用的是哪一版本；网站是否设置了自己的缓存或回退逻辑。
任何纠错渠道都不应承诺“修改后其他平台会在固定时间内同步”。Geofeed 发布或官方修正仅仅是数据更新链路的起点。某些离线数据库可能数月才发布一次更新，某些网站可能使用自建或第三方数据而不是直接订阅数据源。你不能期望一个提交请求同时改变所有查询结果。成功提交后，应在新版本发布后再次查询同一个地址、同一个字段，并在至少两个独立时间点确认。若确有平台长期不更新，应针对该平台的数据使用方式提出询问，而不是反复重复提交已经正确的数据。
最后，纠错目标是让数据更接近真实的网络使用情况，而不是把地址改成你希望显示的国家或城市。如果证据不足以证明位置错误，或者数据源已表示该地址属于 Anycast 或动态出口，那么继续提交可能不会有效果。你可以通过 位置与数据方法 进一步理解地理数据库如何更新和验证。
