What is a Stratum Proxy and Why Bitcoin Miners Need One

A Stratum proxy is a lightweight intermediary server that sits between your ASIC miners and remote mining pools, aggregating connections, enabling intelligent failover, and optimizing network performance. For large-scale mining operations with hundreds or thousands of miners, a properly configured stratum proxy reduces network overhead, improves uptime, and provides centralized control over pool connections.

Without a proxy, every ASIC connects directly to the pool’s stratum server. A 1,000-miner farm generates 1,000 individual TCP connections to the pool, each sending duplicate metadata and receiving duplicate work assignments. This wastes bandwidth, increases latency, and makes pool failover coordination impossible—if the pool goes down, each miner must independently detect the failure and switch, causing minutes of lost hashrate.

With a stratum proxy, all 1,000 miners connect to a local proxy server on your LAN. The proxy maintains a single optimized connection to the pool, aggregating share submissions and distributing work efficiently. When the pool fails, the proxy instantly switches all miners to a backup pool without individual miner reconfiguration.

This guide covers stratum proxy selection, installation, configuration for pool aggregation and failover, performance tuning, and operational best practices for bitcoin mining facilities.

Stratum Protocol Basics for Mining Operations

The Stratum mining protocol (RFC-style documentation at stratum.mining.bitcoin.com) is the standard communication method between miners and pools. Understanding Stratum mechanics helps optimize proxy configuration.

How Stratum Works

Stratum uses persistent TCP connections (port 3333 or 3334 typically) and JSON-RPC messaging:

1. Subscription: Miner connects and subscribes to work notifications
2. Authorization: Miner authenticates with username.workername and password
3. Difficulty Assignment: Pool assigns share difficulty based on miner hashrate
4. Work Delivery: Pool sends block templates (merkle branches, nonce ranges)
5. Share Submission: Miner submits valid shares, pool acknowledges and tracks credit

A stratum proxy intercepts these messages, translating between local miners (many connections) and remote pools (few connections). Proxies can modify difficulty, aggregate shares, and inject failover logic transparently.

Why Direct Pool Connections Don’t Scale

Challenges with direct connections at scale:

• Bandwidth waste: Each miner receives full block templates (~2KB every 30 seconds). 1,000 miners = 2MB/30s = 5.5 Mbps just for template distribution
• Connection overhead: 1,000 TCP connections consume firewall state tables, router NAT entries, pool server resources
• Failover complexity: Configuring backup pools on every miner individually is error-prone and creates staggered failover (miners detect failure at different times)
• Monitoring fragmentation: Tracking 1,000 individual connections for performance issues is impractical

A stratum proxy solves all of these by centralizing pool communication.

Choosing a Stratum Proxy Software

Several open-source and commercial stratum proxy solutions exist. Selection depends on fleet size, failover requirements, and monitoring needs.

1. Stratum Mining Proxy (Python-based)

Repository: github.com/slush0/stratum-mining-proxy
License: Open source (GPL)
Language: Python 2/3
Pros: Simple, lightweight, well-documented, proven in production
Cons: Limited advanced features, no built-in monitoring dashboard

Best for: Small to medium operations (10-500 miners), operators comfortable with command-line configuration.

2. Stratum V1 Proxy (Go-based)

Language: Golang
Pros: High performance, concurrent connection handling, low memory footprint
Cons: Fewer community resources than Python version

Best for: Large operations (500+ miners) requiring maximum throughput and low latency.

3. Braiins Pool Proxy

Provider: Braiins (makers of Braiins OS+ firmware)
Features: Built-in failover, difficulty aggregation, monitoring API
Pros: Enterprise-grade, excellent documentation, active support
Cons: Requires Braiins ecosystem familiarity

Best for: Operations already using Braiins firmware/pool services.

4. Custom Proxy Solutions

Large mining farms (5MW+) often build custom stratum proxies with:

• Multi-pool load balancing
• Geographical pool selection (route miners to nearest pool region)
• Advanced monitoring (Prometheus/Grafana integration)
• Revenue optimization (dynamic pool switching based on fees/luck)

Development cost: $20,000-80,000 depending on feature complexity.

Best for: Mega-scale operations (1,000+ miners) with dedicated DevOps teams.

Installing and Configuring Stratum Mining Proxy

We’ll use the Python-based Stratum Mining Proxy as our reference implementation. Installation on Ubuntu/Debian:

Step 1: Install Dependencies

sudo apt update
sudo apt install -y python3 python3-pip git
pip3 install twisted autobahn

Step 2: Clone and Install Proxy

