矿机显示的算力正常，并不代表这些算力最终都能被矿池有效接收。如果提交到矿池的 Share 中有一部分因为延迟、硬件错误、配置异常等原因被拒绝，矿机依然会消耗电力和散热资源，但这部分工作不会按矿池规则计入有效贡献。
因此，判断矿机是否真正稳定运行，不能只看本地算力。除了矿机端的 Hashrate，还需要结合矿池侧的算力、Share 状态和连接情况一起判断。对于大规模矿场来说，即使拒绝率只持续高出几个百分点，放大到整个机群后，也可能形成明显的收益损失。
截至 2026 年 8 月 13 日，比特币全网算力约为 906.20 EH/s；8 月 8 日难度调整后，网络难度达到 127.48 T。在全网竞争持续增强、电力成本敏感的环境下，长期偏高的拒绝率尤其值得关注。
拒绝率到底在衡量什么？
矿池通过 Share 来衡量矿工贡献的工作量。一个 Share 达到了矿池设定的 Share Difficulty，就可以证明矿机完成了一定量的计算工作，即使它还没有达到比特币网络真正出块所要求的难度。
矿池会根据收到并确认的 Share 估算矿工贡献的算力，并按照对应的结算方式计算收益。常见的 Share 状态包括：
- Accepted Share： 矿池成功收到 Share，并确认它满足当前任务要求。
- Stale Share： Share 本身可能有效，但对应的是旧任务。常见原因是新区块出现后，矿机没有及时收到新任务，或者提交过程存在网络延迟。
- Invalid Share： Share 无法通过验证，常见于硬件不稳定、供电异常、过度超频、固件问题等情况。
- Duplicate Share： 同一份 Share 被重复提交。
- Low-difficulty Share： 提交结果没有达到矿池当前分配的 Share Difficulty。
- Rejected Share： 矿池没有接受该次提交的统称，具体原因仍需结合矿池返回的错误类型进一步判断。
因此，“拒绝率升高”本身只是一个结果，不能直接说明问题一定出在网络。比如 Stale Share 持续增加，更可能与网络延迟、路由不稳定或任务更新不及时有关；如果只有某一台矿机的 Invalid Share 明显上升，则更应该优先检查温度、供电、算力板、固件或超频设置。
排查时最好同时查看矿池返回的拒绝原因和矿机日志，而不是只盯着一个总拒绝率。
拒绝率为什么会影响实际收益？
可以用一个简化关系来理解：
矿池侧有效算力 ≈ 本地算力 ×（1 − 拒绝率）
例如，一个总算力为 10 PH/s 的矿场，如果长期维持 3% 的拒绝率，在其他条件不变的情况下，矿池实际接收到的工作量可能更接近 9.7 PH/s。设备却仍然按照接近 10 PH/s 的运行状态持续耗电。
如果把规模扩大到 1 EH/s，长期 2% 的拒绝率，按同样的简单估算，就相当于约 20 PH/s 的工作没有被矿池接受。
需要注意的是，这只是帮助理解的近似关系。实际收益还会受到结算方式、统计周期、Share Difficulty、拒绝类型等因素影响。但运营上的核心问题很明确：电力已经消耗，部分提交却没有转化为矿池认可的有效工作。
降低拒绝率不会改变比特币全网难度，但可以帮助矿场从现有设备和电力投入中获得更多有效算力。
高拒绝率最常见的六类原因
1. 延迟、丢包和路由不稳定
矿机需要及时接收矿池下发的新任务，并在任务仍然有效时将 Share 返回矿池。高延迟、丢包、频繁断线、DNS 异常、路由器负载过高或 ISP 路由质量不佳，都可能延长这个过程。
如果问题来自网络，通常会看到多个矿机同时出现 Stale Share 增加、频繁重连、超时或 job not found 等错误。如果整个矿场在同一时间出现类似问题，应优先检查 WAN、路由器、交换机、代理、DNS、防火墙以及到矿池节点的网络路径，而不是同时怀疑大量矿机硬件故障。
可以重点检查：
- 生产矿机尽量使用有线网络，避免依赖 Wi-Fi。
- 持续观察到官方矿池节点的延迟、丢包率、重连次数和路由稳定性。
- 节点选择不要只看地理距离，实际链路质量更重要。
- 检查路由器 CPU 负载、NAT 或会话表上限、交换机错误、DNS 解析和防火墙规则。
- 提前配置并测试官方备用节点。
- 条件允许时，将挖矿流量与办公、摄像头、管理网络等流量分开。
2. 新任务下发延迟，导致旧任务继续提交
比特币网络发现新区块后，矿池会向矿机下发新的挖矿任务。如果矿机收到更新较晚，或者仍然继续提交上一轮任务对应的结果，就可能形成 Stale Share。
少量 Stale Share 本身并不异常，因为区块发现和网络通信不可能完全同步。但如果 Stale Share 持续升高，就需要排查。
对于大规模矿场，Mining Proxy 也可能成为瓶颈。即使矿池连接正常，如果代理负载过高或配置不合理，也可能让一批矿机延迟收到新任务。可以结合任务切换时间、代理负载、重连日志、超时记录等判断。
一种简单的对照方法是：将少量矿机切换到另一个官方区域节点，其余设备保持不变。如果这组矿机的 Stale Share 明显改善，问题可能与原有路由或节点选择有关；如果整个矿场都没有变化，则应进一步检查本地网络或代理基础设施。
3. 过度调校、温度过高或硬件老化
矿机本地算力高，并不一定代表运行质量好。激进超频可能推高本地 Hashrate，同时降低芯片在电压和时序上的稳定裕量，进而增加 Invalid Share。
此外，进风温度过高、风道堵塞、风扇故障、供电不稳、线缆老化、PSU 异常、算力板故障等，也都可能增加计算错误。
这类问题通常集中在单台或少量矿机上，而不是整个机房同时发生。可以把异常设备与同一区域、同环境下的正常矿机对比，重点检查芯片温度、算力板状态、风扇转速、Hardware Error、PSU 数据、接头、滤网和风道。
建议按以下顺序排查：
- 先恢复到经过验证的原厂或保守参数。
- 每次只调整一个变量，例如频率、电压、风扇目标、冷却设置或固件。
- 每次调整后记录矿池侧算力、拒绝类型、功耗、温度和硬件错误。
- 如果某块算力板在稳定设置下仍持续产生 Invalid Share，应进一步维修或隔离。
评估调校效果时，不要只看本地算力。如果算力提高的同时带来了更多 Invalid Share、更高功耗、更大冷却负担或更多停机时间，最终利润反而可能下降。
4. 固件、驱动或代理故障
如果拒绝率在固件升级、自动调优设置变更、代理迁移或批量配置发布后突然升高，这些变更本身就是重要线索。
软件或配置变化可能影响矿机参数、任务处理、重试逻辑或设备稳定性。矿场最好记录固件版本、调校配置、代理版本和发布时间，并先在小规模设备上测试，再逐步扩大。
如果发布后拒绝率上升，可以先保留日志，对一小组设备进行回滚，再比较变更前后的矿池侧算力和 Share 状态。不要一出现问题就立刻重启整个机群，否则可能把关键日志和故障现场一起清掉。
5. 矿池节点、端口或 Worker 配置错误
配置错误可能引发鉴权失败、Low-difficulty Share、异常提交，甚至让 Share 被记到错误的账户下。
常见问题包括：
- Stratum 地址填写错误；
- 端口不匹配；
- 算法或币种节点选择错误；
- Worker 格式错误；
- 密码字段或账户配置异常。
切换矿池或节点时，应以官方文档为准。确认 Worker 已在目标账户下正常上线、Accepted Share 持续增加、收益账户配置正确，并在小规模验证无误后再迁移其余设备。
不建议长期依赖旧截图、历史节点列表或第三方配置模板。Worker 重名、代理配置冲突等问题也需要一起排查。
6. 矿池节点或上游服务异常
拒绝率升高并不一定都来自矿场内部。
如果多个不同地点、原本运行正常的矿机，在使用同一个节点时同时出现相似异常，就需要考虑区域路由、节点可用性或矿池侧服务问题。
联系矿池技术支持前，最好提前准备：
- UTC 时间戳；
- 受影响的 Worker；
- 节点和端口；
- 具体拒绝类型；
- 延迟和丢包测试；
- 重连日志；
- 异常前后的矿池侧算力变化。
这些信息能显著提高定位效率，也有助于区分本地设备问题和更大范围的路由或节点问题。
ViaBTC 帮助中心建议，当拒绝率异常时优先检查网络连接、矿机温度和固件状态。早期帮助文档也曾提到，部分场景下 3% 以内的拒绝率可能出现于正常运行中。不过对实际运营来说，与其把某个固定百分比当成通用红线，更有价值的是观察矿场自身基线是否发生了持续变化，并结合具体拒绝原因判断。
先看异常分布，再决定改什么
拒绝率异常出现在哪里、什么时候出现，往往比总百分比本身更有诊断价值。
现象更可能的原因优先处理 只有一台矿机异常，周边机器正常算力板、PSU、线缆、温度、调校或单机固件问题查看硬件错误和温度，恢复保守参数，测试线缆和网络端口 一个矿场所有矿机同时升高WAN、ISP、DNS、路由器、防火墙、代理或本地网络事件检查丢包、重连、路由器容量、DNS 和 WAN 日志 高温、超频或固件更新后升高温度/电压裕量不足，或软件不稳定回滚一组设备，对比矿池侧算力和拒绝类型 切换矿池或节点后开始异常节点、端口、Worker、路由或协议配置错误按官方设置逐项核对，并确认 Accepted Share 正常增长 多个地点使用同一节点时同时异常路由、区域节点或矿池侧问题测试其他官方节点，并向支持提交带时间戳的证据
30 分钟内可以完成的初步排查
出现拒绝率突然升高时，最重要的是避免同时改太多东西。否则即使问题恢复，也很难知道究竟是哪项调整起了作用。
- 先分类拒绝类型。 区分 Stale、Invalid、Duplicate、Low-difficulty、鉴权失败和超时。
- 确认影响范围。 判断是单台矿机、单个机架、单个站点，还是多个矿场同时出现。
- 对齐时间线。 查看异常开始时间是否与固件发布、超频调整、天气变化、网络维护、矿池迁移或供电事件重合。
- 比较本地和矿池侧算力。 使用足够长的统计周期，不要依据几分钟的瞬时值判断。
- 检查网络路径。 测试到当前矿池节点的延迟、丢包、重连和 DNS。
- 检查异常设备。 查看温度、风扇、算力板识别、Hardware Error、PSU 和线缆。
- 每次只做一个受控改动。 例如只回滚一组设备、只切换一个节点，或者只恢复一台矿机到默认设置。
- 验证是否真正恢复。 观察拒绝类型、Accepted Share 和矿池侧算力是否持续改善。
日常监控不应只看一个拒绝率
预防高拒绝率，关键不是设一个固定红线，而是监控能够解释异常的指标。
建议长期关注拒绝率、Stale Share 比例、Invalid Share 比例、断线次数、延迟、丢包、Hardware Error、温度，以及本地算力与矿池侧算力之间是否长期存在异常差距。
矿场可以进一步按站点、矿机型号、固件版本和冷却环境建立历史基线。这样一旦某类设备偏离正常范围，往往能更早发现。
协议层面的改进，例如 Stratum V2，可以改善部分矿池连接和任务分发流程，但它无法解决风扇损坏、供电不稳或算力板故障。运营目标仍然很直接：稳定接收当前任务、及时提交有效 Share，并尽早处理持续偏离正常水平的异常。
高拒绝率不等于这些问题
拒绝率不要与 Pool Luck、Network Difficulty 或 Stale Block 混在一起。
Pool Luck 描述的是矿池出块的统计波动；Network Difficulty 决定的是找到一个有效比特币区块平均需要多少工作量，并不会直接导致 ASIC 产生 Invalid Share；Stale Block 指的是一个有效区块最终没有留在主链上，它与矿池里的 Stale Share 也不是同一个概念。
把这些概念分开，才能正确判断收益为什么发生变化。难度上升导致的收益下降、短期 Pool Luck 波动，以及拒绝率升高，需要采用完全不同的排查思路。
FAQ
比特币矿机的拒绝率达到多少算高？
没有一个适用于所有矿场的固定阈值。更值得关注的是，某台矿机或某个站点的拒绝率是否长期高于自己的历史基线，以及增加的究竟是哪一种拒绝类型。对于大规模机群，即使幅度不大，只要持续时间足够长，也可能产生可观影响。
Rejected Share 会让矿机更耗电吗？
Rejected Share 本身通常不会直接提高 ASIC 的瞬时功耗。问题在于设备仍然持续耗电，但一部分计算结果没有被矿池接受。如果拒绝率长期偏高，同样的运营成本能够换来的有效工作量就会减少。
超频后本地算力更高，利润反而可能下降吗？
可能。激进参数可能提高矿机显示的 Hashrate，但同时增加 Invalid Share、功耗、散热需求、Hardware Error 或停机时间。判断效果时，应同时比较本地算力、矿池侧算力、拒绝状态、功耗和稳定性。
为什么切换矿池后拒绝率升高？
常见原因包括主机名、端口、算法节点、Worker 格式、凭证、DNS、防火墙规则或网络路径配置不正确。应先确认新矿池已经在目标账户下持续收到 Accepted Share，并按照官方配置逐项核对。
一定要选择地理位置最近的矿池节点吗？
不一定。地理距离会影响延迟，但实际路由质量和稳定性同样重要。应综合比较延迟、丢包、重连频率和路由稳定性，选择实际表现最好的官方节点。
结语
高拒绝率的本质，是矿机已经完成并消耗资源的部分工作没有被矿池有效接受。处理这类问题时，第一步不是立即更换设备或反复重启，而是先判断拒绝类型和影响范围，再根据证据逐项排查。
对于矿场运营来说，目标也不只是把本地 Hashrate 拉到最高。硬件稳定、连接可靠、Share 能够持续被矿池接受，最终才能让设备、电力和运维投入更有效地转化为挖矿收益。持续偏离历史基线的拒绝率，越早处理，越不容易演变成长期的收益损失。
参考资料
- Bitcoin Developer Guide: Mining — 矿池挖矿、Share 与挖矿流程。
- Blockchain.com Bitcoin Explorer — 比特币算力与难度数据。
- ViaBTC Help Center: What if the Rejection Rate is High? — ViaBTC 关于拒绝率异常的排查说明。