Nonce 比特币挖矿：零算力与离线为何要分开处理

在比特币矿场日常运维中，「矿机没有产生算力」经常会被笼统地归类为「矿机掉了」或「矿机离线了」。但从实际故障处理来看，零算力和离线并不是同一种状态，也不应该使用同一套排查流程。零算力通常意味着矿机仍然能够被管理系统发现，设备可能保持在线、拥有 IP、控制板仍在工作，但实时算力已经下降到 0；离线则意味着管理系统无法正常获取矿机最新状态，问题可能发生在供电、网络、控制板、交换机、Agent 与矿机之间的通信链路，甚至整个矿场基础设施层。

这一区别看起来只是状态分类，实际上会直接影响矿场的故障响应速度。如果把所有异常矿机都放进一个「故障」列表里，运维人员就不得不逐台确认：究竟是机器还能访问但不挖矿，还是连机器都已经无法访问。对于几十台矿机影响有限，但在几千甚至数万台 ASIC 的矿场里，错误分类会让大量时间浪费在无效排查上。因此，在 Nonce 的矿场管理逻辑中，零算力矿机与离线矿机需要被分别识别和处理。

什么是零算力？什么又是真正的矿机离线？

判断两者最简单的方法，是先问一个问题：现在还能不能正常获得这台矿机的数据？

如果管理系统依然能够访问矿机，知道它的 IP、型号、温度、运行时间等信息，只是当前算力已经变成 0，那么更接近「零算力」。此时矿机并不一定真正断电，也不一定失去网络连接。控制板可能仍然正常运行，只是算力板因为高温保护、风扇异常、电源异常、矿池连接失败、固件问题或者算力板故障而停止计算。

BITMAIN 在 ANTMINER 的故障说明中也将「无法找到 IP」「无法开机」「零算力」和「低算力」划分为不同的故障类别。其中，零算力可能由高温、风扇、电源、算力板、固件或者网络异常导致，而无法找到 IP 则首先需要排查网络和控制板。

离线则不同。离线更重要的特征并不是「算力是不是 0」，而是矿机的状态数据已经无法继续正常更新。设备可能断电、网线断开、交换机异常，也可能因为控制板失去响应，导致管理系统无法继续与矿机通信。在托管场景中，BITMAIN 列出的矿机离线原因还包括设备搬迁、风扇故障、控制板故障、算力板故障、电源故障、高低温、PDU 故障、限电、供电设施维护以及网络故障等。

因此，「零算力」描述的是矿机的计算状态，「离线」描述的则更接近矿机的连接和数据可达状态。一台矿机可以在线但零算力，而一台已经离线的矿机，由于无法获得实时数据，其最后记录的算力值甚至可能不是 0。

状态	管理系统能否获取矿机数据	是否一定产生算力	优先排查方向
正常在线	可以	是	通常无需处理
零算力	通常可以	否	温度、风扇、电源、算力板、矿池、固件
低算力	可以	有，但低于预期	算力板、温度、频率、电源、网络
离线	无法正常获取最新状态	无法确认	供电、网络、交换机、控制板、Agent 通信
睡眠或主动停机	可以或状态明确	否	确认是否为预期策略

这也是为什么矿场管理不能只看「有没有算力」一个指标。矿机在线状态、算力状态、温度、错误信息、运行模式和最后通信时间需要结合起来判断，才能知道真正发生了什么。

为什么零算力不能直接按照离线矿机处理？

零算力最容易出现的误区，是看到算力为 0 就直接认为矿机掉线，然后从交换机、网线或者 IP 开始排查。但如果矿机控制板本身仍然在线，这种排查顺序往往会浪费时间。

以 S19 系列为例，BITMAIN 列出的零算力原因包括高温保护、风扇故障、电源异常、网络或矿池错误以及算力板故障。高温保护发生时，矿机会切断算力板供电，因此算力会归零，但控制板未必离线；风扇异常同样可能触发保护机制，使算力板停止工作；如果电源无法正常向算力板供电，控制板可能继续运行，但 ASIC 芯片无法开始计算。（来源：BITMAIN S19 零算力故障说明）

这意味着，当矿机仍然能够访问时，排查应该优先围绕「为什么算力没有启动」展开，而不是先寻找「为什么网络断了」。

