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

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.

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

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

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.

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 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.

In addition to configuring x-forwaded-for in NPM as suggested by others, you will also need to add 192.168.65.0/24 under Dashboard > Advanced > Networking > Known Proxies in Jellyfin.

deleted by creator

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.

Just to understand better:

• When you say “when accessed from outside my home network”, what kind of access is that? Port forward? VPN?
• Is 192.168.1.1 your router?
• What’s your LAN netmask?
• NPM listens on 192.168.10.201 ports and Jellyfin/Komga on 192.168.10.202 ports?
• A connection from the outside comes through the router, gets forwarded to 192.168.10.201:443, the proxy sends it to 192.168.10.202:8096, and it shows up in the Jellyfin logs as coming from 192.168.65.1?

If all of the above is correct I would look at the network interfaces that are up on the mini-PC and the NAS, as well as inside the containers of the proxy and of Jellyfin, and see if there isn’t a 192.168.65.1 up on there somewhere for whatever reason.

You can also try making a manual request (wget, curl, nc) from the proxy container to Jellyfin and see what it shows up as.

May also want to see what’s the DNS situation in your LAN and on those machines. You mentioned “names” being used, how are those defined and resolved?

Last but not least are the containers you mentioned using docker bridge networks or ipvlan?

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.