Traefik Proxy Protocol

You set up traefik proxy protocol on your entry points to keep real client IP addresses. You must also list the trusted IP ranges of your upstream load balancer. Network teams use this setup when a load balancer sits in front of their cluster. Without it, your backend apps only see the internal IP of the load balancer. Teams often trust broad IP ranges to make this work fast. Broad trust rules let attackers spoof their IP address if they bypass the load balancer.

How traefik proxy protocol works in your network

Standard network hops rewrite the source IP address of each packet. When a user sends a request, the external load balancer takes that traffic first. It opens a new link to your ingress controller and sends the data through. This step hides the original user IP from your ingress logs and backend apps. The protocol fixes this issue by adding a small header to the TCP stream. This header holds the real client IP address and port number.

Your upstream load balancer and your ingress controller must both turn on this feature. First, you tell your cloud load balancer to prepend the protocol header to new links. Next, you update your ingress entry point settings to read that header. You must define a strict list of trusted IP addresses on that entry point. If the source IP matches your trusted list, the controller reads the header. If the source IP is not on the list, the controller drops or ignores the header.

Why trusting broad IP ranges creates security risks

Setting up the protocol requires careful control over your network rules. Anyone who can reach your ingress port directly can send a fake protocol header. If you trust all IP addresses on the entry point, you create a major hole. An attacker can send a forged header that claims a trusted internal IP address. Your backend apps will believe that fake IP and may grant admin permissions.

Teams often struggle to keep the trusted IP list accurate when cloud networks change. Load balancers scale up and down and pick up new internal addresses. To avoid broken traffic, engineers sometimes trust the whole internal subnet. That means any compromised workload in your network can spoof its IP address. You must lock down firewall rules so only the load balancer reaches the ingress port. You also need to audit your subnet rules whenever you add new network ranges.

What native network headers solve and what they leave open

Passing the real client IP solves a specific network visibility problem. Your web logs show where traffic comes from on the public internet. Rate limiting rules and geo blocks work as expected because they see the real IP. Security teams can trace bad web requests back to an external source address.

Still, network headers only tell you about the initial TCP link at the edge. They do not govern how engineers or services interact with internal databases and servers. An IP header cannot inspect the SQL queries or shell commands running inside a session. It also does not stop a valid user from pulling sensitive data like emails or card numbers. Even with accurate IP logs, you still have to manage static keys and broad roles across your stack.

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 happens if only one side turns on the protocol?

The link will fail right away and return errors to the user. Both the upstream load balancer and the receiving entry point must match settings. If only one side uses the header, the receiver reads the bytes as broken data.

Does this protocol work with UDP traffic?

Version two of the protocol supports both TCP and UDP network streams. Version one only uses plain text headers and works with TCP streams. Check what version your cloud load balancer sends before you set up your entry point.

How is this different from the X-Forwarded-For HTTP header?

The HTTP header only works for web traffic at the app layer. This protocol works lower at the TCP transport layer before any TLS encryption happens. That makes it work for any TCP service, including encrypted traffic and databases.

Related guides

• Sase Reviewer
• Sast Group
• Sast Provider