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.

I’m not quite sure where this goes. It’s Nginx Proxy Manager (in case that affects your answer compared to vanilla nginx), and I’m using Docker Desktop for much the same reason: I’m doing as much configuration via GUI as possible. Is this a Docker configuration or an Nginx Proxy Manager configuration? There is a “Custom Nginx Configuration” screen for my Proxy Host; does it go there? In a nested location block?

I really don’t know shit about the GUI tools, but presumably they overlay on the same configuration.

The config I posted would be part of the nginx configuration. You’re instructing it to append the client IP to the X-Forwarded-For header.

There is a “Custom Nginx Configuration” screen for my Proxy Host; does it go there? In a nested location block?

I doubt it, but I’m not sure. The location block would normally be where your reverse proxy configuration would already be, and you’d need to just add that one line. But again, I don’t know how that translates to these GUI tools. Maybe if you search for proxy_add_x_forwarded_for and “Nginx Proxy Manager” you might find what you need.

I know you said you don’t know anything about the GUI equivalent, so I’m mostly responding to this comment to publicly post how far I’ve gotten off of your tips. There is a “Custom Locations” tab for my proxy host in NPM, but even after attempting to follow this guide I found, I can’t get my custom locations to persist after hitting the Save button.

EDIT: I was leaving out the path on the location, so now that that’s corrected, it saves my changes, but I’m not seeing any progress in the IP address reporting.

Try setting this in advanced settings:

proxy\_set\_header Host $host;

proxy\_set\_header X-Real-IP $remote\_addr;

proxy\_set\_header X-Forwarded-For $proxy\_add\_x\_forwarded\_for;

proxy\_set\_header X-Forwarded-Proto $scheme;

Still the same problem, I’m afraid. I also experimented with putting some of this stuff in the Custom Locations section of NPM’s proxy host settings, since that’s how it looks in Jellyfin’s nginx guide. The only feedback that I got at any point that my changes in NPM were doing anything at all was when my mobile app failed to connect to my server because of how I’d mucked around in there; I did delete those changes before adding your suggestions, of course.

Long shot but you might’ve solved the nginx x-forwarded header multiple times without seeing it if the nginx proxy is behind the same bridged docker desktop system setup on your minipc then the visitors IP will show as 192.168.65.1 to the nginx proxy too so you forward that same ip to jellyfin even when it works.
An easy check would be to spin up nginx as a vm instead of a nginx reverse proxy docker image and see if it works.

No real solution, but a lot of chatter regarding that:
github.com/NginxProxyManager/…/674

Thanks, there’s a lot to read through in there, so I’ll see what, if anything, I can apply from it.

The main point was that if your mini-pc running the proxy is also behind a windows docker desktop install it too will have incoming connections appear as 192.168.65.1.

A solution then is to switch to a linux docker host where you can get rid of that hidden NAT. There are many webuis for docker such as dockge and portainer on linux without having to use the terminal.

My preffered solution would be to switch to a router/firewall with reverse proxy support such as opnsense with haproxy and skip the nginx proxy manager completely.
Having the proxy configured in the same UI as vlan, port forwarding, nat rules and so on is nice. opnsenselab.com/…/opnsense-haproxy-reverse-proxy/

I have an OPNsense firewall, but I didn’t know it could do that. I was just following guides for the easy route for most of this stuff.

Congrats! Then you have a guide for an easy reverse proxy right inside your router. :)
Try it out and see if that doesn’t fit you better than the nginx proxy manager.

It looks like it’s a community plugin that’s not there out of the box, but it is for sure one more tool I have in my tool belt to solve this. Thanks for the tip!

ssl.conf

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?

When you say “when accessed from outside my home network”, what kind of access is that? Port forward? VPN?

Accessing via 443 forwarding to my reverse proxy from the internet. My dad will hit my Jellyfin server from his house, and I can hit that server from mobile networks when I’m not on wi-fi.

Is 192.168.1.1 your router?

Yes. It’s also .10.1 on the 10 VLAN.

What’s your LAN netmask?

255.255.255.0 on both VLANs

NPM listens on 192.168.10.201 ports and Jellyfin/Komga on 192.168.10.202 ports?

Correct.

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?

Correct. Jellyfin is actually listening on a different, auto generated, arbitrary port that I just stuck with, but other than that, you got it.

I did check every IP address I could find anywhere on my network and couldn’t find the 192.168.65.X anywhere, but @anamethatisnt@sopuli.xyz here in this thread seems to have identified this as some NAT setting built in to Docker. Running on default settings for network, because I had no idea why I would want to modify any of those settings, they are running as bridge networks.

seems to have identified this as some NAT setting built in to Docker

TBH I also thought about it being the default range used by Docker for its bridge networks, but I was under the impression it uses 172. ranges by default. The official example on their site says it uses 172.30.0.0/16 and 172.31.0.0/16. Also I have an unmodified docker running on one of my machines and it allocated 172.18.0.0/16 for a bridge network.

You can try to docker network create a bridge network and see what range it gets, you’ll see if it gets a 172. or a 168..

