The Bitaxe connects to Wi-Fi but does not mine: checking router and network faults systematically

The Bitaxe connects to Wi-Fi but does not mine: checking router and network faults systematically

Your Bitaxe is on the home network, AxeOS is reachable, but the hash rate stays at zero or no accepted shares arrive? Then the problem often lies not with the device itself but somewhere between Wi-Fi, router and the pool connection.

These cases are tricky precisely because the miner looks “online” at first glance. The display is running, the dashboard is there and the basic configuration seems right. Yet no clean mining operation comes about.

So this article is not about the general setup but about targeted troubleshooting for exactly this state: Bitaxe connected, but no sensible mining output. You get a practical order of checks, typical router causes and a clear sense of when the network, the pool, the firmware or the hardware is responsible.

How to recognise this fault state

The typical case looks like this:

• The Bitaxe is on the Wi-Fi.
• AxeOS loads in the browser.
• The pool details are entered.
• The hash rate stays at zero permanently.
• Accepted shares do not rise.
• The miner reconnects repeatedly or looks restless in its status.

The distinction matters: this is not automatically the same case as an elevated hash rate error in AxeOS. The hash rate error points more towards stability, temperature, voltage or clock. If your Bitaxe is generally reachable but does not build a clean connection to the pool, the cause often lies earlier in the chain: with DNS, router rules, the stratum host, the port or Wi-Fi quirks.

Why “connected to Wi-Fi” does not yet mean mining works

Many newcomers equate a successful Wi-Fi connection with working mining. That would be nice, but in practice it is only partly true.

For your Bitaxe to really mine, several things have to work cleanly at the same time:

• the device needs a stable connection to the home network,
• the router must not block or redirect the outgoing connection,
• the stratum host you entered has to be reachable,
• the port has to be right,
• your pool configuration has to be formally correct,
• and AxeOS, or ESP-Miner, has to run stably.

That is exactly why a Bitaxe can be reachable locally and still not work sensibly. The dashboard then only tells you the device is alive – not automatically that the whole mining path works.

The most sensible order of checks on a home network

With this fault pattern, frantic clicking is no help. A fixed order is better.

1. First check whether there really is a network problem

Open AxeOS and do not look at a single number. What matters most:

• is the number of accepted shares rising at all,
• does the pool status look stable,
• do repeated reconnects appear,
• is the uptime calm or does the state keep breaking down?

If hash rate, shares and connection all look implausible at once, a network or pool access problem is more likely than a pure tuning problem. If you want to read the dashboard itself better, our overview of AxeOS and its most important readouts will help.

2. Check the pool host, port and user field without assumptions

A surprisingly frequent cause is not the router but a sloppy pool configuration. A small typo is enough.

So check soberly:

• is the stratum host exactly right,
• does the port match the chosen pool endpoint,
• is the user field entered in the expected format,
• is a worker suffix used that the pool actually accepts?

In home mining setups in particular it makes sense to start with a pool configuration that is as simple and well documented as possible. If you are still unsure which provider fits your setup, take a look at our guide choosing a Bitaxe mining pool.

3. Check whether the router restricts outgoing connections

Now comes the point that is regularly overlooked with Bitaxe, NerdAxe and similar devices: some routers or security features disturb mining traffic even though normal browsing on the network works fine.

The official ESP-Miner repository points to exactly that. It explicitly notes that certain ASUS and some TP-Link routers can block mining connections and that features like AiProtection or IoT security filters should be checked or temporarily disabled.

That does not mean every ASUS or TP-Link router is problematic. It only means: if your Bitaxe looks online but no clean stratum connection comes about, this point belongs right at the top of the checklist.

4. Relax router features as a test

Security or convenience features that automatically classify, filter or isolate IoT devices are particularly relevant. Typical candidates are:

• AiProtection or similar network protection features,
• IoT security modes,
• client isolation or AP isolation,
• parental controls or content filters,
• DNS or traffic filters with restrictive default rules.

The clean route is not to switch everything off permanently and blindly. It is more sensible to run a short test: disable one problematic feature, restart the miner, watch the behaviour. If the Bitaxe suddenly delivers accepted shares afterwards, you have found the direction.

5. Keep 2.4 GHz Wi-Fi and signal quality in mind

The ESP32 in the Bitaxe can only do 2.4 GHz. Band steering, mesh optimisation or several access points like to push it onto a band or an access point it cannot hold cleanly – then the pool connection drops every few minutes even though AxeOS stays reachable.

What matters here is practicality:

• If your router separates the SSIDs for 2.4 and 5 GHz, set the miner up cleanly on the right network.
• If band steering is active, a simple test with a clearly separated 2.4 GHz SSID can help.
• A Bitaxe should not be run at the edge of reception if you expect a stable pool connection at the same time.

