摘要

  • APNIC 的事故公告记录：2026 年 1 月 27 日 15:45 至 28 日 09:45（UTC+10），RDAP 服务受一次非预期的 Cloudflare 配置影响，共 18 小时。
  • 更严格的浏览器完整性检查，拦截了约 10% 带有“不符合常见浏览器 User-Agent”字符串的 RDAP 请求；这里的统计单位是请求，不是用户或软件数量。
  • 防御拒绝服务和滥用自动化是 APNIC 的正当职责。问题不在是否需要边缘防护，而在浏览器外观是否被赋予了超出其证据能力的准入权。
  • 2026 年 9 月的一次四类客户端抽样均取得相同 RDAP JSON；这只说明当时、当地、该端点的结果一致，不能证明历史细节或全局修复。
  • 一份不公开 WAF 规则的轻量凭据即可闭环：分别记录机器客户端类别、边缘处置、源站到达、协议响应以及配置上线和回滚时间。

先看现在：四种自我介绍，一份相同答案

2026 年 9 月 5 日 20:34 UTC，一组低频探针访问 https://rdap.apnic.net/ip/202.12.29.0。四次 GET 都请求 application/rdap+json，区别只在客户端如何自我介绍：一次不显式发送 User-Agent；一次使用明确标示用途的自动化 User-Agent；一次使用 curl/8.7.1；还有一次采用 Mozilla/Safari 风格的浏览器字符串。

四次响应都是 HTTP 200，内容类型都是 application/rdap+json，正文均为 3,857 字节，SHA-256 完全相同：d6983abd9266f7ac6d6a23b8b5cf67c186aae673a64030fc04e4e457837bb853。响应头显示，请求路径上仍有 Cloudflare。就这一时点而言，机器客户端没有因为诚实表明自身形态而得到不同的注册数据。

这是一项积极但很窄的事实。它没有覆盖其他资源类型、查询路径、HTTP 方法、来源网络、地理位置、边缘节点、访问速率或时间。它也没有复原 1 月的配置。四次相同结果不能证明所有客户端此后永远平等，更不能反向证明事故公告里没有写出的状态码、挑战页面或受影响软件。

探针真正的价值不在“验收一次后结案”，而在展示一种可重复的测量单元：同一查询、同一低速率、不同客户端类别，分别观察边缘与源站。要理解为何需要长期保存这项测量，必须回到 APNIC 自己记录的那 18 小时。

事故公告给出了机制，也留下了必要空白

APNIC 将事故开始时间记为 2026 年 1 月 27 日星期二 15:45，将结束时间记为 28 日星期三 09:45，时区均为 UTC+10。受影响服务是 RDAP，持续 18 小时。公告称，一次 Cloudflare 配置变更产生了非预期效果，执行了更严格的浏览器完整性检查。在此期间，带有不匹配常见浏览器 User-Agent 的请求中，约 10% 被拦截。

“约 10% 的请求”应当原样保留。它不是“10% 的 APNIC 用户”，也不是“10% 的网络运营商”。一个程序可能发出大量请求，一个组织可能运行多个程序，被拒绝后还可能重试。公告没有提供去重后的客户端数量，也没有列出哪些运营决策依赖这些查询。把请求占比直接变成人群占比，会让一个可靠数字承担它没有测量的对象。

公告也没有披露具体 User-Agent、规则阈值、边缘位置、响应状态或正文。缺少这些内容并非一定是透明度失败：安全系统有正当理由不公开可供绕过的细节。分析因此不应自行补写。不可以声称某个常见工具一定被拦截，也不可以断言所有非浏览器请求都失败。

但事故已经明确一项足够重要的事实：一部分请求在注册服务产生正常协议结果之前，就因软件外观被边缘层分类。源站日志可能看不到它们；只模拟浏览器的健康探针则可能顺利通过。于是“源站健康”和“机器客户端可达”成了两个不同问题。

最强的反方理由：边缘防护确实属于服务

APNIC 不可能通过接受无限请求来证明开放。RDAP 易于自动化，既方便资源核验、资产管理和滥用处理，也可能遭遇高频抓取、恶意机器人或拒绝服务攻击。注册机构有责任保护公共查询能力，让正常用户在压力下仍能获得结果。

