Debugging Nginx Proxy Manager Let's Encrypt HTTP Challenge
Nginx Proxy Manager kept failing the Let's Encrypt HTTP challenge on a multi-subdomain Twenty CRM setup. How I found the cause — and what finally worked.
Failure for Twenty CRM Multi-Subdomain Setup
Environment / Context
This setup was used for a Twenty CRM deployment.
The architecture:
Internet
↓
Nginx Proxy Manager
↓
Twenty CRM backend
↓
172.29.99.30:443Multiple subdomains were intentionally routed through the same NPM Proxy Host because they all served the same Twenty CRM instance:
app.sales.lf-t.netlf-t.sales.lf-t.netlft-security.sales.lf-t.netsales.lf-t.netusa.sales.lf-t.net
NPM configuration:
server_name app.sales.lf-t.net lf-t.sales.lf-t.net lft-security.sales.lf-t.net sales.lf-t.net usa.sales.lf-t.net;All domains forwarded to the same backend.
Important Twenty CRM specific note
Because Twenty CRM is commonly exposed through multiple branded/customer-facing domains, it is easy to assume a certificate problem is caused by:
- backend routing
- application configuration
- NPM proxy settings
- CRM redirects
In this case, the backend was healthy.
The actual problem was DNS resolution before the request even reached Twenty CRM.
The failure chain was:
Let's Encrypt
↓
sales.lf-t.net
↓
+--> AAAA record
↓
IPv6 address 2001:1640:5::3:65
↓
IPv6 unreachable
↓
HTTP challenge failedTakeaway for Twenty CRM deployments
When adding multiple domains/subdomains to the same Twenty CRM instance:
Always verify each hostname independently:
dig A domain.example.com
dig AAAA domain.example.comDo not assume that because two hostnames sit on the same NPM Proxy Host they also share the same DNS behavior — one can be fine while the other fails:
app.example.com ✅
crm.example.com ❌A single stale AAAA record on one hostname can break only that hostname's Let's Encrypt challenge.