Understanding Miner Pool Connections and Setup

Every ASIC miner points its hashrate at a mining pool using three pieces of information: a stratum URL (the pool address and port), a worker name (your account, optionally suffixed with a rig identifier), and a password (usually ignored). Get those three fields right and the miner connects, subscribes, and starts submitting shares within seconds. Get one wrong and the machine hashes into the void — drawing power but earning nothing. This guide covers the anatomy of a pool connection, how the three pool slots actually behave, and how to build failover that keeps a rig earning instead of shutting it down.

Anatomy of a stratum connection

Modern Antminers, Whatsminers, and most other SHA-256 hardware talk to pools over the Stratum protocol. A pool entry has three parts:

• Stratum URL & port — written as stratum+tcp://pool.example.com:3333. The prefix declares the transport, the hostname is the pool’s stratum server, and the number after the colon is the port. Pools publish several ports for the same server: a plain port (commonly 3333 or 4444), sometimes a high-difficulty port for large farms, and a TLS/SSL port (often 443) written as stratum+ssl:// for encrypted connections. Use the port the pool documents for your hashrate class.
• Worker name — almost always <account>.<worker>, e.g. bc1qyouraccount.rig01. Before the dot is your pool sub-account (or, on some pools, your payout Bitcoin address); after the dot is a label you choose so you can tell rigs apart on the dashboard. Register the sub-account on the pool’s website first — you won’t see stats or get paid until the account exists.
• Password — optional on nearly every Bitcoin pool. Leave it as x or blank. A few pools use it to pass parameters (for example a fixed difficulty like d=8192), but for normal setup it does nothing and a wrong value will not stop mining.

Why there are three pool slots

The Pool 1, Pool 2, and Pool 3 fields in the miner’s web UI are a priority-ordered failover chain, not three pools mining at once. The firmware always tries Pool 1 first. If it stops responding — the stratum server drops, DNS fails, or shares stop being accepted — the miner falls back to Pool 2, then Pool 3, and returns to a higher-priority pool automatically when it recovers.

This is a redundancy mechanism, so how you fill the slots matters. A miner that loses all configured pools does not keep hammering away at full power — modern firmware idles or throttles hashing when it has nowhere to submit shares, then keeps retrying the connection. That protects you from wasting electricity, but it also means an empty or dead pool chain equals zero earnings until you fix it.

The mistake: three copies of one pool

The obvious approach is to paste the same pool’s three published addresses into the three slots. It works, but it’s a single point of failure: an outage, maintenance window, or routing problem takes down all three entries at once and the miner idles until the pool recovers.

The better pattern: two accounts, two pools

Put your primary pool in Pool 1 (and its second server address in Pool 2 for local redundancy), then put a different operator on separate infrastructure in the last slot. Now the rig only goes idle if both operators fail at once, which is rare. The cost is a second sub-account and two sets of payouts to reconcile — worth it for any rig you care about keeping online.

Step-by-step: configure the pools

1. Register a sub-account (worker account) on your chosen pool’s website and, for real redundancy, a second account on a backup pool.
2. Copy the exact stratum URL and port the pool lists for your region and hashrate. Do not guess the port.
3. Open the miner’s web interface (browse to its LAN IP), log in, and go to Miner Configuration → Pools (wording varies by firmware).
4. Fill Pool 1: URL stratum+tcp://primary.pool:PORT, Worker account.rig01, Password x.
5. Fill Pool 2: the primary pool’s alternate server address (same account), for a fast local fallback.
6. Fill Pool 3: your backup pool’s URL and its own worker account.
7. Save & Apply. The miner restarts its mining process — expect a minute or two before hashrate ramps back up.

Verify the connection

• On the miner’s Status page, confirm the active pool shows Alive and that Accepted shares climb while Rejected and Stale stay near zero. A steady stream of accepted shares — not just a green light — is the real proof it’s working.
• Cross-check on the pool dashboard: within a few minutes your worker should appear online and report a hashrate close to the machine’s spec. Pool-side hashrate is measured from submitted shares, so it lags and fluctuates — judge it over 30–60 minutes, not by the first reading.
• A high reject rate points at a wrong port, a difficulty mismatch, latency to a distant server, or an overclock producing bad shares — not a failed connection.

Common mistakes & troubleshooting

• Worker registered but zero shares. Usually a typo in the URL, a firewalled/blocked port, or DNS the miner can’t resolve. Confirm the rig has a valid gateway and DNS on its network config, then re-check the URL character for character.
• “Dead” pool on every slot. If all three read dead, suspect the network, not the pool: no internet uplink, wrong subnet, or a router blocking outbound stratum ports. The miner will idle and retry rather than burn full power.
• Wrong prefix. stratum+tcp:// for plain, stratum+ssl:// for TLS ports. Pointing a plain client at an SSL-only port (or vice-versa) refuses the connection.
• Frequent hopping between slots. If the rig keeps bouncing to backups, Pool 1 is flaky or too far away — pick a closer stratum server to cut latency and stales. Chasing luck across pools (pool hopping) doesn’t raise long-run earnings on modern reward schemes.

A note on Stratum V2

The ecosystem is migrating from Stratum V1 to Stratum V2, which encrypts the connection and can let the miner build its own block templates for a more decentralized network. Native SV2 currently ships in BraiinsOS+ (industrial Antminers) and in AxeOS/ESP-Miner v2.14.0+ on Bitaxe hardware. Stock and most third-party firmware remain V1-only, so the typical rig uses a stratum+tcp/stratum+ssl V1 endpoint. Match the endpoint to what your firmware speaks.

Related: If a rig connects to the pool but hashrate stays low or a board drops out, isolate it with the ASIC Fault Finder. For hardware that won’t hash at all after setup, start a repair and pull common consumables from ASIC repair parts. Reject-heavy shares are usually a difficulty or share-difficulty issue, not a broken connection.