Backup URLs give a new ASIC miner alternative pool endpoints to try if its primary mining connection becomes unavailable. The basic task is simple: enter a valid primary pool URL in Pool 1, place correctly configured alternatives in Pool 2 and Pool 3, then confirm the miner is submitting accepted shares. The details matter because a wrong port, worker name, or protocol can prevent failover from working when it is needed.

This guide explains a cautious ASIC miner pool configuration process. It uses placeholders rather than fixed endpoints, since mining URLs, ports, supported coins, and firmware options must be checked for the specific coin and pool before use.

What Are Pool Backup URLs and Why Does a New ASIC Miner Need Them?

A pool URL is the mining endpoint entered in an ASIC’s pool configuration. It normally contains a protocol, host, and port, such as stratum+tcp://PRIMARY-POOL-HOST:PORT. It is not the same as the worker name or password; those are separate fields used by the pool and miner firmware.

Backup URLs are lower-priority endpoints the miner can try when its preferred connection is unavailable. They can provide an alternate connection path when a hostname, route, endpoint, or pool connection fails. They do not guarantee zero downtime: the miner, local network, DNS service, pool service, account credentials, and firmware must all be functioning.

For a new device, configure backups before relying on the unit operationally. It is easier to validate a redundant setup during commissioning than during a connection incident.

How Pool Priority and Automatic Failover Work

Many ASIC interfaces display Pool 1, Pool 2, and Pool 3. Manufacturer documentation for Bitmain miners describes these entries as descending priorities: the miner normally uses Pool 1, tries Pool 2 if Pool 1 connects abnormally, and then tries Pool 3 if Pool 2 is also unavailable.

That common model is mining pool priority, not usually a load-balancing tool. A lower-priority pool is generally idle while the higher-priority pool remains healthy. Do not expect hashrate to be deliberately split across all three entries unless your exact miner firmware explicitly documents that behavior.

Failover implementation is device-specific. Different ASIC brands, aftermarket firmware, proxy setups, retry timers, and network settings can change how quickly a miner retries or switches. Read the documentation for the specific model and firmware before assuming its exact mining pool failover rules.

Before You Start: Gather the Correct Pool URL, Worker Name, and Password

Prepare these details before opening the miner interface:

• The correct coin- and algorithm-specific Stratum URL and port from the pool’s current official setup page.
• The required ASIC worker name format for that pool.
• The required password value, if any.
• One or two backup destinations that support the same coin and algorithm as the miner.
• Access to the miner’s status page and logs after saving.

Do not reuse a URL from an old guide, a different coin, or a different mining algorithm. A port that works for one asset may not work for another. Likewise, do not assume every pool accepts an account.worker identity. Pools can impose their own worker-name format, so copy the required format exactly.

The password field may be optional for certain pool and firmware combinations, but it is not universally optional. Enter it exactly as the chosen pool requires; do not treat an empty or arbitrary password as a general rule.

Step 1: Open Your ASIC Miner’s Pool Configuration Page

Sign in to the ASIC miner’s local management interface using the device’s current network address. Look for a page named Mining Configuration, Pool, Miner Configuration, or a similar label.

Before changing anything, record the existing settings or take a protected local note. Do not include passwords, private IP addresses, account names, or worker names in screenshots shared outside your operation. Confirm that the page presents separate fields for URL, worker, and password for each configured pool.

Step 2: Set Pool 1 as Your Primary Mining Endpoint

Enter the selected pool’s current primary endpoint in Pool 1. Use the protocol, hostname, and port exactly as the pool publishes them. Then enter the worker identity in the required format and the required password value.

Pool 1 should be the destination you intend to use under normal conditions. A valid configuration is more than a syntactically correct URL: the account or subaccount must exist, the worker format must be accepted, and the endpoint must support the miner’s coin and algorithm.

Avoid modifying protocol prefixes or ports to make entries look consistent. If the official instructions specify an SSL or non-SSL endpoint, use only an option that your ASIC and firmware support.

Step 3: Add Pool 2 and Pool 3 as Backup URLs

Configure Pool 2 and Pool 3 as lower-priority alternatives. Each entry needs its own valid URL, worker name, and password fields. A backup pool URL with a missing worker field or incompatible credentials is not a usable fallback.

Placeholder configuration example

Use this pattern as a structure only. Replace every placeholder with official, current details for the selected pool, coin, and account.

