来自两个不同层面的两种信号

当某个挖矿操作出现异常时，两类不同的信息常常被混为一谈：一类是矿机控制板上不断上升的硬件错误计数，另一类是矿池仪表盘上不断攀升的拒绝份额数。这两者确实相关，但它们由挖矿流程中不同的层面产生，衡量的并非同一件事。

硬件错误是矿机侧的遥测数据——是由 ASIC 芯片、其控制板或固件所报告的一种状况。拒绝份额则是矿池侧的验证结果——是矿池对某一特定提交工作所作出的判定。如果将其中一个当作另一个的证据，可能会导致运营方在实际问题只是网络路径拥塞时去更换算力板，或是在矿池仪表盘看起来并无异常时忽视真实存在的芯片故障。

本文将这两种信号区分开来，解释每一种信号真正可靠反映的内容，并在仅有其中一种信号出现异常时，给出一套实用的排查顺序。

ASIC 硬件错误究竟反映了什么

在大多数 ASIC 矿机上，状态界面会显示一个硬件错误计数器（通常标记为 HW 或 HW errors），同时还会显示 ASIC 状态、每块算力板检测到的芯片数量、以及报告算力等字段。Bitmain（比特大陆）针对其状态页面的官方文档对这些字段分别作出了定义：HW 反映的是矿机报告的硬件或计算错误；ASIC 状态为“0”表示芯片正常，非零值或“X”则可能表示该芯片无法正常工作；而另一个独立字段则报告算力板上检测到的正常工作芯片数量（Bitmain 支持页面）。

单纯 HW 错误计数的上升并不能作为硬件故障的确凿证据。Bitmain 指出，在矿机以满算力正常运行期间，某些硬件错误是可能发生的，且可能会被内部自行纠正，而不会中断算力输出。如果某项计数缓慢增长，但本地算力保持稳定、芯片数量齐全、温度正常，那么这通常是一个相对较弱的信号；相比之下，更值得关注的信号模式是多个指标同时出现：本地算力下降、算力板报告的芯片数量低于预期、反复出现的温度保护事件、风扇或电源故障，或设备日志显示无法检测到某块板上的芯片。这种组合情况才指向一种值得通过矿机自身诊断日志（而非矿池数据）加以隔离排查的设备级状况。

由于 HW 错误计数器、其重置行为及其确切含义都是由各制造商的固件所定义的，因此不应将其视为一种统一的标准化指标，在不同的 ASIC 型号之间进行直接比较。

拒绝份额究竟反映了什么

在矿池挖矿中，矿机并不会向矿池提交已完成的区块，而是提交份额（shares）——即满足矿池份额目标的工作量证明结果。矿池的份额目标在数值上设置得高于比特币网络的区块目标，这使其更容易被满足，对应的难度也低于实际找到一个区块所需的难度；份额让矿池得以衡量每台矿机在两个区块之间所贡献的工作量（Bitcoin 开发者指南）。

“拒绝份额”是一个统称，泛指任何未被矿池接受的已提交份额。具体的拒绝原因通常属于以下几个子类别之一，而并非“拒绝份额”本身的同义词：

• 过期份额（Stale share）——该工作量在此前某个挖矿任务中本属有效，但提交到达时该任务已不再是当前有效任务。
• 无效份额（Invalid share）——未能通过矿池验证检查的提交。
• 重复份额（Duplicate share）——同一份额被重复提交多次。

比特大陆（Bitmain）将矿池的拒绝率描述为矿池拒绝的数据与矿工发送的数据总量之比，并指出网络不稳定是拒绝率偏高的主要原因之一（Bitmain Support）。这一点对诊断很重要：一批过期份额（stale shares）大多反映的是矿机与矿池端点之间的时序或连接状况，而不是芯片层面的故障。相比之下，无效份额（invalid shares）有时可能伴随着不稳定的挖矿设置、固件问题或供电不一致等情况出现——这些情况同样会影响硬件表现——因此无效份额的上升是一个更合理（但仍非定论性）的信号，提示应检查设备本身。

如果矿池针对同一时段同时报告了接受数和拒绝数，可以按如下方式计算原始拒绝百分比：

Rejected share count ÷ (Accepted share count + Rejected share count) × 100

只有当接受数与拒绝数覆盖同一时间窗口、且份额难度（share-difficulty）设置相同时，这一数值才有意义；如果该时段内份额难度发生了变化，原始计数就不再代表可比的工作量。此外，该结果也不应被解读为比特币（BTC）收益损失的直接百分比，因为收益取决于实际被接受的工作量、矿池的收益计算方式以及发现区块的时机，而非一个简单的份额比例。

为什么这两种信号常被混为一谈

硬件错误与被拒绝份额之间的混淆，通常源于两种习惯性做法：一是认为任何屏幕上出现的红色提示都代表同一类问题，二是比较那些在不同时间窗口或由不同系统测得的数据。矿机本地显示屏报告的是设备自身观察到的信息——它自己的芯片状态、自己的错误计数器、自己计算出的算力（hashrate）。而矿池仪表盘报告的是矿池根据其收到的份额所观察到的信息——这既取决于矿机的输出，也取决于网络路径、上报间隔以及矿池自身的验证逻辑。

