TCP Proxy: How It Works, How It Differs from an HTTP Proxy and Where It Is Used

A TCP proxy accepts a connection on one address and port, opens a second connection to a destination and copies bytes between the two without trying to understand them. It works at the transport layer, layer 4 of the OSI model, so it can carry any protocol built on TCP: PostgreSQL and MySQL, SSH, SMTP and IMAP, MQTT, Redis, game protocols and TLS of any kind.

That makes a TCP proxy the universal adapter of networking. You meet it in front of database clusters, on SSH jump hosts, inside load balancers and, under another name, in every SOCKS5 proxy you rent. Below we look at how the relay works, how it compares with an HTTP proxy, what happens to TLS and to the client's IP address, and we give working configs for nginx, HAProxy and SSH.

How a TCP Proxy Relays a Connection

Every relayed session is really two TCP connections glued together:

1. The client completes a TCP handshake with the proxy, for example on 198.51.100.20:15432.
2. The proxy decides where the session should go: a fixed backend from its config, or a destination the client names.
3. It opens its own connection to that destination, say db.internal:5432.
4. Bytes read from one socket are written to the other until either side closes.

For the client the proxy is the server; for the destination the proxy is the client. The destination therefore sees the proxy's IP, not the original one, a fact that matters later in this article.

Static Forwarders and Dynamic TCP Proxies

TCP proxies come in two flavours, and the difference is who chooses the destination.

• Static forwarders map a listening port to a backend fixed in the configuration. nginx with its stream module, HAProxy in mode tcp, Envoy, socat and ssh -L all work this way. The client does not even need to know a proxy is involved.
• Dynamic proxies let the client name the target for each connection. A SOCKS5 server does this with its CONNECT command, an HTTP proxy with the CONNECT method. Once the target is set, both behave as plain TCP relays. This is the type you get from a proxy provider; see our explainer on what a SOCKS5 proxy is.

TCP Proxy vs HTTP Proxy

Choose the HTTP side when you need to route by URL, rewrite headers or cache. Choose the TCP side when the protocol is not HTTP, when you must not touch the data or when you simply need speed and transparency. The application-layer counterpart is covered in our guide on what an HTTP proxy is.

Forward and Reverse TCP Proxies

A forward TCP proxy sits on the client side and sends outgoing connections into the world, often to give them a different exit IP or to cross a network boundary. A reverse TCP proxy sits in front of servers: it accepts incoming connections from the internet and spreads them across a pool of backends, hiding their real addresses. The software is often the same; only the direction changes.

TLS Through a TCP Proxy

A layer 4 proxy has three ways to handle encrypted traffic:

• Passthrough. The proxy relays the encrypted stream untouched, and the backend holds the certificate. It can still read the server name from the TLS ClientHello (SNI) and route on it: nginx offers ssl_preread, HAProxy the req.ssl_sni fetch.
• Termination. The proxy holds the certificate, decrypts and sends plain TCP to the backend. Handy for adding TLS to an old service that never had it.
• Re-encryption. The proxy decrypts, then opens a fresh TLS session to the backend. Used when the internal network must stay encrypted too.

Decryption on an intermediate node is a topic of its own; our article on SSL/HTTPS proxies explains termination and bridging in more detail.

Keeping the Client IP: PROXY Protocol

Because the backend sees only the proxy's address, logs, rate limits and allow lists lose track of real clients. HTTP solves this with headers, but a raw TCP stream has nowhere to put them. The PROXY protocol, created by the HAProxy project, solves it by prepending one short header to the connection:

PROXY TCP4 203.0.113.7 198.51.100.20 51234 5432

Version 1 is this single text line; version 2 is a compact binary equivalent. Both ends must agree: if the proxy sends the header and the backend does not expect it, the backend reads garbage and drops the connection. nginx, HAProxy, Envoy, Postfix and most cloud load balancers support it.

Configuration Examples

nginx: Balancing PostgreSQL

stream {
    upstream pg_pool {
        server 10.0.4.11:5432;
        server 10.0.4.12:5432 backup;
    }
    server {
        listen 15432;
        proxy_pass pg_pool;
        proxy_connect_timeout 3s;
        proxy_timeout 30m;
    }
}

The stream block lives at the top level of nginx.conf, next to http, not inside it. A long proxy_timeout keeps idle database sessions from being cut.

HAProxy: SSH Jump Host

frontend ssh_gateway
    mode tcp
    bind :2222
    timeout client 2h
    default_backend bastion_hosts

backend bastion_hosts
    mode tcp
    timeout server 2h
    server bastion_a 10.0.7.5:22 check

SSH: A Port Forward in One Command

ssh -L 15432:db.internal:5432 admin@bastion.example.net

While this session is open, a database client pointed at localhost:15432 reaches the database through the bastion. Swap -L for -D 1080 and SSH becomes a dynamic SOCKS proxy instead.

Where TCP Proxies Are Used

• Databases. One stable entry point for PostgreSQL, MySQL or Redis, with failover between replicas.
• Load balancing. Spreading connections for mail, MQTT brokers or custom services across many nodes.
• SSH and admin access. Bastion hosts that expose one port instead of dozens of servers.
• Game and chat servers whose protocols run over TCP; for UDP-based games you need a different tool, described in our guide to UDP proxies.
• IoT. Devices talking MQTT or custom binary protocols to a central broker.
• Outgoing connections with another IP. Scrapers, trading terminals, messengers and other apps that need to reach the internet from a specific country use dynamic TCP proxies, usually over SOCKS5. Node Proxy datacenter proxies are a fast option for this when the target does not require residential addresses.

Limitations

• No insight into content. You cannot route by URL, block a request type or cache responses.
• Connection-level balancing. One long-lived connection always lands on the same backend, so load can become uneven.
• Lost client IP unless the PROXY protocol is configured on both ends.
• Timeouts. Idle database or SSH sessions get cut if proxy timeouts are shorter than application keep-alives.
• TCP only. DNS, VoIP and many games use UDP and need a proxy that relays datagrams.

When to Choose a TCP Proxy

Pick a TCP proxy when the traffic is not HTTP, when the data must pass untouched (for example, TLS passthrough to a backend that owns its certificate) or when you need a thin, fast relay for databases, SSH or message brokers. Pick an HTTP proxy when decisions depend on URLs and headers. If your goal is simply to make an application connect from another IP address, a SOCKS5 proxy, which is a dynamic TCP proxy with authentication, is the shortest path.