What Is a Mining Pool Server Node?
When configuring an ASIC or mining program, users are typically asked to enter a “server,” “pool URL,” or “node” value. In this context, the term refers to the network endpoint that the mining device connects to in order to participate in pool mining — a hostname or IP address combined with a port number, commonly written as a Stratum URL. Through this connection, the pool sends mining jobs to the device, and the device returns completed work in the form of shares.
For a miner operator, the practical unit of configuration is the documented endpoint and port — not the pool's internal server architecture.
Protocol, Hostname, and Port: Reading a Pool URL
A typical pool connection string looks like this:
stratum+tcp://btc.viabtc.io:3333
Each segment has a distinct function. stratum+tcp identifies the connection method the firmware should use to open the session. btc.viabtc.io is the hostname the device resolves and connects to for that coin's mining service. 3333 is the TCP port on which the service accepts incoming connections. The worker identity — typically written as accountname.workerID — is supplied separately, after the connection is established, and is not part of the server address itself.
ViaBTC's published pool documentation lists this structure for its BTC endpoints, along with regional hostnames, a failover port, and SSL-based alternatives (ViaBTC Mining Pools Information). Because pool infrastructure and recommended addresses can change, operators should copy the current value from the pool's official setup page rather than reuse addresses from older firmware screenshots, forum posts, or saved configuration files.
How an ASIC Communicates With a Mining Pool
A typical Bitcoin pool-mining connection works broadly as follows. This is a simplified workflow; the exact messages and their order depend on the protocol and implementation:
- The device opens a connection to the configured endpoint.
- The device identifies itself using the credentials required by the pool, such as an account and worker name.
- The pool sends a job containing the data needed to construct candidate block headers.
- The pool assigns a share target for that session, defining the proof-of-work threshold the device must meet to produce a valid share.
- The device performs hashing locally; the pool server does not perform this computation on the device's behalf.
- The device submits shares that meet the assigned target.
- The pool validates each submission and records accepted shares for accounting purposes.
- When the Bitcoin network tip changes, the pool distributes an updated job so connected devices can move to the new block template.
This workflow reflects the purpose of pooled mining as described in Bitcoin's developer documentation: combining the hashing work of many participants and distributing proceeds in relation to the work each contributes, which reduces the payout variance an individual miner would otherwise experience under solo mining (Bitcoin Developer Guide — Mining). The guide also identifies Stratum as a widely used protocol for this miner-to-pool communication, distinct from the getblocktemplate interface used in some solo-mining and pool-backend configurations.
One distinction merits explicit attention because it is frequently stated incorrectly: a pool's share target is normally easier to satisfy than the Bitcoin network's block target. In proof-of-work terms, an easier target is numerically higher, while the corresponding difficulty is lower. A valid share therefore demonstrates work toward the pool's accounting requirement without necessarily meeting the much stricter network target required to produce an actual block.
Server Node vs. Wallet Address vs. Worker Name
A common setup error is mixing up fields that serve different functions. In ViaBTC's account-based setup, the server endpoint, worker name, and payout address are configured separately:
- Server endpoint — where the device connects to receive jobs and submit shares.
- Worker name — an identifier such as
accountname.worker01that attributes submitted shares to a specific account and device within the pool's system. - Payout or wallet address — configured separately in the ViaBTC account settings and used for distributing mined proceeds; it is not the server endpoint or the worker identity used to connect to ViaBTC.
ViaBTC's BTC setup documentation specifies that the workerID portion after the dot in accountname.workerID must consist of lowercase letters and numbers, with a maximum of 64 characters. This limit applies to workerID, not the complete account-and-worker string (ViaBTC BTC Mining guide). Other pools may use different identity formats, so follow the selected pool's own setup instructions. A wallet address is not a server endpoint; entering it into the server field will not establish a mining connection.
Configuring a Pool Server Endpoint
Most mining firmware presents several pool entry rows, typically labeled Pool 1, Pool 2, and Pool 3, along with worker and password fields. A practical configuration sequence is:
- Confirm the coin and algorithm supported by the device and the pool.
- Open the pool's current official mining guide for that coin.
- Copy the complete connection string exactly as published, including the protocol prefix and port.
- Enter the worker name in the format required by the pool.
- Where supported, enter one or more backup endpoints in the lower-priority pool fields.
- Save the configuration and allow the device time to establish a stable connection before drawing conclusions from the dashboard.
For BTC, ViaBTC's current documentation lists a global endpoint at btc.viabtc.io:3333, with port 443 available as a documented failover option and separate SSL-based addresses for operators whose firmware supports that transport. ViaBTC's guide recommends configuring multiple ports so the device can attempt the next entry if a connection attempt fails; this is operational guidance from ViaBTC's own documentation rather than a universal firmware behavior, since failover handling varies by device and firmware.
After a device reports a stable connection, ViaBTC notes that it may take approximately 10–15 minutes before worker status and accumulated activity become visible in the pool dashboard. This is a practical observation from ViaBTC's support documentation and should not be read as a fixed technical requirement applicable to every pool or network condition.
Why Backup Pool Entries Matter
Backup endpoints can allow a device to continue connecting to the pool if its preferred endpoint becomes unreachable, for example because a particular port is blocked, a specific endpoint is unavailable, or the route to that endpoint has a problem. They cannot restore connectivity if the device's local network or internet connection is down. An alternative port on the same hostname is not necessarily an independent server or network path.
This is a continuity measure rather than a performance optimization: configuring a backup port does not, by itself, reduce rejection rates, lower latency, or change ASIC power draw. Where a device supports multiple pool entries, listing a secondary address from the same pool's documentation is a reasonable precaution, but it should not be treated as a substitute for diagnosing an underlying connectivity problem.
Common Connection and Rejection-Rate Issues
When a device cannot connect, the relevant checks usually involve the connection configuration itself rather than the pool's broader infrastructure: whether the coin and algorithm match the configured endpoint, whether the hostname and port were copied correctly, whether the firmware supports the specified transport, and whether local network, DNS, or firewall settings are blocking outbound traffic.
An increase in rejected shares after changing an endpoint should not automatically be attributed to the new address. Network instability, device overheating, and firmware issues are also common contributors. ViaBTC's troubleshooting documentation treats a rejection rate within 3% as within its normal operating range for BTC mining and links elevated rejection rates to these same factors (ViaBTC — What if the Rejection Rate Is High?). This threshold reflects ViaBTC's own support guidance and should not be generalized as an industry-wide standard, since acceptable rejection rates can vary by pool configuration and network conditions.
It is also worth noting that a pool server and a Bitcoin full node are distinct roles. A full node validates the Bitcoin network and can supply block-template data to mining infrastructure, while the pool server manages device connections, job distribution, and share accounting. These functions can operate within the same organization's infrastructure, but running a mining pool connection is not equivalent to operating a Bitcoin full node.
Stratum V1 and Stratum V2
The original Stratum mining protocol is commonly called Stratum V1. Stratum V2 is a newer protocol with a published specification that defines mining-device channels to upstream nodes and distinguishes between work-providing nodes and proxies (Stratum V2 Mining Protocol specification). Operators should use the protocol and endpoint supported by both their pool and firmware, rather than assume that a V1 connection string can be reused for V2.
A configured endpoint should also be distinguished from a single physical machine. A published pool hostname can route to multiple backend systems, including connection servers and proxies that relay traffic to upstream infrastructure. In Stratum V2, an upstream node can be a work-providing node or a proxy between the device and upstream infrastructure. The endpoint is the operator's connection destination; it does not describe the pool's complete internal architecture.
FAQ
What is the server node in a mining rig?
It is the network endpoint — a hostname or IP address plus a port — that the mining device connects to in order to receive jobs from a mining pool and submit shares. It is usually entered as a Stratum URL in the device's pool configuration field.
Is a mining pool server URL the same as a wallet address?
No. The server URL identifies where the device connects for mining communication, while the wallet or payout address identifies where mined proceeds are sent. On ViaBTC, payout addresses are configured separately in the account. Worker identity formats vary by pool, so follow the selected pool's setup guide.
What do the numbers after the colon in a pool URL mean?
The number after the colon is the TCP port the mining service listens on. Different ports may correspond to different transport options, such as a standard connection or an SSL-based connection, or to backup entries published by the pool.
Why does my ASIC need a worker name?
The worker name allows the pool to attribute submitted shares to a mining identity and track individual devices. On ViaBTC, it uses the accountname.workerID format and is separate from both the server endpoint and the payout address. Other pools may require a different identity format.
Should I configure backup pool servers?
Where firmware supports multiple pool entries, listing a secondary endpoint from the same pool's documentation can help the device continue connecting if its primary endpoint becomes unreachable and the backup remains accessible. It cannot resolve a complete local network or internet outage, and simply adding a backup does not increase local hashrate or reduce rejection rates.
Why is my miner connected but not showing on the pool dashboard?
Some pools require a short stabilization period after a device connects before activity appears in the dashboard. If the device remains invisible well beyond that period, verify the worker name format and connection settings against the pool's current documentation.
Does changing a pool server URL improve ASIC hashrate?
Changing the URL does not directly increase the ASIC's local hashing capacity. However, if the new endpoint improves connection quality, it may reduce stale or rejected shares and increase the effective work accepted by the pool. Local hashrate and pool-side effective hashrate are different measures; a higher pool-side reading should not automatically be interpreted as faster hardware. ViaBTC's support documentation explains how network latency and rejection rates can affect pool-side results (ViaBTC — Pool Hashrate vs. Miner Hashrate).
What is the difference between a mining pool server and a Bitcoin full node?
A pool server manages device connections, job distribution, and share accounting. A Bitcoin full node validates the network and can supply block-template data used to construct mining jobs. The two roles are related but not interchangeable.