1. Caddy version (caddy version
):
2.6.1
2. How I run Caddy:
a. System environment:
Debian 11, Docker (rootless mode)
b. Command:
docker compose up -d
c. Service/unit/compose file:
Dockerfile
FROM caddy:2.6.1-builder-alpine AS builder
RUN xcaddy build \
--with github.com/caddy-dns/digitalocean
FROM caddy:2.6.1-alpine
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
docker-compose.yml
version: "3.7"
services:
caddy:
container_name: caddy
build: .
restart: always
networks:
- etebase_default
- miniflux_default
- rssbridge_default
- seafile_default
ports:
- 80:80
- 443:443
- 443:443/udp
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile
- ./data:/data
- ./logs:/var/log/caddy
- ./site:/srv
- ../etebase/srv:/srv/etebase
- config:/config
networks:
etebase_default:
external: true
miniflux_default:
external: true
rssbridge_default:
external: true
seafile_default:
external: true
volumes:
config:
d. My complete Caddyfile or JSON config:
*.example.com {
redir https://example.com{$uri}
tls {
dns digitalocean {env.DIGITALOCEAN_API_TOKEN}
}
log {
output file /var/log/caddy/access.log
}
}
example.com {
root * /srv/index
file_server
header Strict-Transport-Security "max-age=31536000"
log {
output file /var/log/caddy/access.log
}
}
bridge.example.com {
reverse_proxy rssbridge:80
log {
output file /var/log/caddy/bridge.log
}
}
cloud.example.com {
reverse_proxy /seafdav* seafile:8080
reverse_proxy seafile:80
log {
output file /var/log/caddy/seafile.log
}
}
etebase.example.com {
handle_path /static/* {
root * /srv/etebase/static
file_server
}
handle {
reverse_proxy etebase:3735
}
log {
output file /var/log/caddy/etebase.log
}
}
nc.example.com {
reverse_proxy 10.120.0.2:9090
header Strict-Transport-Security "max-age=15552000"
redir /.well-known/carddav /remote.php/carddav 301
redir /.well-known/caldav /remote.php/caldav 301
log {
output file /var/log/caddy/nextcloud.log
}
}
rss.example.com {
reverse_proxy miniflux:8080
log {
output file /var/log/caddy/miniflux.log
}
}
3. The problem I’m having:
This is one of two servers on which I’m running Caddy 2.6.1–even though the alt-svc
header is showing h3=":443"; ma=2592000
, no content is ever served over HTTP/3. Geekflare’s HTTP/3 testing tool gives the following error message:
Couldn’t connect over HTTP/3. Take advantage of the latest protocol HTTP/3 for better performance.
4. Error messages and/or full log output:
Logs on server launch:
{"level":"info","ts":1663989262.319634,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
{"level":"warn","ts":1663989262.3222895,"msg":"Caddyfile input is not formatted; run the 'caddy fmt' command to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":6}
{"level":"info","ts":1663989262.3235857,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]}
{"level":"info","ts":1663989262.3238082,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc000246fc0"}
{"level":"info","ts":1663989262.3238745,"logger":"http","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
{"level":"info","ts":1663989262.3238966,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"info","ts":1663989262.3245602,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
{"level":"info","ts":1663989262.3253105,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/data/caddy"}
{"level":"debug","ts":1663989262.3255713,"logger":"http","msg":"starting server loop","address":"[::]:443","tls":true,"http3":true}
{"level":"info","ts":1663989262.3255901,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
{"level":"debug","ts":1663989262.3256235,"logger":"http","msg":"starting server loop","address":"[::]:80","tls":false,"http3":false}
{"level":"info","ts":1663989262.3256304,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
Logs when attempting to access one of the configured domains:
{"level":"debug","ts":1663989684.2364225,"logger":"http.handlers.reverse_proxy","msg":"upstream roundtrip","upstream":"miniflux:8080","duration":0.002274311,"request":{"remote_ip":"X.X.X.X","remote_port":"53913","proto":"HTTP/2.0","method":"GET","host":"rss.example.com","uri":"/icon/icon-192.png","headers":{"Sec-Fetch-Dest":["image"],"X-Forwarded-For":["X.X.X.X"],"X-Forwarded-Host":["rss.example.com"],"Accept":["image/avif,image/webp,*/*"],"Dnt":["1"],"Cookie":[],"Cache-Control":["no-cache"],"Sec-Fetch-Site":["same-origin"],"Te":["trailers"],"Accept-Language":["en-US,en;q=0.5"],"Sec-Fetch-Mode":["no-cors"],"Sec-Gpc":["1"],"X-Forwarded-Proto":["https"],"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:105.0) Gecko/20100101 Firefox/105.0"],"Pragma":["no-cache"],"Accept-Encoding":["gzip, deflate, br"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"rss.example.com"}},"headers":{"Cache-Control":["public"],"Referrer-Policy":["no-referrer"],"Content-Length":["881"],"Etag":["b0b36eceb45f494fa4151a7ffce7a31d603f50e1a58c98e335c12776d24e755f"],"X-Xss-Protection":["1; mode=block"],"X-Content-Type-Options":["nosniff"],"X-Frame-Options":["DENY"],"Date":["Sat, 24 Sep 2022 03:21:24 GMT"],"Content-Type":["image/png"],"Expires":["Tue, 27 Sep 2022 03:21:24 UTC"],"Strict-Transport-Security":["max-age=31536000"]},"status":200}
5. What I already tried:
Attempting to run a similar configuration with rootful Docker and host networking produces the same result (non-working HTTP/3, errors on HTTP/3 testers).
Thanks in advance for any guidance you can provide!