TcpProxy Module

🚫

This module is unmaintained. The TcpProxy is no longer actively developed in favour of the Stream module, which provides AsyncRead + AsyncWrite channels directly over the Mixnet without the localhost TCP socket layer. Existing users should plan to migrate. The module will continue to work but will not receive new features or bug fixes.

NymProxyClient and NymProxyServer proxy TCP traffic through the Mixnet. Both run in a background thread and expose a configurable localhost socket that callers read and write to like any other TCP connection. The Stream module replaces this pattern with multiplexed channels on a single client and no localhost socket layer.

Non-Rust/Go developers can use the standalone binaries instead.

Examples

Example	Source
Single connection	`tcp_proxy_single_connection.rs` (opens in a new tab)
Multiple connections	`tcp_proxy_multistream.rs` (opens in a new tab)

cargo run --example tcp_proxy_single_connection
cargo run --example tcp_proxy_multistream

API reference

docs.rs/nym-sdk/tcp_proxy (opens in a new tab) covers types, methods, and the full client/server walkthrough.

Architecture

NymProxyClient uses a Client Pool with one client per incoming TCP connection; if the pool runs dry it falls back to creating clients on demand. NymProxyServer runs a single Nym client with a persistent identity.

Each TCP connection is wrapped in a session ID; messages within a session carry an incrementing message ID, and a final Close message signals that no more outbound bytes are coming. Session and message IDs are necessary because the Mixnet guarantees delivery but not ordering, and ordering matters whenever a parser cares about frame boundaries (gRPC over protobuf, HTTP, TLS).

pub struct ProxiedMessage {
    message: Payload,
    session_id: Uuid,
    message_id: u16,
}

For the full request/response sequence diagram, see the module source (opens in a new tab) or the docs.rs (opens in a new tab) entry.

Examples Client Pool Module