Cloudflare Proxy Protocol
The cloudflare proxy protocol passes the real client IP address to your backend server. You turn this on in your edge network settings and update your server listener. Teams use this setup when routing raw TCP or UDP traffic through the edge. Without it, your backend server only sees the edge network IP address in logs. Still, many teams pair this network setup with broad backend roles and shared keys. Once traffic reaches the server, broad roles let users run almost any command. How the cloud
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 cloudflare proxy protocol passes the real client IP address to your backend server. You turn this on in your edge network settings and update your server listener. Teams use this setup when routing raw TCP or UDP traffic through the edge. Without it, your backend server only sees the edge network IP address in logs. Still, many teams pair this network setup with broad backend roles and shared keys. Once traffic reaches the server, broad roles let users run almost any command.
How the cloudflare proxy protocol works in your network
Standard web traffic uses HTTP headers to pass the original client IP address. Non-web traffic like SSH or database streams cannot use HTTP headers for this task. The cloudflare proxy protocol solves this problem by adding a small header to TCP packets. The edge network puts this header at the very start of the TCP stream. It holds the real source IP address, the destination IP, and the port numbers.
Your backend server must know how to read this extra header right away. You must set up both the edge network and the origin server together. If you turn it on at the edge only, your backend server will break. The server will read the extra header as bad data and drop the request. Teams can pick version one for plain text headers or version two for binary headers. Binary headers take less space and parse faster on busy backend servers.
What edge IP forwarding solves and what it misses
Passing the client IP address helps your team keep accurate network logs. Your firewall rules can check the real source IP before allowing a session. Your security tools can spot bad actors by their home IP address. Rate limiting on the backend server also works better with real client IP data.
Still, network headers only tell you where a packet came from. They do not tell you what the user does inside the session. Once the TCP stream starts, the edge network does not check individual database queries. A developer with a shared database key can still run a bad drop table command. They can also pull full tables with emails, phone numbers, and card numbers. Network routing decides which IP can reach the port, not which commands can run.
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.
Why teams must control queries and commands in flight
Many teams rely on IP allowlists and network headers as their main security check. That approach leaves the backend wide open after a user logs in. Shared database roles give every engineer the same high level of control. If an attacker steals a device on an allowed IP, they get full access.
To reduce risk, teams need control over each query and command in flight. Instead of trusting an IP address, you should check every action by user identity. Masking rules can rewrite emails, card numbers, and national IDs in query results. Approval workflows can pause risky commands before they hit the database engine. Combining edge IP routing with command-level checks keeps both your network and data safe.
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 runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values 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
When should my team use version one versus version two?
Use version one when you need human-readable text headers for quick network debugging. Use version two for production apps because binary headers parse faster with less overhead.
Why do my backend sessions drop after turning this setting on?
Sessions drop when the origin server is not set up to expect the header. You must turn on protocol parsing on your backend listener at the same time.
Does the cloudflare proxy protocol encrypt my database traffic?
No, the protocol only adds source IP metadata to the start of a stream. You still need TLS encryption to protect the data moving across the network.