例如，运维人员可以先查看矿机温度和风扇状态，再检查矿机错误日志以及是否识别到所有算力板，随后确认矿池地址、矿工名和网络连接是否正常。如果这些项目都没有发现异常，再进一步考虑电源或者算力板硬件故障。

BITMAIN 的另一份零算力排查指南也指出，当实时算力或平均算力为 0 时，可以依次检查算力板和数据线、固件、矿池连接、网络、风扇、温度以及电源等项目。（来源：BITMAIN Hashrate Showing ZERO）

所以，零算力首先是矿机内部运行状态问题，其次才可能是网络问题。

对于大规模矿场，更适合先通过 Nonce 的矿机过滤条件筛选出算力为 0、但仍然在线的设备，把这一组矿机独立出来处理。这样运维人员不会把真正失联的设备和仍能远程操作的设备混在一起。

离线矿机为什么应该先查供电与通信链路？

离线矿机的排查逻辑几乎正好相反。

如果管理系统已经无法获取一台矿机的实时状态，此时即使想查看温度、风扇或者算力板，也可能根本无法进入矿机后台。因此，第一步不应该深入检查矿机内部硬件，而应该先确认设备是否仍然具备最基本的「在线条件」。

典型排查路径是从电源和网络开始：设备是否通电，PDU 是否正常，机架是否出现集中掉电；随后确认网线、交换机端口和 VLAN 网络是否正常；如果同一网段同时出现大量设备离线，则应该优先检查网络基础设施，而不是逐台拆矿机。如果设备有电、网络链路正常，但依然无法获得 IP 或访问控制板，则需要进一步检查控制板。

对于通过本地管理节点连接矿机的架构，还必须增加一层判断：到底是矿机离线，还是负责采集数据的 Agent 出现问题？

Nonce 的架构中，Agent 部署在矿场本地网络，通过扫描指定 IP 范围发现和连接 ASIC，再将数据同步至 Workspace。因此，如果某一台设备离线，可能是单机问题；如果整个 IP 段同时无法更新，则需要进一步检查 Agent、VLAN 路由、交换机或者网络配置。相关的连接异常可以结合Nonce Agent 扫描排查进行定位。

这就是单机故障和基础设施故障之间非常重要的区别。

例如，一个矿场突然出现 200 台矿机同时「离线」，如果这些设备恰好集中在同一个机架或者交换机下面，那么逐台重启 ASIC 几乎没有意义。真正的问题可能是一台交换机掉电、一条上联网络中断或者一个 PDU 出现异常。反过来，如果只有一台设备离线，而旁边几十台设备都工作正常，那么故障范围更可能集中在单机电源、网线或者控制板。

零算力与离线，正确的排查顺序有什么不同？

将两个状态拆开之后，矿场可以形成两套明显不同的故障处理流程。

排查阶段	零算力矿机	离线矿机
第一步	确认矿机是否仍可访问	确认矿机是否通电
第二步	查看温度与风扇	检查 PDU 与供电
第三步	查看错误日志	检查网线、交换机与网络
第四步	检查算力板识别情况	检查 IP 与控制板
第五步	检查矿池连接	检查 Agent 与矿机网络连通性
第六步	尝试重启	恢复通信后再判断矿机运行状态
第七步	排查电源、算力板硬件	进入设备内部故障排查

这里有一个很重要的运维原则：只有在能够与矿机通信之后，远程重启才真正有意义。

零算力矿机仍然在线时，管理平台有机会直接向设备下发重启任务。如果零算力来自偶发的软件异常、矿工程序异常或者部分可恢复状态，重启有可能让算力重新恢复。BITMAIN 也单独记录过「算力为 0、重启后恢复」的故障情况，其中可能涉及高温保护或者电源异常。（来源：BITMAIN 零算力重启恢复说明）

但设备已经完全离线时，软件平台通常无法继续向矿机发送普通重启指令。这时如果继续执行「自动重启所有异常矿机」的策略，本质上是在对不可达设备发送无法执行的操作。离线设备应该先恢复供电或通信，随后才进入正常的设备级处理流程。

因此，零算力更适合自动化恢复，离线更适合基础设施告警与人工定位。

