Skip to content

We're upgrading our operations to serve you better. Orders ship as usual from Laval, QC. Questions? Contact us

Bitcoin accepted at checkout  |  Ships from Laval, QC, Canada  |  Expert support since 2016

2020 Critical

Whatsminer Error 2020-2022 – Stratum Pool Connection Failed

Stratum connect fail / pool unreachable. BTMiner opens a TCP socket to the configured pool's stratum+tcp:// endpoint and the connect-phase handshake never completes within the configured timeout. Siblings 2021 (subscribe timeout) and 2022 (authorize rejected) share the root-cause tree. Miner keeps booting and keeps retrying but produces 0 TH/s until the pool path is restored.

Critical — Immediate action required

Affected Models: Whatsminer M20S, M21S, M30S, M30S+, M30S++, M31S, M31S+, M32, M50, M50S, M50S+, M50S++, M60, M60S (all air-cooled BTMiner-based), plus M33S+ / M53 / M63 / M66 hydro family (same BTMiner pool stack)

Symptoms

  • BTMiner dashboard / WhatsMinerTool shows Error Code: 2020 with message like 'stratum connect fail', 'pool unreachable', 'pool0 disconnect', or 'connect pool server failed'
  • Hashrate reads 0.00 TH/s and stays there — miner is otherwise booted, fans spinning, hashboards reporting temperature normally
  • BTMiner log contains repeated 'stratum: connect fail', 'stratum: socket timeout', 'dns lookup failed', or 'pool0 disconnected, reconnecting in 30s' lines
  • API on TCP 4028 ({"cmd":"pools"}) returns pool status Dead or Alive=N with LastShareTime never advancing
  • Sibling codes 2000 (no pool configured), 2010 (all pools disabled), 2021 (subscribe timeout), 2022 (authorize rejected) appear in the same session
  • Status LED shows the 'connected, not hashing' pattern (solid green power, flashing red status)
  • Miner reachable by IP on LAN; control board booted normally; WhatsMinerTool finds it via IPFOUND
  • Pool dashboard (Slush/Braiins, Ocean, Foundry, F2Pool, ViaBTC) shows the worker as offline or last seen minutes to hours ago
  • Pinging the miner's configured pool host from a workstation on the same LAN fails or resolves to a wrong IP
  • Error starts immediately after a BTMiner firmware update, a router change, an ISP outage, or an upstream pool maintenance window
  • Other miners on the same LAN, same pool, same worker format are hashing fine (isolates fault to this specific Whatsminer)
  • Miner RTC clock drifts more than a few minutes from real time (NTP failure masking a TLS stratum handshake break)

Step-by-Step Fix

1

Reboot the miner from WhatsMinerTool or the web UI for a clean stratum-client restart. Transient TCP state, a momentary DNS hiccup, or a brief pool-endpoint blip accounts for 10-15% of Error 2020 cases and clears on a simple reboot. Wait for the miner to fully boot — stratum subscribe can take 30-60 seconds even on a healthy connection. If 2020 clears and hashrate comes up, log the event and monitor for recurrence before assuming root cause.

2

Verify your pool URL against the pool's own current documentation. Open Slush/Braiins, Ocean, Foundry, F2Pool, ViaBTC, or your configured provider and copy-paste their current stratum URL straight from docs into the miner. Pool endpoints rotate, rebrand, and deprecate quietly — a URL that worked in 2023 may be a dead endpoint in 2026. About two-thirds of field 2020 cases are a stale URL. This is the highest-leverage free check on the page.

3

Verify your worker format matches the pool's exact spec. Slush/Braiins wants just worker_name. Foundry, F2Pool, Antpool expect wallet.worker or account.worker. Ocean wants a Bitcoin address in the worker field. Pool closes the TCP connection on a format mismatch, which BTMiner reports as Error 2020 rather than an authorize failure. Check the pool's docs and match exactly.

4

Confirm the miner has a LAN IP and working internet. Check WhatsMinerTool's IP field or the miner's web UI status page. If the miner doesn't have an internet-routable path, stratum obviously fails. If your LAN uses a non-standard DNS resolver or a captive portal (hotel networks, some corporate guest VLANs), stratum fails even with a valid IP. Move the miner to a clean network as a test.

5

Check the pool's status page and Twitter/Telegram. Slush/Braiins status.braiins.com, Foundry status, F2Pool announcements, Ocean status. If the pool is in a maintenance window or outage, 2020 is the correct response and there is nothing to fix on your side — wait it out. 30 seconds of status-page check saves hours of wasted hardware diagnostics. Bookmark your pool's status page for future reference.

6

From a workstation on the same LAN as the miner, run nslookup <pool-host> and ping <pool-host>. Confirm DNS returns a valid IP and the host responds (most pools respond to ICMP; for non-responders use nc -zv <pool-host> <port> or telnet). If DNS fails from the workstation, the miner cannot possibly resolve either — your router's DNS upstream is the fault. Change your router's DNS to 1.1.1.1 and 9.9.9.9.

7

