Caddy via Docker as reverse-proxy to Gitea instance on private server

[Whitestrake (Matthew Fay)]

@njm2112

Even though I eventually got this working and built the container using docker-compose up , I revised docker-compose.yml so that I could use docker-compose up -d in the future without having to re-build the container. Now it just runs using the njm2112/caddy-docker image that is a modified fork of abiosoft/caddy:0.11.0.

You should always be able to use docker-compose up -d. It’s just docker-compose up but it doesn’t run in the foreground, it runs daemonised. You want to use docker-compose build to build the containers, up should only build them if they’re not currently built.

@njm2112

The log and errors directives in common.conf seem to have something wrong the syntax, so I had to revert back to using log stdout and errors log stdout . If you happen to know how I can fix this, I would appreciate it; the error is:

Double check what you put in common.conf vs. what I put in my example. When you specify the log format, you need three arguments to the directive - the path you’re logging, the location of the log file, and the format. You’ve used only the latter two. Use log / /var/log/caddy/access.log "[FORMAT]", not log /var/log/caddy/access.log "[FORMAT]" - that’s why you’re getting wrong argument count.

@njm2112

basicauth simply does not work. I can’t figure out what I’m doing wrong here.

You’ve made the exact same syntax mistake here as you did for log. basicauth needs three arguments - the path you’re protecting, then the username, then the password. You’ve just put the username and password in. basicauth / user pass, not basicauth user pass.

@njm2112

The question is what I do now with the various keys, certs, configs, etc. so that, e.g. , my-local-ip:32400 serves Plex traffic over http.

This has little to nothing to do with Caddy. Caddy’s not listening on port 32400, Plex is, and you’re connecting directly to it.

My honest advice - Plex is a complicated beast. Run it accessible via https://plex.tv and use their site as the frontend, forget about trying to front it with Caddy. It will still transfer video over the private network if you access it via https://plex.tv.

@njm2112

All of the cert/key files are accessible to Caddy through the root/.caddy path binding (which is why I tried using the tls { load /root/.caddy/local } (per Caddy documentation), which didn’t work).

Were the certificate chain/keys concatenated together in PEM files?

@njm2112

I can’t figure out why, but trying to access mydomain.xyz gives me a 526 error from Cloudflare. I have CNAME records setup for my specific subdomains as well as for www.mydomain.xyz, all of which point to my external IP. (I don’t have a wildcard CNAME record.) The request for mydomain.xyz immediately becomes a request for https://www.mydomain.xyz, and that’s where there is apparently a “host error.” What I don’t understand is that in spite of an error being reported here (“Invalid SSL certificate”), I can see that there is a valid certificate issued by Cloudflare and which lists mydomain.xyz and *.mydomain.xyz in the SAN section of the certificate. What am I doing wrong here?

Gotta say, mate, you’re really making it hard for yourself, taking on a lot of complications for this project. Cloudflare is another complicated beast. I’ve written about it a few times in the past.

The certificate that YOU see, issued by Cloudflare, isn’t the certificate your host is presenting. You’re not even connecting to your host, you’re connecting to Cloudflare, and Cloudflare is connecting to your host. Misunderstanding how this system works is very detrimental to trying to deploy a complicated project like this, and my suggestion is that you forget entirely about trying to use Cloudflare to reverse proxy to your Caddy reverse proxy. Just use Cloudflare as DNS - disable all the orange-clouds in your Cloudflare dashboard - and get everything working that way first; get CF on board later if you absolutely need to.

As for what’s going wrong, I don’t know. Cloudflare might be giving you a valid certificate, but your Caddy isn’t giving Cloudflare a valid certificate. Moving the SSL setting from Full (Strict) back down to Full might solve this, but it’s not ideal. Again, get rid of CF’s reverse proxy, get everything working, then reintroduce them later.

---

I can’t recommend enough paying closer attention to the docs and understanding the directives you’re using. A few of the mistakes above are really simple and come down to not knowing how many arguments the directive should be given.