• Pool 1 URL: stratum+tcp://PRIMARY-POOL-HOST:PORT
• Worker: account.worker
• Password: PASSWORD-AS-REQUIRED
• Pool 2 URL: stratum+tcp://BACKUP-POOL-HOST:PORT
• Worker: account.worker
• Password: PASSWORD-AS-REQUIRED
• Pool 3 URL: stratum+tcp://THIRD-POOL-HOST:PORT
• Worker: account.worker
• Password: PASSWORD-AS-REQUIRED

The backup entries must mine the same compatible algorithm. For example, an ASIC designed for one algorithm cannot use a backup endpoint for an unrelated algorithm merely because the field accepts a URL.

Should Your Backup URLs Use the Same Pool or a Different Pool?

There is no single best arrangement. Choose based on the risk you are trying to reduce and the operational work you can support.

Same-pool endpoint redundancy

Using multiple endpoints at the same pool can provide redundancy for an individual hostname, regional route, or endpoint issue. It is simpler because the account and worker setup may remain within one operator. It does not, however, remove dependence on that pool operator.

A backup at another pool operator

Using a different operator as a lower-priority backup can reduce reliance on one pool operator. It also adds work: you need a valid account, worker setup, payout configuration, and compatible endpoint at the second operator. Review the payment settings and operational implications before choosing this route.

A balanced setup can use more than one endpoint for the primary operator and reserve another entry for a separately configured operator. The correct choice depends on your network conditions, administrative capacity, and risk tolerance, not on an assumption that any backup arrangement improves returns.

Step 4: Save the Settings and Verify the Miner Connects

Save or apply the configuration, then wait for the miner to establish a session and begin working. Do not assume a saved page means a successful connection.

On the miner’s dashboard or log page, verify all of the following:

• The active pool is Pool 1 or the intended primary entry.
• The miner reports a connected or alive pool session.
• Accepted shares begin appearing after the normal warm-up period.
• Reported hashrate is broadly consistent with the device’s expected operating condition.
• There are no persistent authentication, DNS, connection, or protocol errors.

A temporary startup message may not be significant, but recurring errors deserve investigation before the miner is treated as operational. Check the pool-side worker view as an additional confirmation when it is available.

How to Test Backup Pool URLs Without Creating a Long Outage

A failover test should be planned. Intentionally disabling the primary can interrupt mining, and a test can be misleading if the miner has long retry timers or cached network state.

Use a short, controlled maintenance window. First confirm that Pool 1 is healthy and that Pool 2 or Pool 3 has valid credentials. Then follow your miner vendor’s supported method to temporarily make the primary unavailable, observe the logs and active-pool status, and confirm whether the miner reaches the intended backup. Restore the primary configuration immediately after the test and verify that the miner returns to normal operation.

Do not repeatedly force failures during ordinary production without a clear plan. Keep notes on the active pool, timestamps, log messages, and recovery result so future miner connection troubleshooting starts with evidence.

Troubleshooting: Wrong Port, DNS Errors, Rejected Shares, and Worker-Name Mistakes

Connection and DNS errors

A connection refusal, timeout, or DNS error often points to a mistyped hostname, incorrect port, unsupported protocol, local firewall rule, gateway issue, or unavailable route. Compare the full URL character by character with the selected pool’s current official instructions. Check that the miner can resolve the hostname and that the local network allows the required outbound connection.

Authentication and share errors

Authentication failures usually require checking the ASIC worker name, account or subaccount spelling, password requirements, and the destination pool’s accepted format. If the miner connects but shares are rejected persistently, verify the selected coin, algorithm, pool endpoint, firmware compatibility, and device time settings.

Do not fix a recurring error by cycling through random ports or password values. Make one documented change at a time, save it, and recheck the log. This preserves a clear path back to the last known-good configuration.

ViaBTC Setup Note: Where to Verify Current Coin-Specific Mining URLs

For ViaBTC, confirm the selected coin’s current URL, port, regional endpoint, payment information, and available protocol options on the official Mining Pools Information page immediately before deployment. The page lists coin-specific endpoint information, including failover-port details for several supported assets.

FAQ

Do ASIC miners switch pools automatically?

Many do use lower-priority entries after a higher-priority connection becomes unavailable, but the precise trigger and timing depend on the model and firmware.

Should backup URLs use the same pool?

They can, especially for endpoint redundancy. A different operator can reduce single-operator dependence, but it requires a fully valid account and worker setup there.

Why is my ASIC not connecting to a backup pool?

Start with the exact URL, port, coin and algorithm compatibility, DNS reachability, worker-name format, password requirement, and miner logs.

Well-configured backup URLs are a practical resilience measure, not a promise of uninterrupted mining. Verify every entry while the miner is new, and recheck current pool details whenever you change coins, firmware, networks, or pool operators.