Caddy runs in its own container on the caddy_net bridge network, so
"localhost" in a Caddyfile site block resolves to Caddy's own
container — never the host, and never a sibling container. That
broke every reverse proxy pointed at a network_mode: host service
(confirmed live with asterisk-do's web admin): once nothing else
(like a forward_auth redirect) intercepted the request first, Caddy
couldn't actually reach the upstream.
- services/caddy.sh: add extra_hosts so host.docker.internal resolves
inside the Caddy container (Linux Docker needs this explicitly —
it's automatic only on Docker Desktop).
- lib/common.sh's configure_caddy_for_service: bare-port upstreams
(its documented "host-network service" case) now target
host.docker.internal instead of localhost.
- services/asterisk-do.sh: its self-contained Caddy block (doesn't go
through configure_caddy_for_service) gets the same fix for local
Caddy, and now correctly targets the droplet's public IP instead of
localhost for the remote-Caddy snippet case, which had the same bug.
services/asterisk.sh needs no direct change — it already goes through
configure_caddy_for_service, so it inherits the fix.
Claude
6c48bdc707