一个只可能显示 100% 的比率

目录里每台 server 都显示一个比率：它的端点在多少比例的日子里答复了我们。/zh/servers 的筛选项叫「已观测日可达率（90 天窗口）」，分三档：99% 及以上、90–98%、90% 以下。

2026-09-23，目录里的 833 台 server 全部显示 100%。下面两档从来都是空的。

怎么发现的

我们在发布一篇讲检测频率的文章之前核对事实。草稿准确地写出了当时的规则：当天只要有一次探测没有得到答复，这一天就不计入，和我们根本没去观测的日子一样处理。

对照代码核这句话的审核者注意到了它的后果。我们的可达性检查从不记录失败。端点没有答复时，这项检查记为「未核实」，也就是我们无法下结论。于是端点没答复的每一天都被剔除，留下来的每一天都是它答复了的日子。这个比率只可能是 100%，或者没有值。

一条只读查询证实了这一点：833 行，全是 100，没有别的值。

从很窄的意义上说，这个数并不假，它准确地给出了规则算出来的结果。但读者看到一台 server 旁边写着 100%，会理解为它每次都答复了，而这个数根本说明不了这一点。

改了什么

问题在于：那些我们无法下结论的日子里，哪些是 server 造成的，哪些是我们自己造成的。

现在，当天只要有一次可达性检查没有得到端点的答复，这一天就算未应答：

• 域名无法解析；
• 连接失败；
• 在探测的时间预算内没有收到完整响应；
• 或者握手被 HTTP 5xx 答复。

如果当天无法下结论的检查全是我们自己造成的（我们被限流，或我们自己的策略拒绝了连接），这一天仍然不计入，既不算可达也不算未应答。

目录从 2026-09-24 起改用这条规则。其中两项有各自的起始日。连接失败要到 2026-09-27 探测器更新之后，才能和我们自己的问题区分开，所以从那天起计入。握手规则从 2026-09-23 起计入，那是探测器开始记录握手失败时 HTTP 状态码的第一天。方法论页写的是同一条规则、同样的日期。

现在是什么样子

2026-09-30，目录里的 1,470 台 server：

已观测日可达率	server 数
99% 及以上	1,338
90–98%	92
90% 以下	40

中间一档的 92 台，每台都恰好有一个未应答日，观测天数在 14 到 19 天之间。目录里 server 的观测天数中位数是 14 天，其中 633 台不超过三天，所以一天就能让这个数变动很多。这也是每个百分比旁边都写着计入天数的原因。

它仍然说明不了什么

目录里几乎所有 server 都是每十二小时探测一次。两次都得到答复的一天，两次之间仍可能中断过，我们也这样写过。这个数描述的是我们观测的那些时刻，不衡量两次观测之间的可用性。

数字从哪里来

2026-09-23 的数字是对目录视图按百分比分组的只读查询。2026-09-30 的数字是约 20:05 UTC 对同一视图的只读查询，按三个筛选档分组，并给出每档观测天数的中位数和范围。「一个未应答日」是由每台 server 的百分比和计入天数推算出来的。