git clone https://github.com/slush0/stratum-mining-proxy.git
cd stratum-mining-proxy

Step 3: Configure Basic Pool Connection

Edit mining_proxy.conf:

HOSTNAME = '0.0.0.0'  # Listen on all network interfaces
PORT = 3333           # Miners connect to this port
POOL_HOST = 'stratum.slushpool.com'  # Primary pool
POOL_PORT = 3333
POOL_FALLBACK_HOST = 'us-east.stratum.slushpool.com'  # Backup pool
POOL_FALLBACK_PORT = 3333

Step 4: Launch Proxy

python3 mining_proxy.py

The proxy is now listening on port 3333. Miners should point to <proxy-ip>:3333 instead of the pool directly.

Step 5: Configure Miners to Use Proxy

Update miner pool configuration:

• Pool URL: stratum+tcp://192.168.1.100:3333 (your proxy’s LAN IP)
• Worker: username.workername (same as before)
• Password: x (or pool-specific password)

Miners now connect through the proxy. The proxy forwards authentication and shares to the configured pool transparently.

Advanced Configuration: Multi-Pool Failover

Reliable mining operations require automatic failover when the primary pool becomes unavailable. Configure multi-tier failover:

Three-Pool Failover Configuration

Edit mining_proxy.conf to include tertiary failover:

# Primary pool (lowest latency, preferred)
POOL_HOST = 'us-west.stratum.foundryusapool.com'
POOL_PORT = 3333

# Secondary pool (different provider for redundancy)
POOL_FALLBACK_HOST = 'stratum.slushpool.com'
POOL_FALLBACK_PORT = 3333

# Tertiary pool (geographic diversity)
POOL_FALLBACK_HOST_2 = 'sg.stratum.slushpool.com'
POOL_FALLBACK_PORT_2 = 3333

# Failover timeout (seconds to wait before switching)
POOL_TIMEOUT = 30

Failover Logic

The proxy monitors pool connection health:

1. If primary pool stops sending work updates for >30 seconds, switch to secondary
2. If secondary pool fails, escalate to tertiary
3. Periodically test primary pool and automatically fail back when available

This ensures continuous mining even during pool outages, DDoS attacks, or maintenance windows.

Testing Failover

Simulate pool failure to verify failover works:

# Block primary pool at firewall level
sudo iptables -A OUTPUT -d <primary-pool-ip> -j DROP

# Monitor proxy logs
tail -f stratum_proxy.log

# Should see: "Primary pool timeout, switching to fallback"
# Miners continue operating without interruption

# Restore primary pool
sudo iptables -D OUTPUT -d <primary-pool-ip> -j DROP

# Proxy should automatically fail back to primary

Network Optimization and Performance Tuning

1. Proxy Server Hardware Sizing

A stratum proxy is lightweight but requires proper sizing:

A basic VM or low-power server (e.g., Intel NUC) is sufficient for most operations.

2. Network Placement

Deploy the proxy on your mining facility’s local network:

• Same VLAN as miners: Minimizes latency and switch hops
• Low-latency uplink: Direct connection to internet gateway (no double-NAT, no VPN tunnels)
• Static IP: Prevents miner reconfiguration if DHCP lease changes

Typical latency targets:

• Miners ↔ Proxy: <1ms (local LAN)
• Proxy ↔ Pool: <50ms (internet)

3. Connection Pooling and Keep-Alive

Configure TCP keep-alive to detect stale connections:

# In proxy configuration
TCP_KEEPALIVE = True
KEEPALIVE_INTERVAL = 60  # seconds

This prevents zombie connections from consuming resources after miner reboots or network hiccups.

4. Difficulty Aggregation

Stratum proxies can aggregate share difficulty, reducing submission frequency:

• Without proxy: Each S19 Pro miner (110 TH/s) submits ~6 shares/second at difficulty 65,536
• With proxy aggregation: Proxy increases difficulty to 131,072, miners submit ~3 shares/second

This halves network traffic and pool server load without affecting earnings (same expected reward over time).

Monitoring Proxy Health and Performance

Implement monitoring to detect proxy issues before they impact mining uptime.

Key Metrics to Track

• Active miner connections: Should match expected fleet size
• Share acceptance rate: Should be 98-99%+ (low rate indicates network issues)
• Proxy CPU/memory usage: Should be <50% under normal load
• Pool response time: Latency to primary/fallback pools
• Failover events: Log timestamps and duration of pool switches

Logging Best Practices

Enable detailed logging for troubleshooting:

LOG_LEVEL = 'DEBUG'  # Options: DEBUG, INFO, WARNING, ERROR
LOG_FILE = '/var/log/stratum_proxy.log'
LOG_ROTATION = True  # Rotate logs daily to prevent disk fill

