With docker behind an existing reverse-proxy / application gateway.
a. System environment:
docker
b. Command:
docker
d. My complete Caddyfile or JSON config:
:443
log {
output stdout
format json
level info
}
tls /var/run/server.crt /var/run/server.key
reverse_proxy backend:80 {
header_up X-Forwarded-For {header.X-Forwarded-For}
}
3. The problem I’m having:
I run caddy behind a reverse-proxy/ application gateway. How can I make caddy “trust” the existing X-Forwarded-For and pass it on the backend?
4. Error messages and/or full log output:
Backend doesn’t get the original X-Forwarded-For header but the one generated by caddy (which is wrong, as it contains the first proxy/ application gateway ip).
5. What I already tried:
I tried to pass on the existing X-Forwarded-For header from the first proxy. Instead of the syntax used in the copied Caddyfile I also tried with “{http.request.header.X-Forwarded-For}”
That’s correct actually, that’s how the header is meant to work. It’s supposed to be a comma separated list of all the proxies the request went though.
I would call that a bug with your backend rather than a problem with Caddy.
Thank’s for you quick reply. I didn’t check if caddy actually overrides the header or appends its client’s ip. Anway, I want/ need to have Caddy transparent to the application, so it should be possible to make it not change the X-Forwarded-For header.
BTW: I think caddy needs to override the header, otherwise it’d be open for spoofing. Other servers allow to specify a list of trusted networks, from which they don’t override the header and pass it on.
Ok, I finally managed to get the backend application to figure out the correct client IP even when there are multiple ips in the x-forwarded-for header. Thanks for your support
