How to set X-Forwarded-For so that it contains the IP of the original caller?

1. Caddy version (caddy version):

v2.1.1 h1:X9k1+ehZPYYrSqBvf/ocUgdLSRIuiNiMo7CvyGUQKeA=

2. How I run Caddy:

Standard docker image

a. System environment:

Docker host: Ubuntu 18.04

d. My complete Caddyfile or JSON config:

	# acme_ca
} {
	reverse_proxy nextcloud:80

3. The problem I’m having:

Summary: it seems that the wrong X-Forwarded-For header is set when reverse-proxyfing.

Details: I run docker on One of the container is the official caddy image (it gets the IP) and another one is Nextcloud (

The logs of Nexcloud show all incoming connections from, despite using the X-Forwarded-For header.

To check at the source, I logged into the Nextcloud container and ran a tcpdump from there to see the details of the incoming HTTP packets. What I see is

X-Forwarded-For:\r\n is the docker bridge gateway, that is as seen from the other side of the bridge.

Anyway, this means that X-Forwarded-For does not contain the IP of the host that made the call (which would be in that case a host on What Nexcloud reports caddy as the caller is another thing - but the IP I am looking for is not in the X-Forwarded-For header anyway.

Now, the Caddy reverse proxy docs states that:

By default, Caddy passes thru incoming headers to the backend—including the Host header—without modifications, with two exceptions:

So here I am, stuck with the IP of the Caddy instead of the one of the host who made the actual call :unamused:

Since the more I test, the more it seems to be a bug (I still hope I am simply wrong - X-Forwarded-For is universally used in in the context of reverse proxies so I would be surprised nobody saw it before), I opened an issue at X-Forwarded-For does not contain the IP of the original caller · Issue #3661 · caddyserver/caddy · GitHub.

Note that manually setting X-Forwarded-For in the Caddyfile does propagate the right IP (the one set). It looks like the issue (if there is one) is that caddy does not set it automatically.

I was wrong. This must be a problem with Nextcloud.

I spun up a whoami container and the header is correct. In another container that logs the client IP the IP is correct as well.

Apologies for the noise - I thought that the tcpdump test was enough to confirm that the IP is incorrect but I will deep dive into the Nextcloud container to understand where the problem is.

The GitHub issue is closed as well.


Thanks for following up!

This topic was automatically closed after 30 days. New replies are no longer allowed.