# FXMinerProxy: a Go mining pool relay with a built-in developer fee

> FXMinerProxy is an MIT-licensed Go proxy that sits between miners and a pool, supports around thirty proof-of-work coins, and ships with a configurable developer fee plus a DNS hijack deployment option. Here is what the repository actually documents, and where it stops.

**FxPool/FXMinerProxy** — 🔥minerproxy,minerproxy,minerproxy,minerproxy,minerproxy,minerproxy,minerproxy,minerproxy,minerproxy,minerproxy,矿池抽水,矿池中转,矿场运维专用

- Repository: https://github.com/FxPool/FXMinerProxy
- Website: http://www.fxminerproxy.com
- Stars: 3,708 · Forks: 505
- Language: Go
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/fxpool-fxminerproxy

## What FXMinerProxy sits between, and why that position matters

A mining rig normally talks straight to a pool. FXMinerProxy inserts a Go process in the middle: the rig connects to the proxy, the proxy connects to the pool, and every share and job travels through it. The README describes the project as a pool relay and fee-collecting proxy, and lists the coins it handles: BTC, LTC, ZEC, ETC, ETHF, ETHW, RVN, CFX, BEAM, ERGO, BTG, AE, FLUX, FIRO, NEOXA, XMR, KASPA, GRIN, KDA, DASH, CKB, RXD, ZIL, the ETHW_ZIL, ETHF_ZIL and ETC_ZIL merged-mining pairs, ZEN, NEXA, HNS, BCH and IRON. The list ends with a note that more coins exist than are shown and that you should install the software to see the full set.

The audience is narrow and stated plainly. This is not a tool for a hobbyist with one ASIC. The README's own deployment table starts at n<200 miners and runs to n>10000, and one screenshot caption claims a 6000+ BTC farm running for a long period. The Chinese subtitle calls it software for mine-farm operations. If you are not running a fleet, the per-miner overhead of 100K to 150K of memory, as the README estimates it, buys you nothing you could not get from pointing the rigs at the pool directly.

The reason the position matters is that a relay sees everything. It can rewrite the destination, and the README says as much: a section titled DNS hijack scheme offers to build a transparent redirection setup for operators who have router access at a mine. That is the same capability that makes the tool useful for a farm owner and makes it a detection problem for a pool.

## How the relay, the fee, and the panel fit together

The repository gives no architecture document, so the mechanism has to be read off the layout and the README. The top-level tree contains install.sh, custominstall.sh, new_install.sh, new_install2.sh, install_en.sh, install_zh.sh and install_zh_cdn1.sh, a ui/ directory, a mobileapp/ directory, an ssh/ directory, a netconfig/ directory, and a prebuilt fxminerproxyv3linux.tar.gz. The README shows a web panel with a home screen and a real-time log view, and links a YouTube walkthrough plus a separate video on tunnel encryption.

The fee model is the part worth reading twice. The README lists a development fee of 0.2 percent for all coins, 0 percent for individuals, and then an activated tier that requires more than 200 miners: 0.18 percent between 200 and 1000, 0.15 percent between 1000 and 5000, 0.1 percent between 5000 and 10000, and 0.05 percent above 10000. Two things are left unexplained. First, what activation means and who performs it. Second, how the fee is actually collected at the protocol level. The README does not describe the share accounting that would let a reader verify that 0.2 percent is what is being taken. For a tool whose central function is redirecting a fraction of hashrate, that silence is the most important gap in the documentation.

The panel is the operational surface: it is where you would look at connected miners and live logs. The README does not document an API, a config file format, or where state is persisted, so anything beyond the UI has to be discovered by running it.

## Installing FXMinerProxy on Linux with install.sh

The README specifies root permissions, CentOS 7+, Debian 8+ or Ubuntu 16+, and recommends Debian. It also requires curl and wget, with the Debian and Ubuntu package commands given. Install those first if the base image is minimal:

```bash
apt-get install curl
apt-get install wget
```

The current version installs with a single piped script. The README gives this exact command:

```bash
bash <(curl -s -L https://raw.githubusercontent.com/FxPool/FXMinerProxy/main/install.sh)
```

To pin a specific version instead of taking the latest, the README shows the same script with a version argument appended:

```bash
bash <(curl -s -L https://raw.githubusercontent.com/FxPool/FXMinerProxy/main/install.sh) 版本号
```

The placeholder is literally the Chinese word for version number in the README, so you substitute a tag from the releases page, for example v15.9.5@260716. After the script finishes, the README points you at a web panel for the first real use: the home screen lists connected miners and the real-time log view shows share traffic. The README does not state the panel's port, its default credentials, or whether the first login is randomized, though one image in the repository is named randlogin.png, which suggests a generated password is involved. Treat that as unconfirmed and check the panel output on first boot.

There are several other installer scripts in the tree, including a CDN variant and a custom one, but the README only documents install.sh.

## Running it on Windows, and the run.exe constraint

The Windows path is simpler and more restrictive. The README requires administrator rights and Windows 8 or later, and recommends Windows Server 2012. Installation is manual: download the release archive, extract it, open the fxminerproxyv3 folder, and run run.exe.

The README adds a specific instruction that is easy to skim past: run.exe is the only executable you should launch, because doing so is what keeps the program from crashing. There is no explanation of what the other binaries in the folder do or what happens if you start one. That is a real operational constraint. If you manage Windows hosts with a scheduler or a service wrapper, you need to point it at run.exe and nothing else, and the README gives no guidance on registering it as a service.

The download table lists the latest archive as fxminerproxyv3.zip and older builds on the GitHub releases page. The README does not publish checksums for either the Windows archive or the Linux tarball, so there is no documented way to verify that a downloaded binary matches what the maintainers built.

## Where FXMinerProxy is the wrong tool

The clearest limitation is that the repository ships prebuilt binaries. The primary language is Go, and the licence is MIT, but the top-level tree contains fxminerproxyv3linux.tar.gz and the Windows release is a zip, with the README pointing users at downloads rather than a build command. An MIT licence on a repository that does not include the source for the artifact you run gives you the licence text and nothing to compile. If your environment requires that you build from source, or that a third party can audit the exact binary in production, this project does not meet that bar as published.

The second limitation is the DNS hijack scheme. It is offered as a service, not as a feature you configure: the README says to contact the maintainers if you are an operator or have router permissions at a mine, and they will build the transparent redirection for you. That is a dependency on a third party for a capability that touches every rig on the network. It also means the deployment is not reproducible from the repository alone.

The third is jurisdictional. The disclaimer states that users must not be residents of mainland China, Cuba, Iran, North Korea, Syria, Russia, or other sanctioned countries and regions, and that the user bears the legal responsibility. That is the project's own text, not a legal analysis, and it is worth reading in full before you decide anything.

Finally, the documentation is thin in exactly the places an operator needs it: no rollback procedure, no uninstall instructions, no documented config keys, no panel port, and no explanation of activation. The README does not document rollback.

## Alternatives, and the difference that actually matters

The obvious alternative is to skip the relay entirely and point miners at the pool. That removes the extra hop, the per-miner memory cost, the panel, and the fee, and it removes the single process that all your hashrate depends on. For a farm that only wants to consolidate connections to one stratum endpoint, a plain TCP forwarder or a load balancer in front of the pool does the same job with a smaller surface and no fee logic.

The more interesting comparison is with pool-side accounting. Pools already measure accepted shares per worker and pay out against them. A relay that takes a percentage works by presenting work to the pool under identities the pool cannot distinguish from ordinary miners, which is why the DNS hijack option exists: the redirection is invisible at the rig. The difference in approach is therefore not about protocol efficiency, it is about who controls the accounting. With pool-side accounting, the pool holds the ledger and the operator sees the same numbers the pool does. With a relay, the operator holds a second ledger and the pool sees only the aggregate. If you are the pool, a relay is a counterparty you cannot audit from your side.

