My point is that this is not a problem with caddy, because at least two reasons:
-
I have 30 containers, many of them log the incoming IP. The IP they log is the client one, retrieved though X-Forwarded-For
(which is the de-factor standard: X-Forwarded-For - HTTP | MDN).
The whoami
container also shows the right header being passed.
-
When you take a network trace in the caddy container, here is what you see when there is a call to nextcloud (172.19.0.23):
172.19.0.31.56186 > 172.19.0.23.80: Flags [P.], cksum 0x5bd7 (incorrect -> 0xb673), seq 1356374864:1356375716, ack 1753153869, win 618, options [nop,nop,TS val 3060191419 ecr 2639773560], length 852: HTTP, length: 852
PROPFIND /remote.php/dav/files/michael/ HTTP/1.1
Host: nextcloud.MYDOMAIN
User-Agent: Mozilla/5.0 (Windows) mirall/2.6.4stable-Win64 (build 20200303) (Nextcloud)
Content-Length: 105
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: fr-FR,en,*
Authorization: Basic bWlja...0Q=
Content-Type: text/xml; charset=utf-8
Cookie: oc_sessionPassphrase=bbXZJ...wjk; nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true; ocflnf1ody3y=7ef75e330054749d600f595009f72a33
Depth: 0
X-Forwarded-For: 192.168.10.251
X-Forwarded-Proto: https
X-Real-Ip: 192.168.10.251
X-Request-Id: 5b27c480-e5e6-4b79-a208-4ff6ef237d58
So there is no miracle: the packet that leaves caddy holds the right header.
It then arrives to Nexcloud. There is something which exposes port 80 - Apache I guess. I believe that this is also Apache that logs the call:
172.19.0.31 - michael [28/Aug/2020:11:19:00 +0000] "PROPFIND /remote.php/dav/files/michael/ HTTP/1.1" 207 1103 "-" "Mozilla/5.0 (Windows) mirall/2.6.4stable-Win64 (build 20200303) (Nextcloud)"
At some point Apache must make the decision on which IP to log, this is (again, I believe) decided in the configuration when I write
'trusted_proxies' =>
array (
0 => '172.19.0.31',
),
'proxy' => '172.19.0.31',
'forwarded_for_headers' =>
array (
0 => 'HTTP_X_FORWARDED_FOR',
),
According to Reverse proxy â Nextcloud 15 Administration Manual 15 documentation
A reverse proxy can define HTTP headers with the original client IP address, and Nextcloud can use those headers to retrieve that IP address. Nextcloud uses the de-facto standard header âX-Forwarded-Forâ by default, but this can be configured with the forwarded_for_headers parameter. This parameter is an array of PHP lookup strings, for example âX-Forwarded-Forâ becomes âHTTP_X_FORWARDED_FORâ. Incorrectly setting this parameter may allow clients to spoof their IP address as visible to Nextcloud, even when going through the trusted proxy! The correct value for this parameter is dependent on your proxy software.
I work in IT, I know that Nextcloud is a complex piece of software - but at some point there are objective tests which show that data flows in and that with a specific configuration - the result is not the expected one.
It is probable that the configuration of my docker instance does not have the magical environment, or that it is incompatible with the configuration but taken into account the number of people on Internet who try to get the right IP and fail (or manage though an undocumented combination of configuration items) is at least surprising.