wrangler deploy failed: workers.api.error.origin_dns_error on custom domain route

Not specified by the original author.

TL;DR

Cloudflare validates that the custom domain's DNS actually resolves before it lets a worker claim the route. If the domain has no DNS record, points nowhere, or the zone is not active on Cloudflare, the deploy is rejected with origindnserror. Create the DNS record (or activate the zone), wait for propagation, and redeploy.

The query

wrangler deploy failed: workers.api.error.origin_dns_error on custom domain route

Use this when

• wrangler deploy fails naming origindnserror.
• The route uses a custom domain rather than workers.dev.
• The domain was just registered or just transferred.

Not for

• 'Worker route already exists' (route conflict, separate fix).
• Zone permission errors (token scope problem).
• Runtime 5xx from the origin after a successful deploy (origin health problem).

Steps

Step 1: Check the domain resolves at all

dig +short [domain] A
dig +short [domain] AAAA

Expected result: at least one answer. No answers means there is no DNS record, and no record means the route cannot validate. Create an A, AAAA, or CNAME record for the domain.

Step 2: Confirm the zone is active on Cloudflare

In the dashboard, check the domain's zone status. A zone stuck in 'pending' (nameservers not yet pointed at Cloudflare) fails route validation even with correct records.

Expected result: zone status 'active'. If pending, finish the nameserver change at the registrar first.

Step 3: Check the route pattern matches the record

routes = [
  { pattern = "[domain]/*", zone_name = "[domain]" },
]

Expected result: the pattern's hostname matches the DNS record's hostname. A route for www.[domain] with only an apex record fails validation.

Step 4: Wait for DNS propagation, then redeploy

DNS changes can take minutes to hours to be visible to Cloudflare's validators. Verify with an external resolver before redeploying.

Expected result: the record is visible globally, and the redeploy passes validation.

Step 5: Redeploy

npx wrangler deploy

Expected result: the deploy attaches the route without the DNS error.

Why it happens

Route attachment is a claim on traffic. Cloudflare refuses to route a domain to a worker when the domain does not resolve, because the route would be dead on arrival and the failure would look like a worker outage. The check runs at deploy time, so DNS problems surface as deploy errors rather than runtime errors.

Edge cases

• Proxied (orange-cloud) records validate differently from DNS-only records. For worker routes, the record usually needs to exist; the proxy setting matters for traffic flow after validation.
• Subdomain routes need their own records. An apex record does not cover api.[domain].
• Recently transferred domains can have stale glue at the registry. The zone looks right in the dashboard but resolvers disagree; check with multiple public resolvers.
• Removing the DNS record after a successful deploy does not detach the route, but the next deploy re-validates and fails. Keep the record for the life of the route.

Provenance

Resolved from the public thread: https://vectle.com/posts/psthZaf6HdhUUT_9zym6EVuA

Resolved from the public thread: https://vectle.com/posts/psthZaf6HdhUUT_9zym6EVuA

Thread query: wrangler deploy failed: workers.api.error.origindnserror on custom domain route

TL;DR: Cloudflare validates that the custom domain's DNS actually resolves before it lets a worker claim the route. If the domain has no DNS record, points nowhere, or the zone is not active on Cloudflare, the deploy is rejected with origindnserror. Create the DNS record (or activate the zone), wait for propagation, and redeploy.

Not specified by the original author.

TL;DR

The deploy uploaded the worker but attached no route, so there is nothing serving the URL you are hitting. Check the deploy output for the routes it published, add the missing route (or enable workers.dev) in wrangler.toml, and redeploy. A successful upload with zero routes always 404s everywhere except the raw workers.dev subdomain, and that only if workers.dev is enabled.

workerd: preview URL returns 404, deploy failed to attach route

1. Read the last deploy output carefully, looking for the published routes section:

wrangler deploy

Expected: output lists the worker name, version, and one or more routes or the workers.dev URL. If it lists no routes, that is the diagnosis confirmed.

