“Server can’t be found” is the browser’s plain-English version of DNS_PROBE_FINISHED_NXDOMAIN. It is what Chrome, Safari, Firefox, and Edge show when the request never made it past the DNS lookup stage: the browser asked the system “what is the IP address of this hostname?” and the system answered “I have no idea.” Nothing about the server is broken yet — the browser never reached one. The misleading word is “server” because almost every other browser error mentions a server. This one mentions the wrong one.
The fix depends entirely on which of the four things went wrong: the hostname does not exist, the hostname exists but the DNS resolver cannot find it, the DNS resolver is unreachable from your network, or the DNS record exists but points at the wrong place. Each of those is a different layer (the registrars, the authoritative nameservers, the network, or the records) and each has a 30-second to 5-minute fix once you know which one. The naive approach — restart the router, switch networks, try again later — sometimes works, and the rest of the time it does nothing because the broken hop is outside your laptop.
Table of contents
- What “server can’t be found” actually means
- The four layers where the breakage can sit
- Layer 1: the hostname does not exist
- Layer 2: the hostname exists but DNS is wrong
- Layer 3: the DNS resolver is unreachable
- Layer 4: the DNS record points at the wrong place
- When the error is your deployment’s fault
- FAQ
- Closing thought
What “server can’t be found” actually means
When you type a URL into a browser, the request sequence is roughly: browser asks the operating system’s DNS resolver for the IP of the hostname, the resolver asks an upstream nameserver (typically your ISP’s, or a configured public resolver like Cloudflare 1.1.1.1 or Google 8.8.8.8), the upstream asks the authoritative nameservers for the domain (the ones the registrar points at), the authoritative nameservers return an A or AAAA record, the resolver caches it, and the browser opens a TCP connection to the resulting IP. If at any step the answer is “no record”, the browser bails before any HTTP request. That bailout is the “server can’t be found” message — Chrome calls it DNS_PROBE_FINISHED_NXDOMAIN, Safari says “Safari can’t open the page because the server can’t be found”, Firefox says “Server not found” with an error code NS_ERROR_UNKNOWN_HOST.
The hidden fact is that the error message does not point at the layer that is broken. “Server can’t be found” suggests the server is missing. In practice, the server is fine — the lookup that would have found the server’s IP is what failed. Diagnosing the right layer is the skill.
The four layers where the breakage can sit
| Layer | Symptom | Where the failure is | Who can fix it |
|---|---|---|---|
| The hostname | NXDOMAIN in dig, browser error on every device | The domain is unregistered, mistyped, or expired | You (the domain owner) or the registrar |
| Authoritative DNS | Intermittent errors, works on some networks but not others | The nameservers are down, slow, or have a config bug | The DNS provider |
| The resolver path | Works on mobile data, fails on home WiFi (or vice versa) | The local network blocks or rate-limits DNS | You (the network owner) or your IT team |
| The record value | The IP in dig is wrong | A record was edited incorrectly or never updated after a deploy | You (the deploy owner) |
Each layer has a 30-second check. dig hostname, nslookup hostname 1.1.1.1, and dig @8.8.8.8 hostname together tell you which layer is broken without touching the browser.
Layer 1: the hostname does not exist
Run dig <hostname> (or nslookup <hostname> if you are on Windows). The output’s status: line tells you what the resolver saw:
NOERRORwith noanswersection: the hostname exists but the type you asked for has no record. (Layer 2 or 4.)NXDOMAIN: the hostname definitely does not exist in DNS. This is the most common case and the easiest to fix — but only if you know what hostname you actually meant.
Three things cause NXDOMAIN that all look the same to a non-developer:
- The hostname is misspelled.
runxbuld.cominstead ofrunxbuild.com. The fix is to type the URL correctly, not to debug anything. - The domain has expired. Registrars send reminder emails to the registrant contact for months, and the emails go to the address the developer set up in 2019 and never checks. If the domain is yours, log in to the registrar and renew it. If the domain is someone else’s, the site is down for everyone and the only fix is the registrant renewing.
- The subdomain does not exist.
blog.example.comfor a site that has noblogsubdomain. Confirm the subdomain is actually configured — check the DNS provider, not the website code.
For a deployment you control, the RunxBuild docs for services and domains walk through the records a service expects. If the service is up and the DNS is missing, the symptom is “server can’t be found” and not the more common 502 from a misrouted origin.
Layer 2: the hostname exists but DNS is wrong
dig returns NOERROR but the answer section is empty, or the nameservers shown in the NS section do not respond to queries. This is the case where the domain is registered but the authoritative nameservers are not answering. The symptom is sometimes intermittent — your local resolver may have cached an older, working answer, while someone else’s resolver gets the broken one.
The fix runs through the DNS provider. Log in, confirm the NS records match what the registrar says they should point at, confirm the zone file has the A and AAAA records for your hostname, and confirm the nameservers themselves are responding (dig @ns1.example.com hostname). Providers like Cloudflare, Route 53, and DNSimple have a status indicator on each nameserver; if one shows red, the fix is to switch the registration to use the others while the broken one recovers.
If the site is behind a content delivery network, the symptom of a misconfigured DNS can also look like “server can’t be found” if the CDN edge is configured to reject the hostname. Cloudflare calls this a “missing DNS record” even when the origin is fine; the fix is to add the hostname to the CDN’s DNS or to disable the proxy.
Layer 3: the DNS resolver is unreachable
You can confirm this layer quickly. Run the same dig hostname from a phone on cellular data, or from a different network (the coffee shop WiFi, a VPN through another provider, anywhere not the broken network). If the hostname resolves there but not on your home network, your local DNS resolver is the broken layer.
Common causes:
- The ISP’s resolver is down or rate-limiting. Switch the device to a public resolver: Cloudflare
1.1.1.1, Google8.8.8.8, Quad99.9.9.9. Once the device uses one of those instead of the ISP resolver, the error goes away. - The office network has a captive portal or a firewall rule that intercepts DNS on port 53. The technical workaround is to point the device at a public resolver explicitly, but the longer-term fix is for the network team to fix the rule.
- A VPN with split-DNS is configured to use the VPN’s resolver for some domains and the system resolver for others, and the routing decides the public hostname is a corporate one. Disconnect the VPN to confirm; reroute the public resolver inside the VPN config to fix.
For apps with a managed database or backend, an unreachable resolver is also a deploy-side concern: the platform’s outbound DNS has to work for the service to reach any external API. The RunxBuild hosting calculator models the network layer alongside the compute and storage so the cost of running on a network with degraded DNS is visible before deploy.
Layer 4: the DNS record points at the wrong place
The hostname resolves, but the IP is wrong. The site loads, or it does not load, on whichever origin that IP points at. The error on the user side can look like “server can’t be found” if the IP happens to belong to a host that is not listening, or it can look like a 502 if the IP points to a load balancer that returns one. Either way, the symptom from the user side is “the site is broken” and the diagnosis from the operator side is “the DNS points somewhere other than the deploy”.
The check that catches this is the comparison between dig hostname and the actual IP of the running service. If those do not match, the DNS is the broken layer. The fix is to update the record to point at the right IP (or, if the deployment is on a platform with automatic DNS, to confirm the platform’s proxy is routing to the correct service).
The most common cause of a wrong DNS record in 2026 is a service that moved between platforms: a DNS record that used to point at a Heroku IP, a Render proxy, or a Cloudflare worker IP now points somewhere else after a migration. If the deployment recently changed platforms, the DNS records are the first thing to check.
When the error is your deployment’s fault
If you are the one who deployed the service, the four layers above cover most of the cases. Two extra cases show up specifically on deployment platforms:
- The platform propagated the DNS but the service was paused, scaled to zero, or had a bad release. The user sees “server can’t be found” in this case if the platform has not yet set up the DNS record that points at a healthy instance, or if it points at a non-listening port. Check the platform’s health dashboard and confirm the latest deploy is
runningand notfailedbefore debugging DNS. - The custom domain was added but the verification step was skipped. Most platforms require a verification record (often a TXT record) before the custom domain routes traffic. If the verification is missing, the platform’s edge may serve a “this hostname is not configured here” page, which the browser shows as “server can’t be found”.
The custom domain overview covers the records a domain needs before traffic starts. For a RunxBuild deploy specifically, the docs for static sites and services describe the records the platform expects.
FAQ
Is “server can’t be found” the same as “site can’t be reached”?
No. “Site can’t be reached” (Chrome) and “Safari can’t connect to the server” (Safari) usually mean ERR_CONNECTION_REFUSED — the browser reached the IP but the port refused the connection. “Server can’t be found” is the DNS-level error described in this post. The two errors have different fixes because the broken layers are different.
Why does the error say “server” when the server is fine?
Because the browser is the user-facing surface and the DNS resolver is invisible. The browser does not know which layer failed; it knows that it could not get an IP. The error message is the most generic phrasing available, but the underlying cause is almost always DNS, not the server.
Can a VPN cause “server can’t be found”?
Yes. A VPN can intercept DNS, force traffic through a proxy that does not resolve the hostname, or block outbound port 53 entirely. Disconnect the VPN as the first diagnostic step when an error appears on a network where you have a VPN configured.
Should I fix this with DNS over HTTPS (DoH)?
DoH encrypts the DNS query so the network cannot see or block the hostname being looked up. It does not fix a broken authoritative nameserver or a wrong DNS record. DoH helps with layer 3 (the resolver path) and only sometimes. The four-layer approach in this post is the one that catches the most cases.
What if dig shows the right IP but the browser still fails?
The IP is right but the port or the protocol is wrong. Most sites run on port 443 with HTTPS. If you typed http://example.com:8080, the port refusal error is what you would see, not the DNS error. Confirm the URL has the right scheme and port.
Closing thought
“Server can’t be found” looks like the same error every time, but the layer that is broken is different each time. The four-layer check — exists, nameservers reachable, resolver path open, record points at the right place — takes 30 seconds with dig and catches 90% of the cases without contacting anyone. For a deployment you control, the RunxBuild hosting calculator is a useful fallback for when the broken layer turns out to be the platform: it shows what the deployment is actually costing, which is the part that sometimes turns an intermittent DNS issue into a “let me migrate this” decision.