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.

No, not for remote access over the internet.

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.

chief executive slopfficer ?

You should make Jellyfin aware of your reverse-proxy IP address or hostname: (in my case localhost as the reverse proxy is running on the same machine).

How to send the X-Forwarded-For header depends on your reverse-proxy. In Caddy which I use, it does it by default.

If you do not sign your commits, you deserve to be impersonated. Well, not really, but you get the gi(s)t.