APP
When Does a Mining Farm Need a Stratum Proxy?
2026-11-09 09:10

What Is a Stratum Proxy?

A Stratum proxy is a software intermediary that sits between a farm's ASICs and the mining pool's server. Instead of each miner opening its own Stratum connection directly to the pool, miners connect to the local proxy, which in turn maintains the upstream connection(s) to the pool and forwards work and share submissions in both directions.

In the Stratum V2 specification, a mining proxy is explicitly described as an optional role: it can aggregate downstream connections for efficiency and may provide monitoring or other services to the operation, but nothing in the protocol design requires a farm to run one (Stratum V2 Protocol Overview). That optionality is the correct starting point for any farm evaluating whether to add this layer.

The Short Answer: Deploy One to Solve a Specific Problem

A mining farm does not need a Stratum proxy simply because it runs many ASICs. Direct miner-to-pool connections remain appropriate when the farm has reliable internet connectivity, manageable traffic volume, and correctly configured primary and backup pool entries on each device.

A proxy becomes worth evaluating when direct connections create a measurable operational problem: constrained or expensive bandwidth, difficulty managing pool routing across a large fleet, a protocol mismatch between legacy firmware and a newer pool endpoint, or a need for centralized visibility into connection behavior. The decision should follow from an identified problem, not from a general assumption that larger farms require more infrastructure layers.

Four Situations Where a Proxy May Be Worth Considering

1. Bandwidth-Constrained or Costly WAN Connections

When many ASICs share a limited or expensive wide-area network link — for example, a remote site on cellular or satellite backhaul — each device opening its own persistent Stratum session and submitting shares independently can represent meaningful aggregate traffic. A hashrate aggregation proxy consolidates multiple miners behind fewer upstream connections, which can reduce the volume of farm-to-pool traffic.

Braiins states that its Farm Proxy can reduce data transfers between a farm and a pool by up to 95%, while noting explicitly that the actual reduction depends on the number of miners and the configuration used (Braiins Proxy). This is a vendor-stated maximum for a specific product, not a general industry benchmark, and should be read as such. The relevant question for an operator is not whether aggregation can theoretically help, but whether the farm's current WAN usage and cost actually justify the added software layer.

2. Centralized Pool Routing and Failover

A proxy can serve as the single local endpoint for a group of miners while routing their traffic upstream according to rules configured once, rather than on every device. For a fleet of several hundred or several thousand ASICs, this can reduce the operational effort of changing pool endpoints, adjusting worker settings, or reassigning backup routes.

Braiins' Farm Proxy documentation describes configurable routing levels and recommends setting a backup upstream target in case the primary route becomes unavailable (Braiins Farm Proxy configuration). Centralizing routing in this way reduces per-device configuration work, but it also means the proxy itself becomes a dependency that must be monitored — a point addressed further below.

3. Bridging Stratum V1 and Stratum V2

Some operations run ASIC firmware that only supports Stratum V1 while evaluating a pool endpoint that supports Stratum V2. A translation proxy can, in principle, bridge this gap, but only where the pool, the proxy implementation, and the miner firmware all support the specific configuration required.

This is not yet the default situation across the industry. ViaBTC's currently published Bitcoin mining endpoints use stratum+tcp connection syntax, consistent with Stratum V1, and the pool has noted that adoption of Stratum V2 across the industry remains uneven. A farm considering a V1-to-V2 translation proxy should treat it as a staged migration project with its own compatibility testing, not as something a proxy enables automatically.

4. Advanced Stratum V2 Architectures, Including Job Declaration

Stratum V2 separates several roles, and a mining proxy is only one of them. Functions such as Job Declaration — which relates to a miner or pool's ability to influence block template construction — belong to a distinct part of the protocol involving additional components, including a Job Declarator and, depending on the architecture, a Template Provider (Stratum V2 Protocol Overview). Installing an ordinary mining proxy does not, by itself, give a farm transaction-selection capability. Operators interested in this functionality should evaluate it as a separate, more involved deployment rather than assuming it is a byproduct of adding any proxy.

When Direct ASIC-to-Pool Connections Are Sufficient

For many farms, the simplest solution is also the correct one: each ASIC connects directly to the pool with a valid primary endpoint and one or more backup entries configured in firmware. ViaBTC, for example, documents a primary BTC endpoint and a separate failover port in its mining setup guide, allowing a miner to fall back to an alternative connection point if the primary one becomes unreachable (ViaBTC BTC Mining Setup).

Where a farm's connectivity is reliable, its traffic volume is unremarkable for its link capacity, and basic backup entries are correctly set on each device, adding a proxy introduces operational complexity without addressing an existing problem. The appropriate test is whether direct connections are currently failing to meet a specific, identifiable need — not whether a proxy is theoretically capable of adding value.

What a Proxy Does Not Fix

