Stratum Proxy Solo Mining Setup: Bridge Your Node to Miners

TL;DR: Setting up a proxy that connects your node to mining hardware sounds complicated, but it’s actually pretty straightforward once you understand what each piece does. You run a full node, then add proxy software that translates between your node’s language and the Stratum protocol your miners speak. This guide walks through why you need it, how to set it up, and the real-world costs of running this setup 24/7.

Why Solo Miners Need a Stratum Proxy

Here’s the thing: Your mining hardware speaks Stratum, but your node doesn’t.

Most cryptocurrency nodes (Bitcoin Core, Monero daemon, whatever) use their own protocol for communication. They’re designed to talk to other nodes, not directly to ASICs or GPUs. Your hardware, though? It’s built to connect to mining pools using the Stratum protocol — a lightweight, efficient way to distribute work and collect shares.

When you’re solo mining, you become your own pool. But there’s a language barrier. Your node generates the block header data, but your miner can’t understand it without translation. That’s exactly what a proxy does — it sits between your node and your hardware, converting requests back and forth.

Without a proxy, you’d need to modify your mining software to directly communicate with your node’s RPC interface. Some miners support this, but honestly? Most don’t, and it’s way more hassle than just running proxy software.

The proxy also handles work distribution if you’re running multiple rigs. Instead of each miner connecting directly to your node (which can overwhelm it), they all connect to one proxy that manages the communication efficiently.

How Stratum Protocol Works for Solo Mining

The Stratum protocol was designed by mining pools to solve a simple problem: How do you send work to thousands of miners without crushing your servers?

Traditional mining used getwork, where each miner repeatedly asked “Hey, what should I mine now?” every few seconds. That created massive server load. Stratum flipped it around — the server pushes new work to miners whenever the blockchain changes or when they finish their current work range.

When you’re setting up a proxy for solo mining, you’re implementing the server side of Stratum. Your miners connect to your proxy as if it were a pool. The proxy subscribes to your node for new block templates, then distributes work ranges to each connected miner.

Here’s what happens every time:

  • Your node creates a new block template with pending transactions from the mempool
  • The proxy requests this template via RPC and converts it to Stratum format
  • Your miners receive the work and start hashing through nonce ranges
  • If a miner finds a valid share below the target, it submits back through the proxy
  • The proxy validates and forwards winning blocks to your node for broadcasting

This whole cycle repeats constantly. Every new block on the network triggers fresh work. It’s pretty efficient, actually — much better than older protocols.

Choosing the Right Proxy Software

Several proxy options exist for solo mining, each with different trade-offs.

CKPool/CKProxy is probably the most popular for Bitcoin solo mining. It’s rock-solid, handles high hashrates without breaking a sweat, and was literally designed for this exact purpose. The developer runs solo.ckpool.org, so you know the software is battle-tested. Setting it up requires some command-line comfort, but the documentation is pretty good.

I’ve been running CKProxy for about six months now, and it’s basically set-and-forget. Once you get it configured, it just works. The only time I’ve touched it was to upgrade Bitcoin Core underneath it.

Stratum Mining Proxy by slush0 is older and more limited. It works fine for small setups, maybe up to 100 TH/s or so, but starts struggling beyond that. The code hasn’t been updated in a while. I’d only recommend this if you’re mining something obscure that CKPool doesn’t support.

Custom node implementations like btcpool include proxy functionality. These are more complex but offer additional features like monitoring dashboards and multi-coin support. Unless you’re running a serious operation, they’re probably overkill.

For GPU mining coins like Ravencoin or Ergo, you might use coin-specific proxies. Some nodes include built-in Stratum servers — Monero’s mining implementation, for example, has basic Stratum support built into the daemon. Check your coin’s documentation first.

Setting Up CKPool for Bitcoin Solo Mining

Let’s walk through a real setup using CKPool, since that’s what most serious Bitcoin solo miners use.

Prerequisites: You need a synced Bitcoin Core node with RPC enabled. Your bitcoin.conf should have rpcuser, rpcpassword, and rpcallowip configured. You’ll also need a Linux server — CKPool runs on Ubuntu, Debian, or similar distros. Windows support exists but is messier.

First, install the dependencies:

sudo apt-get update
sudo apt-get install build-essential yasm libzmq3-dev libsodium-dev git

