Hello Self Hosters! I am new-ish… got Jellyfin working great with tailscale remote access! I love it! I keep getting deeper into this stuff and geeking out… really excited to add my next service: Self-Hosted Nextcloud.

Would someone kindly walk me through setting up reverse proxy to my stuff with Caddy? I really just want HTTPS support, as my media files are one thing, but hosting all my personal info/docs on NextCloud is quite another thing to potentially expose…I want to make sure I harden properly, and HTTPS is clearly a part of that, even if I’m running a tailscale VPN. I have done my best following the docs/tutorial so far, but I’ve hit the wall with this “start” page… Here’s what I’ve got:

  • pointed my domain “A” DNS to my website as a sub-domain… so my address in caddyfile is “sub.mydomain.com”
  • I’ve installed caddy directly on my unbuntu server, but I admin my Jellyfin (and eventually Nextcloud) with Docker via CasaOS interface… is this a problem? Do I need to run Caddy in docker too?
  • I’ve followed the instructions on this start page and I still only get the startpage at “sub.mydomain.com”
  • my tailnet server IP address is what I’m using for the reverse proxy… that’s correct, yes?
  • So many things/guides just say “reverse-proxy --to …” but when I do that, I get an error saying port 80 is ‘already in use’ I have combed my configs & devices on my router…nothing is using port 80 that I can see. Ports 80 and 443 ARE forwarded/open, before you ask! -My next big step in this journey is piHole, so if this will interfere/interact with that in some important way, I appreciate the heads-up mightily!

Thank you in advance, I appreciate it!

  • darkan15@lemmy.worldEnglish
    12·
    19 hours ago

    I’ve installed caddy directly on my unbuntu server, but I admin my Jellyfin (and eventually Nextcloud) with Docker via CasaOS interface… is this a problem? Do I need to run Caddy in docker too?

    The difference between having caddy or any other reverse proxy in docker alongside other apps/services, is that instead of having to expose ports for every container to the host, and then linking every service/app as, localhost:<host-port> to caddy, you can have them on the same docker network and use <container-name>:<container-port> and only expose 80 443 to the host, meaning that the only way to access app/services is through caddy, that way if you disable port 80 after configuring SSL certificates, you can only access services with HTTPS.

    • Profligate_parasite@lemmy.worldOPEnglish
      5·
      14 hours ago

      So, it sounds like you’re staying if I want all my services (jellyfin, nextcloud, etc) behind ONE reverse proxy/https then the easier method is to install Caddy as docker and use the containername:containerport method?.. did I understand correctly? Thanks

      • darkan15@lemmy.worldEnglish
        4·
        12 hours ago

        then the easier method is to install Caddy as docker and use the containername:containerport method?.. did I understand correctly?

        Yes, if the only exposed port to the host or outside, is 443 from caddy container, then the only way to access any of those services is HTTPS through caddy.

      • AbidanYre@lemmy.worldEnglish
        4·
        20 hours ago

        Ha, I completely ignored the picture because it’s a self post. So there is an instance of caddy running on port 80.

        When you say you’re trying to reverse proxy, are you starting up another instance of it instead of restarting the already running service with a new config?

        I’m no expert on caddy, so we’re rapidly reaching the limits of my ability to offer anything useful.

  • gibdos@lemmy.worldEnglish
    5·
    21 hours ago

    You need to point your sub-domain in the Caddyfile to your designated local port. So just add an entry like this to your Caddyfile

    sub.yourdomain.com {
  reverse_proxy XXX.XXX.XXX.XXX:PORT {
   header_up X-Real-IP {remote_host}
  }
  encode zstd gzip
}```

Replace XXX with your public IP and PORT with the local port in your docker container / compose.
  • dimjim@sh.itjust.worksEnglish
    2·
    19 hours ago

    Something that might help with using Tailscale and reverse proxying: you don’t have to use the IPs given to you through the tailnet if you don’t want to. Something tailnet nodes can do is serve the local subnet theyre connected to, even if you’re running the self hosted version Headscale, which is what I do. This is how I am able to have my phone and one other pc connected through Headscale/Tailscale, but still access everything on my local network.

    Im assuming your Jellyfin is on your local network, and you want to connect to it through Tailscale, but still use HTTPS? If that’s the case, you don’t need to do any kind of port forwarding on your router, as everything is funneled through Tailscale anyway.

    • Profligate_parasite@lemmy.worldOPEnglish
      2·
      14 hours ago

      Hey thanks for addressing that. So yes, I have my local ip as a subnet… you’re saying that means i don’t necessarily need the tailnet IPv4 as my pointer?

      • dimjim@sh.itjust.worksEnglish
        1·
        13 minutes ago

        I’ve honestly never tried it, since I have the only node in my home network serve the local subnet. It allowed me to statically assign IPs at home and still use them outside of the house. I suppose there’s nothing stopping you from using the overlay network, especially if you have all devices involved on the Tailscale network, but I didn’t feel like doing that :)

  • irmadlad@lemmy.worldEnglish
    3·
    21 hours ago

    What does your caddyfile look like? I have a sneaking suspicion that you left the caddyfile as it comes installed, which indeed uses port 80 to deliver the Caddy success test. If you point your browser to the ip of your server, do you see the 'It Worked!" page that Caddy serves up?

    sudo nano /etc/caddy/Caddyfile

    Don’t sweat the complications. I know it’s frustrating. Full disclosure, it took me a while to ‘get’ Caddy. Once I did tho, it really is easy peasy. I actually found Cloudflare Tunnels/ZeroTrust easier to set up. I realize some have ‘concerns’ about Cloudflare, which is understandable.

      • irmadlad@lemmy.worldEnglish
        5·
        19 hours ago

        It looks like Elvith Ma’for@feddit.org has you headed in the right direction, so I won’t muddle the waters.

        I meant to include this in my earlier comment, but Caddy has a built in caddyfile validator:

        caddy fmt --overwrite /etc/caddy/Caddyfile
caddy validate --config /etc/caddy/Caddyfile

        Comes in very handy.

      • Elvith Ma'for@feddit.orgEnglish
        5·
        20 hours ago

        If you like, I can send you an example of the Caddyfiles, that I’m using (I used the import directive to split every service into its own Caddyfiles, you could just copy and paste everything in the same file). It will take a few hours until I get home, though.

        But basically you can just put every subdomain and it’s target in a separate block and the add some things globally (e.g. passing the original IP, switching off the admin API of Caddy,…)

        Something like this should work:

        
admin off 

servers {
		client_ip_headers X-Forwarded-For X-Real-IP
}

app.example.com {
    reverse_proxy 127.0.0.1:8080
}

app2.example.com {
    reverse_proxy 127.0.0.1:8081
}

api.example.com {
    reverse_proxy 127.0.0.1:8082
    header {
        Access-Control-Allow-Methods "GET, OPTIONS"
        Access-Control-Allow-Origin "*"
    }
}