当一个真实的硬件问题导致矿机产生不稳定或无效的工作量，而矿池随后将其拒绝时，这两个信号会同步变化。但它们也可能各自独立变化：一台完全健康的ASIC矿机，可能因为矿池端点拥堵或距离较远而显示出较高的过期份额率；而一台存在早期硬件不稳定迹象的矿机，如果矿池尚未收到足够多受影响的提交，其拒绝率也可能依然表现平平、看不出异常。

一种实用的诊断思路

与其孤立地对任一数字作出反应，不如先解读具体信号类型，再对照一组简短的问题进行核实，然后再判断问题所在。

如果硬件错误计数器持续上升，应检查本地算力、芯片数量和温度是否保持稳定。如果这些指标保持稳定，那么仅凭该计数器本身，其作为故障证据的分量就较弱。如果本地算力正在下降、芯片出现缺失，或者同时记录到了散热或风扇故障，那么设备本身就值得进一步细查，应首先从矿机自身的日志入手。

如果被拒绝的份额在上升，应检查是哪个子类别占主导。如果模式集中在过期份额上，首先应指向连接路径——所选的矿池端点、路由或重连行为——而不是算力板（hashboard）。如果模式集中在无效份额上，则更合理的做法是检查近期的固件或调参变更、供电稳定性和散热情况，并结合设备自身的错误日志。

无论是哪种情况，都应确认该模式是只影响单个矿工（worker），还是影响通过同一路径连接的多台矿工。仅局限于单一设备的问题，指向的是该设备本身；而同时影响多台原本相互独立的矿机的问题，则指向某个共享环节，例如网络连接或矿池端点。

为什么本地算力与矿池算力数据会不一致

另一个容易引起混淆的原因，是矿机自身显示屏上的算力与矿池后台显示的算力不一致。这两个数值并不能互相替代：本地算力是设备自行上报的估算值，采用厂商自有的刷新与平均算法；而矿池的算力则是根据其在某一规定时间窗口内实际收到的份额所推算出的估算值。

以ViaBTC的后台为例，其实时算力是以过去10分钟为周期计算的滚动平均值，而日算力则是以过去24小时为周期计算的滚动平均值（ViaBTC）。矿机在重启或短暂断线之后，本地算力可能在几分钟内就恢复正常，但矿池显示的24小时算力数据却可能在较长时间内依然偏低，原因仅仅是此前的停机时间仍落在该滚动窗口之内。这是一种测量窗口效应，并不能独立证明存在硬件错误或矿池侧的问题，在将任一信号视为故障确认依据之前，应先对比相匹配的时间区间内的数据。

结语

硬件错误计数与拒绝份额计数回答的是两个不同的问题：前者描述的是ASIC芯片自身上报的情况，后者描述的是矿池对提交工作量所作出的判定结果。相较于把每一个红色提示都视为同一类故障，仔细阅读具体的拒绝原因、检查硬件信号是否伴随其他设备层面的症状，并在比较数据前对齐测量时间窗口，通常能得出更准确的诊断结论。

常见问题

硬件错误（HW-error）计数持续上升是否一定意味着算力板出现故障？

不一定。部分硬件错误可能在正常运行过程中发生，并能够被自动纠正，不会中断挖矿。如果持续上升的同时还伴随本地算力下降、芯片缺失，或出现温控与风扇故障，那么比起仅凭计数本身，这更能说明设备确实存在实际问题。

过期份额（stale）、无效份额（invalid）与重复份额（duplicate）是否属于三种同等程度的问题？

它们都只是"拒绝份额"这一更大结果类别下的子类，而不是彼此平行、同等级别的独立指标。每一种都指向不同的可能原因：过期份额通常与时序或连接问题有关，无效份额可能指向硬件或配置方面的不稳定，而重复份额则通常源于软件或连接行为导致的重复提交。

我可以用拒绝率来估算挖矿收益的损失吗？

拒绝率是根据同一时间段内相匹配的接受份额数与拒绝份额数计算得出的原始比值，反映的是矿池未接受的提交工作量占比。它并不是一个标准化的收益损失指标，因为实际收益取决于矿池的结算方式、份额难度以及出块时机等因素，而不仅仅取决于这个原始比值。

为什么我矿机屏幕显示的算力与矿池后台显示的算力不一样？

这是因为两者采用了不同的测量方法和时间窗口。矿机本地显示屏呈现的是设备自行上报的估算值，而矿池后台反映的是在某一规定滚动周期内实际收到的份额情况。两者之间的差异更可能是报告窗口效应所致，而非硬件或矿池故障的证据，尤其是在矿机刚刚重启之后。

参考资料

• 比特币开发者指南，《挖矿》—— https://developer.bitcoin.org/devguide/mining.html
• 比特大陆（Bitmain）支持文档，《矿机状态页面详解》—— https://support.bitmain.com/hc/en-us/articles/360013577314-Miner-Status-Page-Explained
• 比特大陆（Bitmain）支持文档，《矿池拒绝率说明》—— https://support.bitmain.com/hc/en-us/articles/5220664696473-The-rejection-rate-of-mining-pools
• ViaBTC，《具备实时算力监控的矿池：理解测量窗口与延迟效应》—— https://www.viabtc.com/en/blog/Mining-mining-pool-with-real-time-hashrate-monitoring-understanding-measurement-windows-and-latency-effects-941