ASIC Miner – API Not Responding

Open your pool dashboard and confirm the miner is still submitting shares. Record current hashrate, last-share timestamp, and accepted/rejected ratio. If the worker is online and healthy at the pool, the mining is fine - you are fixing telemetry, not hardware, and nothing below will make your miner lose revenue. This one confirmation changes the whole posture of the troubleshooting session.

Restart your monitoring tool entirely. Awesome Miner, Hive OS agent, Foreman, Zabbix, Grafana scraper - close and relaunch. About 12% of `API not responding` tickets clear without any miner-side work because the monitoring tool itself was the problem: stale cached connection, exhausted socket pool, wedged auth token after a restart of its own. Costs 30 seconds to try before you touch the miner.

Remove the miner from your monitoring tool and re-add it by IP, not hostname. DHCP lease rotations silently break monitors that cached the old hostname mapping. Re-adding by raw IP rules out ~8% of tickets in one step and tells you immediately if the monitor's allowlist had drifted. If re-adding succeeds, pin the IP in Step 9 to prevent recurrence.

Try a different monitoring tool or raw CLI from a different machine: `nc -zv <miner-ip> 4028` from your laptop, your phone on WiFi, or a Raspberry Pi. If any one of them gets an answer on `:4028`, the miner is fine and the original monitoring host is the problem - its firewall, antivirus, VPN routing, or MDM profile. This isolation step costs nothing and saves shipping a working miner.

Hard power-cycle the miner at the wall - 30 seconds off, not a soft reboot. Wait 3 minutes after power-up. Re-run `nc -zv <miner-ip> 4028`. Roughly 55% of API-dead tickets resolve at this step in D-Central's queue. If it recurs after a predictable uptime window (every 60-96 hours is common), you have a resource-leak pattern pointing at Tier 3 firmware replacement rather than a transient wedge.

Verify the miner IP has not changed and pin it. Log into your router, find the miner's MAC in the DHCP leases table, and set a DHCP reservation so the IP never rotates. Monitoring tools silently break when a miner picks up a new lease - the tool still polls the old IP, the old IP now belongs to your printer, and you see `connection refused` from the printer's closed port instead of a clear error. DHCP reservation is a one-time fix that prevents recurring mystery failures.

Check whether your monitoring host's firewall allows outbound TCP `:4028`. Windows Defender Firewall, Little Snitch on macOS, `ufw` on Linux, corporate endpoint protection - any of these can silently block outbound cgminer traffic because it is an unusual port. Add an explicit allow rule for `:4028` to your miner subnet and retest. This is one of the top misdiagnosed patterns in corporate and MDM-managed environments.

Examine your network-security stack. UniFi / Dream Machine IDS/IPS in strict mode drops cgminer traffic as `anomalous`. ASUS AiProtection does the same silently. pfSense / OPNsense with aggressive outbound rules from an IoT VLAN to a mining VLAN. Disable IDS/IPS or add explicit allow rules for the miner's MAC or IP, then retest. This fix covers roughly 14% of chronic `API unreachable` tickets in mixed home networks.

Assign a static IP to the miner in its own firmware rather than via DHCP. Stock Bitmain: Configuration → Network → Static, enter IP / netmask / gateway / DNS. DCENT_OS and Braiins OS+ expose the same via their network config. Eliminates lease-rotation problems permanently and makes monitoring allowlists stable. Document the IP in a spreadsheet or Pi-hole - you will thank yourself at the next firmware upgrade.

Roll firmware one version back if the API died after a recent update. Identify your control-board revision from its sticker (`BHB42xxx` on S17-era, `BHB56xxx` / `BHB68xxx` on S19/S21). Download the previous stable build from `service.bitmain.com/support/download`. Flash via the miner's web UI or SD card. Back up your pool config first. On Whatsminer, WhatsMinerTool can push a previous firmware bundle; on Bitaxe the bootloader flash via USB-C is non-destructive.

