你每次点开网页、刷视频的时候，数据会在全球几十台路由器之间跳转，最终抵达目标服务器。指挥这一切的是互联网的核心协议 BGP (边界网关协议)。
但很少有人知道，这套诞生于网络互信时代的协议天生缺少内置信任机制，一旦有人意外或恶意宣告不属于自己的 IP 地址段，流量就会被悄悄拐走，也就是行业里说的前缀劫持。
为了堵上这个底层漏洞，互联网行业搭建了一套叫 RPKI（资源公钥基础设施）的实名认证体系。绝大多数人只知道全球五大官方 IP 管理机构在运营这套系统的核心节点，却很少留意到，全世界还散落着成百上千台独立的小型 RPKI 服务器。它们有的是云厂商搭建的，有的来自运营商、高校甚至普通技术爱好者，体量不大，却默默撑起了互联网路由安全的长尾部分。
最近荷兰 SIDN 实验室的研究团队，系统梳理了这些小型服务器的全貌。
简单来说，RPKI 的核心逻辑是让 IP 地址的合法持有者用密码学签名开出一份凭证，也就是 ROA (路由起源授权)。
这份凭证会明确写明某个 IP 前缀，只允许对应自治系统号 ASN 的网络来宣告。
支持 ROV (路由起源验证) 的路由器收到路由信息时，会对照这些签名凭证核对，对不上的宣告直接丢弃，从根源上堵住前缀劫持的漏洞。
整个体系的信任锚点是全球五大 RIR (区域互联网注册管理机构)，分别是负责北美的 ARIN、负责欧洲中东中亚的 RIPE NCC、负责亚太的 APNIC、负责拉美地区的 LACNIC 和负责非洲的 AFRINIC。它们负责分配 IP 地址，也运营着顶层的 RPKI 证书颁发机构。ROA 既可以直接在 RIR 的服务器上发布，也可以由地址持有者搭建独立的小型发布服务器对外公布。
研究首先要划定统计范围，团队最终选择用 ROA 数量作为判断标准，发布的 ROA 对象少于 1300 个的服务器，就归为小型服务器。
这个阈值不是随意设定的，而是根据所有已知 RPKI 服务器的 ROA 数量经验累积分布函数得出的。全球 RPKI 服务器的资源分布极度不均衡，五大 RIR 加上亚马逊 AWS 掌握了绝大多数 ROA，1300 这个数值刚好卡在头部玩家和其余主体的自然分界线上。
研究也特意排除了 AWS 的 RRDP (存储库增量协议) 服务器。亚马逊的 RPKI 发布架构设计非常特殊，和其他小型服务器差异很大，因此没有纳入本次统计范围，这种架构是否具备运营优势也留待后续研究验证。
放着免费的 RIR 服务不用，为什么要自己搭服务器
RIR 本身就给会员提供了免费的 ROA 发布功能，为什么还有人愿意花精力自己运营独立服务器？研究总结了五类核心原因，每一类都有明确的现实需求。
RPKIaaS (RPKI 即服务) 场景
厂商把 RPKI 做成托管服务，提供统一的 REST API 接口，客户不用挨个登录不同 RIR 的后台，也不用适配多套 API，就能自动化管理自己的路由资源。
简化跨 RIR 管理
如果一家机构的 IP 地址来自多个 RIR，比如同时有 ARIN 和 RIPE 分配的地址，自己搭一台统一的发布服务器，就能在一个界面里更新所有 ROA，不用维护多套账号体系。
科研与教学用途
高校和技术爱好者可以用 NLnet Labs 开源的 Krill 证书颁发机构软件，搭建测试环境做 RPKI 相关实验，验证配置方案，或者为部署研究提供数据支撑。
追求完全运营控制权
自己运营服务器就能完全掌握发布节奏、对象签名逻辑和底层基础设施，对安全要求极高或者有自定义路由架构的机构很有价值。
兴趣与学习驱动
自己动手搭一台 RPKI 服务器，是深入理解互联网路由底层架构的好方法，数据里很多体量极小的服务器，本质都是个人爱好者的测试环境。
两千多份 ROA 背后的真实数据画像
研究用 0.15.1 版本的 Routinator 工具 API，在 2026 年 4 月 23 日抓取了所有符合条件的服务器的 ROA 数据。最终的数据集包含 2467 条唯一 ROA，覆盖 3778 个前缀，涉及 1163 个不同的自治系统。
先看地址覆盖规模，有 ROA 覆盖的 IPv4 前缀共 1409 个，对应约 69.8 万个独立 IP 地址，占全球 IPv4 地址总量的 0.0162%。IPv6 前缀有 2369 个，覆盖的地址空间极其庞大。单看比例这个数字很小，但绝对不能轻视，这些前缀里包含了政府公共服务站点，比如安圭拉官方域名 gov.ai 对应的地址，还有很多日常使用的网络服务。这些服务器如果出故障，不会让整个互联网瘫痪，但会让对应网段的路由失去验证能力，部分用户的访问安全会打折扣。
再看有效性表现，判断标准基于 VRP (验证后 ROA 有效载荷)：有效是指存在覆盖对应前缀的 VRP 且起源 AS 匹配，无效是指有对应 VRP 但信息不匹配或者对象已过期，未知是指没找到对应 VRP 或者找到的 VRP 无效被丢弃。所有 ROA 对象里，91% 也就是 3444 条通过验证处于有效状态，1.2% 也就是 48 条验证不通过处于无效状态，剩下 7.6% 也就是 286 条属于未知状态，没有纳入后续分析。
这里有个值得欣慰的发现，所有未知状态的 ROA 对应的前缀，都没有在公网 BGP 里实际宣告。如果有宣告的话，这些前缀就会完全暴露在劫持风险之下。
另外还有两个关键配置数据，超过半数也就是 53.98% 的 ROA 设置了 maxLength 参数，也就是允许比 ROA 记载的前缀更细分的地址段被宣告。而在这些设置了 maxLength 的 ROA 里，有 19.6% 对应的细分前缀没有实际的 BGP 宣告，这类配置存在子前缀劫持的潜在风险。
这些服务器里藏着哪些特殊样本
研究统计了每台服务器的前缀数量、有效性、maxLength 使用情况、BGP 可达率甚至和恶意地址黑名单的重合度，不少服务器都呈现出很特别的特征。
最大也最复杂的r.magellan.ipxo.com
这台由 IPXO 公司运营的服务器是本次数据集里规模最大的，一共承载 776 个前缀，全部都是 IPv4 地址，且 100% 都在公网有 BGP 宣告。但其中 103 个前缀被标记为高风险，原因是设置了宽泛的 maxLength，但授权范围内的子前缀并没有全部做 BGP 宣告。
承载垃圾邮件基础设施的 repo.rpki.space
它只有 79 个前缀，却有 8 个前缀命中了 Firehol 一级恶意地址黑名单，Firehol 是整合各类滥用清单生成拦截前缀库的安全机构。进一步查询对应的 DNS 记录能发现大量邮件域名，基本可以确定这些前缀承载了垃圾邮件发送基础设施。垃圾邮件运营者自己搭 RPKI 服务器的原因也很直接，RIR 本身有完善的滥用治理机制，独立发布服务器相当于多了一层缓冲，会提高投诉和下架的流程成本。
全未知状态的 ca.nat.moe
这台服务器是个极端特例，它的 99 条 ROA 全部处于未知状态，也就是全部没通过密码学验证。但这些前缀里 100% 都有 BGP 宣告，还有 64 条设置了 maxLength，具体成因尚不明确。
配置奇特的rpki-01.pdxnet.uk
它将近一半的前缀把 maxLength 设成了 IPv4 的 / 32 或者 IPv6 的 / 128，也就是理论上授权了范围内每一个单独 IP 的宣告权。但实际上这个配置不会带来安全风险，因为公网 BGP 本身不接受比 / 24 更细分的 IPv4 前缀和比 / 48 更细分的 IPv6 前缀，它的底层前缀本身就已经到了这个边界。至于为什么要做这样的配置，目前还没有明确答案。
很多人会默认自建服务器的机构都是有跨 RIR 地址需求的，但实际数据呈现出更复杂的情况。
统计显示，有相当一部分服务器只发布单一 RIR 来源的前缀，其中又以来自 RIPE 的占比最高。对这类只用到单个 RIR 的运营者来说，简化跨 RIR 管理这个最常见的理由其实并不成立，它们选择自建服务器往往是出于其他需求。
而头部的服务器里，不少确实覆盖了多个 RIR 的地址资源，比如rpki.roa.net就同时覆盖了 ARIN、RIPE、APNIC 和 LACNIC 四大 RIR 的前缀，统一发布的优势非常明显。
被广泛误用的 maxLength 参数
maxLength 是本次研究里最值得警惕的问题。超过半数的 ROA 都使用了这个参数，而 RFC 9319 标准里明确不建议这么做。
举个例子，一条针对 103.0.0.0/22 的 ROA，如果把 maxLength 设为 / 24，就意味着不只是 / 22 这个大段，段内所有 / 23 和 / 24 的子前缀都被授权宣告。BGP 路由的规则是最长前缀匹配，也就是说如果有人用合法的 ASN 宣告其中一个 / 24 前缀，所有验证方都会认为这条路由是 RPKI 有效的。如果没有更快的路由竞争，相当于宽泛的 ROA 间接授权了一次子前缀劫持。
好在设置了宽泛 maxLength 的 ROA 里，约 80% 的子前缀都已经有对应的 BGP 宣告，实际暴露的风险有限。但剩下 19.6% 的 ROA，授权的子前缀完全没有对应的 BGP 宣告，这就属于有风险的配置。攻击者只要拿到对应 ASN 的控制权，就能宣告其中的子前缀，并且顺利通过 RPKI 验证。
理论上解决方法很简单，给每个实际要宣告的前缀单独做 ROA，把 maxLength 设成和前缀长度一致就可以。但这样会大幅增加 ROA 的总数，和 maxLength 原本用来聚合减少 ROA 数量的设计初衷正好相反。
BGPsec 几乎处于零部署状态
除了 RPKI 的起源验证，还有更进阶的 BGPsec 技术，它可以验证整条路由路径上每一个自治系统的签名，确保整条转发路径都没有被篡改。
尽管 BGPsec 早在 2017 年就已经完成标准化，但研究发现不管是小型服务器还是整个行业，BGPsec 的部署率都极低，整个数据集里只有一个自治系统发布了对应的路由密钥。这个现状也和行业内的普遍观察一致，技术标准化只是第一步，落地普及还有很长的路要走。
研究团队联系了其中一家规模较大的运营方 Axivora，它同时运营着 rpki.cc、krill.accuristechnologies.ca 等多台服务器。对方给出的答案很能代表爱好者群体的想法。
最开始搭建自己的 RPKI 发布基础设施，纯粹是因为作为互联网爱好者，想搞懂这套系统到底是怎么运行的。
Axivora 至今还持有两个专门用于教育和研究的 IPv6 /40 地址段，它们把更小的地址段分配给想拥有独立地址空间的个人用户，帮用户生成对应的 ROA 和互联网路由注册表记录，免去了用户自己申请自治系统号的麻烦。
搭建自有发布服务器最初就是为了深入理解 RPKI 生态，观察 ROA 怎么在互联网里传播同步。现在他们自身的业务前缀都已经改用 RIPE 的平台即服务，但依然保留了自有发布服务器，用来做研究、教学和各类实验。说直白点，就是觉得做这件事本身就很酷。
总的来说，小型 RPKI 发布服务器覆盖的只是互联网里很小的一片角落。它们承载的前缀总量不大，却包含了政府服务等关键资源，一旦出问题不会让全网崩溃，但会让部分网络的路由可验证性失效，极端情况下会导致对应网段无法访问。
从验证状态来看，整体情况还算健康，九成以上的 ROA 都能正常通过验证，绝大多数也都和实际的 BGP 宣告对应。唯一值得注意的是 7.6% 的未知状态占比偏高，还有待行业持续关注。
真正需要警惕的是 maxLength 的不规范使用。超过半数的 ROA 没有遵循 RFC 9319 的建议，虽然大部分没有实际风险，但仍有近两成的配置存在子前缀劫持的隐患。当然这个问题不止小型服务器有，大型发布服务器也可能存在同样的配置问题。
至于大家为什么愿意花精力自建服务器，跨 RIR 统一管理是最主要的动因，但绝不是唯一理由。科研、兴趣、控制权需求共同撑起了这片长尾生态，也让互联网的路由安全体系多了一层分布式的韧性。
相关链接：
blog.apnic[.]net/2026/07/15/whos-running-all-those-tiny-rpki-servers/
声明：本文来自黑鸟，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
