Tcp Proxy Server
A tcp proxy server sits between a client app and a backend host. It accepts a network call on one side and opens a new link on the other. Teams use this setup to route traffic into private networks and balance server load. Still, when network rules are too broad, anyone on the subnet can reach every backend port. How a tcp proxy server routes network traffic A tcp proxy server works at layer four of the network stack. First, a client app sends a request to the listening address and port. The
Database Proxy (ProxySQL, PgBouncer) + Kubernetes API Server Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A tcp proxy server sits between a client app and a backend host. It accepts a network call on one side and opens a new link on the other. Teams use this setup to route traffic into private networks and balance server load. Still, when network rules are too broad, anyone on the subnet can reach every backend port.
How a tcp proxy server routes network traffic
A tcp proxy server works at layer four of the network stack. First, a client app sends a request to the listening address and port. The server completes the three-way handshake with the client and holds that link open. Next, the server picks a healthy backend host from a list of known targets. It opens a second three-way handshake with that target host on its private IP.
Once both links are up, the server copies raw bytes back and forth. It reads packets from the client socket and writes them to the backend socket. When the backend replies, the server sends those bytes back to the client. The client never sees the real IP address of the private backend host. In turn, the backend host only sees the IP address of the routing node.
Teams also use this setup to manage TLS encryption at the network edge. In passthrough mode, the server forwards encrypted bytes without reading the payload inside. In termination mode, the server checks the TLS certificate and decrypts the byte stream. Then it forwards plain text or re-encrypted bytes to the internal service.
What layer four routing solves and what it misses
Running a layer four forwarder solves big network routing problems for engineering teams. You do not have to expose every database or service to the public internet. Instead, you keep private hosts in an isolated subnet with strict firewall rules. You also gain a single choke point to track open sockets and byte counts. If one backend host fails a health check, traffic shifts to a working host.
Still, a basic layer four setup leaves a wide gap in daily operations. The server only sees source IP addresses, target ports, and raw byte streams. It knows that a network link started, but it cannot read the protocol inside. Once a socket is open, every command or query passes through unchecked.
Database Proxy (ProxySQL, PgBouncer) + Kubernetes API Server Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
This creates real risks when engineers connect to databases or internal tools. A firewall rule only decides which IP address can open a socket. It does not check which user is typing commands or what queries run in flight. One bad query can drop a table or pull thousands of customer card numbers. Standard network logs only show that megabytes moved across a port at a given time. They never show the actual statements ran or the sensitive records returned.
How to harden your network forwarding setup
Start by locking down which source networks can reach your listening ports. Bind each listener to a specific private interface rather than all open interfaces. Set strict idle timeouts so dead sockets close fast and free up memory. Turn on health checks for every target pool to stop traffic to broken hosts. Log every socket open event, close event, and byte count to a central store. Finally, review your target lists each month to remove old hosts and unused ports.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between a TCP forwarder and an HTTP reverse proxy?
A TCP forwarder moves raw bytes at layer four without reading the app protocol. An HTTP reverse proxy works at layer seven and reads web headers, paths, and cookies.
Does a layer four server slow down database traffic?
It adds a very small network hop because it manages two separate TCP sockets. For most apps, this adds less than a few milliseconds when hosts share a region.
Can a TCP forwarder inspect SQL queries or mask data?
No, a standard layer four server only sees raw packets and port numbers. You need protocol-aware inspection to read SQL statements or rewrite emails and phone numbers in results.