You’re gonna want to configure nginx to send along an X-Forwarded-For HTTP header (there’s also Forwarded, but it’s not as well supported yet). An example in a location block:

location / {
    proxy_pass http://backend/;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Looks like Jellyfin supports it.

the 192.168.65.1 address that manifested out of nowhere

Or it’s indeed the internal virtual lan your docker config uses…

Is that an actual problem or are you really just trying to fix the logs? That should be doable via headers so the real origin is preserved independent of proxying.

https://docs.docker.com/desktop/features/networking/#how-containers-connect-to-the-internet
I think your discord friends are right.

Outbound traffic from the container is sent through Network Address Translation (NAT) using a virtual adapter (typically with an internal IP such as 192.168.65.3). You can view or change this with the Docker Desktop settings.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

6 acronyms in this thread; the most compressed thread commented on today has 14 acronyms.

[Thread #126 for this comm, first seen 12th Oct 2026, 07:30] [FAQ] [Full list] [Contact] [Source code]

Docker desktop for Windows is a bad option for running a reverse proxy since Docker desktop actually runs inside a VM on your Windows host. Because of this it has no direct access to the network interface. So even if you run your reverse proxy container in host mode, the VM that is running Docker desktop still uses an IP handed out by Windows rather than the Windows host IP. 192.168.65.1 is the IP address Windows gives the WSL VM that runs Docker on your Windows box. I’ve had the same problem myself, and the only way that I found to fix this is to use Linux for the host OS. Reference

The way a reverse proxy works is to literally stand in the middle of a connection, so either side only sees them communicating with the proxy, oblivious to the actual endpoint. The only “solution” to this, though it’s more of a hack really, is to somehow send the original IP as additional data in a way that both sides agree on, e.g. the X-Forwarded-For header as others have mentioned, however, as I’ve said, both sides need to support and aggree with that, so you may have to find a setting/config to enable on the services behind the proxy. Think of it this way, if services blindly trusted that header and you weren’t using a reverse proxy, a bad actor could send a request to your service with that header included thereby spoofing their identity in your logs, therefore, this kind of thing is usually opt-in

What your looking for is x-forwaded-for, that http tells an upstream server what the client IP is.

My guess is your docker network might be 192.168.68, there for the client IP you see is in that network.

deleted by creator

If NGINX proxy manager is a docker container on the same machine as your other services you can point it to http://172.17.0.1/ and then the port number. And then the domain can be duckdns or whatever you’re using without the http.

Draw a network map!!! It’s what I’ve done on every security engagement, ever. Mark out all your IP addresses, draw lines to denote the communicating RHP (random high port) against the well-known, e.g. 443/tcp HTTPs, for networks of hosts to servers. Then draw boxes around those IP spaces that are colocated on the same box. Then draw red lines perpendicular to every connection from a client to server that isn’t bounded on a single host.

The red lines denote non-localhost traffic - places to be observed, and for the most part the only IP:port assignments you should be relying on for routing.

My rec, draw the map and if that doesn’t help get back to us w it - or feel free to dm me.

Edit: I’ll find and post an example as a response this thread later.