mining.subscribe Timeout — Pool Unreachable Checklist

Reboot the miner with a full 30-second power-off (not a soft restart). On a Bitaxe, unplug USB-C / DC barrel and wait. On an Antminer / Whatsminer / Avalon, kill power at the PDU. This clears any wedged stratum task state machine — Bitaxe ESP-Miner Issues #105 and #252 specifically describe states where the socket is technically open but no bytes flow until the device fully resets. Boot, watch for 5 minutes. If shares appear, you had a transient state-machine wedge and the underlying network is fine.

Open the pool's official status page in another browser tab. Public-Pool, Solo Satoshi, CKPool, Ocean, Braiins, and NiceHash all post outage / maintenance / DDoS notices on Twitter/X, Discord, or their /status page. If the pool says maintenance, wait 5-30 minutes and retry. If you can't afford the downtime, configure a backup pool URL in your firmware (most stratum clients accept a fallback URL) and let the rig failover automatically until the primary returns.

From a laptop on the same LAN as the miner, run nc -vz pool.host port (Linux/macOS native, on Windows use ncat from the Nmap install). Three outcomes: Connection succeeded means TCP layer is healthy and the problem is application-layer (TLS / protocol / pool overload). Connection refused means the pool's listener is down or you have the wrong port. Operation timed out means a firewall / NAT / ISP filter is dropping packets between you and the pool.

