BITAXE.BALLER

// blog · · by Nathan Baldwin

Troubleshooting a Bitaxe that won't connect to a pool

// Bitaxe stuck on 'connecting' or no shares submitting? Walk through stratum URLs, ports, worker names, and firmware quirks that quietly break pool config.

Nine times out of ten, a Bitaxe that “won’t connect to a pool” is connecting fine — it’s just not submitting shares the pool will accept. The pool’s dashboard shows nothing, AxeOS shows a happy little green dot, and you sit there for an hour wondering why your hashrate is going into the void. The actual TCP socket is up. The credentials are wrong. The worker name is wrong. The difficulty is wrong. Or the firmware has a bug from two versions ago that no one wrote down.

This is the order I work through when a Bitaxe goes dark on a pool, with the failure mode behind each step.

Step 1: confirm the socket is actually open

Before you touch any pool config, check whether the Bitaxe can reach the pool at all. From any machine on the same network, run:

nc -zv stratum.public-pool.io 21496

(Substitute your pool’s host and port.) If you get succeeded, TCP is fine and your problem is at the protocol layer — read on. If you get connection refused or host unreachable, the issue is upstream of the miner: DNS, firewall, ISP, or you typoed the host.

Most home networks pass outbound TCP without complaint, but a surprising number of mesh routers (Eero, Google Wifi) silently block low-numbered ports under “Advanced Security” or similar. If nc fails from a laptop on the same LAN, it’ll fail from the Bitaxe too — and the miner has no way to tell you why.

Step 2: check the stratum URL format

AxeOS expects the pool host without a protocol prefix. These all break in different ways:

If you copy-pasted the URL from the pool’s “Getting Started” page, there’s a 90% chance you grabbed the wrong format. Strip it down to the bare hostname.

Step 3: worker name and the dot convention

Most public pools route hashrate by the part of the username before the dot, and tag the worker name with everything after. So:

bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh.gamma01

…means “pay to this Bitcoin address, label this worker gamma01.” Get the dot wrong and the share lands in some other user’s bucket, or gets rejected outright.

Some pools (Solo CK, Public-Pool) accept a raw Bitcoin address as the username. Some (NiceHash, Mining-Dutch) require an account name. A handful (OCEAN) require a specific template format that includes the pool’s worker prefix. If the pool’s dashboard says “worker not found,” your username string is wrong. Re-read the pool’s docs — every pool spells this differently.

One subtle failure: AxeOS strips trailing whitespace from the username, but not leading whitespace. If you have a space in front of your address (easy to do when copying from a wallet UI), the address looks fine in the AxeOS UI but the pool sees a malformed username and refuses every share. Inspect the field character by character if shares are getting rejected with no error.

Step 4: port and TLS mismatch

Public-Pool, Solo CK, and similar self-hosted pools usually run plain TCP. Big commercial pools (Foundry, F2Pool, ViaBTC) often have separate TLS ports: 443, 3334, or 4444 for SSL, 3333 or 21496 for unencrypted. AxeOS does not support stratum-over-TLS as of AxeOS v2.7.x — if you point it at a TLS-only port, the connection completes, the TLS handshake fails, and AxeOS keeps retrying every 30 seconds without surfacing the error.

If your pool only documents TLS ports, ask in their Discord whether a plain-TCP endpoint still exists. Most still have one for legacy hardware. The Public-Pool docs call this out directly. If they really are TLS-only, you’ll need a TLS-terminating proxy on your network (stunnel, nginx stream module) until AxeOS adds native support.

Step 5: difficulty settings that black-hole your shares

This one bites people who switch pools without resetting the suggested difficulty. AxeOS lets you set a “suggested difficulty” that the pool can either honor or override. If your previous pool was running a difficulty of 1000 and your new pool’s minimum is 8192, every share your Bitaxe submits at the old difficulty gets silently rejected as “share below minimum.” The pool’s protocol response is correct, AxeOS logs nothing visible, the dashboard just shows zero accepted shares.

Set suggested difficulty to 0 for a fresh pool config. The pool will hand back its own minimum on the first stratum subscribe response, and you’ll start submitting valid shares within a minute. There’s a longer companion post on this (/blog/bitaxe-pool-difficulty-suggested-vs-auto) but the short version is: when in doubt, zero it.

Step 6: firmware quirks worth knowing

A few real bugs from AxeOS history that cause silent “won’t connect” failures:

If you’re running anything older than v2.7.x and the symptoms don’t match any of the steps above, update the firmware before you debug further. There’s no point chasing a config bug that was patched twelve releases ago. Compare against the official Bitaxe firmware releases and read the changelog for anything between your version and current.

Step 7: when the miner connects but submits nothing

If nc works, the URL is clean, the worker name is right, the difficulty is zero, and the firmware is current — and you still see zero accepted shares — pull the AxeOS web UI’s serial monitor. It dumps every stratum message in real time. Look for mining.notify arriving and mining.submit going out. If mining.notify is arriving but the miner isn’t submitting, the issue is on the device side (usually undervolt or a flaky power supply causing hashes to fail validation). If mining.submit is going out and the pool isn’t acking, the issue is the worker/difficulty pair.

What to do

Open a terminal and run nc -zv against your pool first. That tells you in two seconds whether you’re debugging the network or debugging stratum config. Then strip the URL down to a bare hostname, zero out the suggested difficulty, and confirm your worker name format against the exact text on the pool’s docs page. If you’re still on AxeOS v2.6 or older, update before anything else.

Try it yourself: Bitaxe Baller is a free desktop app for Mac and Windows that surfaces these recommendations automatically across your fleet — live monitoring, tuning suggestions, pool config, all in a native window. Open source on GitHub.

← back to blog