Bitaxe – Stratum mining.subscribe Failed / Pool Rejects Handshake

Verify the Stratum URL is a bare hostname. Open AxeOS, go to Settings, and read the Stratum URL field one character at a time. Remove any stratum+tcp:// or https:// prefix. Remove any trailing slash. Remove any whitespace before or after the hostname. Save. Reboot with a full 10-second power-cycle. Watch the log for 5 minutes — a clean subscribe produces a single stratum_api: subscribe OK line and the share counter starts moving within one pool job cycle. This alone fixes roughly half of all subscribe failures D-Central sees in tickets.

Match the port to the pool's documented stratum listener. Public-Pool uses 21496 for plain TCP and 21497 for SSL; Solo-CKPool uses 3333; Ocean uses 3334; NiceHash (SHA-256 auto) uses 9200 over SSL only; Braiins Pool uses 3333. If you have SSL enabled in AxeOS, you must use the pool's SSL port — not the plain one. Save and reboot. This is the second-most-common subscribe failure root cause and often masks the URL prefix issue in Step 1.

Cold power-cycle the Bitaxe. Unplug USB-C (or the 12V input on Hex / GT) for a full 10 seconds. Plug back in. This flushes any stuck socket state from ESP-Miner Issue #252 (stratum_api stuck after WiFi timeout) and Issue #105 (TCP reset not handled gracefully). If subscribe was failing because of a stale connection, it now opens fresh. A warm reboot through the AxeOS UI is NOT sufficient — the ESP32-S3 needs a hard power-cycle to clear the stratum task state cleanly.

Switch to a public reference pool to isolate. Point the Bitaxe at public-pool.io:21496, SSL off. This pool accepts every Bitaxe firmware version ever shipped and does not enforce exotic protocol ordering. If subscribe works here, your previous pool is the variable — recheck its documentation for worker format, BTC address requirements, or protocol quirks. If subscribe still fails on public-pool, the problem is local (network, firmware, or device). This step isolates pool-side vs client-side in under 10 minutes.

Toggle the SSL setting and reboot. If SSL was on, turn it off and use the pool's plain-TCP port. If SSL was off, turn it on and use the pool's SSL port (usually plain port + 1). Some Bitaxe firmware releases have edge-case mbedTLS bugs with specific pools' certificates; switching tiers often clears the handshake. Public-Pool and CKPool both run on plain TCP by default — SSL is optional on both. Save the SSL toggle change, save the port change, and cold power-cycle the Bitaxe before judging the outcome.

Verify the router DNS is reachable. On a laptop on the same LAN, run nslookup <pool-hostname>. If resolution is slow or returns a bogus IP, your router DNS is broken. In the router admin panel, override DNS to 1.1.1.1 (Cloudflare) and 8.8.8.8 (Google) as primary/secondary. Reboot the router, reboot the Bitaxe. Canadian ISPs (Bell, Rogers, Vidéotron, Cogeco, Shaw) have flaky default resolvers for stratum hostnames and this fix lands often — it's the single biggest Canadian-specific subscribe fix.

Wait for the device to come out of backoff. Some AxeOS builds implement exponential backoff on repeated subscribe failures — each failed attempt doubles the wait. After three or four failures, the wait can be several minutes. Don't mistake backoff for a permanent failure. If you just corrected a URL/port, give the miner 3 minutes, then reboot if subscribe still hasn't fired. Panic-editing settings during a backoff window extends the next retry interval without helping.

Check that your LAN isn't blocking outbound stratum. Enterprise routers, hotel WiFi, and some carrier-grade NAT (CGNAT) setups block outbound connections on non-standard ports. If you're on a guest/enterprise network, move the Bitaxe to a residential-class LAN. If you're on home WiFi and still blocked, check for a firewall rule on the router or a parental-controls policy filtering 'mining' hostnames. Some ISP-provided routers have built-in content filters that flag stratum traffic.

Capture the USB-C serial log at 115200 baud. Plug a USB-C data-capable cable (not charge-only) into the Bitaxe, open a serial terminal (screen, minicom, PuTTY, or Chrome WebSerial) and watch the boot sequence. stratum_api lines appear after WiFi associates. Classify the error: connection failed = URL/port wrong, DNS lookup failed = DNS, mbedtls_ssl_handshake = TLS mismatch, socket error = network interruption, undesired state = Issue #252. Save a 2-minute log for reference — this is the exact artifact D-Central's repair team asks for on Bitaxe tickets.

Downgrade firmware by one minor version if subscribe broke after an OTA. AxeOS → System → OTA Update — look for a revert option on newer builds, or grab the previous stable .bin from the ESP-Miner releases page and use the USB-C web flasher at https://bitaxe.org/flash. Document which board revision you have (printed on the PCB — Ultra 205 vs 207, Gamma 601 vs 602, Hex 303 vs 304) and grab the matching factory image for that revision. Wrong .bin bricks the device.

