Troubleshooting “Socket connection failed” on the Miner Overview Page

“Socket connection failed” on the Miner Overview (Status) page means the web interface cannot reach the miner’s own mining daemon over its local API socket. The web UI is only a dashboard — it polls the running mining process (cgminer on Scrypt models like the L3+, bmminer on SHA-256 models like the S9) over a local API socket on TCP port 4028. When that process is not running — still initializing, crashed, or shut down by a fault — the dashboard has nothing to talk to and prints the error. It is a symptom, not a root cause. Work the causes below in order, cheapest and most common first.

This guide applies to the following legacy Antminer / Bitmain-firmware units:

A3 · B3 · D3 · L3+ · L3++ · fixed-frequency S9 · V9 · X3 · Z9 · Z9 mini

What the error actually means

On boot, the control board comes up first, then the mining daemon starts, detects the hash boards, initializes every ASIC chip, and only then opens its API socket. The status page can load and query that socket well before mining has stabilized. So the error usually points to one of these conditions:

• The miner is still booting or the daemon is mid-restart (transient — clears on its own).
• The mining daemon crashed or refused to start because a hash board failed to enumerate, a chain came back with the wrong chip count, or the config is corrupt.
• The firmware protected itself and stopped mining after an over-temperature event or a fan fault.
• The pool or network configuration is broken, so the daemon starts, fails every connection, and does not present a healthy socket.
• The firmware image is corrupt and the daemon never launches.

Safety first

The low-voltage DC that feeds the hash boards and control board (roughly 12–15 V on these units) is not a shock hazard. The danger lives inside the PSU: the mains input and primary-side capacitors hold on the order of 410–420 V DC and stay charged after you pull the cord. Do not open the power supply. Unplug the unit and let it sit before touching internal connectors. (These older units run on APW3/APW3++/APW5-class supplies, which operate on 110/120 V at reduced output — normal, not a fault.)

Step-by-step diagnosis

1. Power-cycle and give it time. Fully power the miner down, wait 30 seconds, and bring it back up. Wait a solid 5–10 minutes before reloading the status page — the daemon does not open its API socket until every chip on every chain has initialized. A large share of “Socket connection failed” reports are nothing more than someone reading the page too early. If it clears and stays cleared, you are done.
2. Reload the firmware. A corrupt or partially written firmware image will stop the mining daemon from ever launching. Download the correct official firmware for your exact model from the manufacturer’s support portal — never a random image from a forum, and never firmware for a different model — and re-flash it from the miner’s own upgrade page. After flashing, let the unit run for at least 20 minutes before you judge it, so the chips reach steady state and the daemon settles.
3. Check your pool settings. On the Miner Configuration tab, inspect every pool URL, worker name, and password. Look for stray spaces, a missing stratum+tcp:// prefix, the wrong port, or a typo in the worker. On Scrypt models (L3+/L3++) confirm you are pointed at a Litecoin/Scrypt pool, not a Bitcoin one. Bad pool entries can leave the daemon in a failing loop instead of presenting a clean socket. Fix, save, and let it restart.
4. Verify network stability. Confirm the miner has a valid IP, a correct gateway, and working DNS — a miner that cannot resolve its pool host will churn. Under Network → Diagnostic, use the Ping button to confirm it can reach your gateway and the pool. If the unit is unreachable on the LAN, check the cable and switch port; remember that address resolution maps the miner’s IP to its MAC on the local segment, so a duplicate IP or stale ARP entry on your router will make a healthy miner look dead. A miner that loses its pool or network does not keep drawing full power — the firmware idles it, which is expected.
5. Check the fans and temperatures. An over-temperature or fan fault will make the firmware stop mining to protect the chips — and a stopped daemon shows exactly this error. Open the miner’s kernel/system log and look for Fatal Error: some Fan lost or Fan speed low. If you see it, a fan has failed or is spinning too slowly. Compare the reported voltages of the front and rear fans; if the front fan reads lower, swap the two fan positions and re-test — if the fault follows the fan, that fan is bad; if it stays on the same header, suspect the wiring or the control board. Replace any failed fan with a correct-spec unit and confirm both fans spin up on boot.
6. Reset the miner to defaults. If pool and network look correct but the socket still fails, do a factory reset (via the reset button or the web UI’s restore-defaults option) to clear a corrupt saved configuration, then re-enter your pool details from scratch and re-test.
7. Isolate the control board. Power down and unplug the miner. Disconnect all hash boards from both the PSU and the control board, then boot the unit with only the control board connected. If “Socket connection failed” still appears with no hash boards attached, the fault is on the control board itself (or its firmware), and the board likely needs replacement or repair.
8. Test hash boards one at a time. If the error clears with the control board alone, the culprit is a hash board. Power down, reconnect a single board, and boot; repeat for each. A board that reliably brings back “Socket connection failed” while the others come up clean is the defective one. On the S9-class units each board has its own signal and power connectors — reseat both before condemning a board, since a loose connection mimics a dead chain.

Common mistakes

• Reading the page too soon — wait out the full boot before diagnosing further.
• Flashing the wrong firmware — match the image to the exact model; cross-flashing bricks the daemon.
• Hot-swapping boards — never connect or disconnect a hash board with the PSU energized; power down and unplug first.
• Ignoring the log — it names the failing chain or fan fault outright; read it before swapping parts.

When to escalate

If you have isolated a hash board that consistently triggers the error — missing chips in the log, a dead chain, or a chip-count mismatch — the board needs bench-level repair (chip, PSU-domain, or heat-fault work), not another reflash. Bag the board, note which chain it came from and the exact log message, and open a repair ticket. The same goes for a control board that fails alone.

Related: Match your model and its factory firmware from the Antminer manuals hub, narrow a bad chain with the ASIC fault finder, source replacement fans, boards, and cables from ASIC repair parts, and when a board is confirmed dead, start a repair with us.