IP 归属地准确性实测

测试设计

我们选择 Cloudflare、Google Public DNS 和 Quad9 的公开递归 DNS 地址，是因为它们的运营组织与 ASN 容易核对，同时广泛采用 Anycast。Anycast 会让多个地区的节点宣布同一个 IP，用户通常连接到路由意义上较近的节点，而 IP 数据库只能给这个共享地址保存有限的地理标签。

• 检测时间：2026年8月21日 07:55（中国标准时间；API 记录为 2026-08-20 23:55 UTC）。
• 数据版本：DB-IP City Lite / ASN Lite 2026-08，许可为 CC BY 4.0。
• 查询路径：通过 iphelp站长工具箱 生产环境的 /api/ip-lookup 接口逐个查询，没有手工修改返回字段。
• 样本目的：观察网络归属与城市标签的稳定程度，不比较商业数据库的“谁更准”。

原始结果摘要

这里最值得注意的不是某个城市是否“正确”，而是同一运营组织的 IPv4 和 IPv6 样本保持了相同 ASN，却得到不同国家或城市标签。对 Anycast 服务而言，这并不证明两个请求真的分别到达悉尼和蒙特利尔，更不代表查询者本人位于这些城市。

哪些字段更适合排查

为什么 Anycast 会让“城市”难以定义

普通单播地址通常由一个网络前缀路由到相对固定的服务区域。Anycast 则允许多个节点从不同地点宣布同一个前缀，路由系统会按当前网络策略选择路径。节点可能扩容、撤下或改变上游，用户的实际落点也会随运营商和时段变化。

IP 数据库如果给 Anycast 地址保存一个城市，只能表达某种代表信息，无法同时列出每个边缘节点，更无法知道某一次连接最终落到了哪个机房。要判断真实网络路径，应结合 traceroute、往返时延、服务商诊断页面和目标方日志；仅凭 IP 库坐标画出的地图点不足以证明路径。

应用应该怎样使用 IP 归属数据

1. 始终显示不确定性。界面应写“数据库归属”或“近似位置”，不要写“你的实时位置”。
2. 保留数据版本与来源。同一 IP 在数据库更新后可能改变标签，排查历史问题时需要知道当时使用的版本。
3. 不要单字段做高风险决定。登录风控、付款、封禁或合规判断应结合账户行为、设备信号和可申诉流程，不能只凭城市不一致。
4. 优先按需求选粒度。只需要识别网络运营商时，ASN/组织可能已经足够；没有业务必要就不要展示精确坐标。
5. 允许用户纠错。地址转让、运营商调整和数据库更新存在时间差，产品应提供来源说明与反馈入口。

复现与后续更新

可在首页 IP 查询逐个输入上表地址，结果页会显示当前数据源和版本。数据库按月更新，因此未来结果可能变化；变化本身也是 IP 地理数据库维护过程的一部分，而不是应被隐藏的错误。

1.1.1.1
2606:4700:4700::1111
8.8.8.8
2001:4860:4860::8888
9.9.9.9

如果你使用其他数据库复测，请同时记录数据库名称、版本、查询日期和字段定义。只贴一张地图截图，无法区分数据源差异、Anycast 标签和真实路由变化。