Introduction

A mining pool URL is the network endpoint through which an ASIC receives new jobs and submits shares. When the path between the miner and that endpoint is slow, unstable, or subject to packet loss, a miner can keep working on a job the pool has already replaced, and the resulting share may be marked as stale. Selecting a regional pool URL is therefore a network-path decision, not a guarantee that the dashboard's overall rejection rate will fall. The goal is to identify the endpoint that gives the most reliable, lowest-latency connection from a specific mining site, then confirm the result using the pool's own rejection data rather than assuming that geographic proximity alone solves the problem.

This article explains what a regional pool URL controls, why network path can influence stale and rejected shares, how to evaluate a ViaBTC regional endpoint for BTC mining, and which other causes of rejected shares are unrelated to routing.

What a Regional Pool URL Does

A Stratum URL such as stratum+tcp://btc.viabtc.io:3333 identifies three things: the protocol used for miner-to-pool communication, the hostname or IP address of the pool server, and the TCP port the miner connects to. The mining software uses this address to receive mining jobs and difficulty updates and to submit completed shares back to the pool for validation. It is distinct from a Bitcoin wallet address, which only determines where mined rewards are paid, and from the worker name, which identifies an individual device within an account. ViaBTC's documentation on Stratum addresses describes the same server-and-port structure and recommends copying connection details directly from current official pages rather than reusing older configuration files or forum instructions (ViaBTC, Mining Pool Stratum Address Explained).

A pool may publish more than one endpoint for the same coin—commonly a global address and, where available, one or more regional addresses—so that miners in different parts of the world can connect through a shorter or more stable network path.

Why Network Path Can Affect Rejected Shares

Rejected shares can be reported for several distinct reasons, and only some of them relate to networking:

• Stale shares — the share refers to work the pool has already invalidated or retired, often after a new block or clean job update.
• Duplicate shares — the same valid share is submitted more than once.
• Low-difficulty shares — the submitted share does not meet the difficulty target the pool assigned to that worker.
• Invalid or malformed submissions — the share fails validation for reasons that can include hardware faults, firmware bugs, or incorrect configuration.

Public Stratum protocol references document stale, duplicate, and low-difficulty submissions as separate error categories rather than a single undifferentiated reject, which is why a pool's rejection-reason data, where available, is more useful than the aggregate percentage alone (Stratum protocol documentation).

Network path matters primarily for stale or other network-related rejections. Latency, jitter, packet loss, and brief disconnects between the miner and the pool server increase the chance that a job update arrives late or that a completed share arrives after the pool has already moved on to valid new work. A regional endpoint can shorten or stabilize this path, which may reduce stale-share risk. It does not change the pool's assigned share requirements or resolve invalid work caused by hardware, firmware, or configuration problems, and generally will not fix persistent duplicate or low-difficulty share errors. ViaBTC's own troubleshooting guidance confirms the need to separate these causes: when rejection rate is high, it directs miners to check network connection, miner temperature, and firmware as distinct possible factors rather than treating the URL alone as the fix (ViaBTC, What if the Rejection Rate is High?). The same guidance describes a rejection rate within 3% as ViaBTC's normal operating range for its service; this figure is specific to ViaBTC and should not be read as an industry-wide benchmark.

How to Select the Right ViaBTC Regional URL

The following steps describe a practical process for choosing and verifying a BTC endpoint on ViaBTC. They are configuration guidance, not a mandatory sequence.

1. If ViaBTC publishes a regional endpoint for your location, test it against the global endpoint. For BTC, ViaBTC currently lists a Europe-specific endpoint alongside its global addresses. A mining site in Europe may see a more stable path through the regional endpoint than through a global one, though this should still be verified rather than assumed.
2. Verify the coin, protocol, host, and port before saving the configuration. A mismatched port or an outdated hostname can prevent the miner from connecting at all, which is a different problem from an elevated rejection rate on an otherwise working connection.
3. Configure the documented backup or failover port (ViaBTC lists port 443 as a failover option for its BTC global and Europe endpoints) to provide an alternate connection option if the primary port cannot be reached. A failover port is a continuity measure for certain connection failures; it is not evidence that it performs better than the primary port under normal conditions or that it protects against every server or routing failure.
4. Check worker name and password fields, since incorrect worker formatting can cause connection or authorization errors that are unrelated to routing.
5. Compare actual pool-side rejection data between endpoints before deciding which one to keep in production. Configuration alone does not confirm improvement; observed results over comparable periods do.

Full, current connection details for ViaBTC's supported coins, including BTC global and Europe addresses and SSL endpoints, are maintained on ViaBTC's official connection page and should be checked immediately before changing miner settings, since hostnames and ports can be updated (ViaBTC, Mining Pools Information).