Review logs weekly for patterns: share rejections, connection resets, failover frequency.

Alerting Setup

Integrate proxy health checks with monitoring systems (Nagios, Zabbix, Prometheus):

# Simple HTTP health check endpoint
curl http://<proxy-ip>:8000/health
# Returns: {"status": "ok", "connected_miners": 1000, "pool": "primary"}

# Alert if connected_miners drops >10% below expected
# Alert if pool != "primary" for >15 minutes (indicates sustained failover)

Pool Selection Strategy for Proxy Failover

Choose pools for failover tiers based on reliability, latency, and business continuity:

Primary Pool Selection

Your primary pool should optimize for:

• Lowest latency: Choose a pool with servers geographically close to your facility
• High uptime: Check pool reliability history (public uptime stats)
• Favorable fee structure: Balance fees against pool hashrate/variance

Popular primary pools for US operators: Foundry USA Pool, F2Pool, Luxor.

Secondary Pool (Redundancy)

Select a secondary pool from a different provider to protect against provider-level outages:

• If primary is Foundry USA, secondary might be Slush Pool
• Different infrastructure = independent failure modes

Tertiary Pool (Geographic Diversity)

Choose a tertiary pool in a different geographic region:

• If primary/secondary are US-based, tertiary could be EU or Asia-Pacific
• Protects against regional internet outages, fiber cuts, or DDoS attacks targeting specific regions

Pool Fail-Back Strategy

Configure automatic fail-back to primary pool when it recovers:

FAIL_BACK_ENABLED = True
FAIL_BACK_TEST_INTERVAL = 300  # Test primary every 5 minutes
FAIL_BACK_DELAY = 600  # Wait 10 minutes of stable primary before switching back

This prevents rapid pool switching (“flapping”) if primary is intermittently unstable.

Advanced Use Cases

1. Multi-Region Pool Routing

For globally distributed mining facilities, deploy regional proxies:

• US facility: Proxy routes to us-west.pool.com
• EU facility: Proxy routes to eu-central.pool.com
• APAC facility: Proxy routes to sg.pool.com

Each proxy connects to its region’s optimal pool, minimizing latency globally.

2. Revenue Optimization via Pool Switching

Some operators use automated pool switching to maximize revenue:

• Monitor real-time pool fees, variance, and effective payouts
• Switch to the most profitable pool hourly or daily
• Requires custom scripting or third-party services like MiningRigRentals

Complexity vs benefit: Adds 0.5-2% revenue but increases operational overhead. Best for operations >10MW.

3. Development/Testing Pools

Configure a separate proxy for development miners:

• Production miners → Production proxy → Live pools
• Dev/test miners → Dev proxy → Testnet pool or private pool

This isolates experimental firmware testing from production revenue streams.

Security Considerations

1. Network Segmentation

Isolate the stratum proxy on a dedicated VLAN:

• Miners connect to proxy VLAN (e.g., 192.168.10.0/24)
• Proxy connects outbound to pools via internet gateway
• Firewall rules: Allow miners → proxy:3333, proxy → internet:3333/3334, block all other miner outbound

This prevents compromised miners from accessing other infrastructure or exfiltrating data.

2. Proxy Authentication

Some proxies support authentication to prevent unauthorized miner connections:

REQUIRE_AUTHENTICATION = True
ALLOWED_WORKERS = ['user1.worker1', 'user1.worker2', ...]  # Whitelist

Useful in multi-tenant environments or when preventing rogue miners from leeching pool connections.

3. DDoS Protection

The proxy itself can become a DDoS target. Mitigations:

• Rate limiting: Limit connection attempts per IP (e.g., max 10 connections per miner IP)
• Firewall rules: Only allow connections from known miner IP ranges
• Geographic blocking: If all miners are on-premises, block international connections to proxy

Troubleshooting Common Proxy Issues

Issue: Miners show “Pool not reachable” after proxy setup

Cause: Firewall blocking proxy port 3333 or incorrect miner pool URL.
Fix: Verify proxy is listening (netstat -tulnp | grep 3333), check miner configuration points to correct proxy IP, verify no firewalls blocking port 3333.

Issue: Share acceptance rate drops after enabling proxy

Cause: Network latency between proxy and pool, or proxy CPU overload.
Fix: Measure proxy ↔ pool latency (ping <pool-host>), check proxy CPU usage, switch to fallback pool, increase proxy difficulty aggregation.

Issue: Failover not activating during pool outage

