1. Caddy version (caddy version
):
v2.4.3
2. How I run Caddy:
a. System environment:
Proxmox VM > Debian (10.10) > Docker
b. Command:
Docker Compose
c. Service/unit/compose file:
caddy:
image: caddy
container_name: caddy
hostname: caddy
restart: unless-stopped
networks:
- base
ports:
- "80:80"
- "443:443"
environment:
- MY_DOMAIN
volumes:
- ${USERDIR}/docker/Caddyfile:/etc/caddy/Caddyfile
- ${USERDIR}/docker/caddy/data:/data
- ${USERDIR}/docker/caddy/config:/config
d. My complete Caddyfile or JSON config:
{
admin :2020
email ...
#acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}
ha.horsboll.dk {
reverse_proxy whoami:80
}
3. The problem I’m having:
For the life of me I can’t get reverse_proxy to work with https. If forcing port :80 everything works as intended.
The intent is to have Caddy reverse_proxy my subdomain to a different VM on the proxmox host hosting Home Assistant (which run on another subnet than the docker containers). This works if forcing port 80, but for now I’ve set up some test-containers in the Docker to eliminate this bridging as a source of my errors (or HA requring it’s own setup to accept the proxy - I’ll cross that bridge when I get there I suppose ;).
4. Error messages and/or full log output:
docker caddy logs
gives me the following (which look OK to me)
{"level":"info","ts":1624947039.7097056,"logger":"admin","msg":"admin endpoint started","address":"tcp/:2020","enforce_origin":false,"origins":[":2020"]}
{"level":"warn","ts":1624947039.7097206,"logger":"admin","msg":"admin endpoint on open interface; host checking disabled","address":"tcp/:2020"}
{"level":"info","ts":1624947039.7098718,"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":1624947039.7098897,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"info","ts":1624947039.7100322,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["adguard.horsboll.dk","ha.horsboll.dk"]}
{"level":"info","ts":1624947039.7100985,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc000545500"}
{"level":"info","ts":1624947039.7135723,"logger":"tls.cache.maintenance","msg":"stopped background certificate maintenance","cache":"0xc000544af0"}
{"level":"info","ts":1624947039.7137063,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1624947039.7137303,"logger":"admin.api","msg":"load complete"}
{"level":"info","ts":1624947039.718417,"logger":"admin","msg":"stopped previous server","address":"tcp/:2020"}
5. What I already tried:
I’m fairly new in this home-hosting setup (and Linux), so I feel like it’s something obvious I’m missing. It has been a breeze setting things up to this point, but now I’ve spent almost a weekfull of entire evenings trying to get https to work - and I just don’t have the techical knowhow to troubleshoot it. I feel like I’ve tried everything from setting up firewall rules (and completely disabling the firewall), trying host-networked Docker containers, different Linux distributions (debian and alpine), etc. I honestly can’t remember everything I’ve been though, but I feel like I’ve read every caddy-tutorial and forum post out there, along with the the caddy documentation.
Online port-checkers tell me that :80 is open, but :443 is not. So it seems nothing runs actively on the port, but everything looks mapped correctly from Docker and Caddy seems to be listening on the port (as far as I can see with commands like “lsof -i -P -n | grep LISTEN” (which tells me Docker is listening):
docker-pr 13047 root 4u IPv4 57437 0t0 TCP *:443 (LISTEN)
docker-pr 13053 root 4u IPv6 55378 0t0 TCP *:443 (LISTEN)
Previously I had a Home Assistant/DuckDNS setup running on a RPI, so I know that the port isn’t blocked from my ISP and that my router forwards it correctly. The Docker VM has it’s own IP on my home network, so unless there’s something buried within this software-approach to defining a VM as it’s own device, then everything up to this point has been verified to work on different hardware.
6. Links to relevant resources:
I apologize if there’s something missing in the above. I’m not strong in the Linux-kung fu, but I will do my best to supply further information as requested.
Thanks in advance for any pointers you might have.