This is not an exotic special case but classic home network behaviour: a device can be just well enough connected to load the dashboard and still suffer from an unstable or restless connection.

6. Do not forget DNS and local special configurations

If you use your own DNS filters, Pi-hole, AdGuard, firewalls or VLAN rules on your network, you should check that layer too. Mining fails not only when the internet connection is missing entirely but often because of apparently small infrastructure rules.

Typical examples:

• the pool host name is not resolved cleanly,
• outgoing ports are restricted,
• an IoT VLAN may reach the local network but not the internet reliably,
• DNS or security rules treat stratum traffic as suspicious.

Technically minded users in particular often look at clock, temperature and firmware first. With this fault pattern, though, the boring network part is usually worth checking first.

When the firmware or AxeOS is more likely to be the cause

If the pool details are correct, the router sets no conspicuous filters and the network generally looks clean, the firmware layer comes into play.

ESP-Miner is developed continuously, and AxeOS updates can improve stability, display behaviour or configuration details. If your device runs an older version or behaves oddly after changes, a controlled update makes sense. You will find a general assessment in our post on the Bitaxe AxeOS update.

The order matters, though: an update is no substitute for clean troubleshooting. If the real cause is in the router, new firmware often does not solve the problem for long.

When hardware, cooling or the power supply is responsible

Not every zero-hash-rate case is a network topic. If your Bitaxe is connected but crashes under load, runs hot or shows very restless values, you should check these points too:

• is the cooling working cleanly,
• is the power supply suitable and stable,
• were the clock or voltage set too aggressively,
• does the problem only appear after some run time at temperature?

With experimental settings in particular it makes sense to go back to conservative defaults first. If you want to build your setup to be thermally more robust, accessories such as the Ice Tower Low Profile kit or a quieter Noctua NF-A4x20 can be worth a look. That does not replace troubleshooting, but for permanently stable home setups it is often more practical than tuning at the edge.

Common misconceptions in exactly this scenario

“AxeOS loads, so the network is fine”

No. That only proves you can reach the device locally. For mining, the outgoing connection to the pool also has to work cleanly.

“No hash rate automatically means a hardware defect”

Also no. Especially when the Bitaxe is reachable in the browser, configuration, router rules or pool access are often more likely than a real hardware fault.

“Then I will just update first”

That can make sense, but it should not be the first reflex. Otherwise you may only postpone the problem without understanding the real cause.

“A single reconnect is already proof”

Not that either. Individual brief disruptions happen. It becomes relevant when dropped connections, zero accepted shares and an implausible hash rate occur together.

The pragmatic recommendation for practice

If your Bitaxe is connected to Wi-Fi but does not mine, work in this order:

1. Read the AxeOS values and the pool status carefully.
2. Check the pool host, port and user field exactly.
3. Relax router security features and IoT filters as a test.
4. Check the 2.4 GHz setup and Wi-Fi stability.
5. Check DNS, VLANs, Pi-hole or firewall rules.
6. Only then question firmware, tuning and hardware more deeply.

This order saves time because it covers the most common causes first. In many home network setups the problem lies not in the miner itself but in a network configuration that is too strict or too complex.

Conclusion: with “online but no shares”, the router is often the real suspect

If a Bitaxe is reachable locally but does not build up clean mining performance, do not reflexively assume a hardware problem. On a home network in particular, router features, DNS rules, IoT filters or a sloppy pool configuration are usually the far more likely cause.

For beginners the most sensible next step is therefore usually not aggressive optimisation but a sober network check. For advanced users it is particularly worth looking at router security features, segmentation and DNS.

If you are planning a new or more stable setup, a conservatively configured miner on a clean home network is usually the better choice than a device tuned to the edge in an unnecessarily complicated infrastructure.

FAQ: the Bitaxe is online but does not mine

Why does my Bitaxe show a Wi-Fi connection but no accepted shares?

Because local reachability does not automatically mean the outgoing connection to the pool works. Common causes are wrong pool details, blocked ports, router security features or DNS problems.

Can an ASUS or TP-Link router block Bitaxe mining?

Yes, that is documented as a possible cause. The ESP-Miner project explicitly notes that certain ASUS and some TP-Link routers can disturb mining traffic, especially in combination with features like AiProtection or IoT filters.

Should I update AxeOS first when there is no hash rate?

Not necessarily. The pool configuration and the network should be checked first. An update makes sense if your version is old or the other points have already been cleanly ruled out.

Further reading

If the miner still produces no shares, the troubleshooter walks through every cause and hands your click path to support. For the basic setup use the Bitaxe setup guide, for reading the dashboard AxeOS explained.