I’d make sure you’re forwarding http (port 80) to that same internal host too. I’m assuming thats your jellyfin server. Your browser might not be appending https to your domain and connecting to your router port 80. You can test this by going to both https://<your domain> and http://<your domain>.
On your local network, does going to https://192.168.1.4 present you with what you actually want?
I’m using mailgun and have had zero issues with it. Hard to beat since it’s free.
If vising jellyfin.mydomain.com presents you with your routers config that means you don’t have port forwarding working correctly for ports 443. You should google your router’s name + “port forwarding”.
If you’re a beginner or just for most use cases, using cloudflare with proxied dns records along with Nginx Proxy Manager will provide a good amount of coverage for your homelab.
That’s where nginx security options and other tools like fail2ban come into play. I could’ve mentioned it better in my first sentence but a reverse proxy gives the capability to make it more secure than any options jellyfin will give you.
I’d rather put nginx with modsecurity in front of jellyfin than not.
So the reason you’d want a reverse proxy is because it handles security and would do a much better job of it than an exposed jellyfin port.
Public FQDN -> your home IP -> your router allows 443/whatever to your reverse proxy -> it handles SSL and being hit by the internet (look into nginx security and even fail2ban) -> proxy serves up whatever insecure site/app you’d like.
We solved this with a local service account that has sudo permissions. You can try become_user and become just on the task as needed.
become_user
set to user with desired privileges — the user you become, NOT the user you login as. Does NOT imply become: true, to allow it to be set at host level. Default value is root.
You know I think you’re right. I might be grandfathered into an old plan. I’ve been using mailgun for over 3 years