Is there a way to hack the way Traefik deals with X-Forwarded-For headers?


I am using Traefik (v1.7.12, as an Ingress Controller in a kubernetes instance) as a gatekeeper to access another site (through a kubernetes service of type ExternalName) that I don’t control (a private status page on for the record, that has a very limited configuration regarding IP whitelisting).

I was expecting that the only IP that the target site would see would be the egress Nat IP of my cluster (in the context of a private GKE cluster with a Cloud Nat configuration so that all nodes are private only).

But it looks like the target site is using the X-Forwarded-For header to check the client IP, and for the moment, the values in the X-Forwarded-For header are [“real_client_ip, cluster_nat_ip”] (the real_client_ip is added by the GoogleLB in front of Traefik, the cluster_nat_ip is added by Traefik that sees the GoogleLB with the Google Nat IP)

As the real_client_ip is not whitelisted on the target site, the request is blocked (by the target site).


  • I already tried to use and but the result that I have is that the X-Forwarded-For value is added to existing one
    [“real_client_ip, cluster_nat_ip”,“cluster_nat_ip”]
  • I checked with the support of the site24x7 target site, and they confirmed they are using values in the X-Forwarded-For headers (/off : does-it only seem weak to me?)

My questions
Is there a way to hack (REPLACE and not ADD for instance) the content of the X-Forwarded-For?

Hello, have you try to use:

    address = ":80"

      insecure = false

This will remove all X-Forwarded-For value before Traefik.

Thank your for the suggestion, I did not try yet.

The solution I’m using for the moment is that I have setup a nginx between traefik and the final target host site, and I’m using a config to replace the existing X-Forwarded-For values (and yes, I’m sad because I had to start a nginx just for that)

It’s a hack of the forwarded-header, it’s an “internal” and undocumented option.
You can produce the same behavior with trustedIPs and an “impossible” IP.

The option will be applied only on one entrypoint, but if it’s your “main” entrypoint it’s an issue.

I think we need to add something to do that on v2 :smiley:

I already tried the “trustedIP with impossible IP” without success but I will try again in case of a PBCK issue.

Yes, definitely, it would be nice to add a per-ingress configuration for this kind of hack in traefik V2.

We really like Traefik, keep the good work going on folks!

1 Like