A while a go I started playing around with caddy, mainly to try to begin my learning of it however I put it aside as life got in the way. Now I am returning and I have been able to make some progress but I have hit another wall.
As a basic set up I have the following:
And this works great, it serves up my very basic index.html file I have saved in /var/www. I’m now trying to add a proxy to sonarr which is hosted on another device running in a docker and with a web root of /sonarr. I have added this (after root and before gzip):
proxy /sonarr 192.168.1.100:8989 {
transparent
}
Now a couple things happen, when I had accidentally typed in the wrong internal IP in the caddy file and try to reach mydomain.co.uk - mydomain Resources and Information. I get a 502 bad gateway error but after I corrected this mistake I now get a “This site can’t be reached error”. Both completely baffle me as I would at least assume I should be getting the error the other way round.
Hopefully someone can point out my obvious mistakes!
First step would be to try figure out what Caddy sees when it tries to connect to the upstream server for you.
If you can run the command curl -IL http://192.168.1.100:8989/sonarr from the Caddy host, it’ll give us an idea of what response Caddy’s getting.
P.S. Just as a point of terminology - when we refer to the web root, we’re generally talking about the location on disk that site files should be served out of with respect to the URI of the request. Putting Sonarr under the subfolder /sonarr is universally referred to as a base path or base URL, and you’ll find a setting in Sonarr labeled as such to support this configuration.
That looks like a good response from Sonarr. Next step would be to have a look at the details of Caddy’s response.
Try curl -IL -H "Host:mydomain.co.uk" https://localhost/, swapping mydomain.co.uk as appropriate to match the site label in your Caddyfile. You should get a similar response to the above.
I also tried running curl -IL -H "Host:mydomain.co.uk" https://192.168.1.30:8989/ just in case it helps because I didn’t really understand what the command was trying to do and got the following response:
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
That’s, uhh, a strange bug. Is Caddy running on the standard ports?
Do you still get it if you try, say, curl -IL https://google.com/ ?
As for the command, going through it backwards real quick:
https://localhost/ - connect to yourself over standard HTTPS (implicit port 443) -H "host:mydomain.co.uk" tell the server you want to access mydomain.co.uk (not localhost) -IL fetch the server’s headers, not the content, and follow any redirects
I just realised it wouldn’t have worked, anyway, because curl will still expect a certificate that matches localhost.
The command that will work is: curl -IL https://mydomain.co.uk --resolve 'mydomain.co.uk:443:localhost'
That is assuming the SSL3 error doesn’t keep appearing.
Looks like Sonarr is responding fine. Does https://mydomain.co.uk/sonarr still give a status 502 or a “This site can’t be reached” error in your browser?
I disabled gzip but no change. I enabled it again and disabled minify and it worked! Should have checked that all first but had been following a set up guide so didn’t know how everything worked.