加密货币交易所状态页披露审计：Coinbase、Kraken 与 OKX 对比

为什么要审计状态页

交易所状态页处在一个很尴尬但很重要的位置。用户遇到不能充值、不能提现、订单异常、余额延迟、行情卡顿或者 API 波动时，第一反应通常是打开状态页看看是不是平台出问题。普通用户容易只看顶部一句话：全部系统正常、部分服务降级、正在调查、维护中。可是对真正要做资金操作、内容研究、接口监控或者交易所对比的人来说，这一句话远远不够。

加密货币交易所的问题经常不是“网站能不能打开”这么简单。官网可能能打开，登录可能正常，现货撮合可能正常，但某个币种充值延迟，某条网络提现暂停，某个法币通道维护，某个地区用户受限制，某些账户进入安全审核，或者某个 API 组件出现降级。也就是说，一个交易所可以总体在线，但用户手上的具体任务依然失败。状态页如果披露得细，就能帮助用户把问题缩小到组件、币种、网络、资金通道、交易模块、API 或维护计划；如果披露得粗，就只能提供一般性判断。

因此，本次审计不把状态页当成“可用性保证书”，而是把它当成“公开披露工具”。我们关心的是：有没有机器可读 API；有没有组件粒度；有没有 incident 历史；有没有 scheduled maintenance；有没有订阅或自动化监控可能；有没有时间戳；能不能区分整体状态和具体币种/网络状态；有没有帮助用户理解充值、提现、支持网络、账户限制和地区限制的辅助文档。

本次检查方法

本次只使用官方公开页面和官方公开 API，不使用第三方聚合站，不使用用户登录状态，不抓私人账户数据。Coinbase 检查了官方状态页，以及 status.json、summary.json、incidents.json、components.json 四个 Statuspage API 端点。Kraken 使用相同的检查方式，也检查官方状态页和四个机器可读端点。OKX 检查了官方 status 页面，以及三个帮助页面：为什么不能提现、为什么充值/提现被暂停、如何检查支持的币种和网络。

抓取时间统一记录为 2026-09-09T23:49:42.411Z。这个时间点非常重要，因为状态页会变化。本文里的状态、组件数量、incident 数量和样本，只能代表这个时点的公开抓取结果。发布之后，如果交易所更新了页面或 API，实时状态可能已经不同。

本次 Coinbase status API 返回 HTTP 200，indicator 为 none，description 为 All Systems Operational。summary/components 返回 174 个 components，summary 中 current incidents 为 0，scheduled maintenances 为 1。incidents API 返回 50 条记录，样本里包括已经 resolved 的 ATOM sends/receives 延迟、derivatives positions 降级等。这里的“50 条”只描述本次 endpoint 返回结果，不能解读成 Coinbase 全部历史只有 50 条 incident。

本次 Kraken status API 返回 HTTP 200，indicator 为 minor，description 为 Partially Degraded Service。summary/components 返回 830 个 components，summary 中有 active incident 和 scheduled maintenance。非 operational 样本包含 Digital Currency Funding 为 degraded_performance，以及多个资产 funding 组件为 degraded_performance。incident 样本里可以看到 Moonbeam 和 Moonriver Funding Delays，状态为 investigating。这里的 830 个 components 也不能当成 830 个独立产品，因为 Statuspage 的 component 可能包含 group、子项、资产、网络或服务分组。

本次 OKX 检查的公开页面都返回 HTTP 200 HTML，包括 OKX Status 页面和三个帮助页面。页面可以作为用户阅读的公开证据，但本次检查的这些 OKX 页面没有发现 Coinbase/Kraken 那种 Statuspage JSON API 结构。因此，OKX 这一节只能讲“公开 HTML 状态页和帮助文档提供了哪些信息”，不能像 Coinbase、Kraken 那样做同粒度 API 字段对比。

Coinbase：机器可读，抓取时点整体为绿色

