Stratum Ports and Proxies: Connecting Large Rigs Properly
Stratum is a request-and-response protocol: a miner authenticates with a worker string, receives a job, and submits shares that beat a pool-assigned target — and at farm scale the way you open those connections decides your stale rate and your recovery time. A 5 PH/s site produces about 0.00224303 BTC a day, $189.97 gross at a BTC price of $84,692, which is $7.92 of gross output per hour; two minutes of extra downtime after every network blip is a real line in the budget.
Key takeaways
- Connect rigs to the port that matches the chain and the hashrate class you are running; a wrong port accepts the session and then wastes shares.
- One proxy serving hundreds of rigs turns hundreds of upstream sessions into a handful, which cuts reconnect storms and makes failover something you configure once.
- At 5 PH/s, an extra 4.5 minutes of downtime after every disruption costs about 0.00000701 BTC, roughly $0.59, per event.
- Two percentage points of rejections, from 3% to 1%, is worth about $3.65 net a day at 5 PH/s, from a configuration change that costs nothing to make.
The core idea
A miner's relationship with a pool is one long-lived TCP connection carrying small messages. The pool sends work; the miner answers with shares or with nothing. Because the messages are tiny and the connection idles between jobs, the failure modes are not about bandwidth at all — they are about latency, session count and connection hygiene.
Two configuration choices follow. The port tells the pool which chain and which share difficulty a connection is claiming, and there is normally more than one for a given chain so a slow rig and a fast rig do not share a target. The topology decides whether each machine opens its own upstream session or hands its shares to a local proxy that multiplexes them into a few connections.
Port configuration is easy to get wrong. Pools publish ports per algorithm, and setup guidance for each supported chain exists exactly because a mismatched port produces a session that looks healthy while every share comes back rejected.[1] The pool's fee model assumes it is being paid on valid delivered work, so rejected shares are not billed at all — they simply evaporate.[2]
How it plays out at scale
Below twenty machines, direct connections are fine: session counts are trivial, and each rig failing independently is a feature rather than a problem. Above a few hundred, the arithmetic inverts. Every rig holds state, retries on its own schedule, and occupies its own NAT entry, so when a link flaps they all reconnect at once against the same pool node.
A proxy collapses that into one or two upstream sessions, each holding a job stream that it fans out locally. Rigs talk to a device on the same LAN, so latency drops to a millisecond or two, and the proxy can hold the last known job through a brief internet outage instead of letting every machine restart its session. It also becomes the one place where difficulty, failover targets and worker naming are configured.
| Topology | Upstream sessions for 400 rigs | Latency path | Best suited to |
|---|---|---|---|
| Direct per rig | 400 | Rig to pool node | Small farms, simple operations, maximum blast-radius isolation |
| Local proxy per row or hall | 2–8 | Rig to proxy to pool | Anything above a few hundred rigs on one site |
| Pool-side or hosted proxy | 1–2 | Rig to proxy to pool, proxy far from rigs | Sites with poor local hardware but good upstream links |
Latency matters most at the first hop and least at the last. Moving a proxy closer to the rigs reduces the time a share spends in flight after a job changes, which is where stale shares come from; the remaining distance to the pool is a fixed cost that a good proxy hides from the machine. What a proxy cannot fix is a pool node on the other side of the planet.
Two scenarios compared
Both scenarios start at 5 PH/s, which at current difficulty and network hashrate is 0.00224303 BTC and $189.97 of gross revenue per day — $7.92 an hour, $0.13 a minute.
Scenario A, direct connections to a remote node. Four hundred rigs each hold their own session at roughly 180 ms of round-trip latency. Stale shares run around 3% because jobs change while shares are in flight. When the internet link blips for thirty seconds, all four hundred sessions drop and reconnect on their own timers; restoring full hashrate takes about six minutes because of staggered reconnect backoff. Cost of the blip: about 0.00000935 BTC, roughly 79 cents, plus the ongoing 3% stale leak of 0.00006729 BTC — $5.70 — per day.
Scenario B, two local proxies. Rigs talk to a proxy 2 ms away, and the proxy holds two upstream sessions on a 120 ms path. Stale shares fall to around 1% because the window between job issue and share arrival is shorter. The same thirty-second blip lets the proxy hold the last job; hashrate recovers in about ninety seconds. Ongoing cost of the remaining 1% leak: 0.00002243 BTC, about $1.90, per day.
The difference between the two steady states is 0.00004486 BTC a day, about $3.80 gross and $3.65 net — and the recovery difference across a handful of monthly blips is worth a few more dollars. Neither number is dramatic, and both improve for free once a proxy is in place.
A 1 TH/s machine needs about 22,291 days for 0.01 BTC, while a 1 PH/s farm needs 22.3 days. When a site is big enough that the same percentage of lost hashrate is measured in whole days of production, connection hygiene stops being an infrastructure detail and becomes a revenue line.
Common failure modes
- Wrong port for the chain or the hashrate class. The session stays up, the dashboard shows a live worker, and shares are rejected. Confirm the port against the setup guide for the chain you are actually mining.
- Difficulty set too low for a fast rig. The rig floods the pool with submissions and the surplus comes back as duplicates. Move it to a port intended for its hashrate.
- Idle sessions dropped by a firewall. Stratum is quiet between jobs, so devices with aggressive connection timeouts close healthy sessions. Enable TCP keepalive on the proxy and check how often your NAT table expires entries.
- A proxy without redundancy. The device that reduced your session count is now a single point of failure. Two proxies with the same upstream configuration, or a proxy with a fallback target, avoids trading one outage for a worse one.
- Failover configuration that creates duplicate workers. If primary and backup templates use different worker strings, the pool sees two workers and your per-machine history splits in half.
- Reconnect storms. Rigs configured to retry immediately all return at once after an outage. Staggered backoff is one line of configuration and prevents a second outage caused by the recovery itself.
- Counting the wrong hashrate. After any change, verify against the pool's published mining statistics rather than trusting the local proxy's own tally, then confirm delivered output with the income calculator.
The pool-side view is worth one bookmark: the ViaBTC BTC Mining Pool state page publishes pool hashrate alongside network totals, which is the quickest way to tell a local connection problem from a general network shift.
Frequently asked questions
Is a bigger pool always better?
Size reduces payout variance but also concentrates hashrate. What matters more is fee structure, uptime, latency and payout cadence. For a large rig the latency half of that list is not abstract: it determines how many shares go stale before the job they belong to is replaced.
What happens if my miner goes offline?
Shares stop, so expected income stops with them. Alerts and a dashboard that shows per-worker hashrate shorten the gap between a failure and a fix. With a proxy in place, the same alert tells you whether one rig dropped or the upstream path did.
Do I need TLS on stratum connections?
It is a good default for anything crossing a public network, since the worker string and pool credentials travel in the session. The cost is a small amount of handshake time at connect, which is irrelevant for a session that stays open for weeks but noticeable when hundreds of rigs reconnect simultaneously.
Configure once, monitor the simple numbers
Pick the port that matches your chain and rig speed, put a redundant proxy in front of anything larger than a few dozen machines, and set staggered reconnect timers before you need them. Then track three numbers weekly: stale and rejected share rate, reconnect count, and pool-reported hashrate against the sum of your rigs. Everything else about a large rig's network configuration is commentary.
Data and sources: ViaBTC mining guides for supported chains[1], ViaBTC fee schedule and payout methods[2], ViaBTC earnings calculator[3]. Network difficulty 132.76 T, network hashrate, the 3.125 BTC block subsidy, 144 blocks per day and a BTC price of $84,692 were read from public chain data and market feeds on 21 September 2026. Latency and stale-rate figures are illustrative examples, not measurements of any specific site.