BTW I hope you’re looking at the docker on the reverse proxy machine, not on the jellyfin machine.

The answer was the same on both machines. A 172.17.0.X network was created as a bridge.

Hope you saw my other comment. Docker now also makes 192.168. networks in addition to 172. I’ve explained how to edit your daemon.json to stop it from doing that.

I can take a look after work, but won’t that just change the proxy’s IP listed in my logs instead of properly forwarding along the source IP address?

Yep, you’ll have to fix that by telling your proxy to put the client IP in a header that the target app can recognize and use:

developer.mozilla.org/en-US/…/X-Forwarded-For

But, also, it’s a good idea to have Docker network ranges that don’t overlap your LAN. That would make me uncomfortable too.

You can also look into using IPv4 link-local addresses for Docker bridges (169.254.). Here’s an explanation:

github.com/11notes/RTFM/blob/master/…/daemon.md#n…

That frees you from accidental overlaps with pretty much everything else, but it comes with its own gotcha: link-local isn’t routable. This can come back to bite you if you have an app that relies on announcing a public UDP ip:port to a peer and announces the link-local IP. When a peer tries to connect back, it won’t work. So you have to either tweak the app’s config to make sure you announce a non-169.254. IP, or put the app container on a bridge/macvlan network so it auto-detects and announces a routable IP. There’s all kinds of apps that can be affected by this kind of peer-to-peer behavior (file transfer apps, games, VoIP apps etc.)

But TBH I’ve been using link-local ranges for a while now and only got bitten once (Deluge).

Yep, you’ll have to fix that by telling your proxy to put the client IP in a header that the target app can recognize and use.

I thought that’s what I was trying to do by adjusting both NPM proxy host settings as well as informing Jellyfin where to expect proxy headers from.

But, also, it’s a good idea to have Docker network ranges that don’t overlap your LAN. That would make me uncomfortable too.

Does it overlap my LAN? Is 192.168.65.X not distinguishable from my defined subnets with a 24-bit mask, now that I know where they’re coming from?

And to be honest, you’ve talked past my understanding with a lot of that paragraph, so I’ll have to comb through it later tonight when I have more time. Keep in mind that all of my Docker network settings are default, so it’s a setting I’ve never dabbled with. From what I can tell from the settings it defined on its own, these containers created a 172.17.0.X address, and somehow the proxy responds with (“announces”?) a 192.168.65.1 address. Are you saying that I need to define for it an unused address that’s on my existing 10 VLAN? Somehow all of the tutorials I’ve found in the past months to set up services behind a reverse proxy never mentioned any of these gotchas with Docker and networks.

Yeah that’s because most people are under the impression that Docker only allocates 172. addresses for its bridge network. I was under that impression too.

Turns out it also allocates 192.168 addresses.

Does it overlap my LAN? Is 192.168.65.X not distinguishable from my defined subnets with a 24-bit mask, now that I know where they’re coming from?

The problem is that the default says 192.168.0.0/16, so it can also generate overlapping addresses. The fact it generated a 192.168.65.x address instead of an 192.168.1.x address was pure luck.

Somehow all of the tutorials I’ve found in the past months to set up services behind a reverse proxy never mentioned any of these gotchas with Docker and networks.

The common-sense assumption is that you will adjust your Docker daemon settings so that you prevent overlap with your LAN. (Also, I expect lots of tutorials aren’t that high quality to begin with.)

If you edit daemon.json like I explained and explicitly only put 172. ranges in there you should be safe from overlaps in the future.

The common-sense assumption is that you will adjust your Docker daemon settings so that you prevent overlap with your LAN. (Also, I expect lots of tutorials aren’t that high quality to begin with.)

I would say a high quality tutorial doesn’t assume that I know anything about Docker, and most of them didn’t (which is good, because I don’t), but they also didn’t seem to expect me to want better logging out of my hosted services. Thanks, the /16 subnetting makes sense. I’ll try to edit that json file later today. But we seemingly don’t expect this to fix the problem by itself, so other than telling Jellyfin to expect a proxy at the new reported IP address, what should I expect for next steps?

Need to edit the proxy host for Jellyfin in NPM (advanced tab) and send the X-Forwaded-For header to it.

proxy_set_header X-Forwarded-For $remote_addr;

And also in Jellyfin settings you have to set the IP that it sees the reverse proxy coming from as a “known proxy”, so it knows it can trust that header when it comes from that IP.

jellyfin.org/docs/general/…/reverse-proxy/#forwar…

Alright, I did all of the above. I added the proxy_set_header line to Custom Nginx Configuration for the Jellyfin proxy host by hitting the gear in the upper right of the edit window.

The daemon.json file wasn’t on my mini PC (where NPM lives), so I made a new one with those contents sans the 192.168 line. It was already present on my NAS (where Jellyfin lives), but only with a few other lines that weren’t our default-address-pools. I appreciate your previous instructions not assuming that I know the structure of a JSON file, but I do work with them a lot for my day job, so I was comfortable appending to that file on the NAS (though I did have to re-learn some vim basics to do it).

