SoloLuck Blog · 2026-06-29
It is 2 a.m. Your Bitaxe is humming in the corner, fans spinning, drawing the same watts it always does. But the pool it points at went dark an hour ago — a domain quietly expired, a DDoS wave hit, or the operator's Bitcoin node stalled on an RPC call. Your miner is still hashing at full speed. It just is not submitting a single share to anyone. That silent failure is exactly what a proper bitaxe fallback pool setup exists to prevent.
Almost every AxeOS guide walks you carefully through the primary pool field, then leaves the fallback slot blank or filled with a copy of the primary. That second field is the most ignored setting in the firmware — and it is the one that protects you when something breaks. A fallback pool is simply a second stratum endpoint that AxeOS switches to automatically when your primary stops responding, so your hashrate keeps landing somewhere that counts.
Here is the thesis up front, plain enough to act on while you are still in the settings screen: always fill the fallback field, and fill it with a different pool than your primary. An empty fallback means your hashrate evaporates the moment your one pool blinks. A fallback pointed at the same operator means a single outage takes down both slots at once.
This applies to every AxeOS-based device — Bitaxe Gamma, Ultra and Supra, plus NerdAxe, NerdQAxe and the NerdOCTAXE family. Menus differ slightly across firmware versions, but the two-pool model is identical everywhere. See the SoloLuck setup page for ready-to-paste endpoints, or the Bitaxe solo mining pool guide for the wider picture.
Let's be precise, because solo mining attracts a lot of hand-waving. An outage does not lower your lifetime odds of finding a block. Each hash is independent; a missed hour is just a missed hour, not a penalty against future luck. The universe does not hold a grudge.
What it does waste is the electricity and uptime you already paid for. The power bill, the heat, the wear on the PSU and the ASIC — all of it accrued while your miner submitted zero shares anywhere they counted. That is what "mining for free" means here: you spent the inputs and got none of the (admittedly lottery-odds) output. A fallback pool turns that wasted hour back into a working hour.
The realistic conditions that trigger AxeOS failover are worth naming plainly:
One honest caveat: failover on stock firmware is driven mainly by lost or unreachable connections. A pool that keeps the socket open but stops sending fresh job templates leaves you hashing stale work, and that will not reliably trip the switch on its own — so stale work is a real risk, not a guaranteed auto-failover.
There is also a myth worth busting: "solo is a lottery, so a little downtime doesn't matter." That is backwards. Precisely because it is a lottery, you want every second of hashrate actually submitted somewhere it counts — you cannot know in advance which share is the winning one. A fallback is about reliability and not wasting uptime, not boosting your odds. For the honest math, see is solo mining worth it and the solo mining odds calculator.
This is the question that brought most people here: what do you actually paste into that fallback box? Three rules cover nearly every case.
| Rule | Why it matters |
|---|---|
| Different operator | The whole point of a backup is independence. If primary and fallback share servers, one outage takes down both at the exact moment you need the spare. Use two independent operators. |
| Low latency / nearby | Distance is latency, and latency is stale shares. A distant backup spikes your stale and reject rate right after failover. In Asia, US pools sit 200ms+ away. |
| Right difficulty tier | Tiny ESP32 and Bitaxe units produce shares slowly. A high minimum difficulty makes a small board look dead after a switch. Small devices need a low-min-difficulty endpoint. |
A concrete recommendation that satisfies all three: point your fallback at stratum.sololuck.io. SoloLuck is true-solo (ckpool in -B mode, so you keep the entire block reward), non-custodial, and runs from Asia/Jakarta for low latency. The fee is a flat 2% paid on-chain only if you actually find a block — there is nothing to lose by parking it in your backup slot. It also runs multiple stratum tiers, including a difficulty-1 "Nano" tier on port 3335 for the smallest devices.
As a backup it is genuinely zero-downside: if your primary never goes down, it never fires; if it does, your hashrate lands somewhere fast and close. Don't take the latency claim on faith — the measured head-to-head numbers are on /compare, and a regtest payout proof that solo blocks pay your address is on /proof.
Here is the exact click path. Open your miner's AxeOS web UI in a browser (just type the device's IP on your LAN), then navigate to Settings → Pool Configuration. You will see two groups of fields that look identical — host, port, user, password — one labelled Primary and one Fallback. Leave your primary as-is and fill the fallback group.
address.worker convention. AxeOS labels this the fallback stratum user field. Use a worker name distinct from your primary so you can tell the units apart.x (solo pools ignore it).A copy-paste reference for a SoloLuck backup — replace the placeholder with your own address, and never paste someone else's:
| Field | Value |
|---|---|
| Fallback URL | stratum.sololuck.io |
| Fallback Port | 3333 standard · 3334 TLS · 3335 Nano (diff-1) |
| Fallback User | YOUR_BTC_ADDRESS.bitaxe01 |
| Fallback Password | x |
Pick any worker label after the dot (.bitaxe01, .garage, whatever helps you tell units apart). Need an address first? See how to get a Bitcoin address for mining — use a wallet you control, since SoloLuck is non-custodial and pays straight to that address.
Hit Save and restart when prompted. AxeOS writes both pools to the chip's NVS (non-volatile storage), so your primary and fallback both persist across reboots and power cuts. You set this once and forget it.
SoloLuck runs several ports so each class of device submits shares at a sensible rate. For the fallback slot, pick the tier that matches the miner you are configuring.
| Port | Tier | Best for |
|---|---|---|
3333 | Standard | Bitaxe Gamma/Ultra/Supra, NerdAxe, NerdQAxe |
3334 | TLS (encrypted) | Same hardware on shared / hotspot Wi-Fi (needs AxeOS v2.13.0+) |
4334 | Alternate | Networks that filter the common ports |
3335 | Nano (difficulty-1) | ESP32 / NerdMiner-class, smallest Bitaxe units |
Match guidance: put Gamma / NerdQAxe-class hardware on the standard tier (3333), where its hashrate produces shares at a healthy rate. Put ESP32 and Nano-class boards on the diff-1 tier (3335) so their slower share stream actually registers instead of looking dead. If you are unsure, smaller is safer — a diff-1 endpoint always surfaces shares.
Why TLS matters in the fallback slot: on café Wi-Fi, a shared apartment network, or any link you do not fully trust, port 3334 encrypts the stratum session so your address and worker traffic are not exposed in plaintext. One caveat — encrypted stratum was only added to ESP-Miner in firmware v2.13.0, so a device on older AxeOS will fail to connect to the TLS port. If yours is older, update first or use 3333/4334 in the backup slot.
The full per-tier endpoint list and live per-model odds cards are on /setup. For tiny boards specifically, see the NerdMiner solo pool guide.
A backup you never tested is just a hope. Confirm the switch fires before you need it at 2 a.m.
To confirm the worker actually connected on SoloLuck, look it up by your payout address on the workers / leaderboard view, then use /verify to confirm you are genuinely mining true-solo to your own address — the trust card shows the coinbase output, so you are not taking anyone's word for it.
One important reality check on failback: on current stock AxeOS firmware, the device does not reliably return to the primary on its own while the fallback is still working — a known open issue means it tends to stay on the fallback until you reboot it or reselect the primary manually. So when your test is done, restore the correct primary host and reboot the miner (or switch it back by hand) to put it back on your preferred pool. This is harmless for a free, true-solo backup like SoloLuck, but worth knowing so you are not surprised to find a unit still on the fallback days later.
Almost every "my fallback didn't work" report comes down to one of these four. Each is a two-minute fix in the Pool Configuration screen.
| Mistake | Fix |
|---|---|
| Same pool in both slots | Defeats the entire purpose — one outage drops both. Use two independent operators. |
| Wrong worker / address format | Causes rejects the instant failover kicks in. Use exact address.worker syntax with your real address — no spaces, no leftover example text. |
| High-min-diff backup on a small Bitaxe | The unit shows zero accepted shares after switching. Use the diff-1 Nano tier on 3335 so tiny devices actually surface shares. |
| Distant / high-latency backup | Stale shares spike during failover. Pick a nearby, low-latency stratum — in Asia, that is the SoloLuck advantage. |
The address-format mistake is the sneakiest, because the device looks fine until a failover happens and then every share on the backup gets rejected. Double-check that the fallback user reads YOUR_BTC_ADDRESS.bitaxe01 — your own address, a dot, then a worker label.
Notice the pattern: every fix comes back to the three rules — different operator, low latency, right difficulty tier. Get those right and your fallback is genuinely set-and-forget. If you are still weighing whether any of this lottery is worth your watts, the honest take is in solo vs pooled mining. A fallback does not change the odds — it just makes sure the watts you are already spending are never spent for nothing.
A correctly configured second pool is the cheapest insurance in mining, and it costs you nothing to keep it pointed at a free, true-solo backup. To recap the whole bitaxe fallback pool setup in one breath: fill the fallback field, use a different operator than your primary, pick a nearby low-latency stratum, and match the difficulty tier to your hardware.
For SoloLuck that means stratum.sololuck.io, port 3333 for a Bitaxe Gamma or NerdQAxe and 3335 for an ESP32/Nano-class board, with your own address in address.worker form and x as the password. It is non-custodial true-solo with a flat 2% on-chain fee paid only when you actually hit a block — a zero-downside slot to park in your backup field.
Grab the exact per-tier endpoints and live per-model odds cards on /setup, then paste your fallback and save. The next time your primary blinks, your hashrate keeps working instead of grinding into the void.
Paste your address and copy the config from /setup, watch the pool on /status, and check every claim on /verify. Mine to your own address — that is what makes it truly solo.
Not ready to point a miner yet? Run your gear through the odds calculator, or join Telegram for block & record alerts — no rig required.
Join the SoloLuck community
Mine true-solo with other miners on Telegram — setup help, block alerts, and real people.
Join on TelegramRemembered with a first-party flag — no cookies, no trackers.