Using Caddy as reverse proxy for multiple subdomains

Help
1

1. The problem I’m having:

I currently have Caddy working as a reverse proxy for my Emby server along with Cloudfare DNS API verification. I am trying to add another proxy to it for Sonarr. When I add the additional config commands it is not working properly for the sonarr site. Emby still works fine.

2. Error messages and/or full log output:

3. Caddy version:

v2.8.4 h1:q3pe0wpBj1OcHFZ3n/1nl4V4bxBrYoSoab7rL9BMYNk=

4. How I installed and ran Caddy:

I am running Caddy as a service in Windows 11.

a. System environment:

Windows 11

b. Command:

This is my Caddy config file:

{
	acme_dns cloudflare <api_key>
}

emby.mydomain.com:5555 {
	reverse_proxy :8096
}

sonarr.mydomain.com:5556 {
	reverse_proxy :8989
}

c. Service/unit/compose file:

d. My complete Caddy config:

{
	acme_dns cloudflare <api_key>
}

emby.mydomain.com:5555 {
	reverse_proxy :8096
}

sonarr.mydomain.com:5556 {
	reverse_proxy :8989
}

5. Links to relevant resources:

2

What does it mean? Any details? Logs? curl command results maybe?

3

Thanks for offering to help.

After a decent amount of debugging I ended up fixing it by deleting the Windows service and recreating it. I don’t understand why this was required, but running the command at the CLI seemed to work okay so I just tried deleting and recreating the service and this made it work for the other domains I added.

4

yeah, if recreating the windows service fixed it, I’d look at that before touching the caddyfile much.

when caddy works from an interactive shell but not as a service, it’s usually one of the boring bits: service points at a different caddy.exe, loads a different Caddyfile, or doesn’t get the same env vars the shell had. the Cloudflare token is an easy one to miss there.

I’d run caddy validate --config <path-to-the-service-caddyfile> against the exact file the windows service uses, then compare that path/binary/env with whatever you tested manually.

the separate subdomain blocks look fine for this use case. I’d mostly be suspicious of stale service config or a service restart that didn’t really pick up the change.

5

Thanks again. Just as an FYI - and in case anyone else comes across the same issue…

I added another FQDN today and experienced the exact same problem. Added the config and restarted the service.

I immediately stopped, deleted the service with sc.exe, created it again, started it, and it worked.

So for whatever reason it appears that the service must be deleted and recreated to accept new config parameters.