摘要

  • 研究团队回看 2019 年至 2026 年 4 月的 RIPE Atlas 记录，发现 731 个探针至少一次未通过保守的“互联网速度”检验。
  • 研究者报告了 258 个当时仍触发检验的探针；103 名回复运营者中，93 人更新了探针位置。

地图上的钉子还在德国，数据包却像是从东南亚回来的。一个 RIPE Atlas 探针持续一年多把自己标在莱茵河附近，最短往返时延却不断拆穿这个坐标。2023 年 4 月，运营者终于把它移到文莱。网络早就把答案写在路上，只是地图更新得慢了些。

这不是地图软件的小瑕疵。探针位置本身就是测量输入。研究者用探针的时延推断网络、服务或 IP 地址大致位于哪里；如果测量起点被放错城市，漂亮的图表也会一本正经地把结论画错。

Katherine Izhikevich 等人分析了 2019 年 1 月至 2026 年 4 月的 RIPE Atlas 历史记录。研究识别出 731 个独立探针，占研究涉及探针的 2.4%；它们至少在某个时点表现出与登记位置不相容的时延。到 2026 年 4 月，仍有 155 个探针触发检验。每月数量从 2019 年 1 月的 22 个升至七年后的 155 个。

他们没有凭一条可疑 ping 就猜探针实际住在哪里。RIPE Atlas 的内置 DNS 测量会让在线探针每四分钟查询一次 13 个根服务器身份。研究团队复用这批历史数据：每月首日取三个时点的记录，并为每个探针与根服务器实例保留最短往返时间。光纤中的光速给出了物理下限；如果实际测得的最短时延，竟然比从登记坐标出发的理论最短时延还小，那个坐标就出了问题。

检验门槛设得很高：探针必须同时对至少两个由不同运营者运行的根服务器身份违反物理下限；计算中加入 100 公里的坐标误差缓冲，并排除 Starlink 探针，因为卫星链路可能快过地面光纤的参照值。研究也独立核对了根服务器位置。这些设计让结果更保守，报出来的是已被抓到的下限，不是所有错误坐标的总账。

随后，研究从论文走进了运营流程。2025 年 7 月至 2026 年 4 月，研究者经 RIPE NCC 报告了 258 个当时仍触发检验的探针。RIPE Atlas 随后通知运营者，允许他们接受或质疑更正。103 名回复者中，93 人更新了坐标，10 人对建议的更正提出异议。52% 的坐标更新发生时，探针已经至少 13 周持续触发检验。地理信息的工单队列，显然没有光速快。

有些探针只是搬家后忘了改位置；另一些似乎从部署之初就填错了。托管服务器又多一层麻烦：安装虚拟探针的人，未必知道租来的机器究竟放在哪座城市。十名拒绝更正的运营者中，有四人说探针运行在第三方虚拟服务器上。国家层面的判断可能说得通，城市坐标仍然对不上。

错误不会停在那颗钉子上。RIPE NCC 的 IPmap 使用 Atlas 时延估算 IP 地址所在城市。研究者在最近一年使用的 2,800 个探针中找到 28 个可能错位的探针；它们可能影响 98,000 个候选地址中的 1,125 个城市级估算。更早的一项评估中，2,000 个探针里有 33 个在观测期触发检验，可能波及 8,000 个候选地址中 4.3% 的城市定位。一个错误的测量起点，会把错误借给整条推理链。

RIPE Atlas 原本就提供位置争议按钮，也有“争议中”和“已解决”的系统标签。新研究给这套机制补上了持续、可复查的测量线索。好用的社区地图不需要每个坐标从第一天起就完美；它需要能发现坐标与物理世界打架，并把证据送到有权改记录的人手里。毕竟，光速不会替地图管理员填表，却很擅长揭穿没人搬家的地图钉。

来源： Izhikevich 等，《Rooting Out Incorrect RIPE Atlas Probe Geolocations》，arXiv:2409.19109v4；RIPE Atlas 官方文档：内置测量、探针地理位置、探针标签。