Because you love the pain that comes with pulling your own hair out, one fistful at a time.

1. you rent a domain

2. in the config (provided by the service where you rented the domain) you set it to point to the IP of the device where you run caddy

3. the service tells the relevant global DNS servers your setting

4. your DNS does a DNS lookup and a DNS server returns the IP you configured it to point to

Depending on the DNS you use, you can manually add entries to do 1-3 differently, but that will only work for devices that use your DNS and is hard.

The funnel exposes your local services to the public over https . Like what you want to accomplish with reverse proxy . Its just more straightforward for a beginner.

Personally I closed my router ports and switched to tailscalr funnels after using caddy with mutual TLS for years.

nginx + certbot \ acme for certs from my local Step-CA, proper DNS & I just use a WireGuard VPN on-demand for when I leave my house. As soon as I’m off my Wi-Fi I have the VPN active so I don’t need to expose anything more than 1 port for that to work =]

I might look at Tailscale, if only because I’ve seen plenty of people say that’s how they connect, so worth looking into =]

It looks like jhdeval mentioned this already, but you may need to review your config file. By default, you would likely have nginx listening on ports 80 & 443 for requests to a specific address (i.e.: jellyfin.domain.com) which would be configured in your DNS, & then nginx would direct the jellfin 443 traffic to port 85 to access Jellyfin. Same principle for Bitwarden. If you have your nginx config files, i \ we could take a look & see if we spot any issues.

To access things outside of your LAN (for example from your phone while at the grocery store), each service gets a DuckDNS entry. “service.myduckdns.com” or whatever.

Your phone will look for service.myduckdns.com on port 443, because you’ll have https:// certificates and that all happens on port 443.

When that request eventually gets to your router and is trying to penetrate your firewall, you’ll need 443 open and forwarded to your Debian machine.

So yes, you have it right.

Also forward port 80.

You can also choose a mesh vpn like tailscale and then you don’t have to worry about ddns or port forwarding at all, ace you can still use a reverse proxy.

Yes. (I think)

Nginx Proxy Manager is probably your best bet at this stage. It’s a simple to use GUI with QOL features like automatic certificate acquisition built on top of the industry standard Nginx. It should do everything you need it to do and it’s hands down the easiest to get started with.

When you reach the point that you’re trying to do something outside the scope of Nginx Proxy Manager’s gui, that would be a good time to get into another solution that’s config file based. My weapon of choice here is Caddy. I LOVE how simple and minimal the configuration is and it does a lot of things by default that other solutions don’t.

Plain Nginx is a solid tool but working with it directly will be the least straightforward and beginner friendly of all the solutions. Only reason I’d recommend straight Nginx is if you want experience with it for work.

Traefik, don’t bother with until you have an actual reason to use it over other solutions (Like you’re getting into clustering or kubernetes or anything else that requires dynamic configuration instead of static.)

Maybe have a look at https://nginxproxymanager.com as well. I don’t know how difficult it is to install since I never used it, but I heard it has a relatively straight-forward graphical interface.

Configuring good old plain nginx isn’t super complicated. It depends a bit on your specific setup, though. Generally, you’d put config files into /etc/nginx/sites-available/servicexyz (or put it in the default)

server {  
    listen 80;  
    server_name jellyfin.yourdomain.com;  
    return 301 https://$server_name$request_uri;  
}  

server {  
    listen 443 ssl;  
    server_name jellyfin.yourdomain.com;  

    ssl_certificate /etc/ssl/certs/your_ssl_certificate.crt;  
    ssl_certificate_key /etc/ssl/private/your_private_key.key;  
    ssl_protocols TLSv1.2 TLSv1.3;  
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';  
    ssl_prefer_server_ciphers on;  
    ssl_session_cache shared:SSL:10m;  

    location / {  
        proxy_pass http://127.0.0.1:8096;  
        proxy_http_version 1.1;  
        proxy_set_header Upgrade $http_upgrade;  
        proxy_set_header Connection 'upgrade';  
        proxy_set_header Host $host;  
        proxy_cache_bypass $http_upgrade;  
    }  

    access_log /var/log/nginx/jellyfin.yourdomain_access.log;  
    error_log /var/log/nginx/jellyfin.yourdomain_error.log;  
}  

It’s a bit tricky to search for tutorials these days… I got that from: https://linuxconfig.org/setting-up-nginx-reverse-proxy-server-on-debian-linux

Jellyfin would then take all requests addressed at jellyfin.yourdomain.com and forward that to your Jellyfin which hopefully runs on port 8096. You’d use a similar file like this for each service, just adapt them to the internal port and domain.

You can also have all of this on a single domain (and not sub-domains). That’d be the difference between “jellyfin.yourdomain.com” and “yourdomain.com/jellyfin”. That’s accomplished with one file with a single “server” block in it, but make it several “location” blocks within, like location /jellyfin

Alright, now that I wrote it down, it certainly requires some knowledge. If that’s too much and all the other people here recommend Caddy, maybe have a look at that as well. It seems to be packaged in Debian, too.

Edit: Oh yes, and you probably want to set up Letsencrypt so you connect securely to your services. The reverse proxy would be responsible for encryption.

Edit2: And many projects have descriptions in their documentation. Jellyfin has documentation on some major reverse proxies: https://jellyfin.org/docs/general/post-install/networking/advanced/nginx

That question is a little bit out of the scope of a forum like this. A question like that would better be answered by the nginx documentation. Sometimes the project documentation might have a blurb about nginx configuration specific for that project. For example, Immich.

For the most part, you only have to reference the nginx documentation. I’ve never looked at the Immich config above until now, and my Immich server works great.

I’ve had a reverse proxy for years, but the config files are very foreign to me because I use Nginx-Proxy-Manager. NPM makes nginx usable for dummies like me, at the expense of gaining a deeper understanding of how it works. I’m ok with that, but you might feel differently.