DNS Not Resolving
Two deployment strategies exist for DNS, and the troubleshooting path differs between them. Identify which one you are using before diving in.
Option A — Auto-create: cloudflare_create_record = True on the subscription. The platform creates an individual A record in Cloudflare for each subscription during the build sequence.
Option B — Manual wildcard: cloudflare_create_record = False. You manage DNS yourself, typically with a *.yourdomain.com → server_ip wildcard record. The platform never touches Cloudflare DNS.
DNS Propagation Basics
Cloudflare records with TTL 1 (Auto) typically propagate globally within 1–2 minutes. Longer delays happen when your local ISP has cached an NXDOMAIN response from before the record existed.
Always verify with a public resolver to bypass your local cache:
# Check whether the record exists at all
dig A customer.yourdomain.com
# Bypass local cache — query Cloudflare's resolver directly
dig A customer.yourdomain.com @1.1.1.1
# Check from multiple global locations
# https://dnschecker.org or https://whatsmydns.net
Tip
If dig @1.1.1.1 returns the correct IP but the site is still unreachable, DNS is fine — the problem is with Nginx. Skip to Site unreachable despite DNS resolving.
Option A: Auto-Create DNS Failures
Quick Reference
| Issue | Where to look | Fix |
|---|---|---|
| Record not created at all | Cloudflare tab on subscription — check cloudflare_record field | Run Diagnosis & Fix |
| Record exists but wrong IP | Cloudflare tab → record → target field vs subscription's server_ip | Run Diagnosis & Fix — it detects the mismatch and updates the record |
| Error 81058 (duplicate record) | Chatter on subscription | Run Diagnosis & Fix — it links the existing record instead of recreating |
| API token expired (HTTP 401) | Build Fail Message field on the subscription | Regenerate token in Cloudflare dashboard, update the connector record, re-run |
| Zone ID wrong | Cloudflare tab → cloudflare_record_zone_id | Copy the correct Zone ID from Cloudflare → your domain → Overview → right sidebar |
Record Not Created
- Open the subscription and check the chatter for a DNS error message.
- Go to the Cloudflare tab and confirm cloudflare_connector_id and the Zone ID are both filled.
- Verify the API token in the connector has Zone → DNS → Edit permission on the correct zone.
- Click Action → Diagnosis & Fix — if the record is missing, the fix creates it automatically.
Record Exists but Wrong IP
- Open the Cloudflare tab on the subscription and click the DNS record link.
- The target field in the record must match server_ip on the subscription.
- If they differ, run Diagnosis & Fix — it detects the IP mismatch and issues an update call to Cloudflare without recreating the record.
Error 81058 — Duplicate Record
Cloudflare returns error 81058 when you attempt to create a record that already exists (for example, a leftover record from a previous build or a manually created entry). Diagnosis & Fix handles this automatically: it searches the zone for a matching record, links it to the subscription, and skips recreation.
Note
If 81058 appears repeatedly for new subscriptions, check whether a wildcard or conflicting A record exists in your Cloudflare zone. A *.yourdomain.com wildcard does not block individual record creation, but a pre-existing exact-match record will.
Option B: Wildcard DNS Failures
| Issue | Fix |
|---|---|
| No wildcard record | Add *.yourdomain.com → server_ip as an A record in Cloudflare. Set TTL to Auto. |
| Wildcard exists but subdomain still fails | Check whether a more specific record exists for that subdomain — Cloudflare gives priority to exact matches over wildcards. |
| Proxied (orange cloud) wildcard | SSL must be configured in Cloudflare for the zone. For testing, switch to DNS only (grey cloud) to eliminate SSL as a factor. |
Cloudflare Proxy Mode
The proxy toggle affects both DNS verification and SSL:
| Mode | Traffic path | SSL handled by | dig returns |
|---|---|---|---|
| Proxied (orange cloud) | Through Cloudflare CDN | Cloudflare (Origin certificate) | A Cloudflare IP, not your server IP |
| DNS only (grey cloud) | Directly to your server | Nginx Proxy Manager (Let's Encrypt) | Your server IP |
Note
If you are using Proxied mode, dig will never return your server IP — it will return a Cloudflare anycast IP. This is correct behavior. Do not interpret a Cloudflare IP as a misconfiguration.
Warning
When using Proxied mode, Nginx Proxy Manager cannot obtain a Let's Encrypt certificate because the ACME HTTP-01 challenge never reaches your server. Use a Cloudflare Origin Certificate in NPM instead, or switch to DNS only mode.
Site Unreachable Despite DNS Resolving
If dig @1.1.1.1 returns the correct IP but the domain is still unreachable or returns a 502/504 error, DNS is working correctly. The fault is in Nginx Proxy Manager.
- Open the subscription form and click the NPM server link.
- On the NPM server record, click Test Connection to confirm the Master can reach NPM.
- Run Action → Diagnosis & Fix on the subscription — it checks whether the proxy host exists and will create or repair it.
- If the proxy host exists in NPM but the site is still down, check the NPM Access Log and Error Log for the failing domain.
Tip
See Build Failed for a full breakdown of NPM-specific failures.