Why do ASIC miners go “offline” even though the network is up?

Most “offline” incidents are actually DNS failures, blocked ports, unstable Wi‑Fi/routers, or the miner’s control board rebooting due to heat/power. Confirm DNS resolution, port reachability, and review miner logs for repeated reconnects or watchdog restarts.

What causes high rejected shares on SHA256 ASICs?

Common causes include pointing to the wrong port/algorithm, high latency (stales), unstable overclock/undervolt profiles, firmware bugs, or pool-side difficulty/job cadence problems. The fix is to isolate one miner, run a 20–30 minute test, and compare accepted vs rejected shares.

Do you help with third‑party firmware and tuning?

Yes. We help you pick safe profiles, validate cooling/power headroom, reduce HW errors, and stabilize the miner so accepted share rate stays consistent.

Can you troubleshoot pool-side issues that only affect certain ASIC brands?

Yes. Some pools break edge-case Stratum behaviors (vardiff timing, session handling, job updates). We review logs on both sides and fix the pool configuration or Stratum implementation so mixed fleets stay connected.

ASIC miner troubleshooting (SHA256/SHA256d): offline, rejects, HW errors & firmware stability

ASICs are simple on paper—enter a Stratum URL, a wallet/username, and a worker name. In real life, farms lose revenue from small issues: DNS hiccups, bad ports, unstable OC profiles, overheated hashboards, or pool-side job/difficulty behavior that certain ASIC brands dislike. This guide helps you diagnose the root cause quickly and shows exactly what we fix when you want it handled end-to-end.

On this page

Common symptoms (what users see)
Fix: miner offline / timeout / reconnect loop
Fix: high rejects & stales
Fix: high HW errors, throttling, board dropouts
Firmware and tuning: safe approach
How we troubleshoot (miner + pool-side)
Get help

Common symptoms (what users see)

“Offline” in dashboard or repeated “stratum connection interrupted” messages.
Hashrate looks fine locally, but the pool shows low accepted shares.
Rejects/stales spike after a firmware update, profile change, or network change.
HW errors climb, temperature jumps, or a hashboard disappears intermittently.
Random reboots or a miner that only stays stable at night / in cooler weather.

If you’re still at the basic setup stage, read our Bitcoin miner setup guide and confirm your pool URL and ports are correct.

Fix: miner offline / timeout / reconnect loop

Don’t start by swapping firmware. Start by proving the simplest thing: can this device reliably reach the pool endpoint?

1) Validate pool reachability

DNS: confirm the hostname resolves on the miner’s network (or use a known-good DNS resolver).
Port reachability: check the pool port is open from the miner VLAN (ISP firewalls and cheap routers block uncommon ports).
Correct endpoint: many pools have multiple ports (standard, low-diff, SSL). Using the wrong one can look like “offline.”

2) Remove local network variables

Prefer wired Ethernet over Wi‑Fi bridges.
Check for double NAT, captive portals, or “smart” routers doing aggressive traffic shaping.
If only one rack/site fails, it’s usually a switch/VLAN/DNS problem, not the miner.

3) Confirm the miner isn’t rebooting

A miner that reboots every few minutes will look like a pool connectivity issue. Review the web UI/logs for watchdog restarts. Reboot loops are frequently power or thermal.

Fix: high rejects & stales

The goal isn’t pretty hashrate; it’s accepted shares. Use a 20–30 minute controlled test: one miner, one pool endpoint, no tuning changes mid-test.

Quick decision tree

Rejects are mostly “stale”: latency/jitter, routing, or a proxy in the middle. Move closer to the pool or use a nearer region/gateway.
Rejects are “invalid”: wrong algorithm/port, unstable profile, or firmware/client bug.
Rejects jump only on one pool: likely a pool-side behavior issue (difficulty updates, session resets, odd job cadence).

If you’re operating a pool, this is where protocol quality matters. We harden Stratum behavior and documentation so miners connect cleanly. See our pool build services.

Fix: high HW errors, throttling, board dropouts

Hardware errors are often a systems problem: power delivery + airflow + environment + tuning. A stable miner under load should show consistent temps, consistent fans, and predictable accepted share rate.

Thermals: clogged filters, negative pressure, recirculation, or hot spots cause throttling and board dropouts.
Power: loose connectors, overloaded circuits, or unstable PSUs trigger reboots and “missing board” events.
Over-aggressive profiles: a profile that benchmarks well can be unstable over 24 hours.

Firmware and tuning: safe approach

When you tune (OC/UV) or change firmware, treat it like a production change: small canary test, observe, then roll out.

Baseline first: revert to a stable known-good profile and confirm reject rate and uptime.
One variable at a time: change only one knob (freq, voltage, fan curve) before you judge results.
Measure the right metrics: accepted shares, HW errors, temp stability, and reboots over time.
Document rollback: keep a clear path back to stock settings if stability drops.

How we troubleshoot (miner + pool-side)

Our work is practical: we chase the root cause, not the symptom. Depending on your situation, we can:

Audit configuration: endpoints, ports, worker naming, failover, DNS, time sync.
Stabilize firmware profiles: safe tuning that matches your cooling and power headroom.
Analyze rejects: stales vs invalids; isolate if it’s local network, miner profile, or pool behavior.
Fix pool-side compatibility: Stratum stability, vardiff timing, session handling, and onboarding docs for mixed fleets.
Improve long-term ops: monitoring, alerting, and runbooks so issues don’t repeat.

If you want a broader onboarding guide for SHA256 ASIC fleets, see ASIC miner brands & models (compatibility).

Get help

If your ASICs are offline, your reject rate is climbing, or your firmware profiles are unstable, send us the details and we’ll tell you the fastest path to resolution.

Include these for the quickest fix: miner model(s), firmware version, pool endpoint + port, reject breakdown (stale vs invalid), and a 10–20 minute log snippet.