Introduction

A miner that will not connect, reconnects repeatedly, or submits no shares can have several possible causes. In pooled mining, a device can look "online" in its local interface while still failing to reach the pool, or it can connect successfully but have its shares rejected for reasons unrelated to the network path. Treating every symptom as the same problem leads to unnecessary firmware resets, cable swaps, or hardware replacements.

This guide separates mining pool connection troubleshooting into five checks, performed in sequence: local network access, pool configuration, the Stratum session itself, share rejections, and miner-side performance. Each stage produces different evidence, and conflating them — for example, treating a rejected share as proof of a failed hashboard — obscures the actual cause.

The diagnostic sequence

Before changing any setting, it helps to frame the problem as a sequence of yes/no questions:

1. Can the miner reach its gateway and resolve the pool hostname?
2. Does the configured coin, Stratum URL, port, and worker name match the pool's current documentation?
3. Does the miner complete the Stratum handshake — subscribe, authorize, and receive jobs — and maintain the connection?
4. Are submitted shares accepted, or are they rejected, and for what stated reason?
5. Is the ASIC itself hashing at its expected local rate?

Working through this order prevents wasted effort. A worker that cannot resolve DNS will never reach step 4, so investigating share rejections at that point is premature. If the miner connects and later stops receiving jobs or submitting shares, revisit connection stability rather than treating the earlier handshake as proof that the network is still working.

Step 1: Local network and LAN access

A miner can have general internet access while still failing to reach a specific pool endpoint. This happens when a farm LAN, router, or ISP blocks the required outbound port, or when DNS is misconfigured so the pool hostname cannot resolve, even though other websites load normally from a different device on the same network. BITMAIN's support documentation identifies disabled ports and DNS errors as common network-side causes when a miner cannot connect to a pool (BITMAIN).

Practical checks at this stage include confirming that the miner has a valid IP address and gateway, that the configured DNS server resolves external hostnames, and that the pool's port is not blocked by a router firewall, VLAN rule, or ISP-level restriction. Testing connectivity from the miner's own network segment is more reliable than testing from an unrelated device, since routing or firewall rules can differ by VLAN or physical switch port.

Step 2: Pool configuration fields

Start by checking five configuration fields: coin/algorithm, Stratum hostname, port, worker name, and the password field. A URL copied from an old profile, a different coin's setup page, or a third-party tutorial can lead to mismatched settings, since pool endpoints and supported coins can change over time.

The Stratum URL is the mining server address that issues work and receives share submissions — it is not a wallet address, and the two should never be confused when filling in miner settings. Always verify the current endpoint against the pool's official documentation rather than a saved configuration or screenshot, since addresses, regions, and SSL options can be updated.

For ViaBTC's BTC mining service, the documented global endpoint is stratum+tcp://btc.viabtc.io:3333, with port 443 listed as a failover option, and the worker name format is userID.workerID, where the worker ID portion uses lowercase letters and numbers up to 64 characters; the password field is optional in this configuration (ViaBTC). Readers mining other coins, or using regional or SSL-specific addresses, should confirm the exact current values from ViaBTC's mining pool address directory before saving settings, since listed endpoints and ports can change (ViaBTC).

One caution applies broadly: a port number by itself does not establish whether a connection uses encrypted transport. A failover or alternate port should be treated as an additional connection entry, not as evidence of a particular security property, unless the pool's documentation states otherwise.

Configuring a backup pool entry can allow a miner to switch to an alternate endpoint when its primary configured connection cannot be reached. This depends on the miner's firmware and connection priority settings, and it does not guarantee uninterrupted mining if the backup endpoint is also unreachable or misconfigured.

Step 3: Stratum session and share submission

Once the configuration fields are correct, the next question is whether the miner completes the Stratum handshake: establishing a TCP connection, subscribing, authorizing with its worker credentials, and receiving mining jobs with an assigned share difficulty. A miner that connects but never receives jobs, or that authorizes and then disconnects repeatedly, needs checks of the ongoing network connection, pool responses, and miner software. An earlier successful handshake does not rule out a later network interruption.

If authorization fails, verify the account and worker name against the pool's setup instructions before investigating share quality. An unsuccessful authorization request is distinct from a rejected share submission. However, a submission from an unauthorized worker can also be rejected; identify which request produced the error in the log (Stratum protocol documentation).

After the miner begins receiving jobs, it should start submitting shares — proofs of work sent to the pool to demonstrate contribution toward the pool's payout calculation. Share frequency depends on the miner's hashrate and the assigned share difficulty, so a short period without submissions does not by itself identify a fault (Bitcoin Developer Guide).

For a connected miner with zero shares, check whether the connection remains open, jobs continue arriving, the ASIC has local hashrate, and the miner records submission attempts or errors. Compare the miner's submission counter with the pool's reported data: a miner that submits nothing needs a different investigation from one that submits shares but receives rejections. If connections and jobs remain stable but local hashrate is zero or submissions remain absent, move to the miner-side checks in step 5.

ViaBTC's BTC mining documentation notes that operation status and earnings can be reviewed after the miner has stabilized for roughly 10–15 minutes; this is platform guidance for its BTC monitoring interface rather than a universal benchmark for how quickly any pool reports a new worker (ViaBTC).

When the miner is running but the pool shows an offline worker

Local device availability and pool worker status describe different things. ViaBTC defines an Active worker as connected and contributing work; Offline workers have no reported hashrate and have not been working for 20 minutes to one day, while Inactive workers have not been working for more than one day (ViaBTC worker management).