APNIC 2020 年介绍新 RDAP 架构时说明，访问 rdap.apnic.net 以及相关国家互联网注册机构 RDAP 服务的流量先抵达 Cloudflare，再被代理到 Google Cloud 基础设施。Cloudflare 在这条链上承担负载均衡和 DDoS 防护。边缘层不是站外无关设备；对外部客户端而言，它就是运行中服务的第一道执行面。

Cloudflare 的 Browser Integrity Check 文档也说明了合理用途：系统会寻找常见于垃圾和滥用流量的 HTTP 头，并可能挑战缺少或使用非标准 User-Agent 的请求。把异常头部作为多项风险信号之一并不荒谬。产品文档还提供按规则、主机名或路径调整适用范围的方式。

因此，正确的问题不是“为何要使用 Cloudflare”，也不是“是否应关闭所有机器人防护”。问题更小：一条为交互式网站建立的浏览器启发式规则，是否误覆盖了以机器为正常客户端的协议路径？APNIC 将 1 月的效果称为非预期，说明答案不应被解释为有意的访问政策，而应被治理为配置范围与验证问题。

RDAP 的正常客户端本来就不像浏览器

APNIC 2021 年讨论 RDAP 能否取代 WHOIS 时，将它描述为通过 HTTP 或 HTTPS 传送的结构化 JSON，易于机器解析；同一个客户端能够处理多数 RDAP 服务的响应，HTTP 缓存还可降低重复查询成本。这种架构的价值，就在于程序不必为每个注册机构临时理解一套人机界面。

RFC 9082 规定了域名、名称服务器、实体、IP 网络和自治系统的统一 REST 查询方式。RFC 7480 规定 RDAP 如何使用 HTTP。浏览器内应用当然是合法客户端，跨源访问条款也为它们提供支持；但标准没有把浏览器设为唯一或更有资格的客户端。

命令行工具、软件库、网络资产系统、滥用处理平台和注册机构间流程都可以直接讲 HTTP。它们不携带完整浏览器字符串，并不表示查询语义错误。相反，明确写出工具名称往往比伪装成 Safari 或 Chrome 更有助于故障诊断与责任联系。

这就是浏览器完整性启发式与 RDAP 服务契约发生错位的地方。在网页环境中“不像浏览器”可能是风险迹象；在机器协议中，它同时也是正常客户端的自然形态。若规则不理解后一个语境，就会把诚实的协议参与方式当成异常。

User-Agent 能证明软件，不能证明授权

RFC 9110 对 User-Agent 的定义很克制：它携带发起请求的软件信息，由产品标识和注释构成，可帮助服务器调整响应和定位互操作问题。该字段由客户端自行声明。软件可以缩短它、改变它，也可以冒充另一种软件；规范甚至专门讨论了冒充的后果。

这个字符串不能认证操作者。它不会证明请求来自 APNIC 会员、网络工程师、研究人员还是恶意采集者，也不会说明查询目的、法律权限、合理速率或资源关系。一个熟悉的浏览器前缀不会授予访问权，一个冷门脚本名称也不会取消访问权。

这里不需要走到“永远不要看 User-Agent”的极端。它可以与速率、行为序列、网络信誉和认证状态共同参与风险判断。需要限制的是它的决策权限：弱软件信号不应独自获得硬准入权。

如果它获得这种权力，市场会迅速教会客户端撒谎。正常脚本发现写出真实名称会降低成功率，于是复制浏览器字符串；恶意机器人本来就会这么做。最终，过滤器看见的“浏览器”越来越多，却越来越不知道请求来自什么软件。安全规则以牺牲自身观测能力为代价赢得了短期一致性。

这也解释了为何“参与形式不等于授权”适用于技术边缘。User-Agent 描述怎样参与，不代表参与者拥有什么权限。真正的授权若有必要，应由认证、服务协议、速率政策和可验证行为来承担，而不是由外观代行。

限速、挑战与源站错误必须分栏记录