Anyway, after making those daemon.json file changes, I rebooted the whole machine in both places, not just Docker. That should be enough to make any IP addresses refresh themselves, right? But Jellyfin logs still show access coming from 192.168.65.1. I do find it strange that a container would be using an IP address like this one without reporting it somewhere, but in the Inspect tab of Docker Desktop on the mini PC, it just shows that 172.17.0.X address (2 for IPAddress, 1 for Gateway).

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.

docs.docker.com/desktop/features/networking/#how-…
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.

@ampersandrew@lemmy.world

Thanks!

@lemmyvore@feddit.nl , I already made the JSON file changes, but seeing as this hasn’t changed in Jellyfin reporting after doing so, I think we can point to this as being authoritative for how it appears in Jellyfin logs. But I do have it listed as a known proxy, and I added that X-Forwarded-For header to NPM, so I’m not sure what else I’m missing. With a /24 subnet, this IP address is probably safe though, right?

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

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.

I’ve got a document labeling everything, but I’ve kept my circle small and only expanded out as I conquered the last challenge. The reason I haven’t installed a third service yet is because I don’t have the IPs properly reported yet. I know exactly which machine, IP address, and port each service can be found at.

Draw it!!!

I honestly don’t think I have to. I’ve only got two machines, and I don’t think it’s going to expand any farther than that. And I’m not sure how that helps me with this problem.

Comes to internet for help
Handed a path to a solution
shoots footgun

I’m not trying to be rude. I genuinely don’t see the path between that map and the solution to this problem. Do you need it for your benefit to assist me?

EDIT: This is the best I can do against your instructions with no example. There’s a fair bit of your instructions I don’t understand. 443 is forwarded from the router to the mini PC in this diagram. I don’t know how to draw red lines perpendicular from the client PC to the mini PC, but that’s where it’s going from and to. I’m more concerned with traffic coming from the internet and making its way to Jellyfin.

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.

Yeah, that appears to be the case from a link someone else linked here, but I was unable to trace that from anywhere I could find in my containers before.

I am trying to fix the logs so I can see the origin of connections to my services, but I’ve been unsuccessful in getting additional configurations to resolve that.

Well… it’s the default iirc (192.168.65.0/24). So that’s what docker uses if there is no explicit configuration you could find.

It appears to be, but I didn’t know that until today. And beyond that, I’ve been trying every permutation of both that IP and the IP of the server on my network in my Jellyfin proxy settings, and it still hasn’t helped to surface the origin IP address.

Is it?! I always thought that Docker uses 172.16.0.0/16 by default for its networks. Did that get changed at some point?

That’s what the documentation says. I don’t know if/when that changed as I barely use docker.

Well I’ll be damned, there’s a 192.168. tucked away at the end of the 172. ranges:

docs.docker.com/engine/network/#automatic-subnet-…

{
  "default-address-pools": [
    { "base": "172.17.0.0/16", "size": 16 },
    { "base": "172.18.0.0/16", "size": 16 },
    { "base": "172.19.0.0/16", "size": 16 },
    { "base": "172.20.0.0/14", "size": 16 },
    { "base": "172.24.0.0/14", "size": 16 },
    { "base": "172.28.0.0/14", "size": 16 },
    { "base": "192.168.0.0/16", "size": 20 }
  ]
}

I think I’ve figured it out. Apparently now Docker also adds an 192.168. range on top of 172. ranges for its bridge networks:

docs.docker.com/engine/network/#automatic-subnet-…

Copy that example to your /etc/docker/daemon.json on all your docker machines, without the 192.168 line, and restart docker, and the 192.168.65. addresses will go away.

(Don’t forget to remove the trailing comma on the last address line.)

Mind you, this won’t solve anything, just remove some potential conflicts with your LAN. You will still see clients appearing to come from bogus addresses, except they’ll be in 172. ranges now.

Im first year selfhoster, I’ll try my best. Do you run your containers in a vm, or lxc? In your Nginx compose file, whats your network mode and is it under ports 443:443? In jellyfin is also X:X or else. Did you forward 443 on your router to your minipc 192.168.10.201:443. Maybe something to do with VLANs? And its the VLAN ip range or something.

My containers are run in Docker on the metal, not in a VM. My network settings are defaults, which ends up being bridge mode. And yes, my router forwards 443 to NPM listening on 443. It all works except that it’s losing the origin IP address in the logs.

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

Sorry, Linux is the host OS. It’s Debian.

Sorry, it was late and I was thinking back to my issues with Docker Desktop for Windows. But actually, it doesn’t matter if you’re using Windows or Linux for the host OS. Docker Desktop runs in a VM regardless: Reference I think that’s where this random IP is coming from.

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

Fewer Letters More Letters DNS Domain Name Service/System NAS Network-Attached Storage NAT Network Address Translation UDP User Datagram Protocol, for real-time communications VPN Virtual Private Network nginx Popular HTTP server

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]

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

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