交易所 API 可用率怎么看：失败请求、事件与测量边界

可用率回答的是「在指定时间和网络路径上，被测接口有多少次正常响应」。它不能直接回答你能否顺利下单、提现，也不能证明交易所的资产安全。读这个数字时，观测范围和统计规则与百分比同样重要。

99.8% 是怎样算出来的

假设某接口有 1,000 次纳入统计的请求，其中 998 次成功，2 次失败，可用率就是 998 ÷ 1,000 × 100% = 99.8%。被明确识别为地域限制并排除的请求不应混入这个分母，排除数量也应单独查看。

本站按约 15 秒的间隔探测公开接口；成功需要响应能按该接口预期结构解析，不能只看 HTTP 200。超时、服务器错误和响应内容中的错误都可能造成失败。这个成功率描述请求样本，不是逐毫秒测量的连续运行时间。

为什么有失败，却没有事件

本站用连续失败确认事件：同一接口连续 2 次失败后开启，连续 2 次成功后关闭。这样可以减少一次网络抖动造成的误报，但也会延迟确认，短暂中断可能只计入失败请求，或恰好发生在两次探测之间而未被看到。

因此，零散失败会降低可用率，却不一定形成事件。反过来，事件持续时间是依据探测与确认规则得到的估计，不是交易所每项服务实际中断的精确起止时间。不要直接把失败请求数乘以采样间隔当成宕机时长。

地域限制和网络路径怎么影响结果

明确识别的地域限制与一般连接失败需要分开。HTTP 403 本身不能证明是地域封锁，也可能与访问权限或安全策略有关。本站只按已识别的限制情况分类；不能确定原因时，不应写成某国家用户均不可用。

从同一观测点比较，可以帮助了解这条线路上的差异，但用户所在地区、运营商和连接方式不同，结果也可能不同。采集地点未注明时，延迟数据尤其缺少解释背景。几小时样本与持续数月的样本，也不应被当成相同强度的证据。

可用率、延迟和业务可用性要分开

接口可能每次都成功返回，但速度很慢。延迟中位数反映较典型的等待时间，p95、p99 用于观察较慢的一端；它们都要结合统计时段和汇总方式阅读。仅凭单个极慢请求也不能推断整个平台持续拥堵。

本站测量公开行情类接口，未直接测试真实订单成交、撤单、强平、充值、提现或偿付能力。官方状态页可能覆盖不同服务与地区，适合补充核对，而不是与外部探测简单二选一。

看到异常后如何核对

1. 打开交易所详情，查看观测时段、样本量与具体异常接口。
2. 区分零散失败和已确认事件，检查是否仍持续。
3. 对照平台官方状态页，核对受影响业务和发布时间。
4. 确认自己的网络与相关业务状态；不要把公开接口恢复当作订单已成功。

从事件记录查看探测结果。若主要关心返回的数据是否足够新，可以继续阅读时钟偏移与行情陈旧度。

规则与数据来源

本文的探测与事件定义来自本站测量方法。Coinbase 官方状态页可用于理解平台如何按服务报告状态；它不代表其他平台的规则。本文示意序列不是一次真实事故记录。