Check that the miner's configured account and worker name match the worker you are viewing on the pool. Then check its current pool connection, local hashrate, and submission records. ViaBTC's offline-worker guidance identifies configuration problems, a short runtime before data is submitted, and unstable connectivity or an idling miner as possible causes. It recommends observing data after 10–20 minutes of stable operation for a newly running miner (ViaBTC offline-worker guidance). This observation period does not mean you should wait to address an explicit DNS, connection, or authorization error.

Step 4: Reading rejected shares correctly

Rejected shares are the umbrella category; stale, invalid, duplicate, and other pool-reported reasons are subcategories within it, not separate peer-level problems. BITMAIN defines mining pool rejection rate as the ratio of rejected data to total data the miner sends to the pool, and identifies network instability as a leading cause of elevated rejection levels; its guidance also separates potential fault points across the local network, the operator's broader network, and the pool server itself (BITMAIN).

A stale share is submitted for a job the pool no longer accepts. Receiving a newer job does not automatically make all previous work stale. In Stratum V1, clean_jobs=true tells the miner to discard previous jobs. Delayed job delivery or submission can cause shares to arrive after their job has become obsolete (Stratum protocol documentation). For stale errors, check network latency and connection stability before assuming a hashboard fault.

No single rejection-rate threshold applies uniformly across pools or firmware, since counting methods and displayed labels are not identical everywhere. A more reliable approach is to investigate a sustained increase in rejected shares, and to read the exact reason returned for a share submission — such as stale, duplicate, low difficulty, or another invalid-share message — rather than relying on a generic percentage benchmark. Keep authorization-request failures in the session checks from step 3; if the pool rejects a submission because its worker is unauthorized, revisit those account and session checks.

Step 5: Confirming the ASIC is actually hashing

A successful pool connection does not by itself confirm that the ASIC is hashing normally. Local hashrate, as displayed in the miner's own interface, and pool-estimated hashrate, as calculated by the pool from a rolling window of accepted shares, are related but not interchangeable figures; they should not be compared without accounting for differences in measurement window. A worker can remain connected while individual hashboards underperform or go offline, so checking hashboard status, fan behavior, and local hashrate directly on the miner is a necessary final step rather than an optional one.

Similarly, shares submitted and shares accepted should not be used to infer hardware efficiency, power draw, or revenue on their own; those figures depend on the pool's accounting rules and are distinct from a device-level power or efficiency measurement.

Common errors and the next action

Use the exact log message to choose the next check. These actions help narrow the cause; a message alone does not always prove where the fault lies.

A disciplined approach to changes

When working through these checks, change one variable at a time — for example, correct the Stratum URL first, save the setting, and observe the resulting log messages before adjusting DNS, port, or firmware. Preserve the miner's exact log message (DNS failure, socket connection failure, connection timeout, connection refused, authorization failure, or a specific share-rejection reason) before making further changes, since the same symptom can have different underlying causes across different firmware.

If the problem remains unresolved, contact the pool's support team with the affected worker name, configured endpoint, time of the error, and relevant log messages. ViaBTC's offline-worker guidance recommends submitting a ticket when the configuration, runtime, and network checks do not resolve the issue (ViaBTC).

Conclusion

Mining pool connection failures are easier to resolve when local network access, pool configuration, the Stratum session, share rejections, and miner-side performance are treated as distinct checks rather than one undifferentiated "offline" problem. Verify the coin, Stratum URL, port, and worker name against the pool's current documentation before making firmware or hardware changes, and revisit network stability if a previously successful session stops delivering work. For rejected shares, reading the specific reason reported by the pool or miner keeps the investigation focused on what the data actually shows.

FAQ

Why does my miner show as online but report no shares?

First identify what "online" means in that interface. A reachable device is not proof of pool authorization, and a previously successful pool connection does not prove that jobs or submissions are still flowing. Check current authorization, ongoing jobs, local hashrate, assigned share difficulty, and submission errors. Also distinguish zero submissions on the miner from delayed or rejected submissions on the pool page.

Is port 443 more secure than the default mining port?

A port number alone does not establish whether a connection is encrypted. Port 443 should be treated as an alternate or failover connection entry as documented by the pool, not as proof of a particular transport-security property, unless the pool explicitly states that the port uses encrypted transport.

Should I switch to a backup pool address as soon as I see a connection error?

A backup address can help a miner switch to an alternate endpoint when the primary configured connection cannot be reached, but first confirm that the primary URL, port, and worker name are entered correctly. If those settings are correct and the primary remains unreachable, try the pool's documented backup entry and observe the new connection logs.

Does a higher rejected-share count mean my ASIC is failing?

Not necessarily. Stale work, network instability, and duplicate submissions can cause rejections without proving a hardware fault. Read the exact submission response alongside local hashrate and miner errors. Handle failed authorization requests separately; a rejected submission marked unauthorized calls for account and session checks.

How long should I wait before troubleshooting a newly configured worker?

Investigate explicit DNS, connection, or authorization errors immediately. For pool reporting after stable operation begins, ViaBTC's BTC setup guide gives roughly 10–15 minutes as a reference for checking status and earnings; its offline-worker guidance recommends observing data after 10–20 minutes. These are platform-specific observation periods, not guarantees of recovery or universal rules for every pool or coin (BTC setup guide, offline-worker guidance).

References

• ViaBTC, BTC Mining setup guide
• ViaBTC, Mining Pools Information
• ViaBTC, How to Manage Workers?
• ViaBTC, Why workers may appear offline or inactive while the miner is running (Chinese)
• BITMAIN, What if the miner can't connect to the mining pool?
• BITMAIN, The rejection rate of mining pools
• Bitcoin Developer Guide, Mining
• Slush's Pool, Stratum mining protocol documentation (archived March 7, 2015; used for Stratum V1 protocol behavior)