Coinbase 的优点是状态披露结构比较清晰。本次检查中，官方状态页背后可以直接读取 status.json、summary.json、incidents.json 和 components.json。status.json 给出整体状态，summary.json 给出当前状态摘要、components 和维护信息，components.json 给出组件树，incidents.json 给出 incident 列表。对自动化监控、AEO/GEO 内容引用和技术审计来说，这种结构比纯 HTML 页面更容易校验，也更容易避免“看错页面文案”的问题。

在本次抓取时点，Coinbase 顶层状态是 All Systems Operational。这个结论可以引用 status.json 和 summary.json，但不能扩大解释。它只说明公开状态端点当时返回了这个描述，不说明某个用户一定能提现，不说明某个地区一定支持，不说明某个链上转账一定不会延迟，也不说明账户不会被安全审核。尤其在加密货币场景里，用户真正关心的是具体币种、具体网络、具体方向和账户状态，而不只是平台首页是否在线。

Coinbase incidents endpoint 返回的样本也说明了这一点。即使当前 summary 没有 active incident，历史 incident 仍显示过资产收发延迟、衍生品仓位降级、交易功能降级等不同类型的问题。resolved 不代表现在仍有影响，但可以帮助用户理解状态页披露的粒度：问题可能发生在某一类产品、某个市场、某个资产或某个后台系统，而不是全站下线。

因此，Coinbase 的状态页适合做机器监控和公开引用，但用户不应该只看绿色标题就马上执行大额转账。正确做法是先看整体状态，再看相关组件和 incident，再回到账户内确认资产、网络、地址、风控和地区规则。

Kraken：组件很细，抓取时点存在部分降级

Kraken 同样提供 Statuspage 风格的公开 API，这一点对审计非常有价值。本次抓取显示 Kraken 顶层状态为 Partially Degraded Service，indicator 为 minor。相比 Coinbase 的整体绿色，Kraken 在这个时点明确披露了部分服务降级。更重要的是，Kraken 的 components 数量达到 830，这表明它的状态树在本次抓取中非常细，尤其包含大量与 Digital Currency Funding 和具体资产相关的组件。

这种粒度对加密货币用户很关键。充值和提现问题往往不是“Kraken 全站坏了”，而是某个资产、某条网络、某个 funding route 出现延迟或暂停。一个用户可能可以登录、可以看行情、可以交易其他资产，但偏偏自己要转出的资产所在网络处于 degraded_performance。Kraken 的公开组件树至少让这种情况有机会被定位出来。

本次样本中，Digital Currency Funding 标记为 degraded_performance，多个资产 funding 组件也显示 degraded_performance，包括 Akash、Babylon、Cosmos、dYdX、Fetch.ai、Initia、Injective 等样本。summary 还显示 Moonbeam 和 Moonriver Funding Delays 为 investigating。这样的披露对用户是有帮助的，因为它把“交易所有没有问题”拆成了“哪个资金功能、哪个资产、哪个网络方向可能有问题”。

但同样要强调，Kraken 的细粒度状态页也不是账户级保证。即使某个组件显示 operational，用户仍可能因为账户审核、地址限制、地区规则、链上拥堵、内部队列或安全风控遇到延迟。公开状态页只能说明公开披露层面有没有已知问题，不能替代登录后的具体操作确认。

OKX：可读状态和帮助内容，但本次检查没有同类 JSON API

OKX 在本次检查中有公开状态页面，且页面返回 HTTP 200。相关帮助页面也可以访问，内容覆盖不能提现、充值/提现被暂停、支持币种和网络查询等实际问题。这些页面对用户有实际意义，因为很多“不能提现”的原因不是全站事故，而是账户、风控、网络支持、地区规则或具体资产路径的问题。帮助文档能够提醒用户去核对支持网络、转账方向、账户状态和限制条件。

