Is Your Website Down Because of DNS or Hosting?

Your website won't load. Your first instinct is to panic — your second is to contact support. But which support? Your domain/DNS provider or your hosting company? Pick the wrong one and you'll spend an hour being bounced between them while your site stays dark.

The good news: you can usually figure out which side is broken in about five minutes, with free tools already on your computer. This guide shows you how — in plain English, no sysadmin degree required.

The Quick Answer: Run Two Tests

Everything in this article boils down to two questions:

1. Does your domain name resolve to an IP address? (That's the DNS test.)
2. Does that IP address actually serve your website? (That's the hosting test.)

• Domain doesn't resolve → it's a DNS problem.
• Domain resolves, but the server doesn't respond → it's a hosting problem.
• Domain resolves and the server responds → the problem is something else (your connection, a CDN layer, or the site's own code).

The rest of this guide teaches you how to run both tests and read the results confidently.

What DNS and Hosting Actually Do (Plain English)

DNS is the phone book

DNS (Domain Name System) translates your human-readable domain — yourbusiness.com — into a machine-readable IP address like 203.0.113.45. When you type a domain into your browser, the first thing that happens is a DNS lookup: "what's the address for this name?" If DNS can't answer, your browser never even gets to knock on the server's door. You'll typically see errors like "server IP address could not be found" or ERR_NAME_NOT_RESOLVED.

Hosting is the building

Your hosting server is the computer that stores your website's files and answers when visitors arrive. Once DNS hands the browser the IP address, the browser connects to that server and asks for your pages. If the server is crashed, overloaded, misconfigured, or blocking the request, DNS did its job fine — the building itself has a problem. You'll typically see timeout errors or HTTP 500-series error pages instead.

Why the distinction matters before you call support

DNS issues and hosting issues are fixed by different people, often at different companies. If your domain and hosting are with separate providers (very common), contacting the wrong one first means a round of "not our problem, talk to them" while your site stays down. Five minutes of diagnosis saves you that loop — and when you do contact support, you can say "DNS resolves correctly to 203.0.113.45, but the server times out on port 443," which gets you a much faster answer than "my site is down, please help."

Signs It's a DNS Problem

You don't always need the command line — the symptoms often give it away:

"Server IP address could not be found" / ERR_NAME_NOT_RESOLVED

This is the classic DNS-failure message. Your browser is telling you outright: I couldn't even find where this website lives. The lookup step failed, so hosting never entered the picture. This is DNS until proven otherwise.

Works on your phone data but not Wi-Fi (or vice versa)

Different networks often use different DNS servers. If your site loads over mobile data but not your home Wi-Fi, one network's DNS resolver has stale or broken data for your domain while the other is fine. That's a DNS problem — specifically, a resolver-side one — not a hosting outage. (Your hosting server can't be "down for Wi-Fi but up for mobile.")

You just changed nameservers or DNS records

If you recently pointed your domain to new nameservers, edited an A record, or moved hosts, and the site broke within the last 48 hours — suspect DNS first. Changes need time to propagate worldwide (see our section on propagation below), and a typo'd record will break resolution immediately. Always re-check what you just changed before assuming the server died.

Email works but the website doesn't (or the reverse)

DNS uses different record types for different services: A records point the website to a server, MX records route email. If your email flows fine but the site is down, the MX records are healthy while the A record (or the web server) has a problem — and the reverse tells you the opposite. This split is a strong hint about which record or service to investigate.

Signs It's a Hosting Problem

The domain resolves, but the page won't load

You ran a lookup (we'll show you how below) and got a valid IP address — DNS is doing its job. But the browser spins and eventually gives up. The phone book gave the right address; nobody's answering the door. That's hosting.

Error 500 / 502 / 503 / 504 pages

These HTTP status codes are generated by servers, which means your request reached a server — DNS worked. The server (or something between it and the application, like a proxy) is reporting its own failure. A 500 means the application crashed; a 502/504 means a gateway couldn't reach the backend; a 503 means the service is temporarily unavailable. All of these are hosting-side issues to take up with your host.

"Connection timed out" after resolving fine

If the domain resolves instantly but the connection itself times out, the server isn't accepting connections — it's down, firewalled, or so overloaded it can't respond. DNS handed off correctly; the server dropped the ball.

It broke right after a site update or traffic spike

Did you just update WordPress, install a plugin, or get featured somewhere with a flood of visitors? Application crashes and resource exhaustion are hosting problems. DNS doesn't care how many visitors you have or what plugins you installed.

Step-by-Step: Isolate the Cause in 5 Minutes

You need a terminal (Command Prompt on Windows, Terminal on Mac/Linux). Every command below is read-only — it changes nothing, so it's safe to run.

Step 1 — nslookup your domain

`` nslookup yourdomain.com ``

This asks your computer's DNS server: what's the IP for this domain?

• You get an IP address (e.g. Address: 203.0.113.45) → DNS resolution works. Move to Step 3.
• You get "can't find" / "Non-existent domain" / NXDOMAIN → DNS is failing. Move to Step 2 to confirm.

Note what the output says under "Server" too — that tells you which DNS resolver answered (often your router or ISP). That detail matters for Step 2.

Step 2 — Try a different DNS server

Still in nslookup, switch to a public resolver and ask again:

`` server 1.1.1.1 yourdomain.com ``

(1.1.1.1 is Cloudflare's public DNS; 8.8.8.8 is Google's — use whichever you weren't already on.)

• Fails on your default DNS but works on 1.1.1.1 → your ISP or router's DNS has stale/broken data. The domain's DNS itself is fine. Fix: wait for the cache to expire, restart your router, or just switch your device to the public DNS that works.
• Fails on both → the problem is with the domain's DNS configuration itself (wrong nameservers at the registrar, a deleted zone, a typo'd record). Check your DNS settings at whoever manages the domain's nameservers.

Step 3 — Load the site by its IP address

Take the IP address from Step 1 and paste it into your browser's address bar (as http://203.0.113.45 — use your actual IP).

• The site (or your server's default page) loads → the server is up and reachable; DNS was the problem all along.
• It still won't load → the server itself isn't responding. That's hosting — contact your host, and tell them the IP and what you tested.

One caveat: some shared-hosting servers need the domain name to know which site to show (they host many sites on one IP), so loading by raw IP may show a default page or an error even when the server is healthy. A default page still proves the server is alive — which is the question you're answering.

Step 4 — Check from another network or device

Load the site on your phone with Wi-Fi turned off (mobile data), or ask a friend in another city to try. If it works elsewhere but not for you, the problem is local to your network or device — your DNS cache, your router, or your ISP — not your hosting and not your domain's global DNS.

Step 5 — Check a global DNS propagation tool

If you recently changed DNS, use a propagation checker (search "DNS propagation checker" — several free ones exist) to see what your domain resolves to from dozens of locations worldwide.

• Most locations show the new/correct IP → DNS is fine globally; anyone still seeing the old one just has a stale cache.
• Locations disagree wildly, or many show nothing → propagation is still in progress or the change didn't take. Wait it out (up to 48 hours for full propagation, though most changes settle within a few hours) or double-check the record you edited.

What Each Test Result Means (Decision Table)

Common Traps That Mislead You

Browser cache showing you an old "down" page

Browsers aggressively cache error pages. You might be staring at a failure from an hour ago while the site is already back. Hard-refresh (Ctrl+Shift+R on Windows, Cmd+Shift+R on Mac) or test in a private/incognito window before concluding anything.

Your ISP's DNS cache lagging behind a fix

You fixed the DNS record, but your ISP's resolver cached the broken answer and keeps serving it for hours. Everything looks fine on 1.1.1.1 but broken on your home connection. This is the single most common reason people think "DNS is still broken" after they've already fixed it. Patience — or switching to public DNS — is the cure.

Ping failing doesn't always mean the server is down

Many hosts and firewalls block ICMP ping entirely as a security measure. A failed ping with a working website is completely normal. Ping is a weak test for web hosting — the IP-load test in Step 3 is far more meaningful because it tests the actual web ports.

Cloudflare (or a CDN) sitting in the middle

If your site uses Cloudflare or another CDN/proxy, what you see is the CDN's edge, not your origin server. A Cloudflare error page (like Error 521 or 522) means the CDN is up but can't reach your server — that's still a hosting-side problem, just one layer removed. And when testing by IP, make sure you're testing your real origin IP, not Cloudflare's edge IP. If you're unsure which is which, check your Cloudflare DNS dashboard for the origin address.

Frequently Asked Questions

My site was working yesterday and I changed nothing. DNS or hosting?

Most likely hosting — DNS doesn't usually break on its own overnight. Servers crash, run out of disk space, or get overwhelmed. Run the nslookup test: if the domain still resolves to the same IP as always, it's the server. Contact your host.

nslookup works but the site won't load. What now?

That's the textbook hosting-side signature. DNS did its job (gave you an IP), but the server isn't serving. Check whether it's a full outage (nothing loads) or an application error (you see a 500 page) — then contact your hosting provider and tell them exactly that: "DNS resolves to X, but connections time out / return 500."

The site loads with "www" but not without it (or vice versa). Which is it?

That's DNS — specifically a missing record. Your domain probably has an A record for one version but not the other. You need records for both the root domain (@) and www (either a second A record or a CNAME pointing www at the root). Add the missing record where your DNS is managed.

How long should I wait after fixing DNS before worrying?

Most DNS changes propagate within a few hours, and many within minutes. The industry-standard maximum is 48 hours because of long-lived caches at some ISPs. If a global propagation checker shows your new records nearly everywhere after a few hours, you're done — anyone still seeing the old site just has a stale local cache.

Can DNS and hosting both be broken at the same time?

Yes, especially during migrations — you might have pointed DNS at a new server that isn't configured yet. Diagnose in order: fix DNS resolution first (get the domain pointing at the right IP), then troubleshoot the server. Trying to fix both simultaneously is how you chase your tail.

Should I contact my domain registrar or my hosting company first?

Run the two tests first — then you'll know. Domain resolves but server is dead → hosting company. Domain doesn't resolve at all → whoever manages your nameservers (which might be your registrar, your host, or Cloudflare — check where your domain's nameservers point). Walking in with test results gets you past tier-one scripts and to a real fix much faster.

Still stuck after running the tests? Write down your results — the nslookup output, whether the IP loads, and what error you see — and share them with support. A ticket that says "nslookup returns 203.0.113.45 but the IP times out on port 443" gets fixed in minutes; a ticket that says "site down plz help" starts a long round of basic questions. And if you're rethinking your setup after an outage, our hosting plan guide can help you choose infrastructure that fits what your site actually needs.