There is also a versioning difference worth noting. The README links a Chinese tutorial site and two YouTube videos, and the release cadence visible in the repository is roughly monthly, with v15.9.0@260507, v15.9.1@260516 and v15.9.5@260716 between May and July 2026. Documentation lives in the README and readmes/ rather than a versioned manual, so the instructions track the latest release rather than the one you installed.

## Licence, fee, and what maintenance actually costs you

The licence is MIT and the README carries an MIT badge. MIT permits commercial use and modification, and requires that the copyright notice and permission notice be preserved. It provides no warranty. None of that tells you whether the binaries you download are covered by the same terms, because the repository does not publish the source for the release archives. If licence compliance matters to your organisation, that distinction is the one to resolve first. This is a description of the licence text, not legal advice.

The real recurring cost is the developer fee, not the licence. At the default 0.2 percent across all coins, a 1000-miner operation running at the activated 0.18 percent tier is handing over a share of output continuously. The README does not explain how to verify the collected amount, so the practical cost of adoption includes building your own comparison between what the miners report and what the pool credits. The tier thresholds also mean the fee changes as your fleet grows, which is a planning input rather than a fixed cost.

On maintenance, the last push to the repository was on 2026-07-15, and the most recent release is v15.9.5@260716 from the same day. The project is not archived. The upgrade path documented is the install script with a version argument, and there is no documented migration or rollback step if a new version misbehaves, which is the gap to plan around: keep the previous Linux tarball or Windows zip before you run an upgrade.

## Conclusion

Adopt FXMinerProxy only if you operate the miners yourself and are comfortable with a closed-source distribution that takes a 0.2 percent developer fee by default, with published reductions to 0.18, 0.15, 0.1 and 0.05 percent as the activated miner count crosses 200, 1000, 5000 and 10000. Do not adopt it if you need to audit the code you run, if you are in a jurisdiction where the disclaimer's territorial restrictions apply to you, or if you are a pool operator trying to detect redirected hashrate. Before deploying, verify three things: that the release archive you download matches the release tag, that the fee percentage shown in the panel matches the tier you expect, and that your host has the curl and wget tools the installer assumes.

## FAQ

### How do I install FXMinerProxy on Linux?

The README specifies root permissions on CentOS 7+, Debian 8+ or Ubuntu 16+, with Debian recommended, and requires curl and wget. The install command is a piped script from the repository's install.sh, and appending a version argument installs a specific release instead of the latest.

### How much does FXMinerProxy charge in developer fees?

The README lists 0.2 percent for all coins and 0 percent for individuals, with an activated tier that requires more than 200 miners: 0.18 percent from 200 to 1000, 0.15 percent from 1000 to 5000, 0.1 percent from 5000 to 10000, and 0.05 percent above 10000. The README does not explain what activation involves or how the fee is collected.

### Which coins does FXMinerProxy support?

The README lists BTC, LTC, ZEC, ETC, ETHF, ETHW, RVN, CFX, BEAM, ERGO, BTG, AE, FLUX, FIRO, NEOXA, XMR, KASPA, GRIN, KDA, DASH, CKB, RXD, ZIL, the ETHW_ZIL, ETHF_ZIL and ETC_ZIL pairs, ZEN, NEXA, HNS, BCH and IRON, and notes that the full list may be larger. It says to install the software to see all supported coins.

### What hardware does FXMinerProxy need for a given number of miners?

The README's deployment table estimates 100K to 150K of memory per miner and scales from 1 core, 1 GB and 2 Mbps below 200 miners up to 8 cores, 16 GB and 500 Mbps above 10000. Intermediate rows cover 200 to 500, 500 to 1000, 1000 to 5000 and 5000 to 10000 miners.

## Sources

- [FxPool/FXMinerProxy on GitHub](https://github.com/FxPool/FXMinerProxy)
- [License: MIT](https://github.com/FxPool/FXMinerProxy/blob/main/LICENSE)
- [Project website](http://www.fxminerproxy.com)
- [README](https://github.com/FxPool/FXMinerProxy/blob/main/README.md)
- [Releases](https://github.com/FxPool/FXMinerProxy/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fxpool-fxminerproxy