RDAP 标准并未承诺无限容量。RFC 7481 把可用性和拒绝服务视为安全问题，允许运营者节流单一客户端，并使用 HTTP 机制做认证和授权。RFC 7480 对“因速率而限制”给出了机器可读的路径：推荐 HTTP 429，客户端应降低请求速率，并在收到 Retry-After 时遵守等待时间。

这套语义让程序知道应该做什么。429 表示眼前约束是速率，而不是资源不存在或查询格式错误；Retry-After 则给出何时重试的线索。需要更高容量时，认证机制也比浏览器外观更接近真实授权。

但不能据此声称，1 月所有安全拦截都必须返回 429。机器人挑战与限速是两种控制，公告没有提供足够细节来判定每一项处置。合理要求是分类清楚：边缘因何处置、请求是否到达源站、源站给出何种 RDAP 结果。没有这三栏，就会把不同故障压成一个模糊的“HTTP 不成功”。

浏览器挑战若返回 HTML，即使状态码看起来成功，也不是 RDAP JSON。边缘直接拦截若未到源站，也不该从源站可用率中消失。协议监控需要理解内容类型与执行层，而不仅是端口能否建立连接。

凭据不必公开锁芯

APNIC 无须发布 WAF 表达式、声誉列表、阈值或绕过方法。真正缺少的是服务结果凭据，而非安全配置副本。它可以由四类自有低频探针开始：无 User-Agent、明确命名的自动化客户端、常见命令行客户端和浏览器。

每次探测分别保存边缘处置和源站到达状态，再记录 HTTP 状态类别、RDAP 内容类型、响应类别、延迟，以及在限速场景下是否有 Retry-After。这样，源站正常而边缘拒绝时，事故不会在统计中消失；浏览器探针通过而机器探针失败时，差异也会立即显现。

第二部分是变更谱系：配置标识、影响范围、责任人、复核人、上线时间、回滚时间和回滚后验证。公开内容只需足以证明浏览器导向规则没有无意间覆盖整个 RDAP 主机或路径，不必披露攻击者可利用的精确条件。按客户端类别发布聚合拦截占比，也可以在不暴露阈值的前提下显示漂移。

APNIC 已有“用户视角”的测量语言。其 2025 年第二季度注册服务可用性文章，将 RDAP 成功测试定义为五秒内得到非错误 HTTP 响应，并用成功测试数除以总测试数。为这项度量增加客户端类别维度，不是推翻原公式，而是让“用户”更接近协议的真实使用者。

APNIC 2026 年第一季度秘书处更新称，所有核心注册服务都达到或超过 99.99% 可用率。简短摘要没有给出分母和方法细节，不能据此断言该说法与 1 月事故矛盾。需要补上的仍是测量接口：哪些边缘结果、哪些客户端类别、哪些时间段进入这项百分比。

结论的边界

本文不主张 APNIC 的 RDAP 当前仍有故障，不主张所有机器客户端都曾被拦截，也没有受影响用户、软件或运营决策的可靠数量。四次现状探针不能填补公告未披露的事故细节。现有材料也不足以指控 APNIC 或 Cloudflare 违反标准。

可以确定的是，一项机器协议曾在 18 小时内让浏览器外观承担了过多的判断权，而 APNIC 明确称这一效果非预期。修复一条规则可能很快；证明同类范围错误不会静默重现，则需要持续、分层、按客户端类别的凭据。

安全和开放不是二选一。真正的选择是：让边缘防护保留力量，同时不让一个可伪造的软件标签冒充授权。

来源

  1. APNIC：2026 年 1 月 28 日服务公告
  2. APNIC Blog：用于提供 RDAP 的新基础设施
  3. APNIC Blog：RDAP 是否已准备好取代 whois
  4. APNIC Blog：2025 年第二季度注册服务可用性
  5. APNIC Blog：2026 年第一季度秘书处更新
  6. Cloudflare 文档：Browser Integrity Check
  7. RFC 7480：RDAP 的 HTTP 用法
  8. RFC 7481：RDAP 安全服务
  9. RFC 9082：RDAP 查询格式
  10. RFC 9110：HTTP 语义