ASIC Miner Pool Settings Guide (2026): Correct URL, Worker Name, and Failover Setup
Use the right pool URL, worker format, and failover order to stop idle ASICs, rejected shares, and payout mistakes on day one.
ASIC miner pool settings are correct when the machine points to the exact pool URL and port, the username follows the pool's required format, the password field matches the pool rule, and backup pools are configured in a real priority order. If those four items are right, most new ASICs will begin submitting shares within minutes. If they are wrong, the miner can look healthy while producing zero valid work.
This guide covers the practical setup sequence for home miners and small farm operators in 2026: where to find the right endpoint, how to format worker names, when to use wallet-based logins versus account-based logins, and how to build a failover stack that keeps hashrate online during a pool outage. Good pool settings will not rescue a bad ROI model, but they do prevent avoidable downtime, rejected shares, and miscredited payouts.
Why pool settings matter more than most first-time buyers expect
The pool section in your miner dashboard decides where work comes from, how shares are credited, and what happens when the primary endpoint stops responding. On most ASICs you will see three pool rows. Row one should be your primary destination. Rows two and three should be real failover options, not copies of the same dead endpoint.
Before editing pool fields, make sure the rest of the machine is stable. Bad power, weak airflow, and flaky Ethernet often look like pool problems. If you are still building the physical environment, start with our rack layout and power distribution guide, then review our garage ventilation setup guide and firmware and maintenance checklist before you leave a new unit running unattended.
The four fields you must get right
| Field | What to enter | Common mistake |
|---|---|---|
| Pool URL | The exact hostname or stratum endpoint shown in your pool dashboard or official help page. | Using an old endpoint copied from a forum post or a different region. |
| Port | The port paired with that URL for your hardware and payout mode. | Mixing a low-difficulty or solo port with the wrong account type. |
| User / Worker | The exact login format the pool requires, often wallet address, account name, or account.workername. | Entering only a wallet when the pool expects username.worker. |
| Password | The pool's required placeholder, token, or worker password if one is used. | Leaving a required field blank or pasting the website login password by habit. |
Those fields sound simple, but they are where most day-one failures happen. A wrong character in the worker string can send hashrate to the wrong subaccount. A wrong port can connect without producing valid credit. Repeating the same endpoint in all three rows creates the illusion of redundancy while leaving you with a single point of failure.
Pre-power checklist before you touch the pool screen
- Confirm the miner has stable power and the correct line voltage for the model.
- Use a wired Ethernet connection instead of temporary Wi-Fi bridges when possible.
- Update the management password and restrict dashboard access to your LAN or VPN.
- Verify the clock, firmware version, and fan behavior after the first boot.
- Keep your power cost assumptions separate from pool configuration so you do not confuse a setup issue with a profitability issue.
Step-by-step: how to configure ASIC miner pool settings correctly
1. Pull the endpoint from the pool's official dashboard
Do not trust screenshots that float around social media, old marketplace listings, or random YouTube descriptions. Open the pool's current dashboard or official help center and copy the exact URL and port it publishes for your coin and payout method. Some pools want a wallet address in the user field. Others want an account name followed by a worker suffix. Copy the format exactly as shown.
If your pool offers multiple protocol choices, review the pool's current documentation before switching. For background on newer pool communication standards, the Stratum V2 project overview is a useful reference, but you should still follow the connection instructions published by your chosen pool.
2. Use a worker naming system you can scale
A worker name should tell you which machine is hashing without opening the rack door. A simple pattern such as garage-s21-01, farm-a-row2-05, or hosting-bay3-unit12 is enough. The point is consistency. If you plan to run more than one miner, name workers so you can identify bad boards, unstable units, or network drops from the pool dashboard in seconds.
Avoid worker names that only make sense today, such as newminer or test1. Six weeks later those labels become useless. Clean naming is an uptime tool, not just an accounting detail.
3. Set the primary pool first, then add real failovers
Enter your main pool in row one. Save carefully. Then add a genuine fallback in row two. A good failover can be the same pool in a different region if the operator supports regional endpoints, or a second pool if you prefer provider diversity. Row three is for your least preferred backup, not a duplicate of row one.
If you copy the same URL into all three rows, the miner cannot escape a real outage. If you point row two and row three to a different pool, remember that payout method, account format, and worker syntax may change. Double-check every field before you rely on those backups.
4. Save, reboot if required, and watch accepted shares
Some dashboards apply pool edits instantly. Others need a restart of the mining process. After saving, watch the miner status page for five to ten minutes. You want to see the machine connect, receive work, and accumulate accepted shares. A short burst of instability right after a restart is normal. A flat accepted-share counter is not.
Also open the pool dashboard itself. The worker should appear online and begin reporting hashrate after the pool's normal averaging delay. If the machine says it is connected but the pool sees nothing, focus on worker syntax, port choice, DNS reachability, and firewall rules before you blame the hashboards.
5. Record the final settings outside the machine
Once the miner is stable, save the exact pool rows, firmware version, IP address, and worker name in your own operations log. This makes replacement, troubleshooting, and remote support far faster. It also stops small farms from drifting into undocumented one-off configurations that nobody wants to touch later.
Primary vs failover design for home miners and small farms
Home miners usually care about simplicity. In that case, a practical stack is one primary pool plus one backup region from the same operator, followed by a second operator as the final fallback. Small farms often care more about uptime and operational separation. They may prefer a diversified stack from day one, especially when different racks are assigned to different payout or treasury policies.
Whichever route you choose, keep the logic clear. Your backup should exist for continuity, not for experimentation. Do not leave stale test pools in the rotation. If a temporary endpoint was used for setup, remove it after validation.
The most common pool-setting mistakes and how to fix them
- Connected but earning nothing: Usually a wrong worker format, wrong port, or the wrong coin endpoint.
- Frequent pool switching: Often caused by weak network links, unstable DNS, or failover rows that are misconfigured.
- Shares credited to the wrong account: The user field was copied from another machine or another customer's subaccount template.
- All three pools dead at once: They were all copies of the same provider or the same outdated hostname.
- High reject rate after setup: Check latency, firmware stability, temperature, and whether the endpoint region matches your location.
If rejects spike after a pool edit, do not change five things at once. Roll back to the last known-good row, verify the machine's thermals, and inspect the network path. We often see operators chase a supposed pool issue when the real problem is overheating, packet loss, or an overloaded power strip causing the miner to brown out under load.
Security and reliability rules worth following
Pool credentials are part of your operating stack, so treat them that way. Change the default miner password immediately. Restrict dashboard exposure. Do not leave management panels open to the public internet. If the pool supports account alerts or worker notifications, enable them so you learn about outages before your next manual check.
It is also smart to separate payout credentials from maintenance access. The person who can reboot a machine does not always need permission to edit the destination account. On larger deployments, documented change control matters more than clever tuning.
When to revisit pool settings after the first install
Re-check pool rows any time you change firmware, replace a control board, move the machine to a new network, or switch the payout destination. You should also review the configuration after a long outage, because some operators change regional endpoints or retire old ports over time. A once-valid setup can become stale.
For most miners, a short monthly audit is enough: verify the primary endpoint is still current, confirm failovers still authenticate correctly, and make sure worker names match your asset list. That kind of routine review pairs well with the maintenance checks in our firmware and maintenance guide.
Bottom line
The best ASIC miner pool settings are not complicated, but they do need to be exact. Copy the current endpoint from the pool's official documentation, use the correct worker format, build real failovers, and confirm accepted shares before you walk away. That process prevents the most common first-day failure: a machine that is powered on, making noise, and earning nothing.
FAQs
What should I enter in the worker name field?
Enter the exact format your pool requires. Some pools want a wallet address, some want an account name, and many want a pattern like account.workername. Copy the format from the pool's current dashboard or help page instead of guessing.
Should I use the same pool URL in all three rows?
No. That gives you no real redundancy. Use a primary destination first, then configure genuine failovers such as a second region from the same pool or a second operator with its own correct login format.
Why is my ASIC connected but not earning?
The usual causes are a wrong worker string, a wrong port, the wrong coin endpoint, or a network path problem. Check accepted shares on the miner, then confirm the worker appears on the pool dashboard after the normal averaging delay.
When should I change ports or protocol options?
Only when the pool's official documentation tells you to. Different ports can map to different difficulty settings, payout modes, or protocol options. If your pool supports newer transport methods, review its documentation first and change one variable at a time.