Hello everyone, I have another question regarding reverse-proxying again, specifically for the linuxserver.io jellyfin image.
On the dockerhub page for this image there are 4 ports listed which should be exposed:
- 8096 for the HTTP Web UI
- 8920 for the HTTPS Web UI
- 7359/udp for autodiscovery of jellyfin from clients
- 1900/udp for service discovery from DLNA and clients
Additionally there is also an environment variable JELLYFIN_PublishedServerUrl which is for “Setting the autodiscovery response domain or IP address”. I currently have that set to my subdomain https://jellyfin.mydomain.com though I am not sure if that is correct.
I already have a reverse-proxy set up allowing me to access my servers webinterface under https://jellyfin.mydomain.com without exposing the https port on the container. What I am unsure about now however, is what to do with the two ports for UDP traffic.
By my understanding, a reverse-proxy will only forward traffic which comes to the ports 80 for http and 443 for https. Those are also the only ports my reverse-proxy container has exposed alongside the management interface. As such the 2 udp ports will not be reachable under my jellyfin domain.
How can I change this or is this even an issue?
You must log in or register to comment.
Don’t worry about the UDP ports, they’re only needed on the LAN and only in certain conditions. Basically Jellyfin uses them to “announce” things to the LAN.
On 7359 it announces clients where to connect; this can help you when first starting a client to let it connect automatically instead of you having to enter http://IP or https://jellyfin.mydomain.com.
On 1900 it advertises itself as a DLNA server. This is only relevant if you have other DLNA-capable devices. DLNA is a cool protocol that allows devices to act as server, controller or renderer and to cooperate to cast streams. For example you can use your phone as a DLNA controller to get media from Jellyfin acting as a DLNA server and cast it to a TV acting as a DLNA renderer. If your TV has DLNA capability then you may be interested in the BubbleUPnP phone app which can act as a controller, and that’s when you may be interested in enabling 1900.
Or you can comment out the “ports:” section in your config and say “network_mode: host” instead and all 4 ports will be mapped automatically and work as intended (it’s what I do).
Good to know. I thought there was some issue with those ports and the reverse-proxy because the DLNA function doesn’t seem to be working but from some googling this seems to be more of a docker problem in general when you are not using host mode for networking.
I believe the UDP ports are for discovery on your local network so no need to handle them with your reverse proxy. If you’ve got them passed through docker your local devices should pick them up.
They’re also not required since you can always just enter the address manually. I don’t bother passing them into my container.
So far so good. The URL is correct, because its the external address. You also don’t need to publish both http and https ports. I only map external https to internal http but you can do https to https. No serious modern browser tries http first and because I always force https anyways, it doesn’t need to be public. Only the reverse proxy may need it, for Let’s Encrypt.
Both UDP aren’t needed for public access. I only have mapped 8096 to my reverse proxy and it works.
