I'm running Proxmox VE on a Dell PC with an Ubuntu 22.04 VM. Docker Compose hosts a multi-tenant service behind an Nginx reverse proxy, with MySQL, phpMyAdmin, ACME, and a Let's Encrypt companion generating certificates automatically. Each customer also has a web container and a file manager container.
The setup serves five websites, but one domain intermittently receives the certificate for the default website instead of its own certificate. For example, repeated tests against secondwebsite.com sometimes return its correct certificate for all 200 requests, while other times all 200 requests return the certificate for firstwebsite.com, which is configured as Nginx's DEFAULT_HOST.
DNS records appear correct, nginx -T shows the expected configuration, and I have not found duplicate Nginx containers. I also investigated Docker, UFW, and iptables rules, but clearing the rules only helped temporarily. The behavior can return after containers are stopped or after the Proxmox host and VM are rebooted.
The test uses SNI with openssl s_client, so I'm trying to determine whether the problem is caused by DNS or IPv6 routing, another listener or reverse proxy, or a customer container becoming unavailable and causing the generated Nginx configuration to fall back to DEFAULT_HOST. The environment uses Ubuntu 22.04, Docker Compose 5.0.2, Nginx 1.31.0, and the ACME companion 3.1.3. What should I check first?
3 Answers
The pattern of getting 200 correct results or 200 incorrect results is a strong clue that traffic is reaching different endpoints, rather than Nginx randomly changing certificates. Check every DNS result, including IPv6: `dig +short A secondwebsite.com` and `dig +short AAAA secondwebsite.com`. Then connect directly to each returned address with SNI and inspect the certificate. Also verify both IPv4 and IPv6 listeners in `nginx -T`, including `listen 443 ssl` and `listen [::]:443 ssl`. An old AAAA record, stale public IP, second port forward, or another Nginx instance could be serving the default certificate.
If DNS and IPv6 are clean, look for an extra HTTPS listener or backend that exists only after a reboot. Test each resolved IP directly with `openssl s_client -connect IP:443 -servername secondwebsite.com`, and check the host’s NAT rules and Docker-published ports. One address serving the default certificate identifies the path that needs fixing; the certificate generation itself is probably not the root cause.
Another possibility fits the behavior after restarts: the generated virtual host may disappear when the customer’s web container is stopped, crash-looping, or not discoverable by the configuration generator. In that case, the request can fall through to DEFAULT_HOST, which explains both the default certificate and the repeated blocks of correct or incorrect results. Check the customer container status and logs, then inspect the generated Nginx configuration while the issue is happening. Also review the ACME companion and docker-gen logs to see whether the vhost or certificate files are being removed and regenerated.
That makes sense. I’ll test each A and AAAA address directly and compare the certificates instead of only testing the hostname.