Flash the current stable firmware via USB-C web flasher as a known-good baseline. Chrome or Edge (WebSerial required), connect the Bitaxe via USB-C, visit https://bitaxe.org/flash, pick the exact board revision, and flash factory. This wipes NVS and forces a clean stratum state machine. Any subscribe failure surviving a fresh factory flash + clean URL + documented port + SSL off is an upstream (pool or network) issue, not a Bitaxe issue.

Measure packet loss between Bitaxe and pool. From a laptop on the same SSID, run mtr <pool-hostname> for 5 minutes. Look for packet loss above 1% on any hop inside your LAN or at your ISP's edge. Hop-1 loss = router/WiFi issue (move Bitaxe within 3m of AP, lock to 2.4GHz channel 1/6/11). Hop-2 to hop-5 loss = ISP egress problem (call the ISP or switch pools to one with a geographically closer endpoint). Canadian miners pointed at Singapore pools routinely see 2%+ loss and frequent subscribe drops.

Swap the USB-C cable and PSU with known-good units. A flaky USB-C cable that handles charging fine can drop data packets at the ESP32-S3's UART — and if the ESP can't speak cleanly to its own peripherals, the stratum client hangs in weird places. Use a data-capable USB-C cable ≥3A rated. Use a reputable PD PSU (Anker, Apple 30W, or a D-Central Bitaxe PSU). Cheap USB-C bricks sag under load and cause secondary failures that look like stratum bugs.

Check the BTC address format for the pool. Pools are strict about worker naming conventions: Public-Pool wants bc1q... or 1... or 3... + .workername; Ocean uses a username format; NiceHash uses the account username. A subscribe may technically succeed but authorize fails instantly and the session drops before the first job — misread as a subscribe bug. Cross-reference the pool's getting-started doc. Lightning addresses pasted by mistake are a common cause on Bitaxe tickets.

Roll to a specific known-good firmware version for your board revision. If you identified a firmware regression in the serial log, flash the specific stable version that pre-dates the regression. The ESP-Miner release archive is at https://github.com/bitaxeorg/ESP-Miner/releases. Verify the .bin filename matches your board revision before clicking flash — BM1366 firmware on a BM1370 Gamma will hash-boot and subscribe, then fail at mining.notify in a way that looks like a subscribe bug. Document the version you land on.

Wireshark the stratum exchange directly. Run Wireshark on a laptop plugged into the same LAN (ideally a mirror port on a managed switch, or ARP-spoof the Bitaxe's gateway to pull traffic). Filter tcp.port == <pool-port> and ip.addr == <bitaxe-ip>. You should see SYN → SYN-ACK → ACK, then a TLS client hello (if SSL) or a JSON mining.subscribe line, then the pool's response. Missing SYN-ACK = outbound blocked. TLS hello but no server hello = SSL port mismatch. JSON subscribe with no response = pool-side filter. Subscribe response with an error field = pool-side policy.

Rebuild ESP-Miner from source with extra logging. This is the Mining Hacker move when you have a reproducible subscribe failure not documented in any GitHub issue. Clone bitaxeorg/ESP-Miner (or the fork matching your variant), add ESP_LOGI traces around the stratum_api_subscribe function, build with ESP-IDF, flash via USB-C. The extra log lines often pinpoint exactly where the state machine stalls. PRs welcome upstream — this ecosystem grew because plebs with soldering irons and Git accounts sent fixes back.

Test against a local stratum server. Spin up a local CKPool or public-pool fork on a home server (Raspberry Pi, old laptop) and point the Bitaxe at 192.168.x.y:3333. If subscribe works locally but fails against the internet pool, your internet path (ISP, NAT, upstream) is filtering or corrupting stratum traffic — call the ISP or move to a different pool endpoint. This is a diagnostic trick, not a permanent fix; but for troubleshooting weird network paths, it's conclusive.

Ship it to D-Central. Stop DIY when (a) a factory-flashed, stock-config Bitaxe fails to subscribe on public-pool.io:21496 over a known-good LAN with 1.1.1.1 DNS, (b) Wireshark shows SYN-ACK arriving and JSON subscribe being rejected with an error you can't decode, (c) subscribe survived a cable/PSU/pool swap plus a factory flash plus a DNS override plus a different LAN, or (d) physical damage is visible. D-Central pioneered the Bitaxe Mesh Stand and first Bitaxe/Hex heatsinks, stocks every variant and spare parts, and runs bench test rigs for stratum diagnostics. Book at https://d-central.tech/services/asic-repair/.