Explicit scheme required in Caddyfile for reverse proxy?

Help
1

1. Caddy version 2.4.3

Behind a docker traefik reverse proxy handling Let’s Encrypt TLS.

2. How I run Caddy:

a. System environment:

Docker on Debian VPS

c. Service/unit/compose file:

version: "3.7"

services:
    websvr:
        image: caddy:2
        command: caddy run --config /config/caddy/Caddyfile --adapter caddyfile
        deploy:
            labels:
                traefik.http.routers.website-websvr.rule: Host(`example.io`, `www.example.io`)
                traefik.http.routers.website-websvr.tls: "true"
                traefik.http.routers.website-websvr.tls.certresolver: letsencrypt
                traefik.http.services.website-websvr.loadbalancer.server.port: 80
                traefik.docker.network: ssl_proxy
                traefik.enable: "true"
        environment:
            TZ: Europe/Berlin
        networks:
            - ssl_proxy
        volumes:
            - config:/config
            - data:/data
            - log:/var/log

networks:
    ssl_proxy:
        external: true

volumes:
    config: {}
    data: {}
    log: {}

d. My complete Caddyfile or JSON config:

{
    auto_https off
    email admin@example.io

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

example.io {
    redir https://www.example.io{uri} permanent
}

www.example.io {
    encode zstd gzip

    root * /data/srv/example.io

    file_server
}

3. The problem I’m having:

I’m seeing a “Bad gateway 502” error when trying to connect to the server. Explicitly setting the scheme to http://www.example.io makes it work, and I want to understand why.

2

This is really more of a question for Traefik than for Caddy.

FYI, you can probably entirely replace Traefik with Caddy by using caddy-docker-proxy. It’s a plugin which makes it possible to configure Caddy via Docker labels:

This would heavily simplify your setup, because then you’d only have one web server instead of two, and you’d get the benefits of Caddy’s more resilient ACME implementation.

3

Ah, on a second reading, I realize you meant http:// in front of the site address in your Caddyfile. That was kinda ambiguous.

But yes. Caddy defaults to listening on the HTTPS port, even if you turn off auto_https. So specifying http:// forces it to use the HTTP port instead. You could also append :80 instead of using http:// if you wanted, for the same effect (just for the sake of example).

My point about using caddy-docker-proxy still stands though – it should greatly simplify your setup by using that.

4

Cheers, the info that Caddy defaults to listening on HTTPs is what I must have missed reading the docs. Regarding traefik vs caddy as proxy: How’s caddy’s ACME implementation more resilient? Also, by first looks of it, traefik seems much more powerful as a reverse proxy.

5

Caddy supports multiple ACME backends simultaneously, so if there’s a problem with one, it will fall back to the other. Caddy supports both Let’s Encrypt and ZeroSSL by default. Also, Caddy’s handling and avoidance of rate limits is much stronger. Caddy performs OCSP stapling, improving the general performance of the web, and will automatically notice if its certificate was revoked and renew it automatically (not unheard of, if an ACME CA makes a mistake, it’s happened to both Let’s Encrypt and ZeroSSL).

What are you noticing that Traefik does that Caddy doesn’t? Caddy’s reverse_proxy module is very powerful.

1 Like
6

This topic was automatically closed after 30 days. New replies are no longer allowed.