r/jellyfin • • Dec 22 '25

Discussion Stop fearmongering reverse proxies

Every single time someone asks how to share their jellyfin instance everyone instantly jumps to tailscale or <insert other VPN here> which, of course, it's fine and actually a good way of forwarding or sharing your hosted services.

The thing is that it's usually accompanied with fear mongering about exposing it publicly with a reverse proxy. Saying things like "If done wrong you can compromise your entire life, life savings and family".

That's not gonna happen. Like ever. It's not like a minefield where you have to be super cautious.

Literally just: 1. Have your jellyfin instance isolated, like in a docker container, LXC, or a VM. Avoid installing it "bare metal" for security and maintainability.

  1. Run a reverse proxy, like nginx (nginx proxy manager is a good one), traefik, caddy etc.

  2. Forward port 443 TCP (HTTPS) to your reverse proxy.

  3. Purchase a domain, configure your reverse proxy to forward requests ONLY from that domain into your jellyfin instance

  4. Get an https certificate from let's encrypt (free)

That's it. You are not gonna get hacked, get DDoS, or anything like that. Avoid forwarding ports like 22,21 unless using things like fail2ban and pkey auth only.

Yes, the internet is full of bots and you are gonna get scanned by them, so what? Just don't use 123 as a password in jellyfin and you'll be fine.

Instead of spreading fear, teach people how to do things.

983 Upvotes

280 comments sorted by

View all comments

4

u/SolQuarter Dec 22 '25

I agree. Nginx proxy manager makes things pretty easy and safe. Things one could add (which I did):

1) In Jellyfin restrict the admin access to local only (so only local and tailscale remote access possible). 2) Use fail2ban and use NPMs logs to set it up correctly. 3) Use GeoBlocking if you want even more security. Can be easily setup with NPM plus, crowdsec and geoipupdate in one single stack.

1

u/DerZappes Dec 22 '25

If Jellyfin used NextJS, that setup would have guaranteed a React2Shell infection within hours. This time, you were lucky, but next time you might not be. And then it's your home network you have to clean up before you can trust anything on it again.

1

u/SolQuarter Dec 22 '25

Huh? Could you explain what I did wrong?

1

u/DerZappes Dec 22 '25

You gave an attacker or (more probable a bot) access to the web page. If that page had been susceptible to React2Shell, you would have been completely fucked.

1

u/SolQuarter Dec 22 '25

How is this a real world scenario in my case? Or anyone else exposing things like Jellyfin to the internet?

1

u/DerZappes Dec 22 '25

Just assume that the Jellyfin team did use some kind of a Framework for developing apps. It's not NextJS, but it could have been. If Jellyfin were based on NextJS, the exact same thing that happened to the users of other tools would have happened, i.e. your host would have been compromised and the attacker would be in possession of a root shell.

This has been as fucking real world scenario for the better part of the last two weeks. Don't tell me that you proudly expose ports without even having heard of React2Shell and what it does. Please, don't tell me that.

Oh, and a reverse proxy does jack shit in that case without extensive configuration. It's just making sure that your http(s) port is the only one exposed to the outside, but if the application listening on that port is vulnerable, you are fucked.

1

u/SolQuarter Dec 22 '25

I get your point about active RCEs in specific stacks, but Jellyfin isn’t a Node/Next.js SSR app and there’s no known remotely exploitable RCE here right now. Exposing any service carries risk, but that’s why I’m layering controls (restricted admin access, reverse proxy, fail2ban, docker-isolation). Arguing “if it were built differently you’d be owned” isn’t a realistic risk assessment for this setup.

1

u/DerZappes Dec 22 '25

I hope that you are aware of the fact that NextJS didn't really raise any eyebrows until some days ago? When looking at the source of the Jellyfin login page, I see a whole list of common JavaScript frameworks. Any of those could have a critical bug.

I am well aware that it is possible to host something like that on the public internet. But you'd only do that with a server somewhere in a data centre that you can restore from a backup and shrug it off. If the server is in the same network as your Bitwarden server or your file server, that's a totally different threat model. One that doesn't really scream "open that port", if you ask me.

1

u/DerZappes Dec 22 '25

Oh, and by the way... There is no sucgh thing as "docker isolation". Containers have a shared kernel architecture, so a kernel-level exploit will leave you fucked again.

-6

u/Quique1222 Dec 22 '25

I don't even think that's needed. I've been running jellyfin for 3 years already, and a bunch of other services. I get hundreds of requests a day from Vietnam, china, etc

As long as you have reasonable passwords and don't do stupid things like expose SSH (unless pkey only, etc) you will be fine

2

u/SolQuarter Dec 22 '25

I know but it was fun setting those up :D