As others have mentioned, a reverse proxy, like nginx or caddy. These are web servers, so you need to configure it or an app that runs in it. May I shill: Nginx Proxy Manager (NPM).
this post was submitted on 23 May 2026
190 points (97.0% liked)
Selfhosted
56958 readers
1339 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 3 years ago
MODERATORS
If client certificates and basic auth is not supported by jellyfin:
- reverse proxy
- strong random subdomain
- wildcard certificate
- tls1.3 only
- doh/dot only
1-3 make random scanners unable to find your service, 4&5 even hide it from your ISP. Dot/doh service will still know your subdomain, so be your own dot/doh ! :D
load more comments
(5 replies)
Run the jellyfin in a container that only has read privileges to the videos ( make sure you can't get out to your whole NAS from there), put that behind a Cloudflaired tunnel.
It's not technically secure, but if they can't get a foothold in your network and the only thing they can access is your video catalog, that's a reasonable amount of risk.
load more comments
(4 replies)
Ask them to visit https://ipv4.icanhazip.com/ and give you back the number, then whitelist in your webserver, as well as your LAN/VPN range, deny rest. Explain they can only reach jellyfin from their home internet. Repeat if they get 403 forbidden after they get a new WAN IP.
That or VPN like openziti, wireguard but gets more complicated.
This is solid. I wonder if you could rig up a ddns somehow to keep it seamless?
load more comments
(3 replies)
For a remote and non-technical user I would say IP whitelisting offers a decent tradeoff.
On your end you expose your jellyfin port to internet, but restrict at the router level to your user's client IP address as soon as you have it. Obviously in practice this works best if the address does not change often.
Also not as ideal if their ISP uses CGNAT. Still waaay better than fully open, but you would be giving access to many households
Yep, that's why I call that a tradeoff. Far from perfect and yet so much better than nothing.
Pros:
- Likely cuts 99.99% of attacks.
- Nothing to do on client's end.
Cons:
- Whitelisting must be updated everytime the client address changes.
- Not 100% bulletproof as operators (notably for mobile networks) can NAT multiple connections behind a single publicly addressable IPv4 address.
- Also IP addresses can be spoofed but I doubt that would be a major concern here.
Is there a way to this with like a MAC address instead of an IP? Allowing specific devices (my parents have a Firestick that they travel with) would be pretty ideal.
No, not for remote access over the internet.
Perhaps (and I know I might be weird) running pangolin on something like hetzner? (Which I do)
load more comments
(3 replies)
At the very minimum stick a reverse proxy in front like caddy, nginx, or Traefik. Then have some middleware like crowdsec to inspect what's going on. Then whitelist the IP or the country IP block.
There is much more but those would be the bare minimum.
load more comments
(1 replies)
If anyone has any tips for getting Tailscale running via Docker on my Openmediavault machine, I'm open to it. Everyone lauds it for being dead simple and I cannot for the life of me get it running on the machine it needs to be. Not sure my wife can/will handle anything more complicated.
Just read their actual documentation. You'll want to either way.
Secure is relative, you should be aware that jellyfin itself has security issues https://github.com/jellyfin/jellyfin/issues/5415 most of which are harmless, but at least one is fairly serious and allows people to watch your media without authentication, and adding an extra layer of authentication on the proxy would likely cause issues with clients.
That being said, if you're okay with those security issues what I would do is have a cheap VPS, connect both machines to tailscale, and have something like Caddy on the VPS to do the forwarding.
Just leaving this here
Now, let's address this clearly once and for all. What is possible is unauthenticated streaming. Each item in a Jellyfin library has a UUID generated which is based on a checksum of the file path. So, theoretically, if someone knows your exact media paths, they could calculate the item IDs, and then use that ItemID to initiate an unauthenticated stream of the media. As far as we know this has never actually been seen in the wild. This does not affect anything else - all other configuration/management endpoints are behind user authentication. Is this suboptimal? Yes. Is this a massive red-flag security risk that actively exposes your data to the Internet? No.
https://github.com/jellyfin/jellyfin/issues/5415#issuecomment-2825240290
It really seems overblown of an issue...
Except most people have almost the same structure because of media organizers like radarr/sonarr. At the very least they should hide that behind a setting to not require auth (since the header should be there for most clients) so only people running an old client would be affected. They could also add an extra salt to that hash or something similar.
I agree, it's not critical, but it shouldn't be hand waved either. And like I said, security is relative, I would argue for most people this is fine, but I still think this should be taken more seriously.
load more comments
(5 replies)
load more comments
(1 replies)
load more comments
(6 replies)
Set up a reverse proxy with https always on. And get a good (physical) firewall, preferably something akin to opnsense, pfsense, openwrt. Exposing is always a risk, and if you do want it, you have to bear the responsibility for your own security. Keep things up to date, set up monitoring and a good logging system (Wazuh) comes to mind.
Exposure means a security risk. How you deal with that security risk is your choice.
Cloudflare and the likes forbid usage of their stuff for these things.
load more comments
(9 replies)
Reverse proxy with auth in front of the actual jellyfin login. Like pangolin.
load more comments
(16 replies)
Possibly mTLS, which you'd configure in your reverse proxy. You could email them the certificate and instructions on installing it. I believe for Chromium browsers on Windows you basically just double click the cert and click through the wizard. Firefox I know has a thing in the settings for importing the cert. Android you just tap on the cert and make sure it opens with 'Certificate Installer' if it gives you the option.
load more comments
(3 replies)
Not at all, there's legal risk if you're hosting your blurays. Cloudflare even explicitly forbids such use. VPN or nothing imo.
Wow, Cloudflare is against piracy? Every single site I've ever seen in my life is registered with Cloudflare and uses their DNS with the exception of PTB I believe.
Not sure about that, I think it's more just that they don't want people streaming terabytes of traffic through their edge.
load more comments
(1 replies)
They have to be. They have to at least somewhat comply with laws to avoid lawsuits and fines
load more comments
(1 replies)
load more comments
(1 replies)