Caddy 0.9.x seems to respond to everything with a 404

Help
1

Hi, I’ve been using caddy 0.8.3 for a while now for my reverse proxy, but now I’m trying to reverse proxy UniFi which means I need to remove a header, which 0.8.3 can’t do. So, I got a new copy of caddy 0.9.2 (I’ve tried both from getcaddy and github, no extra features enabled from either) and fired it at my existing config. It seemingly imported my config file with minor nags about proxy_header, but I noticed it was listening to http://:2015 a lot: But as long as my stuff works that’s fine. Problem was it wasn’t working fine.

It seems like every single request (whether it’s to a specific file or a reverse proxy) returns a 404. It also doesn’t log it in my access logs. I’m after messing with it for a while now (It was actually why I was still on 0.8.3, despite my excitement for DNS challenges), but now it’s really annoying me.

I’m after deleting the .caddy folder to reset it, and I’m after trying to run ‘stripped down’ caddyfiles, but it just seems to refuse working. The Caddyfile itself should be fine, it’s mostly just reverse proxies.

I’m ALSO after noting that (and this is REALLY wierd) if I actually just view (the caddy server’s IP):2015, it serves one of my reverse proxied sites!

Some things to note: I am running caddy as root. The reason for this is that I’m running it in a linux container, and so I cannot use setcap. I’m not overly worried if someone manages to break in to caddy because they’ll have access to… Well, caddy’s container.

Anyways, without further ado: My Caddyfile (snips obviously)

MyDomain {
        root /opt/www
        log / /opt/access.log "{remote} -> {status} for {method} {host}{path}"
}
CouchPotato.MyDomain {
        proxy / http://192.168.1.122:80
        log / /opt/access.log "{remote} -> {status} for {method} {host}{path}"
}
Sonarr.MyDomain {
        proxy / http://192.168.1.121:80
        log / /opt/access.log "{remote} -> {status} for {method} {host}{path}"
}
Hades.MyDomain {
        proxy / http://192.168.1.1
        log / /opt/access.log "{remote} -> {status} for {method} {host}{path}"
}
Guacamole.MyDomain {
        proxy / http://192.168.1.126:8080/guacamole
        log / /opt/access.log "{remote} -> {status} for {method} {host}{path}"
}
PRTG.MyDomain {
        proxy / http://192.168.1.4
        log / /opt/access.log "{remote} -> {status} for {method} {host}{path}"
}
WebVirtManager.MyDomain {
        proxy / http://192.168.1.127:8000 {
                proxy_header X-Forwarded-Host {host}
        }
        log / /opt/access.log "{remote} -> {status} for {method} {host}{path}"
}
Transmission.MyDomain {
        proxy / http://192.168.1.111:9091
}
OwnCloud.MyDomain {
        proxy / http://192.168.1.128/owncloud {
                proxy_header X-Forwarded-For {host}
        }
        log / /opt/access.log "{remote} -> {status} for {method} {host}{path}"
}
UniFi.MyDomain {
        proxy / https://192.168.1.129:8443 {
                insecure_skip_verify
        }
        log / /opt/access.log "{remote} -> {status} for {method} {host}{path}"
}
Styx.MyDomain {
        proxy / http://192.168.1.3
        log / /opt/access.log "{remote} -> {status} for {method} {host}{path}"
}

Now, here’s the output from 0.8.3 running that Caddyfile:

root@Apollo:/opt# /opt/caddy-0.8.3/caddy -conf /opt/Caddyfile
Activating privacy features... done.
MyDomain:443
couchpotato.MyDomain:443
sonarr.MyDomain:443
hades.MyDomain:443
guacamole.MyDomain:443
prtg.MyDomain:443
webvirtmanager.MyDomain:443
transmission.MyDomain:443
owncloud.MyDomain:443
unifi.MyDomain:443
styx.MyDomain:443
MyDomain:80
couchpotato.MyDomain:80
sonarr.MyDomain:80
hades.MyDomain:80
guacamole.MyDomain:80
prtg.MyDomain:80
webvirtmanager.MyDomain:80
transmission.MyDomain:80
owncloud.MyDomain:80
unifi.MyDomain:80
styx.MyDomain:80

That one works (With the exception of unifi, of course). Now 0.9.2:

root@Apollo:/opt# /opt/caddy-0.9.2/caddy -conf /opt/Caddyfile
Activating privacy features... done.
WARNING: proxy_header is deprecated and will be removed soon; use header_upstream instead.
https://MyDomain
https://couchpotato.MyDomain
https://sonarr.MyDomain
https://hades.MyDomain
https://guacamole.MyDomain
https://prtg.MyDomain
https://webvirtmanager.MyDomain
https://transmission.MyDomain
https://owncloud.MyDomain
https://unifi.MyDomain
https://styx.MyDomain
http://MyDomain
http://couchpotato.MyDomain
http://sonarr.MyDomain
http://hades.MyDomain
http://guacamole.MyDomain
http://prtg.MyDomain
http://webvirtmanager.MyDomain
http://transmission.MyDomain
http://owncloud.MyDomain
http://unifi.MyDomain
http://styx.MyDomain
http://:2015
http://:2015
http://:2015
http://:2015
http://:2015
http://:2015
http://:2015
http://:2015
http://:2015
http://:2015
http://:2015

And this one’s all 404s. Unless you access the http://:2015 part, in which (currently) it routes to transmission.MyDomain’s server. Note that accessing transmission.MyDomain returns a 404, of course.

So yeah, any ideas on this? I’m sure it’s got to be something dumb, but I have no idea.

2

That’s weird… looking into this.

3

Oh, and just to add to the oddities (It might actually help too, who knows) I should note that despite almost every single site including an access log, I haven’t been able to get 0.9.2 to output any of them.

4

So… I feel dumb, this is a case-sensitivity bug.

For now, lowercase your site addresses. Let me know if that helps… (Edit: I’ve also pushed a fix to master so you can build from source if you want to.)

5

I would never have imagined that my habit of using UpperCamelCase for domains would bite me in the ass in such an odd way… Ah well, it’s fixed now anyways. Thanks.

6

Yeah, sorry about that. I’ll add some tests soon and the fix will go out with the next release.

7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.