TCMinerProxy Transparent Proxy

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 TCMinerProxy 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 TCMinerProxy 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 TCMinerProxy nodes. The target can be a downstream TCMinerProxy TMS port instead of a pool. The first TCMinerProxy server does not need to decrypt, decompress, or convert the TMS 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 TMS, HAProxy, or another encryption, compression, or forwarding tool, and the traffic must pass through one TCMinerProxy jump server before reaching another TCMinerProxy server that connects to the pool.

Typical path:

Local TMS -> TCMinerProxy transparent proxy jump server -> Downstream TCMinerProxy TMS port -> Pool

Without transparent proxy, the first TCMinerProxy server would usually need to parse or decrypt local TMS traffic and then re-wrap it into the protocol expected by the downstream TCMinerProxy 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 TCMinerProxy server handles the TMS protocol.

Jump Port Settings

When creating the proxy port on the jump TCMinerProxy server:

1. Select TP or transparent proxy as the listening protocol.
2. Set the listening port that local TMS will connect to.
3. Set the primary pool address to the downstream TCMinerProxy TMS port, such as next-tcminerproxy.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 TCMinerProxy TMS port uses an encrypted channel, so the jump server should pass the local TMS stream unchanged to that TLS/SSL target.

TMS Protocol Matching

The local TMS protocol must match the downstream TCMinerProxy TMS port protocol.

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

Verification

1. Confirm the downstream TCMinerProxy TMS port is running and can connect to the pool.
2. Start the transparent proxy port on the jump TCMinerProxy server.
3. Change local TMS to use the jump server address and transparent proxy port.
4. Confirm local TMS connects successfully and the jump server connection count increases.
5. Check miners, hashrate, and connection logs on the downstream TCMinerProxy 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 TCMinerProxy server and the final pool as the source of truth for business data.

Common Mistakes