Traefik Proxyprotocol
To set up traefik proxyprotocol, enable the protocol on your entry point and trust your load balancer IP. This rule tells the router to read the client IP from the TCP header. Teams often set up this flow when a cloud load balancer sits in front of their cluster. Without it, every log entry shows the load balancer IP instead of the real user IP. When teams trust wide IP ranges by mistake, attackers can spoof headers and bypass IP rules. How traefik proxyprotocol works in your network Standard
Traefik Middleware Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To set up traefik proxyprotocol, enable the protocol on your entry point and trust your load balancer IP. This rule tells the router to read the client IP from the TCP header. Teams often set up this flow when a cloud load balancer sits in front of their cluster. Without it, every log entry shows the load balancer IP instead of the real user IP. When teams trust wide IP ranges by mistake, attackers can spoof headers and bypass IP rules.
How traefik proxyprotocol works in your network
Standard network hops rewrite the source IP address of a packet as it travels. Your app only sees the IP address of the last machine that touched the packet. The HAProxy protocol fixes this issue by adding a small header at the start of a TCP connection. That header holds the true origin IP address and port of the user.
Both sides of the network hop must agree to use this header format. First, you turn on the feature on your cloud load balancer. Next, you set up the entry point on your ingress router to expect that header. If one side sends the header and the other does not expect it, the connection fails.
You also must define a list of trusted IP addresses on the router entry point. This list holds the private IP ranges of your upstream load balancers. When a packet arrives from a trusted IP, the router parses the header and updates the client IP. If a packet arrives from an untrusted IP, the router ignores the header to stop IP spoofing.
Managing trusted IPs for safe routing
Setting the right trusted IP range is the most important step in this setup. Many teams use a wide subnet mask because load balancer IPs can change over time. If that subnet also holds worker nodes or test pods, a bad actor inside the cluster can forge headers. They can pretend to come from an approved office IP address.
To keep this setup safe, place your load balancers in their own small subnets. Only add those exact subnet ranges to your router trust list. Check these rules whenever you change your cloud network layout. You should also test what happens when an untrusted host sends a fake header to your entry point.
Traefik Middleware Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What network headers solve and what they leave open
Preserving the client IP helps with rate limits, geo blocks, and basic audit logs. Your router can drop traffic from unknown networks before it reaches your web apps. Your log files will also show where web requests came from on the public internet.
Still, network headers only tell you where a packet started its trip. They do not tell you which person sent the request or what commands they plan to run. Once a user passes the IP check, the router forwards their traffic without checking the payload inside. If an engineer logs into an internal tool or database, the IP log cannot show what queries they ran. It also cannot mask sensitive fields like emails, phone numbers, or card numbers in query results.
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
Why do my connections break after enabling the protocol?
Both your upstream load balancer and your router entry point must turn on the feature at the same time. If only one side uses it, the router reads the header as bad data and drops the request.
What happens if I trust all IP addresses on the entry point?
Trusting all IPs lets anyone on the internet send a fake header to your router. Attackers can spoof their IP address to bypass your allowlists and rate limits.
Does this protocol work for UDP traffic in my cluster?
The second version of the protocol supports both TCP and UDP traffic streams. You must check that your upstream cloud load balancer supports version two before you route UDP packets.