Bitaxe – Stratum URL Contains stratum+tcp:// Prefix
Informational — Monitor and address as needed
Symptoms
- AxeOS Stratum URL field contains `stratum+tcp://`, `tcp://`, `stratums+ssl://`, `https://`, or any other prefix before the hostname
- AxeOS shows `0 Accepted` and `0 Rejected` shares after 10+ minutes online
- Serial console at `115200 baud` shows `getaddrinfo failed` against a string that contains a colon and slashes (e.g. `stratum+tcp:`)
- Serial log line reads `lwip_getaddrinfo: 1` (host-not-found) — `stratum+tcp:` does not exist on any DNS server on Earth
- Pool docs were copy-pasted whole from a documentation page or YouTube tutorial without editing
- URL field ends in `:21496`, `:3333`, `:25` or `:7777` — port number appended to URL instead of in the separate Port field
- AxeOS saved the long string without complaining — there is no client-side validation on the URL field
- Pool worker page (Public-Pool, ckpool, Braiins, NiceHash) never registered your worker name
- Multiple Bitaxe units misconfigured the same way — all from the same docs / tutorial source
- WiFi connected, AxeOS dashboard loads on LAN, OLED shows IP and RSSI — only the pool side is blank
- Stripping the `stratum+tcp://` prefix and moving the port to the Port field makes shares submit immediately
- First-time Bitaxe operator on first-time setup (this is the #1 first-day failure mode at D-Central's bench)
Step-by-Step Fix
Open AxeOS in a desktop browser at `http://<bitaxe-ip>/`. Find the IP on the OLED if you don't remember it. Log in if your AxeOS build prompts. Navigate to Settings → Stratum (or Pool, depending on AxeOS version). Look at the exact saved string in the Stratum URL field and screenshot it for your records before changing anything — useful for support tickets and post-mortem.
Strip every character before the bare hostname from the Stratum URL field. Delete `stratum+tcp://`, `tcp://`, `stratums+ssl://`, `https://`, or any other prefix. The field should contain only the hostname (`public-pool.io`, `solo.ckpool.org`, `pool.braiins.com`) or an IPv4 address (`172.81.181.23`). No leading slashes, no colons, no plus signs. AxeOS does not validate this field on save — the green 'saved' indicator only confirms the string was written, not that it is a valid hostname.
Strip every character after the bare hostname from the URL field. No trailing slashes, no `:port`, no path segments, no query strings. If the pool docs say `stratum+tcp://public-pool.io:21496/some-path`, you want only `public-pool.io` in the URL field — nothing else. The DNS resolver will fail on any character outside the RFC 1035 hostname character set (alphanumerics, dots, hyphens).
Move the port number into the dedicated Port field. AxeOS has a separate numeric Port input below or beside the URL field. Type the port number only — `21496` for Public-Pool, `3333` for solo.ckpool.org and Braiins Pool, `9200` for NiceHash SHA-256, `3334` for Ocean. No colon, no scheme, no leading characters. Verify the field accepts only digits — if the field rejects your input, you typed a non-digit somewhere.
Match the SSL toggle to the port. If your pool's port is the SSL-enabled port (e.g. `21497` for Public-Pool SSL, `443` for some pools, `3334`/`3335` for Braiins SSL), enable the SSL checkbox below the Port field. Otherwise leave it off. SSL toggle and port must agree, or the TLS handshake fails on the pool side and you see a different (but equally non-functional) error class. Mismatched SSL is symptom-twin to the prefix bug — both look like 'connection failed' from the dashboard.
Verify your worker username field matches the pool's required format. Public-Pool wants `<btc-address>.<worker-name>` (e.g. `bc1q...example.bitaxe-gamma`). solo.ckpool.org wants `<btc-address>` only — no `.worker` suffix. Braiins Pool wants `<braiins-username>.<worker-name>`. NiceHash wants `<nh-mining-address>.<worker-name>`. Ocean wants `<btc-address>.<worker-name>`. Wrong username format makes shares get rejected even after the URL fix lands the connection — both bugs together look exactly like neither bug, frustratingly.
Save settings, then cold power-cycle the Bitaxe for 30 full seconds. Pull the barrel jack or XT30 connector. Wait — capacitors take time to drain and any stale stratum state in SRAM needs to clear. Five seconds is not enough. Plug back in. The soft reboot path through AxeOS often retains stale stratum / DNS cache state — pull the power for the full 30 seconds. Watch the OLED through reboot.
Watch the AxeOS dashboard for share count. You should see 'Accepted' climb above zero within 60–90 seconds of full WiFi+stratum reconnect. If the counter is still zero at 5 minutes, the prefix wasn't your only bug — you have a stacked configuration problem (worker name, SSL mismatch, DNS, or pool-specific quirk). Continue to Tier 3.
Cross-check on the pool's web worker page. Open the pool's dashboard in your browser, search for your worker name. If your worker appears with a recent 'Last share' timestamp, the connection is good — you're done, document the working configuration. If your worker is missing entirely, the pool isn't seeing you — back to Tier 3 diagnostics.
Document the working configuration. Screenshot the Stratum URL field, Port field, SSL toggle, Username field, Password field. Save in your home-mining notes alongside the Bitaxe variant and AxeOS firmware version. Restore from this screenshot on every reflash. First-time setup is where this prefix bug bites hardest — and second-time setup after a reflash is where it bites a second time. A working-config screenshot eliminates both.
Capture a serial boot log at `115200 baud` if Tier 1+2 didn't fix it. USB-C **data** cable (not charge-only — many cheap USB-C cables omit data lines). PuTTY on Windows, `screen /dev/ttyACM0 115200` on Linux/macOS, Arduino Serial Monitor cross-platform. Reboot the Bitaxe. Save the first 90 seconds of output. Search for `lwip_getaddrinfo`, `stratum_api`, `wifi:`, `sntp:`. The exact error code on `lwip_getaddrinfo` tells you the failure class.
Decode the LWIP error code. `lwip_getaddrinfo: 1` = host not found (NXDOMAIN — your URL field still contains junk, or the pool hostname is mistyped, or DNS is broken). `lwip_getaddrinfo: 4` = name format error (URL field has invalid characters — colon, slash, plus). `lwip_getaddrinfo: 11` = would-block / timeout (DNS resolver too slow — different bug class). Cross-reference Espressif's LWIP API docs at docs.espressif.com for the full error-code table.
Reflash the latest stable AxeOS via the official USB-C web-flasher at https://bitaxeorg.github.io/bitaxe-web-flasher/. Chrome or Edge only (Web Serial API — Firefox/Safari unsupported). Connect a USB-C data cable. Choose 'Erase Flash' before reflash to wipe NVS and any wedged settings or stale URL strings. Select the correct firmware `.bin` for your chip variant: `BM1366` = Ultra, `BM1368` = Supra, `BM1370` = Gamma and GT, `BM1397` = Max. Hex / UltraHex run the `ESP-Miner-multichip` fork. Wrong `.bin` bricks the board.
Reconfigure stratum settings from scratch after reflash. 'Erase Flash' wipes everything — WiFi credentials, stratum URL, worker name, password. Re-enter from your Tier 2 screenshot. The fresh flash often unsticks legacy state from older AxeOS builds that may have stored a malformed URL string in NVS that the AxeOS UI doesn't surface for editing.
Test on Public-Pool as a known-good sanity check. Configure: URL `public-pool.io`, Port `21496`, SSL off, Username `<your-btc-address>.bitaxe-test`, Password `x` (Public-Pool ignores password). Cold-cycle. Public-Pool is permissive, well-documented, and DNS-clean. If shares land at Public-Pool but not at your original target pool, your original pool has a setup quirk — check that pool's connection page for required worker-name format, password convention, or extranonce subscription.
Open a D-Central support ticket when (a) prefix stripped, port moved, cold-cycled, AxeOS reflashed with Erase Flash twice, shares still don't submit at Public-Pool sanity check; (b) URL field re-corrupts with prefix characters after every save (corrupted NVS or JS regression); (c) multiple identical units fail simultaneously while one sibling works fine; (d) serial log shows `lwip_getaddrinfo: 1` against a string you cannot find in any AxeOS field — stale NVS state needing controlled erase. Reach out via D-Central Discord or the Bitaxe Troubleshooting Guide ticket form.
What D-Central does at this point: bench-side reproduction with the same Bitaxe variant, same AxeOS build, controlled WiFi network, full serial trace with optional `CONFIG_LWIP_DEBUG` build flags. We confirm the bug class, document a reproducer, and either (a) fix the operator's network/firmware config remotely, or (b) file a GitHub issue against bitaxeorg/ESP-Miner. D-Central is a regular contributor — our reports come with hardware-grade reproduction notes, maintainers triage them quickly.
Ship to the bench if you want hands-on diagnosis. Anti-static bag, double-box with 3 cm+ foam every side. Include a note: Bitaxe variant, AxeOS firmware version, exact strings in URL / Port / Username / Password fields (screenshot is fine), router make + model, what you've already tried. Most 'URL prefix' tickets close without hardware repair — the issue is configuration, not silicon — but bench reproduction proves it definitively. Diagnostic-only tickets typically turn around 3–7 business days.
When to Seek Professional Repair
If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.
Related Error Codes
Still Having Issues?
Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.