A Stratum proxy operates at the level of network communication between miners and the pool. It does not alter the ASIC's hashing silicon, and it cannot compensate for conditions originating in the hardware itself. Specifically, a proxy does not increase:

  • the device's local hashrate as reported by its own firmware;
  • hardware efficiency measured in J/TH;
  • the physical condition of hashboards, power supplies, fans, or network interface hardware.

If a farm's underlying issue is degraded chips, thermal throttling, an unstable power supply, or a failing switch, a proxy will not resolve it, because the fault exists upstream of where the proxy intervenes. Persistent discrepancies between a device's local hashrate reading and the pool's hashrate estimate should be investigated using matching, sufficiently long observation windows, along with rejected-share data and firmware/hardware diagnostics — not assumed to be a connectivity problem solvable by adding a proxy.

Evaluating the Need: A Measurement Checklist

Before deploying a proxy, an operator can gather a small set of concrete measurements to confirm whether a real problem exists:

  • WAN traffic volume and cost between the farm and the pool over a representative period, to establish whether a reduction would have practical value.
  • Number of concurrent pool connections relative to the number of active miners, to see whether the WAN edge or the pool's connection handling is under pressure.
  • Connection stability, including reconnects, timeouts, DNS failures, and failover events, to determine whether centralized routing or additional endpoints would help.
  • Rejected-share patterns, with stale, invalid, and duplicate shares identified as distinct subcategories under the broader category of rejected shares, so that the actual cause of any elevated rejection rate can be diagnosed rather than assumed.
  • Firmware and protocol compatibility across the fleet, confirming which ASICs support Stratum V1 only and which pool endpoints are available, before considering any V1-to-V2 translation.
  • Configuration burden, meaning how often pool endpoints, worker names, or backup routes must be changed across the fleet, which indicates whether centralized routing would meaningfully reduce operational effort.

These measurements point toward whether the relevant problem is bandwidth, routing complexity, protocol compatibility, or something unrelated to connectivity altogether — such as hardware condition.

Deployment Considerations and Risks

Introducing a proxy changes the farm's architecture, and that change carries its own trade-offs that should be weighed against the problem it is meant to solve.

First, a proxy becomes an additional point of failure: if it goes offline, every miner routed through it may lose its connection simultaneously, rather than failures being isolated to individual devices. For this reason, retaining a backup pool configuration directly on the ASIC — separate from the proxy — is a reasonable precaution some proxy vendors themselves recommend (Braiins Farm Proxy configuration).

Second, running proxy software adds ongoing operational work: deployment, version updates, log review, and configuration management all require attention that a direct-connection setup does not.

Third, pools differ in supported protocol versions, endpoint formats, and routing behavior, so a proxy configuration validated against one pool cannot be assumed to work identically against another without testing.

Fourth, on the security side, Stratum V2 specifies authenticated encryption for connections to a remote upstream server, while the connection between local mining devices and a local proxy may use a lighter, optional handshake arrangement (Stratum V2 Protocol Security). A proxy can therefore improve the security posture of the farm-to-pool link under Stratum V2, but it does not automatically make an otherwise unprotected Stratum V1 deployment secure, and the farm's local network security still matters independently of the proxy.

Conclusion

The decision to deploy a Stratum proxy should be driven by a specific, demonstrated operational need rather than by fleet size alone. Bandwidth constraints, the administrative burden of managing pool routing across many devices, a planned migration from Stratum V1 to V2, or a requirement for advanced V2 functionality are all legitimate reasons to evaluate a proxy. Where none of these conditions apply, correctly configured direct connections with valid backup pool entries remain a simpler and often sufficient choice. In every case, a proxy addresses the communication layer between miners and the pool — it is not a substitute for diagnosing hardware faults, firmware issues, or local network problems.

FAQ

Does adding a Stratum proxy increase a farm's hashrate?

No. A proxy manages connections and share routing between miners and the pool; it has no effect on the ASIC's hashing silicon, local hashrate, or J/TH efficiency.

Can a proxy fix a high rejected-share rate?

Only if the cause is connectivity-related, such as unstable routing or excessive latency to the pool. Stale, invalid, and duplicate shares are distinct subcategories of rejected shares and should be diagnosed individually before assuming a proxy is the solution.

Is a proxy required to use Stratum V2?

No. Many pools and ASICs connect to V2 endpoints directly where supported. A proxy becomes relevant mainly when bridging V1-only firmware to a V2 upstream, or when aggregating many V2-capable devices.

Does installing a proxy give a farm control over block templates?

No. That capability belongs to Stratum V2's separate Job Declaration functionality, which requires additional components beyond a standard mining proxy and corresponding pool support.

What is the main risk of deploying a proxy?

It introduces a single point of failure: if the proxy becomes unavailable, all miners routed through it can lose their pool connection at once, which is why retaining a backup pool configuration directly on the ASIC is a reasonable precaution.

References

Prev
ASIC Hardware Errors vs. Rejected Shares: Which Problem Are You Actually Seeing?
Next
How to Detect Hot-Air Recirculation in an ASIC Mining Room