Clone and build CKPool:

git clone https://bitbucket.org/ckolivas/ckpool.git
cd ckpool
./configure --enable-ckproxy
make

The build process takes maybe two minutes on a decent machine. If it fails, you’re probably missing a dependency — the error message will tell you what.

Create a configuration file (ckproxy.conf):

{
"proxy" : "",
"serverurl" : ["127.0.0.1:3333"],
"btcaddress" : "YOUR_BITCOIN_ADDRESS",
"btcsig" : "/solominer.com/",
"nodeserver" : "127.0.0.1:8332",
"nodeuser" : "your_rpc_user",
"nodepass" : "your_rpc_password"
}

Replace the placeholders with your actual values. The btcaddress is where your block reward goes if you find a block. The btcsig appears in the coinbase transaction — it’s basically your signature on the block.

Start the proxy:

./ckproxy -c ckproxy.conf

You should see output showing it connecting to your Bitcoin Core node and starting the Stratum server. Point your miners at your_server_ip:3333 and they should start receiving work immediately.

Don’t make my mistake: I forgot to open port 3333 in my firewall the first time. Spent like 20 minutes troubleshooting why my miners couldn’t connect before I realized. Check your firewall rules if miners won’t connect.

GPU Mining Coins: Proxy Setup for AMD and NVIDIA

GPU mining requires different proxies since most coins use different algorithms than Bitcoin’s SHA-256.

For Ravencoin (KAWPOW algorithm), you’ll typically use the node’s built-in Stratum server. The Ravencoin daemon has mining support built in. In your raven.conf:

server=1
rpcuser=youruser
rpcpassword=yourpass
rpcallowip=192.168.1.0/24
gen=1
genproclimit=0

The genproclimit=0 tells it not to mine with CPU but to accept external miners. Point your T-Rex miner or TeamRedMiner at the node’s RPC port with the mining.subscribe method.

Actually, most modern GPU miners can connect directly to nodes for solo mining without needing separate proxy software. T-Rex, for example, just needs:

t-rex -a kawpow -o http://127.0.0.1:8766 -u youruser -p yourpass --no-watchdog

For Ergo (Autolykos), the node also includes Stratum support. In your ergo.conf:

ergo {
node {
mining = true
useExternalMiner = true
}
}

The default mining port is 9053. Your GPU miner connects there directly.

Monero (RandomX) is slightly different since it’s CPU-focused. The monerod daemon includes basic mining functionality, but for serious hashrate, you’d use XMRig connected directly via RPC. No proxy needed — XMRig speaks directly to the daemon.

The pattern here? Most modern coins have caught on that miners need Stratum support, so they’ve built it into their nodes. Bitcoin is actually the exception, not the rule, because it predates the Stratum protocol.

Network Configuration and Security

Running a proxy means opening ports and handling authentication. You need to think about security.

Firewall rules: Only open your Stratum port (usually 3333, 3334, or similar) to your local network unless you’re running a public pool. There’s zero reason to expose it to the internet for solo mining. If your miners are on the same LAN as your node, keep everything internal.

If you must access your proxy remotely, use a VPN. Seriously. Don’t just open ports to the internet and hope for the best. I’ve seen people’s nodes get hammered by random miners trying to use their proxy as a free pool.

Authentication: Most proxy software supports worker authentication. Use it. Even on your local network, it’s good practice. Choose strong passwords — treat it like you’re protecting your actual coins, because basically you are.

Resource monitoring: Your proxy needs CPU and network bandwidth. Not tons, but some. Each connected miner maintains a socket connection and receives frequent work updates. At 100+ miners, this adds up. Monitor your proxy server’s CPU usage and network traffic to make sure it’s not becoming a bottleneck.

A typical setup might use:

  • 5-10% CPU on a modern processor (more during block changes)
  • 1-5 Mbps network bandwidth per 100 miners
  • 100-200 MB RAM for the proxy process itself

Those numbers scale roughly linearly. Double your miner count, expect roughly double the resources.

Costs of Running a Proxy Setup 24/7

Let’s talk real numbers, because running this infrastructure isn’t free.

