Bitaxe – Wrong Pool Port / Stratum Port Mismatch

Pull the per-pool stratum port reference table from this page on a second screen. Find your pool. Note the plain TCP port and (separately) the TLS port. Confirm against the pool's own getting-started page in a fresh browser tab — pools occasionally rotate ports. Write the correct port down on paper before touching AxeOS. This eliminates the muscle-memory 3333 typo that breaks 90% of fresh setups; D-Central support tickets show this same pattern week after week, ecosystem-wide.

Open AxeOS Settings → Stratum. Read your current Stratum Port field. If it does not match what you wrote down, change it. Be careful: AxeOS Stratum Port is a numeric field — type only digits, no spaces, no commas, no port-range. 21496 is valid. 21496/tcp is not. A value like 3333-3335 will not parse. Save.

Set the SSL toggle to match the port type. Plain TCP ports (3333, 21496, 1314, 5040, 3334) → SSL off. TLS ports (443, 21497, 9200, 4444, 5060) → SSL on. NiceHash is TLS-only on 9200 — SSL must be on. Public-Pool offers both — 21496 plain or 21497 TLS, you choose. A mismatched SSL toggle yields a TLS handshake error or a plain socket receiving garbage bytes. Save.

Cold power-cycle the Bitaxe. Unplug USB-C (or 12V XT30 / barrel on Hex / GT) for a full 10 seconds. Plug back in. Open AxeOS in your browser within 90 seconds and watch the live log. A clean port + correct SSL produces stratum_api: subscribe OK followed by authorize OK followed by the share counter starting to move. A warm reboot through the AxeOS UI is NOT sufficient — the ESP32-S3 needs a hard power-cycle to clear stratum task state.

If your pool is not on the per-pool table, find the official Getting Started or How to Connect doc on the pool's own website. The port is always there. If it is not, the pool is unprofessional — pick another pool. Public-Pool, Solo-CKPool, and Ocean all publish their ports prominently and are pleb-friendly. Bookmark the correct page so you have the canonical source for next time.

If you copy-pasted a port from a YouTube tutorial, throw that number out and look up the current one from the pool's official docs. YouTube tutorials go stale fast. A tutorial from 2023 quoting Slush port 3333 is still correct (Slush hasn't changed); a tutorial quoting Public-Pool port 3333 is wrong (Public-Pool uses 21496); a tutorial quoting Ocean port 3333 is wrong (Ocean uses 3334).

Save your correct port + SSL combo somewhere outside AxeOS — a password manager, a notes file. AxeOS factory resets erase the stratum config. Re-typing from memory after a factory flash is exactly when port-mismatch errors creep back in. Document the pool name, hostname, plain port, TLS port, and SSL toggle setting that worked.

Test the port from a laptop on the same LAN. On Linux/macOS: nc -v <pool-host> <port> and watch the response. On Windows: Test-NetConnection -ComputerName <pool-host> -Port <port> in PowerShell. Connection refused = wrong port (no service listening). Connected + immediate close = wrong service answering. Connected + cursor sits = right port (good). Hangs forever with no message = TLS port hit with plain TCP, or LAN firewall blocking outbound.

If nc connects, type a sample stratum subscribe and watch the response: {"id":1,"method":"mining.subscribe","params":[]} then Enter. A real stratum service replies with {"id":1,"result":[[...],"<extranonce1_hex>",<extranonce2_size>],"error":null} within a second. If you get nothing, get garbage, or get an HTTP response (HTTP/1.1 400 Bad Request), you are hitting a non-stratum service on that port — back to the port table.

If the laptop test succeeds but the Bitaxe still fails, your Bitaxe's WiFi network is the variable — outbound port filter, captive portal, or a guest-SSID isolation rule. Move the Bitaxe to a known-good residential LAN with no enterprise firewall. Cold-cycle. Test again. Hotel WiFi, school networks, and corporate guest WiFi block stratum ports almost universally.

Verify firmware version. AxeOS → System → Firmware Version. Cross-reference against https://github.com/bitaxeorg/ESP-Miner/releases. Pre-v2.1.x builds have known stratum bugs (Issue #105 TCP reset handling, Issue #252 stratum_api stuck). If you are on an old build, OTA-update to current stable, then re-test the port. A correct port on broken firmware can still appear to fail.

If your pool requires TLS on 443 but your ISP or corporate firewall blocks outbound 443 to non-Google/non-CDN destinations (rare on residential, common on enterprise), switch to a pool with a plain TCP endpoint that does NOT require TLS. Public-Pool 21496 plain is the cleanest fallback for testing — if it works there, your original pool's :443 TLS endpoint was the problem.

If you are behind carrier-grade NAT (CGNAT) — common on cellular hotspots and some rural ISPs — outbound stratum on non-standard ports can be sporadically dropped. Either move to a pool that exposes a :443 TLS endpoint (CGNAT rarely blocks 443), or get out of CGNAT (request a public IPv4 from your ISP, or use a wired ISP). Bell, Telus, and most US cellular providers run CGNAT on residential 5G/LTE plans by default.

Update the fallback pool config too. AxeOS supports a primary + fallback pool. If your primary port is wrong AND your fallback port is wrong, both will fail. Set both pools to known-good port + SSL combos. The fallback is your insurance — wasted insurance if the port is also broken.

Pcap the handshake with Wireshark on a laptop on the same LAN. Filter tcp.port == <port> and ip.addr == <bitaxe-ip>. Trigger the Bitaxe to retry stratum (cold-cycle). Watch the SYN-SYN/ACK-ACK handshake. SYN with no SYN-ACK = outbound blocked at LAN/ISP/pool firewall. SYN-ACK returned and Bitaxe sends bytes immediately RST'd by the server = service mismatch. SYN-ACK + TLS ClientHello with no ServerHello = TLS port mismatched with SSL toggle off, or pool-side cert renewal.

If you are a multi-Bitaxe operator, audit every device's stratum config in one pass. AxeOS does not centralize config — each device has its own port and SSL toggle. After a router or pool change, check all of them. D-Central sees fleet operators bring in 4-8 Bitaxes where 3 are working and 5 are silently wrong-ported because someone applied the new port to half of them and forgot the rest.

If you maintain a custom ESP-Miner fork, add a startup-time port-sanity check: have the firmware test the configured port against a list of known-bad-for-this-pool numbers and warn in the AxeOS UI before subscribe ever fires. PR upstream — bitaxeorg/ESP-Miner welcomes contributions. The pleb mining ecosystem grew because plebs sent fixes back, not because a vendor handed them down.

Test against a local stratum server. Spin up ckpool or public-pool source on a Raspberry Pi on your LAN. Point the Bitaxe at 192.168.x.y:3333. If subscribe lands locally but fails to the internet pool, the issue is your egress path — not the Bitaxe, not the port number. ISP, NAT, or upstream filter.

Stop DIY and ship to D-Central when (a) every port on the table tested above for your pool returns connection refused from a known-good LAN with the right SSL toggle, (b) Wireshark shows SYN-ACK arriving but the Bitaxe never sends a subscribe (ESP32-S3 stratum task is dead), (c) you have factory-flashed the latest stable ESP-Miner and tried two different pools and both fail at the port layer despite documented-correct ports, or (d) physical damage is visible — scorched USB-C, blown fuse on VIN, a Bitaxe that gets hot before WiFi associates. D-Central pioneered the Bitaxe ecosystem and stocks every variant. Book at https://d-central.tech/services/asic-repair/.