Proxy Tcp
You set up a proxy tcp service by opening a listener socket that forwards bytes. This server accepts client packets and sends them to a backend address and port. Teams often use a load balancer or reverse forwarder for this basic network routing. When teams grant broad network rules, any user on the subnet can reach the backend. Broad network permissions also let devs run risky queries once the socket opens. How a native proxy tcp setup works A transport layer forwarder works at layer four of
Database Proxy (ProxySQL, PgBouncer): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a proxy tcp service by opening a listener socket that forwards bytes. This server accepts client packets and sends them to a backend address and port. Teams often use a load balancer or reverse forwarder for this basic network routing. When teams grant broad network rules, any user on the subnet can reach the backend. Broad network permissions also let devs run risky queries once the socket opens.
How a native proxy tcp setup works
A transport layer forwarder works at layer four of the network stack. It does not read the app data inside the network packets. First, the client starts a three-way handshake with the listening port on the server. The server accepts this handshake and opens a first socket for the client. Next, the server opens a second socket to the target backend machine. It links these two sockets together in memory to pass raw byte streams. When the client sends bytes, the server copies them into the backend socket. When the backend replies, the server copies those bytes back to the client. The server tracks active state in a memory table using source and destination ports. When either side sends a close packet, the server tears down both sockets. Teams also set up idle timeouts to drop dead sockets that stop sending packets. Health checks ping the backend port to make sure it still accepts new handshakes.
What transport routing solves and where it falls short
Transport forwarding solves basic network routing and hides internal IP addresses from outside clients. It lets ops teams place databases and internal services inside private subnets. Teams can change backend IP addresses without asking devs to update their local client apps. It also spreads network load across several backend machines to stop single server crashes. Firewall rules become simpler because the backend only trusts the forwarder IP address.
Still, a layer four forwarder only checks IP addresses and port numbers. It decides which machine can open a socket, not which person is logging in. Once the socket opens, the forwarder stays blind to the commands moving through it. It cannot tell a safe read query from a command that drops a table. Teams still have to pass static database passwords and keys to every engineer. If an engineer leaves the team, admins must rotate those shared keys across every app. Network logs only show byte counts, socket durations, and source IP addresses. Auditors cannot see which user ran a specific query or read sensitive rows. Also, raw transport forwarding cannot rewrite sensitive fields like emails or card numbers in results. To control actions in flight, teams must check identity and parse the app protocol.
How to harden transport forwarding
Start by locking down source IP rules on the public listening port. Only allow traffic from known office networks or corporate virtual private networks. Next, turn on mutual TLS between the client and the listening server. Mutual TLS checks client certificates before the server opens a backend socket. Set strict timeouts so idle sockets close after a few minutes of silence. Limit the maximum number of open sockets per client IP to block floods. Ship all connection logs to a central log store for your security team. Pair your network forwarder with strict database roles that limit write permissions. Give read-only roles to devs who only need to check production state.
Database Proxy (ProxySQL, PgBouncer): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between a TCP forwarder and an HTTP reverse forwarder?
A TCP forwarder copies raw bytes at layer four without reading the protocol. An HTTP forwarder works at layer seven and reads headers, paths, and cookies. This lets it route requests based on URL paths and hostnames.
Does transport forwarding encrypt my network traffic by default?
No, standard transport forwarding only copies the exact bytes the client sends. If the client sends plain text, the bytes stay in plain text. You must add TLS termination or use end-to-end encryption inside the app protocol.
Why do my database sockets drop through a transport forwarder?
Most transport forwarders close sockets that sit idle past a set timeout. Databases and clients often keep pooled sockets open without sending any bytes. Turn on TCP keepalive packets so the forwarder knows the socket is still alive.