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:
{
admin 0.0.0.0:2015
email xxx@xxx.xxx
# acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}
https://nextcloud.mydomain.eu {
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 192.168.10.2
. One of the container is the official caddy image (it gets the 172.19.0.31
IP) and another one is Nextcloud (172.19.0.23
).
The logs of Nexcloud show all incoming connections from 172.19.0.31
, 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: 172.19.0.1\r\n
172.19.0.1
is the docker bridge gateway, that is 192.168.10.2
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 192.168.10.0/24
. 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:
- It adds or augments the X-Forwarded-For header field.
- It sets the X-Forwarded-Proto header field.
So here I am, stuck with the IP of the Caddy instead of the one of the host who made the actual call