Hardware costs: You need a server or dedicated PC for your node and proxy. This doesn’t need to be fancy. A used office PC with an SSD and 8GB RAM works fine for most coins. Budget $200-400 for decent hardware. Bitcoin’s blockchain is huge (currently 500+ GB), so make sure you have storage space.

Dell OptiPlex 7040 (Refurbished)

Perfect for running a node and proxy — Core i5, 8GB RAM, 500GB SSD. Quiet, efficient, and dirt cheap on the used market.

View on Amazon

Electricity costs: This is the ongoing expense. A typical node + proxy server pulls 50-100W depending on hardware and blockchain activity. At $0.12/kWh (US average), that’s roughly $4-9 per month just for the node infrastructure.

That might not sound like much, but remember — you’re also running your miners. An Antminer S19 pulls 3250W. That’s $280+ per month in electricity at the same rate. The node is small potatoes compared to the mining hardware, but it’s still a cost to factor in.

Internet requirements: You need a stable connection with reasonable upload speed. Your node participates in the peer-to-peer network, relaying blocks and transactions. Budget 100-200 GB of bandwidth per month for a Bitcoin node, maybe more if you run multiple coins.

Most home internet connections handle this fine, but if you’re on a metered plan or have data caps, factor that in. Satellite internet with 50 GB monthly caps? Not gonna work well.

Maintenance time: This isn’t a dollar cost, but it’s real. Nodes need updates. Software occasionally breaks. You’ll spend a few hours per month on maintenance, more if something goes wrong. If you value your time, factor that in.

Total monthly cost for infrastructure: $5-15 for a typical solo mining setup. That’s before the mining hardware itself, which dominates the cost equation.

Monitoring Your Proxy and Node Performance

Once everything’s running, you need to watch it. Solo mining already involves long stretches between blocks — you don’t want to miss one because your proxy died.

Log monitoring: Your proxy and node both generate logs. Check them regularly, or set up automated monitoring. Look for:

  • Connection errors from miners
  • RPC timeouts to your node
  • Orphaned shares (might indicate network issues)
  • Unusual hashrate drops

CKPool’s logs are actually pretty readable. You’ll see each miner connection, every block template change, and any submitted shares. When difficulty adjusts or a new block hits the network, you’ll see the proxy distribute fresh work.

Hashrate validation: Make sure your reported hashrate matches what your miners claim. If you’re seeing a big discrepancy, something’s wrong — maybe network latency, misconfiguration, or hardware issues.

Some proxy software includes web interfaces for monitoring. These are super helpful, actually. You can see connected miners, current work, hashrate graphs, and recent submissions at a glance.

Node sync status: This is critical. If your node falls behind the blockchain tip, you’re mining stale work. Any blocks you find won’t be accepted because they’re building on outdated chain state. Most nodes have a getinfo or similar RPC call that shows sync status and block height.

Check it daily. Compare your node’s block height to a block explorer. They should match within 1-2 blocks (accounting for propagation delay).

Troubleshooting Common Proxy Issues

Things will go wrong eventually. Here’s what I’ve learned from months of running this setup.

“Proxy won’t connect to node”: Nine times out of ten, this is RPC configuration. Double-check your bitcoin.conf or equivalent config file. Make sure rpcuser and rpcpassword match what you put in the proxy config. Verify rpcallowip includes your proxy’s IP address. Restart both the node and proxy after config changes.

“Miners can’t connect to proxy”: Firewall, almost always. Check your iptables rules or Windows Firewall settings. Make sure the Stratum port is open for your miners’ IP addresses. Test with telnet or nc to verify the port is actually listening.

“Hashrate drops periodically”: This might be the proxy struggling during block template updates. When a new block hits the network, the proxy needs to quickly fetch new work from the node and push it to all miners. If your node is slow (mechanical HDD, limited RAM), this creates lag. Upgrading to an SSD often fixes it.

“Shares rejected as stale”: Network latency or slow node response. Check your ping times between miners, proxy, and node. If any hop exceeds 50-100ms consistently, you’ll see more stale shares. This is especially problematic for coins with fast block times like Kaspa.

“Found a block but it wasn’t accepted”: This one hurts. Could be several things. Maybe your block became an orphan because another miner found it first. Or your node wasn’t fully synced when you found it. Or there’s a bug in how the proxy constructs the block. Check your node’s logs for the exact rejection reason.

