Wrong client IP in logs

[ajpanton]

Sitting behind a reverse proxy, the logs show the connecting user as having my reverse proxy's IP.

I currently have this config:

behind-reverse-proxy = true;
original-ip-header = "X-Forwarded-For";
trusted-proxies =
(
	"127.0.0.1",
	"::1",
	"192.168.0.0/16",
	"172.16.0.0/12"
);

but actually, changing these (trusted-proxies or behind-reverse-proxy) makes no difference whatsoever. Not to the logs, not to the functionality ("it just works" =)). I've tried with two different reverse proxies (hence the two IP ranges), but I've also tried to set the exact IPs without the subnet.

The only place where I can see these actually do something is the wt_config.xml file, which gets auto-filled with the config settings when the container starts.

Checking with my nginx webserver, which also sits behind the same reverse proxy, I can log the x-forwarded-for header, which does indeed contain the original client IP.

[epoupon]

Hello! Is it using the docker image? Can you check the lms log "User Xxx logged in from..."?

[ajpanton]

LMS is running in Docker, if that's what you meant.

[2025-Jul-13 20:28:16.372] 1 [/ HJolwiw5yDEsalEi] [info] - 140614873463608 [UI] User 'x' logged in from '192.168.x.x', user agent = Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0, locale = 'en-GB'

nginx webserver, also running in Docker alongside LMS, going the same route through the same reverse proxy, outputs this in its logs (variable $http_x_forwarded_for) remote.client.IP.address, 192.168.x.x

[epoupon]

Then I guess you have to trust docker's gateway IP adress, which is by default 172.17.0.1

[ajpanton]

That's included in 172.16.0.0/12 though. Not sure if it supports subnets, so added the gateway IP for the network LMS is on, the gateway for the bridge network (I have no idea what else to do at this point) as well as 172.17.0.1 and even 0.0.0.0 for good measure. No change.

[Kromtar]

@ajpanton I have exactly the same problem

[FibreTTP]

I think the issue is that Wt (the webapp framework used by LMS) most frustatingly ignores local IPs in the X-Forwarded-For header, so if you're accessing from a local IP, it's just going to use the direct client IP instead.

This is such a big oversight. I tried signing up to their issue tracker last year to report it, but I think I crashed their web server somehow and couldn't be bothered trying again.