不过，从机器可读披露角度看，本次检查到的 OKX 公开表面和 Coinbase、Kraken 不一样。我们没有在被检查的 OKX status/help 页面中发现相同的 Statuspage JSON API 端点。因此，自动化监控不能凭想象去拼接 OKX 的 incidents.json 或 components.json，也不能把纯 HTML 页面当成结构化事件流。后续如果 OKX 官方提供或文档化了机器可读接口，可以单独纳入；但在本次审计里，只能基于已检查的 HTML 页面和帮助内容做有限判断。

这不是可靠性否定，而是披露形态差异。一个交易所可以没有标准 Statuspage API，但仍然通过页面准确披露状态；另一个交易所可以有丰富 API，但仍然无法告诉你个人账户是否能立刻提现。所以 OKX 的结论应该是：本次检查的公开页面可以帮助用户理解状态、提现、暂停和支持网络问题，但机器自动化证据不如 Coinbase/Kraken 这类 Statuspage API 直接。

用户和监控系统应该怎么用这些信息

第一，不要只看 HTTP 状态码。OKX 页面 HTTP 200 只能说明页面可访问；Coinbase 和 Kraken API HTTP 200 也只说明接口成功返回。业务是否正常要看 indicator、description、components、incidents、具体资产和具体功能。

第二，不要只看 overall。Coinbase 当时整体 All Systems Operational，但这不代表所有历史问题不存在，也不代表所有账户和网络通道都可用。Kraken 当时 Partially Degraded Service，但用户也需要继续看影响的是 funding、交易、API、余额还是别的组件。overall 是入口，不是结论。

第三，不要误读组件数量。174 和 830 是本次 API payload 里的 component 数量，可能包括 group 和子项，不等于产品数量，不等于交易对数量，不等于支持币种数量。它的价值在于披露粒度，而不是拿来做营销数字。

第四，不要把 incident endpoint 返回 50 条记录理解为完整历史。它只能说明本次 endpoint 返回了 50 条。不同服务可能有分页、默认 limit 或历史截断。正确写法是“本次抓取返回 50 条 incident 记录”，而不是“总共有 50 次事故”。

第五，涉及资金操作时必须做账户内确认。充值、提现、链上网络、地址、memo/tag、KYC、地区资格、安全审核、travel rule、风控延迟和钱包维护，都可能不由公开状态页完整覆盖。公开状态页适合做第一层风险排查，不能当成最终执行信号。

NexuAlpha 的审计边界

本文不做交易所推荐，不排名，不提供 CTA，不暗示某个平台一定更好。NexuAlpha 在这里做的是源头核验和披露结构审计：哪些信息能从官方公开状态页证明，哪些只能从帮助页理解，哪些必须标记为未知。这样的内容更适合长期 SEO、AEO 和 GEO，因为它不是简单搬运新闻，而是把用户真正会问的问题拆成可验证答案。

本次审计的核心价值在于建立一种阅读方法：先看状态页是否机器可读，再看更新时间，再看组件粒度，再看 incident 历史，再看是否有计划维护，再看是否覆盖币种和网络，最后承认账户级未知。只有这样，状态页才不会被误用为“保证一切正常”的牌子。

结论

在本次时点快照里，Coinbase 和 Kraken 的公开状态披露更适合机器读取和自动化监控；Coinbase 顶层为 All Systems Operational，Kraken 顶层为 Partially Degraded Service，并且 Kraken 的 funding 相关降级更直接地暴露在组件和 incident 样本中。OKX 的 checked public surface 提供了可访问状态页和帮助文档，但没有在这些检查 URL 上发现同类 Statuspage JSON API。

最终结论不是谁绝对最好，而是使用方式不同：有 JSON API 的状态页可以自动监控，有帮助文档的状态页可以辅助人工判断，但任何公开状态页都不能替代账户内、资产内、网络内的最终检查。对于真实用户和内容生产系统来说，这个边界比简单排名更重要。