Set the miner's DNS explicitly via WhatsMinerTool Network Settings. Primary 1.1.1.1 (Cloudflare), secondary 9.9.9.9 (Quad9). This bypasses any ISP-provided router DNS that might be filtering, caching stale records, or redirecting hostnames. Reboot the miner after saving. About 15% of 'mystery 2020' on home networks is the ISP router's DNS being uselessly aggressive. Free fix, takes five minutes.

8

Test stratum-port egress from your workstation. nc -zv stratum.slushpool.com 3333 on Linux/macOS, or Test-NetConnection stratum.slushpool.com -Port 3333 on PowerShell. If it returns refused or times out, your ISP, firewall, or router is blocking outbound TCP on the stratum port. Residential ISPs in North America have been caught filtering port 3333 — try the pool's alternate ports (4444, 25, 443) one by one.

9

Rotate to an alternate pool port. Most major pools publish multiple stratum ports — a 'high' port (3333, 4444), a 'low' port (25, 80), sometimes an HTTPS-wrapped variant (443). Change your miner's pool URL to the 443 variant and reboot. If 2020 clears on 443 but fails on 3333, your ISP is filtering. Port 443 is functionally un-blockable since it would break the web.

10

Configure a fail-over pool in slot 2. WhatsMinerTool supports three pool slots; set slot 2 to a completely different provider (Ocean, F2Pool, or your secondary choice). Reboot. If slot 2 connects but slot 1 still errors, you've isolated to a pool-side problem on your primary. If both fail, the root cause is on your LAN/WAN and you've ruled out the pool. Always run two pools in production — revenue protection against 2020.

11

Power-cycle the router for 30 seconds, restore, wait 3 minutes for WAN to stabilize, then reboot any managed switches, finally reboot the miner. This sequence clears stale DHCP leases, NAT translation entries, and any misbehaving firewall state. It looks trivial but fixes about 20% of intermittent 2020 cases on home networks, particularly consumer routers with 30-day uptime that have quietly run out of NAT table entries.

12

Disable any VPN, proxy, or DNS-filtering service on the miner's path. If you route miner traffic through a Pi-hole, AdGuard, NordVPN, Mullvad, or any split-tunnel VPN, temporarily route the miner direct-to-WAN as a test. Many VPN providers rate-limit or block stratum traffic as 'unusual,' and DNS filters sometimes flag pool hostnames. See our VPN Interfering with Pool Connection article for deeper coverage.

13

Force an NTP resync and verify the clock. WhatsMinerTool System Time page. If the miner's clock is more than ~5 minutes off real time, TLS-wrapped stratum handshakes (which many pools now require) fail on certificate validity windows. Manually set NTP server to pool.ntp.org or time.cloudflare.com, force resync, confirm the clock matches reality within seconds, reboot. Clock-drift 2020 is criminally under-diagnosed.

14

Roll back to the previous stable BTMiner firmware if Error 2020 started immediately after a firmware update. Burn the prior image with Raspberry Pi Imager, insert the SD card into the control-board slot, hold the reset button through the recovery sequence for your model (M30S family: 10 seconds through boot; M50/M60 differs). MicroBT has shipped stratum-client regressions in specific builds — rollback is a valid and routine fix.

15

Capture a packet trace of the miner's pool-connect attempt. Mirror the miner's switch port (or run tcpdump on the router): sudo tcpdump -i eth0 -w /tmp/stratum.pcap host <pool-ip>. Open in Wireshark. You'll see one of three patterns: (a) SYN with no SYN-ACK (WAN blocking upstream), (b) SYN-ACK-RST (pool refusing — IP banned, rate-limited, endpoint dead), or (c) full TCP handshake followed by stratum JSON that fails (pool-side or auth-side). Decisive, not speculative.

16

Try a Stratum V2 endpoint via a local proxy. If your pool offers V2 and stock BTMiner's V1 client is flaky, run Braiins Farm Proxy or an open-source Stratum V2 proxy on a local Raspberry Pi, point the miner at the proxy, let the proxy handle the upstream. Adds a layer but resolves V1 stratum regressions cleanly. Bonus: per-miner visibility you don't get from stock BTMiner, and encrypted upstream that's harder for ISPs to filter.

17

Tunnel stratum through a VPS if your ISP is filtering. Rent a $5/month VPS in a neutral jurisdiction, run a simple TCP port-forward (or socat / nginx stream proxy) from VPS port 3333 to pool:3333, point the miner at the VPS. This routes around residential ISP filtering cleanly. Inelegant but effective — and a reminder that censor-resistant mining infrastructure is a real part of the decentralisation stack, not a footnote.

18

Book a D-Central remote diagnostic or ship-in repair when you've cleared Tiers 1-3 and 2020 persists across multiple pools, multiple networks, explicit DNS, explicit NTP, and rolled-back firmware. That's a compound miner-side fault — control-board NIC, corrupted firmware that SD recovery couldn't clear, or a damaged network transformer. We'll either clear it live on a remote session, or give you a clean ship-in plan with expected turnaround and repair cost.

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.