SSH into the miner and inspect the cgminer / bmminer / btminer config. On custom firmware: `ssh root@<miner-ip>`, then `cat /config/cgminer.conf | grep -iE 'api-allow|api-listen|api-network'`. Healthy permissive state is `"api-listen": true, "api-network": true, "api-allow": "W:0/0"`. Any of these set to `false` or missing your monitor's IP is the fix. Edit the config, restart the daemon (`/etc/init.d/cgminer restart` or `systemctl restart bmminer`), retest.

Restart only the API daemon without rebooting the miner. On custom firmware: `ssh root@<miner-ip>`, `/etc/init.d/cgminer restart` (Braiins OS+), `systemctl restart bmminer` (DCENT_OS), or `systemctl restart btminer` (Whatsminer custom builds). Non-destructive - mining continues during the restart, shares keep flowing, the API socket rebinds fresh. Recovers from descriptor-leak and port-rebind wedges without losing any revenue.

Check resource usage via SSH: `free -m` for memory, `df -h` for filesystem, `ps aux --sort=-%mem | head -10` for top processes. Free memory under 20 MB or `/tmp` above 90% full points at resource exhaustion - the API gets killed first by the OOM-killer because the mining process has higher priority. Short-term fix: reboot. Long-term fix: flash a firmware with better memory hygiene (DCENT_OS, Braiins OS+, LuxOS) on Antminer hardware.

Cross-flash DCENT_OS (D-Central's own open-source Antminer firmware - the Mining Hackers' option: modern daemon, proper API with per-chip telemetry, autotuning, per-chip HW%, stratum v2, SSH always on, open-source on GitHub, no licensing fees). Fixes the API-wedge class of bug permanently on Antminer hardware because the daemon is better-engineered. Alternatives: Braiins OS+, LuxOS, Vnish. On Whatsminer: stick with matched official `btminer` bundles - DCENT_OS is Antminer-only. On Canaan: use official firmware. On Bitaxe / NerdAxe: update AxeOS via OTA or USB-C bootloader.

Verify firmware signatures and checksums before flashing. Any firmware not cryptographically signed by Bitmain, D-Central, Braiins, LuxOS, or the legitimate project maintainer is a risk - miner firmware has shipped with coin-redirect backdoors in the past. Download from the official source only and compare SHA-256 checksums before flashing. Five minutes of verification saves you from silently mining to an attacker's wallet.

Stop DIY and book a D-Central bench slot when all three are true: (a) SSH, web UI, and API on `:4028` are all dead and the miner has stopped submitting shares at the pool as well, (b) UART console at 115200 baud shows no boot output or repeated `squashfs error` / `mmcblk0: error` / `ubifs: error` / `Kernel panic` lines, and (c) SD card flash or eMMC reflash does not restore boot on hardware that supports one. You are looking at eMMC wearout, SoC failure, PMIC failure, or control-board power-rail damage. Book at https://d-central.tech/services/asic-repair/.

D-Central bench process for dead-API / dead-control-board repairs: documented U-Boot access and eMMC programmer, JTAG recovery where available on the specific SoC (Xilinx Zynq on older Antminers, Amlogic or custom on newer Bitmain, custom on Whatsminer / Avalon), eMMC chip replacement with programmed stock from inventory if wearout is confirmed, PMIC sanity check, full firmware rebuild from known-good image, and 24-hour burn-in at nameplate to verify the API, web UI, pool connection, and hashrate all stay up under sustained load.

Ship safely. Control-board-only repairs: anti-static bag, bubble-wrap padding, small box - the board is roughly 150 mm by 80 mm and ships cheaply from most of Canada. Full-miner ship-ins: original Bitmain / Whatsminer / Canaan box if available, otherwise double-walled box with 5 cm of foam on every side, fans removed or padded, PSU shipped separately or padded. Include a note with observed symptoms, firmware version string, network-layer steps already tried, `nc` / `nmap` / `curl` output you captured, and contact info - saves diagnostic time and your repair cost.