A Practical Comparison Test for Mining Sites

When a site has more than one plausible endpoint to choose from, a controlled comparison produces more reliable evidence than switching URLs based on assumption. The following is practical guidance, not a fixed industry procedure:

• Where feasible, hold the ASIC model, firmware version, clock settings, and cooling conditions constant across the comparison.
• Test one URL at a time on a given miner, or split a group of comparable miners between two endpoints running the same firmware.
• Compare equivalent operating periods rather than a single instantaneous dashboard reading, since short-term fluctuations in rejection rate are normal.
• Review the pool-reported rejection rate, rejection reasons if the interface exposes them, disconnect or reconnect events in the miner's own logs, and hashrate stability on the pool dashboard for each endpoint.
• Where possible, also check basic connection quality metrics (packet loss, jitter, round-trip time) from the mining site to each candidate server, since these help explain—rather than replace—the pool-side results.

There is no universal fixed duration that applies to every mining site; the observation window should be long enough to capture normal operating variation and should be the same length for each endpoint being compared.

When Changing the URL Will Not Solve the Problem

A regional URL change addresses network path only. If rejection rate remains elevated after switching endpoints and confirming a stable connection, the cause may instead involve one or more of the following:

• An unstable local internet connection, overloaded router or switch, or a congested cellular or satellite uplink.
• Packet loss or routing changes introduced by the ISP rather than by the pool's server location.
• ASIC overheating, which can affect share validity independent of network conditions.
• Firmware faults or an outdated firmware version.
• Incorrect pool or worker configuration unrelated to the URL itself.
• Persistent duplicate or low-difficulty share errors, which generally point to share-validation, firmware, hardware, or configuration issues rather than ordinary network latency.

ViaBTC's support documentation groups network connection, miner temperature, and firmware as the three areas to check when rejection rate is high, which reflects this same separation between routing and non-routing causes.

ViaBTC BTC Regional Connection Details

The table below reflects ViaBTC's currently published BTC connection information from its Mining Pools Information page, updated August 14, 2026. Hostnames and ports can change; verify the current values on ViaBTC's official page before applying them to a miner.

SSL endpoints depend on miner firmware compatibility and do not by themselves lower rejection rate; they are an alternative transport option rather than a routing optimization.

Conclusion

A regional pool URL is a practical way to shorten or stabilize the network path between a mining site and the pool, which can reduce the likelihood of stale or other network-related rejections tied to delayed job delivery or delayed share submission. It is not a universal fix for every rejected share, since persistent duplicate, low-difficulty, and invalid submissions typically trace back to hardware, firmware, configuration, or other non-routing causes. The most reliable approach is to test a regional endpoint where ViaBTC publishes one for the mining site's location, compare it with the currently documented global endpoint, configure the published failover port, and then compare pool-side rejection data over equivalent operating periods before treating the change as an improvement. When rejection rate stays elevated after confirming a stable connection, the next step is to check local network quality, ASIC temperature, firmware, and configuration rather than continuing to change pool URLs.

FAQ

Does connecting to the geographically closest pool server always produce the lowest reject rate?

Not necessarily. Physical distance does not guarantee the best network route; actual latency, jitter, and packet loss along the path from a specific mining site can make a farther server perform better in practice. The endpoint should be verified with observed pool-side rejection data rather than chosen on distance alone.

What does ViaBTC consider a normal rejection rate?

ViaBTC's support documentation states that a rejection rate within 3% falls within its normal operating range. This figure is specific to ViaBTC's service and should not be treated as a general mining-industry standard.

Are all rejected shares caused by network issues?

No. Rejected shares can result from stale work, duplicate submissions, shares that do not meet the assigned difficulty, or invalid submissions linked to firmware, hardware, or configuration problems. Network path mainly affects stale and other network-related rejection risk.

Will switching to an SSL endpoint lower the rejection rate?

Not by itself. SSL endpoints are an alternative transport option that depends on miner firmware support; they are not documented as a method for improving rejection rate or route performance.

How long should a URL comparison test run?

There is no fixed industry duration. The test period should be long enough to reflect normal operating conditions and should be the same length when comparing two endpoints, so the results are based on comparable data.

References

• ViaBTC Help Center, Mining Pools Information
• ViaBTC Help Center, What if the Rejection Rate is High?
• ViaBTC Help Center, BTC Mining
• ViaBTC Blog, Mining Pool Stratum Address Explained
• ViaBTC Blog, How to Configure a Mining Pool Address: Port and Worker Settings
• BitcoinTalk, Stratum protocol documentation