If a miner won’t pull an IP, won’t hash despite having one, or has vanished after a move, the fault is almost always one of four things: DHCP (it never gets an address), the physical link (bad cable, port, or power), a firewall or ISP block on the pool port (online but can’t reach the pool), or a stale IP after a relocation. Work them in that order. Everything below assumes the miner is fully powered and its control board has booted — a machine starved of clean power fails networking tests for reasons that have nothing to do with your network.
Before you start: tools that make this fast
- A laptop on the same subnet as the miner (same router/switch, no VLAN separating them).
- A known-good Cat5e/Cat6 patch cable — the single most common failure. Swap it early.
- Your router’s admin page (the DHCP client/lease list) or the manufacturer’s IP Reporter utility for Windows.
- A terminal for
pingandarp -a. ARP resolves an IP to the hardware MAC, which is how you identify which device on the network is your miner.
Case 1 — A brand-new miner never gets an IP at all
The control board is booting but nothing is handing it an address. Check, in order:
- DHCP is running. The miner ships in DHCP mode — it expects a server to lease it an address. If your switch/router has DHCP disabled, the miner sits with no IP forever. Enable DHCP, or assign the miner a static address by hand.
- MAC binding / MAC filtering is off. A router that only leases to a whitelist of known MACs will silently refuse the new miner. Disable the filter or add the miner’s MAC.
- The physical link is real. Confirm the RJ45 link LEDs are lit at both the miner and the switch. No link light means a cable, port, or (rarely) a dead network jack on the control board — swap the cable and port before blaming the miner.
- Bench-isolate it. Plug the miner’s Ethernet port straight into a laptop or a dumb switch you control and watch for a lease. If it works there, the fault is your production LAN, not the miner.
Do not confuse the Ethernet jack with the board’s UART header. The network cable belongs in the RJ45 port; UART is a low-level TTL serial console used for firmware recovery, not for handing the miner a network connection.
Case 2 — Some new miners get an IP, others don’t
When part of a batch leases fine and the rest don’t, you’ve run out of addresses, not connectivity.
- Your DHCP scope is too small. Consumer routers often default to a pool of roughly 99 addresses. Ten miners on a home LAN plus phones, laptops, and cameras can exhaust that fast. Widen the DHCP range, or better, put the fleet on its own subnet with a properly sized scope. Understanding subnet/CIDR sizing pays off the moment you run more than a handful of machines.
- Test one of the “failing” units in isolation on the bench LAN from Case 1. If it leases there, the address pool — not the hardware — is your bottleneck.
Case 3 — The miner has an IP but isn’t hashing
The miner is on the network and its web UI loads, but it never reaches the pool. This is a routing/firewall problem, not a networking-hardware one.
- The pool port is blocked. Stratum typically runs over TCP on ports such as 3333, 4444, or 25 depending on the pool. Some ISPs and corporate firewalls block outbound mining ports. Try a different pool port, or confirm with the operator that the port is open.
- A router policy is filtering it. Whitelists, content filters, or access-control rules can let a device onto the LAN while blocking its outbound traffic. Review the router’s firewall/ACL rules.
- Pool credentials are wrong. Re-check the pool URL, port, and worker name in the miner’s Miner Configuration page. A typo in the stratum URL looks identical to a network outage from the dashboard.
- Prove the network. Move a couple of miners to a completely different network. If they hash there, the original LAN is filtering pool traffic.
Clear up one misconception: a miner that loses its pool or network link does not keep drawing full wall power. The firmware idles the hashboards when it can’t submit work, so a “dead” miner that’s not hashing is usually a connectivity fault, not a hardware emergency.
Case 4 — Miners drop out intermittently while running
Random disconnects that clear on a reboot point at the physical layer or unstable power:
- Marginal cabling or a flaky switch port. Re-seat and swap the patch cable, then try a different switch port. Cheap unmanaged switches overheat in a warm hashroom and drop links.
- Unstable power. A PSU sagging under load or a loose board power connector can brown out the control board and knock it off the network mid-run. Confirm every connector is fully seated and the PSU is rated for the model’s draw.
Finding a miner that moved — and the reset button
Relocate a miner and its old IP is often meaningless on the new network. Three ways to find it again:
- IP Reporter. Run the manufacturer’s IP Reporter tool on a laptop, then briefly press the miner’s physical IP report button (a pinhole on the control board). The miner broadcasts its current address to the tool. See the IP Reporter reference for the exact workflow.
- ARP / lease scan. From a machine on the same subnet, run
arp -aor open the router’s DHCP lease table and match the miner by its MAC address — the MAC is printed on the unit and never changes. A MAC address is the fixed anchor when the IP is a moving target. - Factory-reset to DHCP. With the miner powered on, use a pin to press and hold the reset button for about 5 seconds. Both the red and green LEDs go dark to confirm the reset; the miner reboots and comes back up requesting a fresh DHCP lease with default settings. This clears any stale static IP left over from the old location.
Common mistakes
- Assuming a no-hash miner is “broken hardware” when the pool port is simply firewalled.
- Reusing an old static IP on a new network that hands out a different subnet — nothing will route.
- Testing with the same suspect cable at every step instead of swapping it once, early.
When it’s not the network
If the miner never lights a link LED on a known-good cable and port, won’t boot far enough to answer a ping, or resets to no effect, the fault has moved from the network into the control board or power stage. Work it as a hardware fault from there: isolate the PSU, control board, and hashboards one at a time.
Related: Match symptoms to a repair path with the ASIC Fault Finder, pull the correct setup and reset procedure for your model from the miner manuals library, or hand a stubborn unit to the bench via Start a Repair.
