为什么 Bitaxe 的份额被拒绝，或统计没有出现？

先检查连接路径。矿机需要连接成功、通过授权并收到任务，才可能提交已接受份额。

1. 核对主机、端口和 TCP/TLS 是否匹配。单独的主机字段不要填写协议前缀。
2. 在设备日志中查找 DNS、超时或 TLS 错误，检查具体受影响的网络规则，不要直接关闭所有防护。
3. 确认授权后收到了任务。尝试其他入口前，先保存当前配置。

连接只是其中一个阶段。矿机还需要收到有效任务，并找到满足所分配份额目标的结果。

1. 核对设备日志中的授权和新任务，确认矿机正在计算哈希。
2. 查看当前份额难度，用下方等待时间工具理解低算力下为什么反馈可能较少。
3. 查看提交份额后收到的实际响应。错误需要按对应分支处理；地址被拒绝无法靠继续等待解决。

分开判断矿机收到的响应与看板刷新。遥测延迟或不可用，本身不能证明矿机已经停工。

1. 将完整钱包地址和矿工名称与设备上保存的设置逐一核对。
2. 检查最后一份已接受份额的时间以及看板时间窗口，不要只看旧的累计数。
3. 如果矿机持续收到接受响应，记录时间，并就遥测缺失联系支持。

提交的工作可能对应已经不再接受的任务。需要调查任务更新和连接情况，一次 ping 测量无法确定原因。

1. 记录完整响应及发生时间，同时保留重连或新任务消息。
2. 在保持电压、频率等设置不变的情况下比较连接稳定性。
3. 核对矿机与矿池日志是否对应同一任务。没有原因或含义不明确时，请向支持人员确认。

这两类错误与过期工作不同。重复提交占比不自动等于相同比例的计算时间损失。

1. 重复提交时，检查相同任务与 nonce 是否被再次发送，以及重连行为。
2. 难度过低时，对比矿机收到的目标、实际提交结果和固件处理难度的方式。
3. 未核实支持情况前，不要照搬其他矿池通过密码设置难度的语法。为运营方保留简短、脱敏的日志样本。

矿池算力根据提交工作估算。设备读数与短时间窗口内的矿池估算可能不同，份额较少时波动尤其明显。

1. 比较相同时间窗口，并让估算积累足够的已接受工作。
2. 同时记录份额难度、中断情况和实际拒绝原因。
3. 换池后最高难度或份额数变大，不能证明每次哈希的出块概率变高了。