Passthrough Proxy
A passthrough proxy routes raw network traffic straight to a backend server without opening it. It reads the target address from the initial handshake and forwards the encrypted bytes. Teams often set up this routing method to expose internal apps or databases. They rely on the backend server to check keys, certificates, and user roles. Still, broad backend roles give users too much power once they log in. How a passthrough proxy routes network traffic In a standard setup, a client starts a n
Database Proxy (ProxySQL, PgBouncer): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A passthrough proxy routes raw network traffic straight to a backend server without opening it. It reads the target address from the initial handshake and forwards the encrypted bytes. Teams often set up this routing method to expose internal apps or databases. They rely on the backend server to check keys, certificates, and user roles. Still, broad backend roles give users too much power once they log in.
How a passthrough proxy routes network traffic
In a standard setup, a client starts a network session with the routing node. The routing node does not hold the private encryption keys for the destination service. Instead, it looks at unencrypted routing hints during the first step of the handshake. Server Name Indication is a common hint used in TLS traffic routing.
This plain text field tells the router which backend service the client wants. The router matches that name against a list of allowed backend addresses. Then it opens a raw TCP pipe to the right destination host. Every packet after that flows straight between the client and the backend server.
The backend system handles the TLS handshake and checks the user login credentials. Network teams like this design because it keeps private keys on the final server. It also cuts down CPU work on the middle routing nodes. The router never decrypts or re-encrypts the data stream in transit.
Where network routing works and where it falls short
Forwarding raw packets solves basic network reachability across private subnets. It hides backend IP addresses and puts one public entry point in front. It also satisfies strict rules that require end-to-end encryption up to the final host. If an attacker compromises the router, they do not find private TLS keys.
Yet this blind forwarding creates a huge gap for security and operations teams. Because the router cannot read the traffic, it cannot see what users run. It only knows that a client IP sent a certain number of bytes. It knows when the session started and when the session ended.
Database Proxy (ProxySQL, PgBouncer): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Once a developer or app logs in, the network tier goes blind. A user with a broad database role can run a destructive drop command. They can also pull tables full of emails, phone numbers, and card numbers. The router cannot block bad commands or rewrite sensitive fields in the query results.
Why backend roles alone do not stop risky actions
Teams try to fix this blind spot by creating stricter roles on the database. In practice, maintaining dozens of tiny roles across many servers takes too much time. Engineers often share a few strong accounts to debug live issues fast. Static permissions decide who can log in, not what each command does in flight.
Native database audit logs can record queries on the host itself. Still, turning on full query logs across every host hurts disk space and speed. Admins also have to collect and parse different log formats from every single engine. Even when logs work, they only tell you about a mistake after it happens.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between TLS passthrough and TLS termination?
TLS passthrough sends encrypted traffic straight to the backend without decrypting it. TLS termination decrypts traffic at the edge so the router can inspect the contents.
Can a passthrough router log database queries or shell commands?
No, it cannot read anything inside the encrypted stream. It only logs basic network details like IP addresses, ports, byte counts, and session times.
When should a team avoid using a passthrough setup?
Avoid it when you need to audit individual queries or block risky commands. You must inspect the traffic protocol to mask sensitive fields like national IDs in results.