Tcp Proxy Protocol
The tcp proxy protocol passes the real client IP address across network load balancers. You enable it on both the sender and receiver to keep source network details intact. Teams use this standard when a load balancer sits in front of backend servers. Without it, backend logs only show the internal address of the load balancer. Still, network headers only track the machine address and cannot limit broad user roles. How the tcp proxy protocol works in network routing When a load balancer forwa
Database Proxy (ProxySQL, PgBouncer) + Model Context Protocol (MCP) Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
The tcp proxy protocol passes the real client IP address across network load balancers. You enable it on both the sender and receiver to keep source network details intact. Teams use this standard when a load balancer sits in front of backend servers. Without it, backend logs only show the internal address of the load balancer. Still, network headers only track the machine address and cannot limit broad user roles.
How the tcp proxy protocol works in network routing
When a load balancer forwards traffic, it opens a new link to the server. This action hides the original client IP address and port number from the backend. The protocol fixes this problem by adding a small header at the very start. As soon as the link opens, the sender writes the client address and port. The backend server reads this first line before it processes any normal traffic.
This standard exists in two versions for different network needs. Version one uses plain text that humans can read during basic network checks. Version two uses a compact binary format that parses faster for high traffic systems. Version two can also carry extra details about the transport layer and encryption status. Both versions send this metadata once at the start of each new stream.
How to set up senders and receivers safely
Both sides of the network link must agree to use the protocol at once. If the sender writes the header without the receiver knowing, the stream will break. The receiver will misread the header bytes as corrupted app data and drop it. If only the receiver expects the header, it will reject normal traffic right away. Teams must update the load balancer and the target service during the same window.
You also need strict firewall rules to protect any port that accepts these headers. Anyone who can reach that port directly could fake the header and spoof addresses. Your firewall must block public traffic from hitting the backend server port on its own. Only your trusted load balancers should have permission to send traffic to that port. This network lock ensures that the source IP in the header stays trustworthy.
Database Proxy (ProxySQL, PgBouncer) + Model Context Protocol (MCP) Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What source IP forwarding solves and what it leaves open
Preserving the client IP helps teams run IP allowlists and write accurate network logs. Your backend database or app server can see which subnet started the network stream. Security tools can block unknown regions or rate-limit bad IP addresses at the edge. Compliance teams also get the origin network address they need for basic log reviews.
Still, a network header only tells you where a packet came from on the wire. It does not tell you which engineer or service account owns that session. Once the network check passes, the user logs in with a shared database role. The protocol cannot see or control what queries or commands run inside that stream. An approved IP address can still run a bad delete query or dump tables. To protect raw data like emails, phone numbers, card numbers, or national IDs, teams need controls that inspect requests in flight.
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 beside the service as an open-source proxy, a sidecar for your database or API.
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 review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Does the tcp proxy protocol encrypt network traffic?
No, the protocol only adds a source address header at the start of a stream. To encrypt data in transit, you must still set up TLS on your servers.
What happens if a client connects directly to a port expecting the header?
The server will fail to parse the missing header and close the link right away. Always put a firewall rule in place so only your load balancer reaches that port.
Can this protocol track which database queries a user runs?
No, it works at the transport layer and only runs when the stream first opens. It cannot read SQL statements, check user identity, or rewrite sensitive fields in results.