摘要

  • 同一托管者在同一个IP地址后最多连接2个软件探针，在同一个BGP可见前缀内最多连接4个；跨托管者计算时，同一个IPv4前缀最多32个，同一个IPv6前缀最多64个。
  • 规则公开说明了系统成本、密集部署的有限新增价值、例外渠道和阈值可调整性；尚未公开连接某一时刻BGP状态与某一次暂停决定的可复核记录。
  • 一份保护隐私的内部／托管者凭据，应绑定决定时间、路由观察范围、解析出的前缀、计数、触发层级、解除条件与例外复核；公众层面则只需延迟或分组后的汇总结果。

四个数字，四种计数关系

RIPE Atlas需要的不是探针数量本身，而是有差异的观测位置。每个连接中的探针都会消耗中央系统资源；同一网络、同一地点部署过多软件探针，所得结果也可能高度相似。另一方面，探针保持在线会为托管者带来可用于自定义测量的credits。平台既要鼓励参与，也要防止奖励机制把“多开进程”误当成“增加视角”。

2026年4月29日的上线通知把这种权衡写成四条上限：同一托管者、同一IP地址最多2个软件探针；同一托管者、同一个“BGP所见”IP前缀最多4个；不论托管者是谁，同一IPv4前缀最多32个，同一IPv6前缀最多64个。超过上限的探针不能连接，直到同组其他探针退出。

2、4、32、64不是同一测试的不同严厉程度。2把账户和地址绑定；4把账户和路由前缀绑定；32与64跨越账户，在整个前缀内计数，同时区分地址族。一台探针可能通过地址层，却在账户前缀层或全局前缀层被拦下。因此，有意义的状态不能只有“farming violation”，还要说明究竟是哪一个集合、哪一条上限起了作用。

RIPE NCC没有把这些数字写成不可改变的自然常数。通知明确说，上限以后可能调整。它也承认一种边界情况：同一用户的多台探针看起来来自同一网络，实际却在地理上相距很远；托管者可以发邮件解释，请求放宽限制。当时的估计是13名托管者的71个探针会受影响。这个数字只属于4月29日的部署判断，既不是今天的存量，也不能证明71个探针后来全部被暂停。

真正改变证据性质的是“BGP所见”四个字。规则没有简单拿注册分配、整个ASN或用户填写的地点当成操作边界，而是采用可观察的路由状态。这比行政标签更贴近网络，但也更会移动：更具体的路由可能出现，聚合可能恢复，公告可能撤回，起源AS可能变化，不同观测点还可能看到不同结果。设备没有搬家，账户没有转移，物理接入没有改变，计数所用的前缀边界仍可能改变。

这是一项网络机制推论，不是已经发生的RIPE Atlas事故。现有资料没有证明某个探针仅因BGP变化而被暂停或解除；也没有说明执法逻辑究竟采用哪一个路由源、哪些采集器、怎样的可见性门槛、什么时间点或怎样的前缀选择规则。不能把未知填成故障，但应把这些坐标保存在决定记录中。

大型接入网提出了真正的反例

在公开邮件讨论中，Robert Scheck很快问到AS3209与AS3320。他回忆过一次排障：处于同一个BGP可见前缀内的不同探针，表现并不一样。

这不能证明每一个额外探针都不可替代，却足以拆开两个常被混同的概念。“同属一个全球路由前缀”不等于“拥有相同测量视角”。大型接入网络在同一外部公告下，可能包含不同内部路径、汇聚设备、策略和故障域。前缀是控制上方便的近似，不是实验同质性的定义。

RIPE NCC在官方回复数据中的回答很克制：现有限额是按当时部署情况选择的，目的在于不影响这些大网络通常连接的软件探针数量；团队会继续观察，并可能让大前缀获得更多余量。这说明前缀规模是已知调节面，却不是对AS3209、AS3320或所有大ASN承诺特殊配额。

讨论还提出了一个更直接的问题：托管者会看到明确原因，还是只能看到“Disconnected”？RIPE NCC当时承诺增加专门标签，并在启用措施前联系那13名预计受影响的托管者。7月15日网站更新说明如今写明：探针概览会告知托管者，其探针因farming violation而处于hold状态。

这个改进很重要。它把主动接入控制与防火墙、线路或控制器故障区分开来，避免托管者沿着错误方向排障。但标签仍不是凭据。它没有说明触发的是2、4、32还是64，系统当时解析出什么前缀，组内有多少探针，也没有给出下一次复算时间。

展示前缀，不等于解释决定

现行探针管理FAQ再次列出四项上限、“BGP所见”前缀和地理分散例外渠道。探针、托管者与赞助者FAQ则补上激励背景：在线探针为托管者产生credits，RIPE Atlas追求拓扑多样性，并明确要阻止credit farming。

公开的探针列表API文档包含prefix_v4与prefix_v6字段。它们能描述探针处于哪个前缀，却不能自动回答一次暂停为何发生。已审查文档中没有一个公开对象，把前缀字段、决定时刻的路由状态、组内计数、阈值层级和复核结果连接起来。

这也不意味着全部反滥用逻辑都应公开。精确源IP、账户关联和便于试探规则的细节需要保护。应区分两种透明度：RIPE NCC与受影响托管者需要足以复现决定的私有记录；研究者与公众需要不暴露个人部署的汇总指标。无需在“全部秘密”和“全部公开”之间二选一。

RIPEstat的BGP State文档在这里提供的是证据语法，而不是Atlas实现说明。一项可复算的路由观测可以注明资源、时间戳、采集器选择、来源标识和查询时间。没有证据表明防集中机制使用RIPEstat、RIS、全部RIS采集器或同一种计算。这个例子只说明，“BGP所见”完全可以拥有比一句话更精确的坐标。

一份不帮助规避的暂停凭据

私有凭据首先记录决定时间、地址族和经过保护的源地址表示；接着保存当时解析出的前缀、路由状态时间与数据观察边界。如果存在多个覆盖或竞争公告，还要写下选择规则，而不是让托管者事后猜测。

第二部分指出触发层级：是同一托管者在同一IP后的第3台，同一托管者在前缀内的第5台，IPv4组内的第33台，还是IPv6组内的第65台？决定前计数和当时有效上限必须成对出现。多个连接同时到达时，还应留下稳定排序规则。

第三部分说明怎样解除。“直到其他探针退出”适合作为政策摘要，却不足以指导运营：何时重算？路由变化是否触发重评？有没有队列？最终是哪一个事件让探针恢复连接？例外记录应包含申请时间、理由类别、处理结果、复核者与失效日期，但不公开敏感说明。

公众报告可以更简洁：按地址族与阈值层级统计暂停和解除，披露等待时长分布、例外申请及结果、阈值修改带来的变化，以及因BGP边界变化而发生的重评数量。数量太小时，可以分桶或延迟发布以避免识别托管者。

这份凭据是Theo March的编辑建议，不是假定RIPE NCC没有内部日志，也不把所有超过阈值的托管者称为滥用者。产品标签指向一种控制状态，不能单独证明人的主观意图。

来源