TLS process freezes all Docker containers?

1. The problem I’m having:

I’ve set up Caddy as a reverse proxy for my services running in Docker. I have an external domain, and have the DNS point to my internal IP of the Docker host machine. Services are only accessible from local network or VPN, so I set up DNS-01 challenge with Porkbun’s API. I got everything working great, except for one (very disruptive) glitch:

The first time any browser loads a domain or subdomain, it takes a couple of minutes and then times out – and during that time, every container I have in Docker stops responding as well, then it all just continues working like nothing happened. Subsequent visits to that domain/sub on that browser load instantly and without issue.

Checking Docker resources during this lockout, everything looks fine. Max Container CPU Usage is about 8%, Container Memory Usage is about 4GB (out of 30.44GB) – so it doesn’t appear that the containers are actually locking up, they just stop communicating outside of the containers. I can’t load them on other devices, either.

As such, I stripped it all down to base install and started adding components back in to see where the issue begins.

If I set tls internal in my Caddyfile, every subdomain loads immediately and without issue.

If I set a path to tls certs, I get the lock-up behavior again. Looking at the logs, it seems to just spam it a million times?? I have no idea what’s going on here.

2. Error messages and/or full log output:

3. Caddy version:

v2.10.2

4. How I installed and ran Caddy:

a. System environment:

Windows 11 Pro, WSL2 (version 2.6.1.0)
Docker Desktop 4.48.0, Docker Engine version 28.5.1
Ubuntu 24.04.3 LTS

b. Command:

docker compose up -d

c. Service/unit/compose file:

services:
 caddy:
   container_name: caddy
   restart: always
   image: caddy:latest
   volumes:
      - /mnt/c/Docker/caddy/conf:/etc/caddy
      - /mnt/c/Docker/caddy/site:/srv
      - /mnt/c/Docker/caddy/data:/data
      - /mnt/c/Docker/caddy/config:/config
      - /var/run/docker.sock:/var/run/docker.sock
      - /home/dusti/.acme.sh:/home/dusti/.acme.sh
   ports:
     - 80:80
     - 443:443
     - 443:443/udp
   networks:
     - caddy
# networks
networks:
 caddy: 
   external: true

d. My complete Caddy config:

# globally
{
	debug
}

(tls) {
	tls /home/dusti/.acme.sh/heida.cloud/fullchain.cer /home/dusti/.acme.sh/heida.cloud/heida.cloud.key
}

heida.cloud {
	import tls
}

*.heida.cloud {
	import tls
	# Audiobookshelf
	@books host books.heida.cloud
	handle @books {
		reverse_proxy 192.168.1.5:13378
	}
	# Homepage
	@homepage host homepage.heida.cloud
	handle @homepage {
		reverse_proxy 192.168.1.5:3000
	}
	# Channels DVR
	@channels host channels.heida.cloud
	handle @channels {
		reverse_proxy 192.168.1.5:8089
	}
	# Lazy Librarian
	@librarian host librarian.heida.cloud
	handle @librarian {
		reverse_proxy 192.168.1.5:5299
	}
	# Trilium
	@notes host notes.heida.cloud
	handle @notes {
		reverse_proxy 192.168.1.5:8001
	}
	# Readeck
	@bookmarks host bookmarks.heida.cloud
	handle @bookmarks {
		reverse_proxy 192.168.1.5:8000
	}
	# Portainer
	@portainer host portainer.heida.cloud
	handle @portainer {
		reverse_proxy 192.168.1.5:9443
	}
	handle {
		respond "Oops! That subdomain hasn't been configured yet!"
	}
}

recipes.heida.cloud {
	import tls
	reverse_proxy 192.168.1.5:9925
}

5. Links to relevant resources:

I narrowed in on the problem! I had host networking enabled on Docker Desktop, and turning it off solved the issue. I’d like to have the option to use host networking, though, so if there’s an actual fix here please help!

This doesn’t seem to be a Caddy issue. It’s either a Docker issuer or a problem with your host network.