Selfhosted

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.

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

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]

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.

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

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.

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?