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!

EDIT! - CaddyOS uses 80 as default gateway, turns out! So, switched that… now Caddy is starting properly… STILL can’t get the ‘welcome’ page to go away… still a problem with my caddyfile I suppose.

  • irmadlad@lemmy.worldEnglish
    3·
    2 days 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·
        2 days 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.

            • Profligate_parasite@lemmy.worldOPEnglish
              1·
              18 hours ago

              ugh. no. Now caddy wont start… various errors… sometimes it says listening port 80, port 80 in use. This morning after reset and caddy fmt --overwrite, it says: Error: loading initial config: loading new config: http app module: start: listening on :443: listen tcp :443: bind: permission denied Error: caddy process exited with error: exit status 1

      • Elvith Ma'for@feddit.orgEnglish
        5·
        2 days 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 "*"
    }
}
        • Profligate_parasite@lemmy.worldOPEnglish
          2·
          18 hours ago

          Thanks very much, this is really helpful… one thing I note is that I don’t know what “api.example.com” is … is that necessary to make this work or is it just an option? I haven’t mucked with API of Caddy at all…do I need to?

          • Elvith Ma'for@feddit.orgEnglish
            2·
            18 hours ago

            No, that’s just another hypothetical app that you’re using a reverse proxy for. I just included it to show how you can also set settings for a single subdomain/reverse proxy entry that isn’t used globally on all domains that get served. I used a hypothetical REST API that needs a CORS Header that other apps don’t need (or maybe serve themselves).

            admin off disables Caddy’s admin interface (which shouldn’t be public and if you’re using config files this usually isn’t needed. So just a bit of gardening)

            servers sets some general server options.

            and then I just inserted several blocks that each define a reverse proxy to a different app / backend to show that you can just dump them all in a single Caddyfile. And the last example to show that you can set specific settings only for a specific subdomain instead of globally. As I set headers mostly used by REST APIs, I just called that api.example.com instead of app3.example.com.

          • Profligate_parasite@lemmy.worldOPEnglish
            1·
            17 hours ago

            I’ve tried this caddyfile version and one above, for both, I get “Problem loading page. Secure connection failed. Internal error.” Oddly, I get the ‘welcome to caddy’ page directly at my IP but at my sub domain I get the error.