What a Stratum Connection Drop Actually Means

A Stratum connection drop occurs when an ASIC miner's persistent session with a mining pool ends unexpectedly, producing log entries such as "pool dead," "socket connect failed," "connection refused," "timeout," or repeated reconnect attempts. Stratum is the protocol most pools use to deliver work and receive submitted shares over a continuous two-way TCP connection; when that connection breaks, the miner stops receiving new jobs until it reconnects and re-establishes the mining session (Bitcoin Developer Guide).

A disconnect message does not, by itself, identify the cause. The same symptom can originate from a typo in the pool address, a local network fault, an unreachable or temporarily unresponsive endpoint, a firmware or protocol incompatibility, or a hardware event that stopped the miner. Treating every drop as a pool outage — or every drop as a hardware fault — leads to wasted troubleshooting time. The method below separates miner status, network/session status, and pool-side records so each layer can be checked independently.

Start by Identifying What Actually Failed

Before changing any setting, determine which layer is affected.

This triage step keeps a session-level problem from being confused with a hashboard, thermal, or pool-accounting issue.

Verify the Pool URL, Port, Coin, and Worker Name

Configuration errors are one of the most common causes of repeated disconnects, and they are also the easiest to rule out. Confirm every field against current, official pool documentation rather than an old screenshot or a copied configuration file:

• the stratum+tcp:// prefix, if the firmware requires the full URL;
• the exact hostname;
• the correct port;
• the correct coin and mining algorithm;
• the worker-name format required by that pool;
• whether a password is required or ignored;
• the order of primary and backup pool rows.

As a concrete reference, ViaBTC's current BTC mining configuration guide lists stratum+tcp://btc.viabtc.io:3333 as the primary BTC endpoint with port 443 as an alternate, and specifies a worker name in the format userID.workerID, where the worker ID is limited to 64 lowercase alphanumeric characters. Pool endpoint lists change over time, and the broader ViaBTC Mining Pools Information page maintains the current directory of endpoints, regional options, and failover ports across supported coins. Reusing a hostname or port from an old configuration file, a forum post, or a different coin's setup is a frequent, avoidable source of connection failures.

Before changing firmware or advanced settings, confirm these five fields:

1. Coin and mining algorithm
2. Stratum hostname
3. Port
4. Full worker name
5. Backup endpoint order

Check the Miner's Local Network

If the pool address and worker name are confirmed correct, move to the local network layer.

• Confirm the Ethernet link light and switch-port status.
• Confirm the miner has a valid IP address, subnet mask, gateway, and DNS server, whether assigned by DHCP or set statically.
• Check whether the miner's local web dashboard stays reachable while the pool session fails — if it does, the control board and LAN interface are functioning, and the fault likely sits further upstream.
• Compare the affected miner against a working miner on the same switch and subnet.
• Review outbound firewall rules, particularly on networks that restrict outbound traffic to specific ports.

Bitmain's ANTMINER troubleshooting reference treats incorrect pool information, network configuration errors, and Internet disconnection as distinct diagnostic paths rather than a single "network problem" category (BITMAIN Support). Following the same separation — configuration, then LAN, then upstream connectivity — avoids conflating unrelated faults.

Read the Miner Log Before Changing Firmware or Performance Settings

The miner's log usually indicates which stage of the connection failed. Interpret entries by their meaning rather than by exact wording, since text varies across firmware and pool implementations.

Stale, duplicate, and low-difficulty submissions can all result in a share not being accepted or credited by the pool, although miner and pool interfaces may report these categories separately. A rejected share indicates the pool did not credit that specific submission; it does not by itself confirm or rule out a Stratum connection problem, since a miner can remain connected while still submitting invalid or duplicate work. A note on terminology: a pool's assigned share target is intentionally easier to satisfy than the Bitcoin network's block target, which in numeric terms means the pool target is higher and the pool share difficulty is lower than network difficulty (Bitcoin Developer Guide).

Test Failover Correctly

Most ASIC firmware supports multiple configured pool rows. When troubleshooting a drop:

• Use a documented backup endpoint for the same coin and algorithm, unless intentionally switching pools.
• Avoid substituting a hostname or port copied from another pool or another coin.
• If the primary endpoint fails and a backup connects successfully, record the timestamps and log excerpts — this helps narrow the problem to the primary endpoint, port, or network path rather than a complete loss of connectivity from the miner.
• If all configured endpoints fail at the same time, investigate the miner's LAN, DNS, gateway, and upstream connection before concluding that the pool is unavailable.

Rule Out Miner Restarts and Hardware Protection Events

A Stratum session ends whenever the mining software stops running, regardless of network condition. Before treating a drop as network-caused, check:

• uptime and reboot timestamps in the miner's status page;
• fan alarms, over-temperature warnings, or thermal-protection events;
• power-loss or power-instability events;
• control-board errors or hashboard initialization failures.

If a disconnect coincides with a restart or a protection event, the connection loss is a consequence of the hardware event rather than its cause. Diagnosing the underlying thermal, power, or board issue should take priority over adjusting network settings in that case.

When to Collect a Packet Capture or Escalate

Reserve packet capture for cases where hostname, port, and LAN checks have already been completed and the cause remains unclear. A capture on the miner's network segment can show DNS queries and responses, TCP connection attempts, TCP resets, retransmissions, and sessions that establish and then close. This level of detail is useful when escalating to a pool's support channel or an ISP, since it separates "the miner never reached the server" from "the miner connected and was later disconnected." Because captures can include worker identifiers, pool endpoints, and internal IP addresses, avoid sharing them in public channels; provide them only to the relevant support contact.

Preventing Repeat Drops

A few practices reduce how often this troubleshooting cycle needs to be repeated:

• Keep firmware on a version supported by the hardware manufacturer, since older firmware may lag behind current protocol or endpoint requirements.
• Configure the pool's documented primary and backup endpoints rather than a single address.
• Maintain stable DNS and gateway configuration instead of relying on inconsistent DHCP behavior.
• Where practical, isolate miner traffic from congested or unreliable local network segments.
• Note recurring disconnects by time and affected miner so a pattern — such as a specific switch port or a specific time of day — becomes visible; this does not need to be a formal record-keeping system for a home or small-farm deployment, just enough detail to spot a repeating cause.

Frequently Asked Questions

Does a Stratum disconnect mean the mining pool is down?

Not necessarily. A disconnect can originate from an incorrect pool address, a local network fault, a firewall rule, a firmware issue, or a hardware event on the miner itself. Confirm the miner's configuration and local network before concluding the pool endpoint is unavailable, and check whether a documented backup endpoint for the same pool connects successfully.

Why does my miner connect but still show rejected shares?

A connected session and share rejection are separate issues. Rejected shares can result from stale work caused by network latency, duplicate submissions from firmware or proxy behavior, or shares that do not meet the pool's assigned difficulty. Review the specific rejection reason in the log rather than assuming the connection itself is at fault.

Should I switch to a different port if my miner keeps timing out?

Testing a pool's other documented port, such as an alternate port listed in the pool's own configuration guide, can help isolate whether an outbound firewall rule or ISP-level filtering is blocking the original port. This is a diagnostic step, not a guaranteed fix, and the port used should always come from the pool's current official documentation.

Can a firmware update fix repeated connection drops?

A firmware update may be relevant if the miner's protocol implementation is outdated or incompatible with a pool's requirements, but firmware should be changed only after configuration, DNS, and local network checks have been completed. Changing firmware first can obscure whether the original cause was a simple configuration error.

How do I tell if a drop was caused by the miner rebooting?

Check the miner's uptime and event log for a reboot timestamp, fan alarm, thermal-protection event, or power-related error around the same time as the disconnect. If these appear together, the Stratum session likely ended because the mining software stopped, not because of a network fault.

References

• Bitcoin Developer Guide, "Mining", Bitcoin.org.
• BIP 310, "Stratum Protocol Extensions", Bitcoin.org.
• BITMAIN Support, "Troubleshooting and Solutions for ANTMINER Failures".
• ViaBTC Help Center, "BTC Mining".
• ViaBTC Help Center, "Mining Pools Information".