Failure to serve static pages, reverse proxy and log to a file, all in one

[jherazob (Jaime Herazo)]

1. Caddy version (caddy version):

2.3.0

2. How I run Caddy:

a. System environment:

Debian 10, physical machine, systemd, from the official debian package

b. Command:

service caddy start

c. Service/unit/compose file:

paste full file contents here

Physical machine, not Docker or similar

d. My complete Caddyfile or JSON config:

{
        debug
        storage file_system {
                root "/mnt/glustershare/var/lib/caddy/"
        }
}

site1.domain.com {
        file_server
        root * /var/www/html
        log {
                output file /var/log/caddy.log
        }
}

address1.domain.com,
address2.domain.com,
address3.domain.com
{
        reverse_proxy http://127.0.0.1:1580

        log {
                output file /var/log/caddy.log
        }
}

3. The problem I’m having:

• I have two virtualhosts, one serves just some static html and the other reverse proxies to an app on localhost, caddy storage is on Gluster because this will be one of N machines in a cluster once this works. Logging activated to a file. Debug is on.
• The static pages fail to appear, a browser shows nothing and wget shows it goes to HTTP/1.1 502 Bad Gateway
• The proxy app on any of the domains throws an SSL error, wget says “OpenSSL: error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error” which from what i’ve seen is what you get when trying to connect to a domain that isn’t managed by Caddy
• There’s certificates on the storage for all the domain names
• All the A records resolve correctly
• The log file shows nothing
• Syslog shows only startup messages, but confirms that the certificates were loaded:

Feb 17 18:42:31 tracker-01 caddy[26850]: {"level":"debug","ts":1613583751.5946832,"logger":"tls","msg":"loading managed certificate","domain":"address2.domain.com","expiration":1620905018,"issuer_key":"acme-v02.api.letsencrypt.org-directory","storage":"FileStorage:/mnt/glustershare/var/lib/caddy/"}
Feb 17 18:42:31 tracker-01 caddy[26850]: {"level":"debug","ts":1613583751.5973823,"logger":"tls","msg":"loading managed certificate","domain":"address3.domain.com","expiration":1620905018,"issuer_key":"acme-v02.api.letsencrypt.org-directory","storage":"FileStorage:/mnt/glustershare/var/lib/caddy/"}
Feb 17 18:42:31 tracker-01 caddy[26850]: {"level":"debug","ts":1613583751.6030135,"logger":"tls","msg":"loading managed certificate","domain":"site1.domain.com","expiration":1620816314,"issuer_key":"acme-v02.api.letsencrypt.org-directory","storage":"FileStorage:/mnt/glustershare/var/lib/caddy/"}

4. Error messages and/or full log output:

When getting the static page with wget:

HTTP request sent, awaiting response... 
  HTTP/1.1 502 Bad Gateway
  Server: Caddy
  Date: Wed, 17 Feb 2021 17:49:25 GMT
  Connection: close
Remote file does not exist -- broken link!!!

When getting the proxied app on any of the domains:

OpenSSL: error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
Unable to establish SSL connection.

5. What I already tried:

I have tried several variations, enabling and disabling individual domains, completely removing part of the config and at least a couple of days dedicated to troubleshooting this, with no results. This was supposed to be the easy part of the setup thanks to Caddy and previous experiences with it suggested this would be easy, but has become quite troublesome.

6. Links to relevant resources:

---

Any help would be appreciated

[francislavoie]

Could you try connecting with curl -v? It generally gives more helpful information. It would also be best if you don’t omit the domains, it’s often useful in helping track down the issue.

A 502 typically means that Caddy couldn’t connect to the upstream service. Are you sure your app is running at 127.0.0.1:1580 and is serving HTTP (not HTTPS)?

What does your file structure look like in /var/www/html? You can use the tree command to give a sample.

[jherazob (Jaime Herazo)]

Never mind, a coworked had moved the IP to another machine which also has Caddy after a miscommunication, therefore all the web responses were justified. After some needed coordination moved the IP back and what do you know, everything works as expected!

Will close this topic now, my fault.