I'm running Proxmox VE on a Dell PC, with an Ubuntu 22.04 VM hosting Docker Compose. The setup is a multi-tenant hosting platform using Nginx as a reverse proxy, along with MySQL, PhpMyAdmin, an ACME/Let's Encrypt companion, and separate web and file-manager containers for each customer.
The platform hosts five websites. Most of the time, each domain receives its own correct HTTPS certificate, but occasionally a domain such as secondwebsite.com receives the certificate for the main site, firstwebsite.ch, which is configured as Nginx's DEFAULT_HOST. The behavior is intermittent rather than a consistent configuration failure.
For example, repeatedly running openssl s_client with the correct SNI sometimes returns the second website's certificate 200 times in a row, while other times it returns the main site's certificate 200 times in a row.
DNS records appear correct, nginx -T shows the expected configuration, and there are no duplicate Nginx containers. I also investigated Docker and UFW iptables rules, but clearing or changing them only helped temporarily. The problem can return after Docker or the Proxmox VM is restarted.
What could cause Nginx to alternate between the correct certificate and DEFAULT_HOST's certificate, and what diagnostics should I run? The relevant versions are Ubuntu 22.04, Docker Compose 5.0.2, Nginx 1.31.0, and the ACME companion 3.1.3.
2 Answers
The pattern of getting 200 correct results or 200 incorrect results is a strong sign that requests are reaching different endpoints, rather than Nginx randomly changing certificates. Check every DNS result with `dig +short A secondwebsite.com` and `dig +short AAAA secondwebsite.com`. Test each returned IPv4 and IPv6 address directly on port 443 while still sending `-servername secondwebsite.com`. If one address returns the default certificate, investigate that address, its port forwarding, and any old server still listening there. Also verify both IPv4 and IPv6 listeners in `nginx -T`, including `listen 443 ssl` and `listen [::]:443 ssl`.
An outdated AAAA record, old public IP, or second reverse-proxy instance can produce exactly this behavior.
Another possibility is an extra IPv6 listener or an older Nginx endpoint that still has only the default certificate. Compare IPv4 and IPv6 explicitly with `curl -4` and `curl -6`, and inspect the public NAT or firewall rules to make sure both protocols reach the same Docker proxy. The Proxmox and VM layers are unlikely to alter TLS certificates by themselves; they matter mainly if they expose another address, forwarding rule, or stale service.
Rather than repeatedly testing the hostname alone, record the resolved addresses and certificate subject for each one. That will quickly distinguish DNS or routing from dynamic Docker/Nginx configuration generation.
If the individual IPs all return the correct certificate, check whether a web container is stopping or crash-looping. With a Docker-generated Nginx configuration, the virtual host can disappear when its associated container is unavailable. The request then falls through to DEFAULT_HOST, which explains why the wrong certificate appears in long blocks and why the issue may return after a restart.