Cant access service on host machine (Caddy in Docker)

1. Caddy version (caddy version):


2. How I run Caddy:

Caddyfile with docker

a. System environment:

Kubuntu 20.4 with docker. Pi-Hole as local DNS.

c. Service/unit/compose file:

version: "2.1"

    container_name: caddy
    image: caddy:latest
    restart: unless-stopped
      - "80:80"
      - "443:443"
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config

d. My complete Caddyfile or JSON config: {
    reverse_proxy jellyfin:8096

http://cockpit, http://cockpit.lan {

http://pi.hole, http://pihole, http://pi.hole.lan, http://pihole.lan {
    rewrite * /admin{uri}
    reverse_proxy pihole-server:80

http://logs, http://logs.lan {
    reverse_proxy dozzle:8080

3. The problem I’m having:

I added an endpoint to my Caddyfile, which is the only endpoint not running in a docker container, but running on my host machine.

http://cockpit, http://cockpit.lan {

For some reason, I get redirected to https and an error: (from firefox)

Secure Connection Failed

An error occurred during a connection to cockpit.lan. Peer reports it experienced an internal error.


No output from the Caddy logs.

5. What I already tried:

Toggling various TLS settings and switching the IP to the lan IP.

Not sure what is going on. Every other endpoint works as normal. The only difference with this on is that it’s not located inside the docker container.

You don’t see anything when you run docker-compose logs caddy?

I meant no logs after I hit that endpoint. But it looks like I am wrong now. I got output after restarting Caddy. Here is the full log, last two are after I hit the endpoint:

* today at 7:37 PM {"level":"info","ts":1610674666.2435098,"msg":"shutting down apps then terminating","signal":"SIGTERM"}
* today at 7:37 PM {"level":"info","ts":1610674676.9210384,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
* today at 7:37 PM {"level":"info","ts":1610674676.9229052,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["","localhost:2019","[::1]:2019"]}
* today at 7:37 PM {"level":"info","ts":1610674676.9230645,"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}
* today at 7:37 PM {"level":"info","ts":1610674676.923075,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
* today at 7:37 PM {"level":"info","ts":1610674676.923109,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc0003bc8c0"}
* today at 7:37 PM {"level":"info","ts":1610674676.9231153,"logger":"http","msg":"server is listening only on the HTTP port, so no automatic HTTPS will be applied to this server","server_name":"srv1","http_port":80}
* today at 7:37 PM {"level":"warn","ts":1610674676.9231348,"logger":"http","msg":"user server is listening on same interface as automatic HTTP->HTTPS redirects; user-configured routes might override these redirects","server_name":"srv1","interface":"tcp/:80"}
* today at 7:37 PM {"level":"info","ts":1610674676.9236023,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["",""]}
* today at 7:37 PM {"level":"info","ts":1610674676.9301112,"msg":"autosaved config","file":"/config/caddy/autosave.json"}
* today at 7:37 PM {"level":"info","ts":1610674676.930122,"msg":"serving initial configuration"}
* today at 7:37 PM {"level":"info","ts":1610674676.9307046,"logger":"tls","msg":"cleaned up storage units"}
* today at 7:40 PM {"level":"error","ts":1610674845.046871,"logger":"http.handlers.reverse_proxy","msg":"aborting with incomplete response","error":"context canceled"}
* today at 7:40 PM {"level":"error","ts":1610674845.8488488,"logger":"http.handlers.reverse_proxy","msg":"aborting with incomplete response","error":"context canceled"}

It seems like this is just a Cockpit issue. I switched it to a redir:

http://cockpit, http://cockpit.lan {
    redir /

which is working.

I think this cockpit.conf should work:

AllowUnencrypted = true
Origins =
ProtocolHeader = X-Forwarded-Proto

But it doesn’t. My Cockpit just crashes after I login. The redirect works without it though.

This probably makes it expect that it’s being requested with the Host set to, but you’re passing it cockpit.lan. But yeah, seems like cockpit rejecting the connection, not a problem with Caddy.

I actually set the correct endpoint in my own file, and it didn’t work. The cockpit.conf file breaks cockpit on it’s own for me. Even while accessing through localhost. But the problem seems entirely on that end, not Caddy. Thanks again.


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