Bitaxe – Pool Connection Timeout / Socket Closed by Peer

Power-cycle the Bitaxe for 10 seconds (not a soft reboot). Resets any wedged stratum task, Wi-Fi handler, or lwIP socket state, and lets you start tracking the AxeOS reconnect counter from a known zero baseline before applying any other fix.

Update AxeOS firmware to the latest release from the official ESP-Miner GitHub or AxeOS web flasher. ESP-Miner has shipped multiple stratum reconnect, fallback-pool, and lwIP socket teardown handling fixes throughout 2024-2026 — running latest firmware is the single biggest fix for many users without further changes.

Switch to a Bitaxe-friendly pool. Solo: solo.ckpool.org:3333 (low-overhead, tolerates low-rate connections). Solo lottery: stratum.public-pool.io:21496 (Bitaxe-community-aligned). Or Ocean's solo endpoint with configurable difficulty. Avoid commercial pools (Antpool, ViaBTC, F2Pool) at sub-1-share-per-5-min rates — they reap idle connections aggressively.

Verify Wi-Fi signal strength on the AxeOS dashboard. Target RSSI of -65 dBm or stronger (less negative). Anything weaker than -70 dBm is borderline; below -78 dBm and intermittent Wi-Fi disassociation will manifest as 'socket closed' because Wi-Fi drops first and TCP follows. Move the Bitaxe closer to the AP if needed.

Verify pool URL syntax in AxeOS. Format is `host:port` only — drop any `stratum+tcp://` prefix, which older Bitaxe firmware tolerated but current versions can choke on. Worker name format: `<btc-address>.<workername>` for solo pools, `<account>.<workername>` for commercial. Malformed URLs cause immediate handshake failures, not idle-timeout drops, but worth ruling out.

Log in to your home router admin and find the firewall/NAT settings. Look for 'TCP timeout', 'TCP established idle timeout', or 'session timeout'. Defaults vary: 30 min on Linksys/TP-Link/D-Link consumer, 60 min on Netgear, 1-2 hr on Asus AsusWRT/Merlin, 2 hr on pfSense/OPNsense. Raise to 14400s (4 hours) minimum, ideally 28800s (8 hours). Save and reboot router.

Hardcode the pool IP to bypass DNS as a failure mode. From any network device run `nslookup <pool-hostname>` and note the IP. Paste the raw IP into AxeOS pool settings (e.g. `38.97.6.10:3333` instead of `solo.ckpool.org:3333`). Re-check monthly because pools occasionally renumber. Eliminates DNS resolution as a stratum drop cause.

Configure secondary/fallback pool intentionally in AxeOS. Set primary to your preferred low-overhead solo pool, fallback to a different operator on different IP space and infrastructure. When primary blips, fallback catches the session and you don't lose hashing time. Note: known AxeOS bug in some versions where the device stays on fallback and refuses to return — see related-errors and check release notes.

Build ESP-Miner from source with TCP keepalive enabled. Clone github.com/bitaxeorg/ESP-Miner, locate the stratum socket creation (typically main/tasks/stratum_task.c), and ensure setsockopt() calls SO_KEEPALIVE on with TCP_KEEPIDLE=60, TCP_KEEPINTVL=30, TCP_KEEPCNT=3. Build with ESP-IDF and flash. Forces kernel-level keepalive probes that refresh NAT mappings on every router between you and the pool. Check release notes — recent versions may already include this.

Run a packet capture during a real drop using port mirroring on a managed switch and Wireshark on a connected laptop. Filter on the Bitaxe IP. The capture tells you definitively which side sent the FIN/RST — your router (NAT loss), the pool (pool-initiated reap), or somewhere upstream — and whether retransmits went unanswered. This is the gold-standard diagnostic for chronic cases.

Investigate stratum v2 / SRI support. Stratum v2 has explicit session resumption, encrypted channels, and better partial-work handling. ESP-Miner stratum v2 support has been a moving target — check the ESP-Miner issue tracker and release notes for current state. If your pool supports v2 and ESP-Miner does too, this fundamentally upgrades network resilience over v1's stateless TCP.

Set up a VPS or colo near your pool's region and route Bitaxe traffic through a WireGuard or OpenVPN tunnel. Eliminates ISP-level shenanigans, gives you a stable predictable NAT, and on the VPS you can configure iptables/nftables to never reap idle TCP. Adds 1-5 ms latency, irrelevant to hash performance. Cost: $5-20/month VPS plus 30 min setup.

Replace consumer router with programmable open-source firewall hardware running OpenWrt, pfSense, or OPNsense. Lets you set TCP idle timeouts arbitrarily, run conntrack monitoring, log socket lifetimes, and enforce custom policy. For hash-farm operators a $150-400 mini-PC firewall is a one-time purchase that pays back in eliminated mystery drops across the fleet.

Test on a different ISP/network for 24 hours by tethering Bitaxe to a phone hotspot or alternate connection. If hotspot dramatically reduces reconnect rate, your ISP is the problem — possibly CGNAT layering an extra timeout, possibly DPI throttling stratum traffic. Options: request IPv4 passthrough or static IP from ISP (sometimes free, sometimes $5/mo), VPN out, or switch ISP for mining traffic.

File or upvote a GitHub issue on github.com/bitaxeorg/ESP-Miner/issues if your specific failure mode isn't already documented. Include AxeOS firmware version, exact log lines (especially error strings), hardware variant, pool, reconnect cadence, and any Wireshark findings. The maintainers triage real bug reports quickly. The Bitaxe community is one of the most responsive open-source hardware ecosystems.

Reach out via D-Central support or the Bitaxe Discord with your full diagnostic dump. D-Central has been part of the Bitaxe ecosystem since manufacturing the original Bitaxe Mesh Stand, the first heatsinks for Bitaxe and Bitaxe Hex, and stocking every variant. Drop your `socket closed by peer` log excerpt with hardware variant and firmware version — someone has almost certainly seen the exact pattern.

If isolated to a single Bitaxe via cross-pool and cross-network testing — meaning siblings on the same network behave fine while this specific unit does not — investigate the unit's hardware. Check the ESP32 antenna connection (some Bitaxe variants have a u.FL or chip antenna with known connection sensitivities), Wi-Fi RSSI compared to siblings in the same physical location, and consider RMA or hardware replacement.

Note: DCENT_OS is NOT applicable to Bitaxe. DCENT_OS is D-Central's open-source firmware for Bitmain Antminer hardware (BM1398/BM1362/BM1368-class ASICs). Bitaxe runs ESP-Miner/AxeOS on an ESP32-S3 microcontroller — fundamentally different platform. ESP-Miner is itself fully open-source and Mining-Hacker-aligned, so the spirit is the same — the binary is not. Don't try to flash DCENT_OS on a Bitaxe; it will brick the device or simply not flash.