XMRig Proxy
A short, practical overview of the stratum proxy that sits between many miners and a pool — what problem it solves, when a Windows user needs one, and when they do not.
The problem it solves
Every miner normally holds its own connection to the pool. With a handful of machines that is fine. With dozens or hundreds, the pool sees hundreds of low-difficulty workers, each generating its own job traffic and share submissions. XMRig Proxy collapses that into a small number of connections: miners talk to the proxy on your own network, the proxy talks to the pool.
What changes when you use it
- The pool sees a few high-difficulty workers instead of many small ones, which reduces overhead on both sides.
- Pool credentials and failover live in one place instead of on every machine.
- You get a single local view of which rigs are connected and submitting.
- The proxy becomes a dependency: if it stops, the miners behind it stop too.
Do you need one?
If you run one desktop, no. The proxy adds a component without adding hashrate. It starts to make sense somewhere around a dozen machines, or earlier if your pool charges for connection count or your network egress is constrained. For a single Windows PC, point the miner straight at the pool as described on the configuration page.
How it is configured
The proxy uses the same JSON style as the miner: an upstream pools block for the real pool, a bind block for the address and port your miners connect to, and optional TLS on either side. Miners are then configured with the proxy's address in place of the pool's. It runs on Windows as well as Linux, though most operators host it on an always-on Linux box.
Proxy questions
Does the proxy mine?
No. It forwards work; all hashing happens on the miners behind it.
Does it increase hashrate?
No. It reduces connection and traffic overhead for large deployments.
Where is it published?
In the same organisation as the miner; see the repository overview.