Docker won't start all of a sudden

1. Caddy version (caddy version):

v2.1.1:latest

2. How I run Caddy:

Using at a reverse proxy for bitwarden and a calibre

a. System environment:

Unraid + Docker

d. My complete Caddyfile or JSON config:

calibre.nagpal.info {
reverse_proxy 10.0.0.111
}

3. The problem I’m having:

Docker won’t start

4. Error messages and/or full log output:

{“level”:“info”,“ts”:1602363617.5931454,“msg”:“using provided configuration”,“config_file”:"/etc/caddy/Caddyfile",“config_adapter”:“caddyfile”}
{“level”:“info”,“ts”:1602363617.5954368,“logger”:“admin”,“msg”:“admin endpoint started”,“address”:“tcp/localhost:2019”,“enforce_origin”:false,“origins”:[“127.0.0.1:2019”,“localhost:2019”,"[::1]:2019"]}
{“level”:“info”,“ts”:1602363617.5957289,“logger”:“tls.cache.maintenance”,“msg”:“started background certificate maintenance”,“cache”:“0xc0004131f0”}
{“level”:“info”,“ts”:1602363617.5969772,“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”:1602363617.5970075,“logger”:“http”,“msg”:“enabling automatic HTTP->HTTPS redirects”,“server_name”:“srv0”}
{“level”:“info”,“ts”:1602363617.5972846,“logger”:“tls.cache.maintenance”,“msg”:“stopped background certificate maintenance”,“cache”:“0xc0004131f0”}
run: loading initial config: loading new config: loading http app module: provision http: server srv0: setting up route handlers: route 0: loading handler modules: position 0: loading module ‘subroute’: provision http.handlers.subroute: setting up subroutes: route 0: loading handler modules: position 0: loading module ‘reverse_proxy’: provision http.handlers.reverse_proxy: invalid start port: strconv.ParseUint: parsing “”: invalid syntax

5. What I already tried:

Reinstalled docker and stripped caddy file down to one entry

Hi, TN! Sorry for the inconvenience. This is known regression in v2.2.0. The code used to assume port 80 in the absence of a port in upstream address, then it didn’t, and now it does again. It’s already fixed but not released yet. The fix will be included in v2.2.1. For now the workaround is to append :80 to upstream addresses if you didn’t have a port defined for them.

2 Likes

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