Debugging Nginx Proxy Manager Let's Encrypt HTTP Challenge

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:443

Multiple 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      |      |      vsales.lf-t.net      |      |      +--> AAAA record             |             |             v        IPv6 address        2001:1640:5::3:65             |             |             v        IPv6 unreachable             |             |             v        HTTP challenge failed

---

Takeaway for Twenty CRM deployments

When adding multiple domains/subdomains to the same Twenty CRM instance:

Always verify each hostname independently:

dig A domain.example.comdig AAAA domain.example.com

Do not assume that because:

app.example.com ✅crm.example.com ❌

share the same NPM Proxy Host, they also share the same DNS behavior.

A single stale AAAA record on one hostname can break only that hostname's Let's Encrypt challenge.