Cause: POOL_TIMEOUT set too high, or fallback pool not configured correctly.
Fix: Reduce timeout to 30 seconds, verify fallback pool credentials in config, test failover manually (iptables block primary pool).

Issue: Proxy crashes under high miner load

Cause: Insufficient server resources or memory leak in proxy software.
Fix: Upgrade proxy server CPU/RAM per sizing guidelines, monitor memory usage, restart proxy daily via cron if memory leak suspected, consider Go-based proxy for better concurrency.

Operational Best Practices

• Run proxy as a service: Use systemd or supervisor to auto-restart on crashes
• Redundant proxy servers: Deploy two proxies with load balancing for HA (requires DNS round-robin or miners configured with multiple proxy IPs)
• Regular updates: Keep proxy software updated to patch security vulnerabilities
• Backup configuration: Store mining_proxy.conf in version control (Git) for disaster recovery
• Test failover quarterly: Simulate pool outages to verify failover logic works as expected

Stratum V2 Protocol: Future-Proofing Your Proxy

Stratum V2 is the next-generation mining protocol offering:

• Encryption: TLS-encrypted miner ↔ pool connections prevent eavesdropping
• Job negotiation: Miners can select their own block templates (decentralization)
• Binary protocol: More efficient than JSON-RPC (lower bandwidth, faster parsing)

Stratum V2 proxies are in early adoption (Braiins Pool supports it fully as of 2024). For new deployments, consider V2-compatible proxies to future-proof infrastructure.

Migration path: Most V2 proxies support V1 backward compatibility, allowing gradual firmware upgrades without replacing proxy infrastructure.

Case Study: 2MW Mining Facility Proxy Deployment

A 2MW mining operation with 1,200 Antminer S19 units (132 PH/s) deployed a stratum proxy with three-tier failover:

• Primary: Foundry USA Pool (US-East, 12ms latency)
• Secondary: F2Pool (US-West, 45ms latency)
• Tertiary: Slush Pool (EU, 95ms latency)

Proxy hardware: Intel NUC (4-core i5, 8GB RAM, 1Gbps NIC)

Results:

• Bandwidth usage reduced 73% (from 8.2 Mbps to 2.2 Mbps)
• Pool failover events: 3 in first 6 months (primary pool DDoS, maintenance windows), zero hashrate loss during switches
• Share acceptance rate: 99.2% (up from 98.1% with direct connections due to reduced network jitter)
• Operational cost: $300 one-time hardware + $50/month power/internet for proxy server

ROI: Improved uptime (0.3% reduction in stale shares) added ~$3,500/month revenue at $40,000 BTC, payback <1 month.

Frequently Asked Questions

Do I need a stratum proxy if I only have 10-20 miners?

Not strictly necessary, but still beneficial. Even small operations gain from centralized failover and reduced miner configuration complexity. The proxy can run on a Raspberry Pi ($50 hardware cost).

Can I use a proxy with multiple different pools simultaneously?

Yes, for load balancing. Configure multiple proxy instances (one per pool) on different ports, then assign miners to different proxies. Advanced proxies support multi-pool load balancing within a single instance.

Will a proxy reduce my mining earnings?

No. The proxy is transparent to pool accounting—shares are credited identically whether submitted directly or via proxy. Any latency added by a properly configured local proxy (<1ms) is negligible compared to internet latency.

How do I monitor which pool the proxy is currently using?

Check proxy logs or expose a status API endpoint. Most proxies log pool switches: tail -f stratum_proxy.log | grep "Switching to".

Can I run the stratum proxy on the same server as my mining farm management software?

Yes, as long as the server has sufficient resources. Common colocation: Proxy + monitoring dashboard + fleet management on a single VM or physical server.

Conclusion: Why Every Mining Operation Should Use a Stratum Proxy

Stratum proxies are a foundational infrastructure component for professional bitcoin mining operations. They reduce network overhead, enable intelligent pool failover, centralize configuration management, and improve overall operational reliability—all at minimal cost and complexity.

For small operations (10-100 miners), a proxy simplifies pool management and protects against pool downtime. For large operations (500+ miners), proxies are essential for bandwidth efficiency and failover coordination.

Implementation is straightforward: a few hours of setup, minimal ongoing maintenance, and immediate uptime benefits. Combined with proper pool selection and failover testing, a well-configured stratum proxy ensures your hashrate is always mining, even when individual pools experience issues.

For hosted mining services featuring enterprise-grade pool failover and network optimization, contact Rax Mining. Our infrastructure includes redundant stratum proxies, multi-region pool routing, and 99.9% uptime SLAs to maximize your mining revenue.