为什么大矿场尤其需要把两种状态分开？

矿场规模越大，状态分类的重要性越高。假设一个拥有 10,000 台矿机的矿场，在某一时刻出现 300 台异常设备。如果系统只告诉运维人员「300 台异常」，现场人员很难立即判断工作量和处理优先级。但如果系统进一步告诉你，其中 210 台在线但零算力，70 台低算力，20 台离线，那么处理策略就完全不同。

210 台零算力矿机可以先通过远程方式批量检查和恢复；70 台低算力设备可以继续运行，同时进入第二优先级排查；20 台真正离线的机器则需要进一步按机架、交换机、PDU、IP 段或者矿场区域进行聚类，判断是否存在共同故障。

Nonce 可以通过多重过滤查询组合运行状态、算力、温度等条件定位问题矿机，而不是把所有异常设备混合到一个列表里。对于需要执行远程恢复的设备，也可以在筛选完成后进行批量重启。

这实际上改变了矿场运维的基本单位。传统做法往往是「看到一台坏一台、处理一台」；而规模化矿场更需要按照异常类型形成设备集合，例如「在线且零算力」「高温且低算力」「某网段集中离线」「某型号连续异常」。运维对象从单台矿机变成一组具有相同特征的设备，处理效率才能随着矿场规模扩大而保持稳定。

自动化处理零算力时，不能简单设置成「0 算力就重启」

把零算力和离线分开，只是第一层分类。真正进入自动化管理后，还需要进一步判断异常是否持续，以及矿机当前是不是本来就不应该产生算力。

例如，一台矿机刚刚启动时，算力可能需要一定时间才能稳定。如果系统刚检测到 0 就立即执行重启，可能会出现矿机启动、触发规则、再次重启、再次启动的循环。类似的问题还可能发生在人工维修、主动停机或者矿机处于睡眠状态时。因此，更合理的自动化规则应该同时包含「算力阈值」和「持续时间」。

Nonce 的自动重启功能可以基于算力低于指定阈值的条件执行恢复操作。实际矿场在配置规则时，更应该避免把所有短暂波动都当作真正故障，而是给设备留出合理的观察窗口。

一个更完整的自动恢复逻辑可以理解为：「矿机在线 → 当前应该处于挖矿状态 → 算力低于设定阈值 → 异常持续超过观察时间 → 执行重启 → 等待恢复 → 再次检查算力。」

而离线设备则应该进入另一条路径：「设备数据长时间未更新 → 判断影响范围 → 检查是否为集中离线 → 检查 Agent、网络或供电 → 恢复通信 → 重新获取矿机状态 → 再决定是否需要重启或维修。」

同样是「没有收益」，背后的故障层级完全不同

从收益角度看，零算力和离线最终都会造成类似结果：矿机没有正常向矿池提交有效工作，矿场损失了本应获得的 BTC 产出。但从运维角度看，两者对应的故障层级完全不同。

零算力通常意味着「管理链路还活着，但是挖矿链路出了问题」。矿场仍然有机会获得设备信息、读取日志并执行远程操作，因此很多问题可以通过软件层快速定位。

离线则意味着「连管理链路本身都可能失效」。在这种情况下，真正的问题可能根本不在 ASIC，而在供电、网络、交换机、路由、Agent 或整个机架基础设施。

这也是为什么一个成熟的比特币矿场管理系统不能简单地把「算力 0」等同于「矿机离线」。只有把设备连接状态、实时算力、温度、矿机模式、错误信息和数据更新时间分别记录，运维人员才能判断故障究竟发生在哪一层。

在 Nonce 中，可以先通过查询零算力矿机找出仍然在线但停止计算的设备，再通过查询离线矿机单独定位已经失去连接的设备。对于大型矿场，这并不仅仅是界面上的两个筛选条件，而是两条完全不同的运维路径：零算力优先解决「为什么机器不算」，离线优先解决「为什么机器看不见」。

把这两个问题分开，才能进一步实现批量排查、自动恢复和异常分级。当矿场从几百台 ASIC 扩展到几千甚至数万台时，真正决定运维效率的往往不是发现了多少故障，而是能否在发现故障的第一时间，把它准确地送进正确的处理流程。