What I wish I knew earlier: Keep backups of your working config files. I’ve accidentally broken my setup during “improvements” and had to reconstruct the working configuration from memory. Not fun.

When NOT to Use a Proxy

Honestly? Sometimes you don’t need one.

If you’re mining with just one or two devices that support direct node connection, skip the proxy. One less thing to maintain and troubleshoot. XMRig for Monero, for example, connects straight to monerod with no proxy needed. Why add complexity?

For really small hashrates — like a NerdMiner or lottery mining setup — you might just use a public solo pool instead. Solo.ckpool.org for Bitcoin, woolypooly’s solo pools for GPU coins, whatever. Yes, you pay a small fee (typically 0.5-2%), but you skip all the infrastructure hassle.

The proxy setup makes sense when you’re running serious hashrate, multiple miners, or want complete control over your mining. For hobby mining or learning? Public solo pools are often the smarter choice.

I started with public solo pools before building my own setup. Learned the basics, understood what I actually needed, then moved to self-hosted when I added more hardware. That progression made way more sense than jumping straight into proxy configuration.

Real-World Solo Mining Expectations

Let’s be brutally honest about solo mining odds, because setting up all this infrastructure doesn’t change the math.

Bitcoin: At current network difficulty, you need around 100 TH/s to have a 1% chance of finding a block per year. The reward right now is 3.125 BTC (post-2026 halving), worth about $66,077 per BTC. But your odds are still terrible unless you’re running 1+ PH/s.

Your proxy setup doesn’t improve these odds. It just lets you try.

GPU-mineable coins: Way better odds, actually. Ravencoin, Ergo, Alephium — these have lower network hashrates. A 6-GPU rig might find a block every few weeks to months depending on the coin. Still lottery mining, but not quite as hopeless as Bitcoin.

CPU coins: Monero solo mining with a single CPU is basically pointless. You’d need a server farm. Even with 100 CPUs, you’re looking at years between blocks on average.

The question becomes: Why run a proxy setup for odds this long? For some people, it’s about the principle — being a full network participant, not trusting pools. For others, it’s the thrill of the hunt. For me? It’s learning how this stuff actually works at a deeper level.

Just don’t expect to get rich. If you want consistent income, join a pool. If you want to understand mining infrastructure and occasionally get lucky, solo mine with proper awareness of the odds.

FAQ: Stratum Proxy Solo Mining

Can I use one proxy for multiple types of miners?

Yes and no. One proxy instance can handle multiple miners of the same type (ASICs or GPUs mining the same algorithm), but you can’t mix Bitcoin miners and Ethereum miners on the same proxy since they speak different variants of Stratum. You’d need separate proxy instances for each coin, each connecting to its respective node. The hardware can be the same server, but the software instances need to be separate.

How much hashrate can a typical proxy handle?

CKPool easily handles 1+ PH/s on decent hardware. The developer runs solo.ckpool.org which serves way more than that. Your bottleneck is usually the node, not the proxy. A properly configured proxy on a quad-core processor with adequate RAM can serve hundreds of miners without breaking a sweat. I’ve run 20+ GPUs through one proxy instance with zero issues. Network bandwidth becomes the limiting factor before CPU does in most cases.

What happens if my node goes down but the proxy stays up?

Your miners keep running but they’re doing useless work. The proxy can’t fetch new block templates without the node, so it serves stale work. Any blocks found won’t be valid because they’re building on outdated chain state. This is why monitoring node sync status is critical — you’re wasting electricity if your node dies. Some proxy software detects this and stops serving work, but not all implementations do.

Do I need a static IP address for proxy mining?

Only if your miners are at a different location than your proxy. On your local network, any IP works — just point your miners at your proxy server’s LAN address. If you’re running miners at multiple locations and want them all to connect back to one proxy, then yes, you’d need either a static IP or a dynamic DNS service. For typical home setups where everything’s on the same network, dynamic IPs are fine.

Can I switch between solo and pool mining without reconfiguring?

Not seamlessly. Your miners need to point at different servers — your proxy for solo, the pool’s server for pool mining. You could set up multiple miner profiles or scripts to switch between them quickly, but there’s no automatic failover. Some miners support backup pools in their config, so you could theoretically set pool mining as a failover if your solo proxy goes down, but that’s not a standard feature across all mining software.