Transparent Proxy

Transparent proxy forwards incoming data to the configured target address without parsing the payload. It does not identify miner protocols, wallets, or worker names, and the current RustMinerSystem node does not apply fee logic, replacement rules, or full statistics that depend on protocol parsing.

In practice, it is a transparent jump path: whatever data comes in is sent to the target.

Difference From Plain Forwarding

Plain forwarding usually uses a mining pool as the target address. Miners connect to the forwarding port, and RustMinerSystem forwards the traffic to the upstream pool. This works well when the goal is only to centralize miner access through one port.

Transparent proxy is more useful between RustMinerSystem nodes. The target can be a downstream RustMinerSystem RMS port instead of a pool. The first RustMinerSystem server does not need to decrypt, decompress, or convert the RMS stream; it only passes the local encrypted/compressed stream to the next server.

When To Use It

Use transparent proxy when the local site already uses RMS, HAProxy, or another encryption, compression, or forwarding tool, and the traffic must pass through one RustMinerSystem jump server before reaching another RustMinerSystem server that connects to the pool.

Typical path:

Local RMS -> RustMinerSystem transparent proxy jump server -> Downstream RustMinerSystem RMS port -> Pool

Without transparent proxy, the first RustMinerSystem server would usually need to parse or decrypt local RMS traffic and then re-wrap it into the protocol expected by the downstream RustMinerSystem server. That is harder to configure and adds another encryption/decryption or compression step, increasing CPU cost and latency risk.

Configuration Model

The key idea is simple: the jump server only transports bytes transparently, and the downstream RustMinerSystem server handles the RMS protocol.

Jump Port Settings

When creating the proxy port on the jump RustMinerSystem server:

1. Select TP or transparent proxy as the listening protocol.
2. Set the listening port that local RMS will connect to.
3. Set the primary pool address to the downstream RustMinerSystem RMS port, such as next-rustminer.example.com:9000.
4. Select TLS/SSL as the target pool protocol.
5. Keep fee wallets, wallet replacement, worker replacement, and other parsing-based features disabled or ignored.

Important: the jump server target protocol must be TLS/SSL. The downstream RustMinerSystem RMS port uses an encrypted channel, so the jump server should pass the local RMS stream unchanged to that TLS/SSL target.

RMS Protocol Matching

The local RMS protocol must match the downstream RustMinerSystem RMS port protocol.

The jump port only acts as a transparent proxy. It does not convert RMS2 to RMS3, and it does not convert RMS3(Zstd) into another protocol. Protocol version, compression level, super compression, and related settings must still match between local RMS and the downstream RustMinerSystem server.

Verification

1. Confirm the downstream RustMinerSystem RMS port is running and can connect to the pool.
2. Start the transparent proxy port on the jump RustMinerSystem server.
3. Change local RMS to use the jump server address and transparent proxy port.
4. Confirm local RMS connects successfully and the jump server connection count increases.
5. Check miners, hashrate, and connection logs on the downstream RustMinerSystem server.
6. Confirm the worker appears on the final pool.

Transparent proxy ports do not provide complete wallet, worker, hashrate, or fee statistics. Use the downstream RustMinerSystem server and the final pool as the source of truth for business data.

Common Mistakes