# XMRig Proxy: a Stratum front end for fleets of Monero miners > XMRig Proxy is a GPL-3.0 C++ program that sits between many short-lived miners and a single CryptoNote pool connection, cutting pool side connections from 100,000 workers down to 391. It is built for operators running their own rigs, and it carries a donation fee and a file descriptor ceiling you have to plan around. **xmrig/xmrig-proxy** — Monero (XMR) Stratum protocol proxy - Repository: https://github.com/xmrig/xmrig-proxy - Website: https://xmrig.com/proxy - Stars: 719 · Forks: 383 - Language: C++ - License: GPL-3.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/xmrig-xmrig-proxy ## Built for donation traffic, not for shared mining pools XMRig Proxy solves a narrow problem that shared mining infrastructure creates. A pool operator who wants to run a donation campaign for the XMRig miner faces a specific shape of load: thousands of miners that connect, mine briefly and disconnect again, often every few seconds. Each one of those miners wants its own connection to the pool, and the pool pays that cost in sockets, memory and rate limiting. The project documentation states the intent directly, describing the proxy as designed to handle donation traffic from XMRig, where no other solution works well with high connection and disconnection rates. The mechanism is connection reuse. The proxy accepts connections from miners on a local address, keeps them warm, and multiplexes the work coming from them onto far fewer connections toward the pool. The project documentation puts a number on the effect, saying the proxy reduces the number of connections to the pool, decreasing 100,000 workers down to just 391 on the pool side, and claims it can manage over 100K connections on an inexpensive low-memory virtual machine with just 1024 MB of RAM. Those are the project authors figures rather than measurements from an independent test, but the design follows directly from what the tool does. The audience is therefore an operator of many machines under their own control, which is a different person from someone renting hash power. The primary language is C++, the licence is GPL-3.0, the default branch is master and the homepage is xmrig.com/proxy. Topic tags name Monero, XMR, Stratum, RandomX, CryptoNight and Aeon, and the project states that the proxy is compatible with any pool and any miner that supports NiceHash, which is the dialect constraint that decides whether it fits your setup. ## The codebase is shared with the XMRig miner The top-level layout is compact: .gitignore, CHANGELOG.md, CMakeLists.txt, LICENSE, README.md and the directories cmake, doc, res and src. There is no vendored dependency tree of note, no web frontend and no bundled database. The build is driven by CMake, and the project documents its own build instructions on a separate page at xmrig.com/docs/proxy rather than in the repository. The important architectural note is that the project documentation says the codebase is shared with the XMRig miner. That is why the option list carries flags which look out of place for a proxy, such as --algo=ALGO, --coin=COIN, --user=USERNAME and --pass=PASSWORD for talking to a mining server, and the --daemon family of options for solo mining against a node. Those options exist in the binary because the shared source tree is compiled wholesale, not because a proxy needs to select a mining algorithm. A reader looking at --algo=ALGO will find it has no meaningful effect on the proxy's job of relaying Stratum jobs. The same reuse explains the stray mining-oriented settings such as --custom-diff=N, --custom-diff-stats and --no-workers. The first overrides the difficulty the pool hands out, the second changes which shares the proxy counts for its statistics, and the third turns off per worker accounting so that a high churn fleet does not pay for tracking state it will never use. For a donation traffic workload, that switch is the difference between a proxy that keeps a ledger of thousands of ephemeral workers and one that does not. ## First run: bind a local port, point it at a pool, and check the configuration There is no package manager entry here. Binary releases are published on the GitHub releases page for xmrig/xmrig-proxy, and the source is cloned from the repository with the git clone command given in the project documentation, after which the project sends you to xmrig.com/docs/proxy for build instructions. The download options and the network options that matter for a first deployment look like this: ```bash -b, --bind=ADDR bind to specified address, example "0.0.0.0:3333" -m, --mode=MODE proxy mode, nicehash (default) or simple --custom-diff=N override pool diff --custom-diff-stats calculate stats using custom diff shares instead of pool shares --reuse-timeout=N timeout in seconds for reuse pool connections in simple mode --no-workers disable per worker statistics --access-password=P set password to restrict connections to the proxy --no-algo-ext disable "algo" protocol extension ``` The first run should be small and reversible. Start the proxy bound to a loopback address, point it at a pool with --url, and let the miners reach it. The --access-password=P option restricts who can connect to the proxy at all, which matters more than it first appears: a proxy with no access password is a public relay that anyone on the network can use to borrow your pool connection. The --dry-run option tests the configuration and exits, which is the cheapest way to catch a malformed --url or a bad --config file before a live fleet starts reconnecting. The Misc group also holds -c, --config=FILE for a JSON-format configuration file, -B, --background to run detached, and -l, --log-file=FILE plus -A, --access-log-file=FILE for logging. On a proxy that sees constant reconnects, the access log is the instrument that tells you whether a spike is new miners arriving or old miners failing to reconnect. ## Linux file descriptor limits are the first wall you hit The project documentation flags this with emphasis: if you are using Linux and need to manage over 1000 connections, you must increase the limits on open files, with a pointer to an Ubuntu setup page in the project wiki. This is the single most common operational surprise with a tool like this, and it is a hard failure rather than a slow degradation. A proxy that accepts miners until it hits the process limit stops accepting, and the symptom arrives as miners reporting connection refused or hanging, not as a clear error in the proxy log. The relationship between the limit and the workload is direct. Every inbound miner connection is at least one file descriptor in the proxy process, and the pool side connections add to that count, plus the listening socket, log files and whatever else the process has open. The default soft limit on many Linux distributions is well below what a large fleet needs, which is exactly why the project links to a dedicated setup page rather than assuming a sane default. Two related limits are worth planning for as well. The --reuse-timeout=N option controls how long a pool connection may be reused in simple mode, so a pool that drops idle connections will produce reconnect churn that looks like miner churn unless you tune it. And the --http-no-restricted option, discussed below, can widen the HTTP API from localhost to anywhere on the network, which adds exposure on a host that is holding thousands of open sockets. ## Nicehash mode by default, simple mode when the pool is a plain Stratum server The --mode=MODE switch selects between nicehash, which the option list marks as the default, and simple. The two differ in how the proxy speaks to the pool on the upstream side. Nicehash mode exists because the tool has to interoperate with the widest possible set of pools and miners, and the project states compatibility with any pool and any miner that supports NiceHash. Simple mode is the alternative for deployments where the pool side is under your control and you want a plain Stratum exchange with the --reuse-timeout=N behaviour applied. This is the main design trade-off in the project and it is worth being explicit about. The nicehash dialect adds protocol compatibility at the cost of some protocol expressiveness, and the --no-algo-ext option exists to disable the algo protocol extension when a particular pool or miner misbehaves with it. Operators who have spent time on pool compatibility debugging tend to know that the algorithm and share reporting details are where mismatches appear, and the option list gives levers for the common ones. Upstream resilience is handled separately. The -r, --retries=N option sets how many times to retry before switching to a backup server, with a default of 5, and -R, --retry-pause=N sets the pause between retries with a default of 5 seconds. The --rig-id=ID and --keepalive options are marked as needing pool support, which is a good indication of the division of responsibility: the proxy can keep a connection warm, but only the pool can honour a keepalive packet or attribute statistics to a rig identifier. The TLS options on the pool side complete the picture. --tls enables SSL/TLS support and is also marked as needing pool support, while --tls-fingerprint=HEX provides a pool TLS certificate fingerprint for strict certificate pinning, which turns a trusted certificate chain into a hard check against a known fingerprint. For a proxy that sits between many machines and one pool account, that pinning is a meaningful defence against interception, at the cost of breaking when the pool rotates its certificate. ## The HTTP API binds to localhost unless you deliberately open it Monitoring a high churn proxy is awkward without an API, and XMRig Proxy exposes one over HTTP. The option list shows the default bind host as 127.0.0.1, with --http-port=N to set the port, --http-access-token=T to set an access token and --http-no-restricted to enable full remote access, which the help text notes is only safe if an access token is set. That last caveat is the important part. The proxy already has a --access-password=P for inbound miner connections, and the API has a separate token. Binding the API to 127.0.0.1 and scraping it from a local agent is the conservative arrangement, and the restricted mode exists precisely so that the default is safe. A deployment that sets --http-no-restricted without an access token is exposing a control surface for the mining fleet to anyone who can reach the port, on a machine that by design holds a large number of open connections. Other API-level knobs include --api-worker-id=ID and --api-id=ID, which set custom identifiers used by the API, and --no-workers, which disables per worker statistics entirely. On a proxy handling a hundred thousand ephemeral workers, per worker statistics are the expensive part, and being able to switch them off is a deliberate performance choice rather than a debug switch. ## Solo mining through a daemon is the built-in alternative to proxying The alternative to running a proxy is not another project. It is the --daemon option set already in the binary. The --daemon flag uses the daemon RPC instead of the pool for solo mining, and it comes with --daemon-zmq-port for a daemon with ZeroMQ publishing enabled, --daemon-poll-interval=N with a default of 1000 milliseconds and --daemon-job-timeout=N with a default of 15000 milliseconds. The --self-select=URL and --submit-to-origin options extend the same path, pulling block templates from a URL and optionally submitting the solution back to that URL. The difference in approach is fundamental. A pool proxy aggregates many miners onto a shared pool account, and its value comes from connection efficiency and from central policy, such as the ability to set a custom difficulty or to turn per worker statistics off. The daemon path removes the pool from the picture entirely, so each miner talks to a node, and the point of the proxy becomes connection fan-in rather than fan-out. The single --daemon flag exists in the binary even though a proxy instance normally exists to serve many miners at once. For a single home rig the proxy has nothing to add, since the pool connection count is already one. For an operator with a donation fleet, the connection collapsing is the whole justification, and the project's own framing, that the proxy is designed to handle donation traffic from XMRig, is the most honest description of when to reach for it. ## Maintenance pace, donation fee and what the documentation leaves out The repository is not archived and the last push was on 2026-10-06. The most recent tagged release is v6.26.0, published on 2026-03-28, ahead of v6.24.0 from 2025-06-23 and v6.23.0 from 2025-06-16. The gap between the newest tag and the newest push is around six months, which is the normal shape for a project that ships infrequent point releases rather than continuous ones. A CHANGELOG.md is present at the top level, and it is the place to look before upgrading, since the option list changes between major versions. The donation fee is part of the operating cost and is stated plainly. The default donation fee is 2 percent, and it can be reduced to 1 percent or completely disabled using the donate-level option, with the --donate-level=N option list entry showing a default of 0. The project documentation is specific that this fee applies only when you utilize more than 256 miners, so a small deployment is unaffected. Anything above that threshold should decide which level to run before the fleet is live, since changing it later means restarting a process that thousands of miners are cycling through. The documentation gaps are real and worth stating. The project documentation does not document a rollback procedure for a failed upgrade, does not state which pool dialects are tested against which release, and does not give guidance on what happens to in-flight Stratum jobs when the proxy is restarted. It also does not explain the on-disk state, if any, that survives a restart, which matters for a tool whose whole purpose is to keep connections warm. The build instructions live on xmrig.com/docs/proxy rather than in the repository, so the source tree and the documentation can drift apart independently. ## Conclusion XMRig Proxy is worth deploying when you own the mining hardware and the churn is the problem, since the connection collapsing is the entire reason the tool exists. It is the wrong choice for a single home rig, where a pool connection costs nothing, and for anyone unwilling to accept a default 2 percent donation fee, which can be lowered with donate-level but only applies above 256 miners. Verify the upstream limit on your VM, confirm that the pool speaks the NiceHash compatible dialect the project requires, and read the release notes before upgrading, because the last push was on 2026-10-06 while the newest tagged build is v6.26.0 from 2026-03-28. ## FAQ ### What does XMRig Proxy actually do for a mining operation? It accepts connections from many miners and multiplexes them onto a much smaller number of pool connections. The project documentation states that 100,000 workers can be reduced to 391 connections on the pool side, and that over 100K connections can be managed on a virtual machine with 1024 MB of RAM. ### How do I install and run XMRig Proxy on Linux? Binary releases are published on the GitHub releases page for xmrig/xmrig-proxy, and the source is cloned from the repository with the git clone command given in the project documentation, with build instructions hosted at xmrig.com/docs/proxy. On Linux, the project documentation states that managing over 1000 connections requires increasing the limit on open files, with a setup page in the project wiki. ### Does XMRig Proxy have a usage fee or donation level? The default donation fee is 2 percent, which can be reduced to 1 percent or disabled through the donate-level option, set with --donate-level=N. The project documentation states that the fee applies only when you use more than 256 miners. ### How is the XMRig Proxy HTTP API secured? The API binds to 127.0.0.1 by default, with --http-port=N to set the port and --http-access-token=T to set an access token. The --http-no-restricted option enables full remote access, and the option help notes that it is only safe if an access token is set. ### Can XMRig Proxy mine solo without a pool? Yes. The --daemon option uses the daemon RPC instead of the pool for solo mining, with --daemon-poll-interval=N defaulting to 1000 milliseconds and --daemon-job-timeout=N to 15000 milliseconds. The --self-select=URL and --submit-to-origin options cover self-selected block templates. ## Sources - [License: GPL-3.0](https://github.com/xmrig/xmrig-proxy/blob/master/LICENSE) - [Project website](https://xmrig.com/proxy) - [README](https://github.com/xmrig/xmrig-proxy/blob/master/README.md) - [Releases](https://github.com/xmrig/xmrig-proxy/releases) - [xmrig/xmrig-proxy on GitHub](https://github.com/xmrig/xmrig-proxy) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xmrig-xmrig-proxy