Verify DNS resolution with dig +short pool.host (Linux/macOS) or nslookup pool.host (Windows). If it returns nothing, returns SERVFAIL, or returns an obviously wrong IP (private RFC1918 address, or an IP that doesn't ping), your DNS is broken. Override the miner's DNS to 1.1.1.1 (Cloudflare) or 9.9.9.9 (Quad9) at the device or router. ESP-Miner Issue #184 documents that early AxeOS builds did not retry on DNS failure, so a DNS hiccup at boot can lock the rig until reboot.

Confirm the URL scheme matches the port. stratum+tcp://pool:port speaks plain TCP; stratum+ssl://pool:port wraps the socket in TLS. Public-Pool plain TCP is 21496, SSL is 21497. CKPool plain is 3333. NiceHash SHA-256 is SSL only on 9200. Mix scheme and port and the TLS handshake never completes — log shows subscribe timeout because no JSON ever moves. Save, reboot, observe for 5 minutes.

If the pool offers TLS, run openssl s_client -connect pool.host:port -showcerts from a laptop on the same LAN. Healthy: handshake completes, certificate chain prints, you can paste {"id":1,"method":"mining.subscribe","params":["test/1.0"]} and get a JSON response within 10 seconds. Hangs at handshake: pool's TLS endpoint is the wrong port or down. Wrong cert: you're hitting a generic cloud LB and the pool's stratum endpoint moved — check the pool's docs for the current TLS endpoint.

Check path MTU with tracepath pool.host (Linux) or tracert -d pool.host (Windows). Look for the line PMTU= and confirm it stays at 1500 the whole way. PPPoE residential connections drop to 1492; many VPN tunnels and corporate WANs run 1400-1450. If you see PMTU drop below 1500 and ICMP type-3 / code-4 is filtered, you've got a PMTUD black hole — TCP three-way handshake completes (small packets) but the larger application data (subscribe JSON + extranonce response) gets silently dropped.

If you confirmed PMTUD breakage, drop the miner's TCP MSS clamp at your router. On most consumer routers this is in WAN settings as MSS clamping, MTU, or path MTU discovery. Set MTU to 1400 and TCP MSS clamp to 1360 as a conservative test. Reboot the miner, watch the stratum log. If subscribe completes, you had a path-MTU black-hole. Long-term: complain to your ISP about ICMP filtering or migrate the rig off the affected uplink (cellular fallback, second WAN).

Benchmark RTT with ping -c 50 pool.host (Linux/macOS) or ping -n 50 pool.host (Windows). North-American pools from North-American homes should land 20-100 ms with under 10 ms stdev. EU / Asia pools from North America land 150-300 ms — workable for stratum v1 but marginal on v2 with version-rolling. If RTT exceeds 400 ms sustained or jitter exceeds 50 ms, your transit is unstable and subscribe will time out under load. Pick a closer pool — Public-Pool runs nodes in NA and EU, Ocean runs multiple regions, Braiins pool offers regional endpoints.

Check whether your ISP throttles non-standard outbound TCP. Some residential providers (notably observed on certain Canadian residential lines, but pattern exists globally) shape outbound traffic on long-lived non-HTTP ports after sustained use. Test by routing through a VPN that does not block stratum (Mullvad, IVPN — confirm they don't filter port 3333 / 21496). If subscribe completes through the VPN, you have ISP shaping. Workarounds: pick a pool whose stratum runs on 443 (some pools offer this), self-host a stratum proxy on a VPS, or escalate to your ISP.

Disable any local VPN, firewall outbound rules, parental control, ad-blocker DNS (NextDNS, Pi-hole), or QoS rule that touches the miner's IP. Test subscribe with a clean network path. NextDNS and Pi-hole have been observed to filter or rate-limit TLS handshakes on uncommon ports; corporate next-gen firewalls may classify stratum traffic as crypto-mining and block it. Whitelist the pool hostname / IP range in your DNS filter and the miner's MAC in your firewall before re-enabling protections.

Flash a firmware that exposes verbose stratum frame logging. On Antminer hardware, install DCENT_OS — D-Central's open-source Antminer firmware, the Mining Hackers' option — which logs every subscribe / authorize / notify frame with timing in the per-share log. Alternatives on Antminer: Braiins OS+ with bos --stratum-debug, LuxOS, Vnish. On Bitaxe, the AxeOS USB-C serial console at 115200 baud already shows verbose stratum events. With per-frame visibility you can see exactly which line of the handshake never returned and target the fix instead of guessing.

Capture a packet trace. From a laptop on the same LAN, run a port-mirror on your switch (or use a hub-tap) and capture with Wireshark filtered to host pool.host and tcp.port == 3333 (or whatever port). Subscribe timeout in capture looks like one of three patterns: no SYN-ACK from pool (firewall / pool down), SYN-ACK followed by one application packet then silence (PMTUD black-hole or pool overload), or full TLS handshake then silence at JSON layer (pool-side stratum service hung). Each pattern points at a different fix.

Try a different pool to isolate pool-vs-rig fault. Configure a known-reliable backup pool — public-pool.io:21496 plain TCP is the most permissive, no auth required for the BTC address worker. If the rig subscribes cleanly to the backup pool but not to the primary, the problem is at the primary pool (their issue, not yours — open a support ticket with them). If the rig can't subscribe to any pool, the problem is on your side: rig hardware, LAN, or upstream.

Roll firmware back or forward by exactly one version. Some Bitaxe AxeOS, Antminer, Whatsminer, and Avalon firmware builds have shipped stratum bugs (see ESP-Miner Issues #84, #105, #184, #252; see Bitmain firmware changelogs). The wrong firmware for a late-rev hardware revision can also brick the controller, so verify the build matches your hardware revision before flashing. Watch for 24 hours after the rollback to confirm stability.

On Antminer SSH-capable controllers, log in via SSH and tail /var/log/cgminer.log (or /tmp/cgminer.log) live during a subscribe attempt. Look for accept lines, subscribe rejected, socket connect failed, or DNS lookup failed. The miner side log usually resolves the ambiguity that the dashboard hides. On DCENT_OS this is even cleaner — verbose stratum frame logging is on by default.

Reseat the Ethernet cable and connector at both ends. Check the controller's link-LED (10/100 amber, 1000 green for most controllers). Try a different cat5e/cat6 cable — bent pins, corroded connectors, or RJ45 terminations cracked from yanking the cable produce intermittent link that passes ARP and DHCP but drops application packets. Swap to a known-good cable, swap the switch port, and re-test.

Hardware test the controller's NIC / PHY. With the miner powered, ifconfig eth0 (Antminer SSH) or the equivalent on Whatsminer / Avalon should show RX OK, TX OK, errors and dropped near zero. Persistent NIC errors point at a failing PHY chip on the controller — common after lightning strikes, PSU surges, or extended high-humidity operation. This is a controller-board-level repair and belongs in Tier 4.

Stop DIY when: a known-good LAN with confirmed nc / dig / openssl / MTU all healthy still cannot subscribe across three different pools; the controller's NIC shows persistent ifconfig errors; physical damage to the RJ45 jack or controller PHY is visible; or you've reflashed firmware twice and the symptom persists. You're now in controller-replacement territory — book a D-Central ASIC Repair slot and ship the controller (or whole miner) for bench-level diagnosis.

D-Central bench process: replicate the symptom against a known-good pool on a known-good LAN, swap the controller / Ethernet daughterboard with a tested unit, run a 24-hour burn-in subscribing and submitting against public-pool.io. On Antminer hardware, controllers are typically swapped or PHY-chip reflowed. On Whatsminer, the controller and ethernet PHY are integrated and replaced as a unit. On Avalon, the AUC controller is swapped. Bitaxe controller replacement is a board swap from D-Central's pioneer-stocked spare inventory.

Ship safely if you go to Tier 4. Pack the controller (or whole miner) in anti-static bags, double-box with at least 5 cm of foam every side. Include a printed note with your observed symptom timeline, firmware version, pool URL/port, the diagnostics you've already run (nc / dig / openssl outputs), and your contact. Saved diagnostic time at the bench is saved repair cost on your invoice.