Help! Docker caddy suddenly no longer can find DNS records?

[Whitestrake (Matthew Fay)]

@rinkrealclose

Unfortunately still not connecting and getting an error from nextcloud, but not jellyfin

ERR ts=1722534209.9936292 logger=http.log.error msg=dial tcp 172.20.0.4:11000: connect: connection refused [...]

So, Caddy resolved the nextcloud service to IP 172.20.0.4 and tried to connect on port 11000. So, Caddy is working as configured. The service refused the connection, though.

I have to assume this is due to the way the Nextcloud AIO works… Yep, looking at Caddy Docker Compose Example · nextcloud/all-in-one · Discussion #575 · GitHub I can see evidence of this as they’ve had to work around the problem. They solved the issue by putting Caddy on the host networking stack, though. That won’t work for you because you want to be inside the Compose network to proxy to Jellyfin, too.

So - Nextcloud doesn’t run inside the mastercontainer. It runs in a separate container that the mastercontainer spins up. This separate container listens on the Docker host on the port specified in the APACHE_PORT env var.

That means you need Caddy to talk to the Docker host, not to the Nextcloud service inside the Compose network.

Add this to your Caddy service:

    extra_hosts:
      - "host.docker.internal:host-gateway"

And change your Caddyfile from: reverse_proxy nextcloud:11000

To: reverse_proxy host.docker.internal:11000

This will have Caddy connect to the host itself, on which Nextcloud-AIO will establish a port 11000 listener on for your Nextcloud app.

@rinkrealclose

Jellyfin opens here, but again no Ips work, but now it doesn’t time out!

Did you try https://jellyfin.wallaby-gopher.ts.net in that box instead of an IP address?

@rinkrealclose

Noticing yours doesn’t have a port I tried removing it after the reverse proxy and can get an error with either jellyfin/nextcloud

ERR ts=1722534699.102591 logger=http.log.error msg=dial tcp 172.18.0.3:80: connect: connection refused request={"remote_ip":"100.122.199.7","remote_port":"42278","client_ip":"100.122.199.7","proto":"HTTP/2.0","method":"GET","host":"jellyfin.wallaby-gopher.ts.net","uri":"/web/serviceworker.js","headers":{"User-Agent":["Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"],"Accept":["*/*"],"Sec-Gpc":["1"],"Sec-Fetch-Dest":["serviceworker"],"Priority":["u=4"],"Te":["trailers"],"Accept-Language":["en-US,en;q=0.5"],"If-None-Match":["\"1dadb2d244eb780\""],"Cache-Control":["max-age=0"],"Accept-Encoding":["gzip, deflate, br, zstd"],"Service-Worker":["script"],"Sec-Fetch-Mode":["same-origin"],"Sec-Fetch-Site":["same-origin"],"If-Modified-Since":["Sun, 21 Jul 2024 05:16:29 GMT"],"Dnt":["1"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"jellyfin.wallaby-gopher.ts.net"}} duration=0.000489597 status=502 err_id=18cyk0rne err_trace=reverseproxy.statusError (reverseproxy.go:1269)

seeing as these are the same error but the wrong port now, I must be doing something wrong with the reverse proxy. At least we can see it’s trying to dial the right IP now.

Don’t remove the port. It needs to be going to the correct port. If you remove the port Caddy will assume port 80 (the default for HTTP, which is the assumed scheme unless you specify a HTTPS upstream). I have no port on my whoami proxy because whoami listens for HTTP on port 80 by default so there was no need to specify it.

@rinkrealclose

I tried adding :443 again, no dice.

I think you’ve said you’ve tried this a few times over our various troubleshooting, but I’m not sure why - can you tell me what the indication was that this might have been a possible solution? I don’t know that at any point it made sense to throw port 443 on anything. Caddy will handle HTTPS, you shouldn’t need to worry about that. And your services aren’t running on port 443, they’re serving - as far as I know - HTTP on other ports.

@rinkrealclose

Here’s the full compose file with the cleaner caddyfile portion thanks to you:

You could move your configuration back to a separate volume-mounted Caddyfile if you liked.

The container_name: "jellyfin-ts" doesn’t serve much purpose at all since Caddy is proxying to jellyfin and Docker DNS is using the service name (not the container name) to resolve an IP for it.