How to configure stratum proxy for mining rigs? (Network optimization)

Understanding Stratum Proxy Fundamentals

1. A Stratum proxy acts as an intermediary between mining rigs and the mining pool server, aggregating multiple rig connections into a single upstream connection to reduce network overhead.

2. It decouples the rig’s connection stability from the pool’s infrastructure by buffering job assignments and handling reconnection logic locally.

3. The proxy operates at the TCP layer and does not alter mining protocol semantics—it forwards stratum messages verbatim while managing session multiplexing.

4. Latency reduction occurs because local job distribution eliminates round-trip delays for every new mining job request across wide-area networks.

5. Network congestion near the pool endpoint is mitigated since only one persistent TCP stream carries aggregated work submissions and difficulty updates.

Required Components and Dependencies

1. A Linux-based host with static IP assignment and minimal firewall restrictions on ports 3333, 3334, or custom stratum ports.

2. stratum-mining-proxy software compiled from source or installed via package manager—common implementations include braiins/stratum-proxy and coinfoundry/miningcore-stratum-proxy.

3. OpenSSL libraries for TLS termination if secure upstream communication is enabled, alongside libuv for asynchronous I/O handling.

4. Sufficient RAM (minimum 512MB) to buffer pending jobs and maintain per-rig state without swapping under load.

5. A configuration file specifying upstream pool address, port, worker credentials, and local bind interface—no wallet integration or blockchain sync is involved.

Step-by-Step Deployment Workflow

1. Download the latest stable release binary matching the host architecture and verify its SHA256 checksum against the official repository signature.

2. Create a dedicated non-root user with limited filesystem permissions and assign ownership of the proxy binary and config directory to that user.

3. Configure upstream_host, upstream_port, and upstream_user fields in the YAML or JSON config, ensuring no plaintext passwords are exposed in logs.

4. Set listen_address to 0.0.0.0:3333 and adjust max_connections based on expected rig count and average job frequency.

5. Launch the proxy as a systemd service with restart-on-failure policy and journal logging enabled for real-time diagnostics during initial rig onboarding.

Traffic Routing and Load Distribution

1. Configure each mining rig to point its miner software to the proxy’s local IP and port instead of the original pool endpoint.

2. Enable job_fanout mode if deploying multiple proxies behind a load balancer to distribute upstream pressure across redundant pool gateways.

3. Apply iptables rules to rate-limit inbound connections per IP to prevent abuse or accidental flood from misconfigured firmware.

4. Monitor active sessions using netstat -tnp | grep :3333 and correlate with internal proxy metrics exported via Prometheus endpoints.

5. Route outbound traffic through a dedicated NIC or VLAN if co-located with other high-throughput services to avoid packet loss due to interface saturation.

Frequently Asked Questions

Q: Can a Stratum proxy handle both SHA-256 and Ethash-based mining protocols simultaneously?A: No. Each proxy instance is compiled and configured for one specific algorithm family. Separate processes must run for BTC and ETH mining operations.

Q: Does the proxy modify share difficulty or perform any form of share rewriting?A: No. Share validation remains entirely with the upstream pool. The proxy transmits shares unaltered and does not interpret their cryptographic content.

Q: Is it possible to run the proxy inside a Docker container without sacrificing performance?A: Yes. Containerized deployment is supported when using host networking mode and mounting /dev/shm for shared memory access required by some miner binaries.

Q: What happens when the upstream pool disconnects temporarily?A: The proxy maintains local job cache and continues distributing cached work to rigs until reconnection succeeds or timeout thresholds trigger failover logic.