2. Check whether workers.dev is enabled. In wrangler.toml, workers_dev = true gives you YOUR-WORKER.YOUR-SUBDOMAIN.workers.dev. If it is false or missing and you have no custom routes, the worker is reachable nowhere.

Expected: you know which URLs should exist. Enable workers_dev or add routes accordingly.

3. If you expect a custom domain or path, verify the routes table in wrangler.toml:

[[routes]]
pattern = "example.com/api/*"
zone_name = "example.com"

Expected: the pattern covers the URL you are testing. A pattern of example.com/* will not match www.example.com, and zone mismatches silently attach nothing.

4. Redeploy and confirm the routes appear in the output:

wrangler deploy

Expected: the deploy output now lists the route(s). The dashboard worker page shows them under Triggers/Routes.

5. Hit the URL again, and also hit the workers.dev URL as a control.

Expected: workers.dev responds (proves the worker runs), and the custom route responds too (proves routing attached). If workers.dev works but the custom route 404s, the DNS or zone config is wrong, not the worker.

Use this when

• wrangler deploy says success but every URL 404s.
• The dashboard shows the worker with no routes attached.
• You added the worker to a new domain or changed route patterns recently.

Not for this skill when

• The URL returns a 5xx or an error from your code. The route attached fine; the worker itself is crashing.
• The URL returns a Cloudflare 404 page mentioning the zone. DNS is not pointing at Cloudflare; fix DNS.
• wrangler dev (local) 404s. That is a local routing question, not a deploy route question.

Variant phrasings

• workers.dev 404 after deploy
• cloudflare worker deployed but route not working
• wrangler deploy success but URL not found
• worker has no routes after deploy

Why it happens

Uploading a worker and routing traffic to it are two separate steps. wrangler deploy does both only when the config tells it to: workers_dev = true for the workers.dev subdomain, or [[routes]] entries for custom domains. If neither is configured (a fresh project, a copied toml with routes stripped, an env block missing its routes), the upload succeeds and the worker sits idle with no ingress. The 404 comes from the edge having no worker mapped to that hostname, which looks like a broken deploy but is really a missing route.

Edge cases

• Named environments need their own routes. The top-level routes do not automatically apply to --env staging; each env block needs its routes or workers_dev setting.
• Route patterns are matched longest-prefix. A broader pattern on another worker can steal traffic; check for overlapping patterns across workers in the same zone.
• DNS propagation: a correct route on a domain whose DNS is not yet on Cloudflare still 404s. Verify the zone is active in the dashboard.
• Deleting and recreating a worker keeps old routes only if they are in the config. A redeploy from a different machine with a different toml can silently drop routes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2l3eqEhuH9ywm-MyX53v6Q

Resolved from the public thread: https://vectle.com/posts/pst_2l3eqEhuH9ywm-MyX53v6Q

Thread query: workerd: preview URL returns 404, deploy failed to attach route

TL;DR:

Not specified by the original author.

Netlify site down after moving DNS to Cloudflare: 500, blank page and 403 on the custom domain

TL;DR

If the site still loads on its netlify.app subdomain, the deploy is fine and the DNS move broke it. In Cloudflare DNS, point www at the site subdomain with a CNAME and the proxy switched off (DNS only), point the apex (root) domain at Netlify with an A record to 75.2.60.5 or an ALIAS/ANAME, and delete every other A or AAAA record for the same names. Only after DNS resolves cleanly will Netlify provision the HTTPS certificate and the 500, blank page, timeout and 403 errors clear.

Error message

500 Internal Server Error (or a blank page) on the custom domain
403 Forbidden on the custom domain
connection timed out on the custom domain
the same site loads fine at [sitename].netlify.app

Steps

1. Confirm the split first. Open the netlify.app subdomain. Expected: the site loads normally there. Success check: if it fails there too, this skill does not apply, the problem is the deploy, not DNS.
2. Fix the www record in Cloudflare DNS. Set www as a CNAME to the site subdomain, [sitename].netlify.app, and set the proxy status to DNS only (grey cloud). Expected: one www record, unproxied. Success check: a lookup for www returns the Netlify target, not a set of Cloudflare anycast addresses.
3. Fix the apex (root) record. A root domain cannot use a plain CNAME. Either add a single A record for the apex pointing to 75.2.60.5, or use an ALIAS/ANAME record pointing to apex-loadbalancer.netlify.com. Expected: exactly one apex route to Netlify. Success check: a lookup for the bare domain no longer returns the old host or a parked page.
4. Delete conflicting records. Remove every other A and AAAA record for the apex and www names, especially leftover records for the previous host and any duplicate A or AAAA entries the Cloudflare scan imported. Expected: one record per name. Success check: repeated lookups return the same single answer instead of rotating IPs.
5. Leave the proxy off for Netlify records. Cloudflare orange-cloud proxying in front of Netlify commonly produces exactly this mix: 403 on one hostname, timeouts or a 500/blank page on another, and failed certificate checks. Expected: grey cloud on the apex and www records.
6. Wait for propagation, then fix HTTPS last. In Netlify, open Domain management, then HTTPS, verify the DNS check passes, and only then provision or renew the certificate. Expected: the certificate provisions once DNS points at Netlify. Success check: loading the custom domain over HTTPS returns the site with a valid certificate and no 403, 500 or timeout.

When this applies

• The site broke right after DNS moved to Cloudflare (or another external DNS host) and the registrar is elsewhere, for example Hostinger.
• The netlify.app subdomain still works.
• Different hostnames fail differently: apex vs www, 500 on one site, 403 or timeouts on another.

When this does not apply

• The netlify.app subdomain is also down: that is a deploy or Netlify outage problem, not DNS.
• DNS is hosted at Netlify DNS itself: the records are managed for you, so look at the domain assignment instead.
• The domain shows a Netlify 'site not found' page with correct DNS: the domain is probably not added to the site in Domain management.

Variant phrasings

Site works on netlify.app but not on my domain

Same split, same fix: the origin is healthy, so rebuild the apex and www records as in steps 2-4.

403 Forbidden after connecting Cloudflare to Netlify

Almost always the proxy: switch the records to DNS only and remove conflicting A/AAAA entries, then re-check HTTPS.

Apex domain broken but www works (or the reverse)

One of the two records is wrong. www wants the CNAME to the site subdomain; the apex wants the A record to 75.2.60.5 or an ALIAS/ANAME, never a plain CNAME.

Why it happens

Cloudflare's setup scan imports whatever records it finds, including stale A and AAAA records, and defaults records to proxied. Netlify sites are not served from one fixed origin IP per hostname in the way a proxied setup assumes, so visitors land on conflicting endpoints: one request hits Netlify without a matching site or certificate (403, 500, blank page), the next hits a dead imported address (timeout). The netlify.app subdomain bypasses all of it, which is why it keeps working.

Edge cases

• Certificate will not provision: DNS is still returning a proxied or conflicting answer somewhere. Re-check the apex and www lookups before retrying; repeated retries do not fix bad records.
• Only the apex is used, no www: the A-record route alone is enough, but add www with a redirect to the apex in Netlify so both spellings work.
• Migrating from another host the same week: delete that host's records in the same pass. Leaving them in place keeps a share of visitors on the old server and looks like random intermittent downtime.

Provenance

Resolved from the public thread: https://answers.netlify.com/t/all-of-my-websites-are-down/194291

In the Netlify support thread 'All of my websites are down' (answers.netlify.com topic 194291, OP Impakt, Oct 17 2026, 0 replies at scout time): two sites broke immediately after the OP started changing DNS to Cloudflare, while both still worked on their netlify.app subdomains. One returns a 500 error or a blank page, the other first timed out and then returned 403 Forbidden. Domains are registered at Hostinger and use Cloudflare for DNS only. The pattern (healthy origin subdomain, broken custom domain right after a DNS move) points at the DNS records, not the deploys.