You open your browser, type in your domain, and get a blank page, a timeout error, or a cryptic "This site can't be reached" message. Before you panic and fire off an angry ticket to your host, you need to answer one critical question: is your website actually down for everyone, or is it just broken on your machine? The answer changes everything about how you respond, and getting that answer takes about 60 seconds if you know where to look.
Step One: Confirm Whether It Is Down for Everyone or Just You
Your browser cache, a bad DNS entry on your local machine, or a regional network issue can all make a site look offline when it is perfectly healthy everywhere else. Do not skip this check.
The fastest method is to use a second device on a completely different network — your phone on mobile data, not on your home Wi-Fi. If the site loads fine on mobile data, the problem is local to your network or machine, not your server.
You can also run a quick check from multiple global locations using the DNS Lookup tool to see whether your domain resolves to a valid IP address from different vantage points. If DNS resolution fails globally, that is a different class of problem than a web server going down.
Third-party uptime checkers like isitdownrightnow.com or downforeveryoneorjustme.com provide a fast second opinion. They ping your URL from their own servers and report back whether they received a valid HTTP response.
What the Error Message Is Actually Telling You
Error messages are not just annoyances — they are diagnostic clues. Here is what the common ones mean:
- ERR_NAME_NOT_RESOLVED / DNS_PROBE_FINISHED_NXDOMAIN: Your browser cannot resolve the domain name to an IP. Either DNS is broken, the domain has expired, or nameservers are misconfigured.
- ERR_CONNECTION_TIMED_OUT: DNS resolved fine, but the server never responded. The web server process may be crashed, the server is overloaded, or a firewall is dropping packets.
- ERR_CONNECTION_REFUSED: The server is reachable but actively refusing connections on port 80 or 443. Apache or Nginx is likely stopped, or it is listening on the wrong port.
- 502 Bad Gateway / 503 Service Unavailable: Your web server is running but the application behind it (PHP-FPM, Node.js, a database) has crashed or is overloaded.
- 521 / 522 (Cloudflare): Cloudflare cannot reach your origin server. The problem is between Cloudflare and your host, not between your visitor and Cloudflare.
Check Your DNS First — It Is the Most Common Culprit
A huge proportion of "my site is down" reports are actually DNS failures. Your domain may have expired, your nameservers may have been changed accidentally, or a recent DNS edit propagated incorrectly.
Run this from your terminal or command prompt to check what IP your domain is resolving to:
The 8.8.8.8 forces the query through Google's public DNS, bypassing your local resolver. If you get "Non-existent domain" or no IP address, the DNS layer is broken. If you get an IP, compare it to your hosting control panel — they should match.
On macOS or Linux, you can use dig for more detail:
If the IP is wrong — for example, pointing to an old host you left six months ago — you need to update your A record at your DNS provider (usually your domain registrar or a service like Cloudflare).
Also check whether your domain registration is still active. Go to your registrar's control panel and look for expiry warnings. An expired domain stops resolving immediately once the grace period ends.
Ping and Traceroute to Isolate Network Problems
If DNS resolves correctly but the site is still unreachable, run a ping to check basic connectivity to the server IP:
If pings time out but DNS resolved an IP, the server may have ICMP blocked by a firewall (common), the server may be fully down, or there is a routing problem between you and the data center.
Run a traceroute to see exactly where packets are stopping:
On macOS or Linux:
Look for where the hops stop responding. If they stop several hops before your server's IP, the issue is likely with an upstream provider or the data center's network. If they reach your server's network but stop at the last hop, the server itself is the problem.
Check Whether Your Web Server Is Actually Running
If you have SSH access to your server, this is the most direct way to diagnose the issue. Log in and check the status of your web server process.
For Apache:
For Nginx:
If the service shows as "inactive" or "failed", restart it:
Then check the error log for what caused the crash:
Common causes visible in logs: out of memory, a syntax error in a config file after a recent edit, a PHP process crash, or disk space exhaustion.
Check Disk Space and Memory
A full disk will bring down a web server instantly and silently. This is embarrassingly common on VPS plans where logs grow unchecked.
If any partition shows 100% used, that is your problem. Clear old log files, rotate logs, or expand the volume:
Check available memory:
If you are completely out of swap and RAM, the kernel may have killed your web server process (OOM killer). Check the kernel log:
Check Your PHP or Application Layer
A 500 Internal Server Error or a blank white page usually means PHP has crashed or your application threw an unhandled exception. Enable error display temporarily in your PHP configuration or check the PHP-FPM logs:
For WordPress sites specifically, a common cause is a plugin or theme update that broke PHP compatibility. If you can access your server via SSH or FTP, rename the plugins directory to disable all plugins at once:
If the site comes back, re-enable plugins one at a time by renaming the folder back and then individually renaming each plugin subdirectory until you find the culprit.
Firewall and Security Software Blocking Traffic
If your server is running but web traffic is not getting through, a firewall rule may be the cause. Check whether ports 80 and 443 are open:
If UFW is active and ports 80 or 443 are not listed as allowed:
For servers using iptables directly:
Security tools like Fail2Ban can also inadvertently block legitimate traffic if your own IP triggered a rule. Check whether your IP is banned:
What to Do When the Problem Is on Your Local Machine
If third-party checkers confirm the site is up everywhere else, your machine has a stale DNS cache or a bad hosts file entry. Flush your DNS cache:
Windows:
macOS (Ventura / Sonoma):
Linux (systemd-resolved):
Also check your hosts file for any manual overrides that might be pointing your domain to a wrong IP:
Windows: C:\Windows\System32\drivers\etc\hosts
macOS / Linux: /etc/hosts
If your router's DNS cache is the problem — common after changing nameservers — simply reboot your router. Most consumer routers do not have a manual DNS flush option, though some Asus routers (accessible at asusrouter.com or 192.168.1.1) let you restart the WAN DNS from the admin panel under WAN settings. TP-Link routers (accessible at tplinkwifi.net or 192.168.0.1) require a full reboot to clear DNS state. Netgear routers (routerlogin.net or 192.168.1.1) are the same — a reboot from the admin panel clears any cached DNS entries.
Contacting Your Host When You Have Exhausted Local Fixes
If you have confirmed: DNS resolves correctly, the server IP is reachable, no firewall is blocking traffic, your web server process is running, disk and memory are healthy, and the site is still down — the problem is likely inside your hosting infrastructure and you need to escalate.
When you contact support, provide:
- Your domain name and the IP it resolves to
- The exact error message and HTTP status code you see
- Output of
curl -Iv https://yourdomain.com(this shows headers and SSL handshake details) - A traceroute to your server IP
- The time the outage started
This saves you from the generic "have you tried clearing your cache" first-response loop and gets you to a tier-2 engineer faster.
How to Prevent This From Happening Again
Reactive troubleshooting is painful. Put a few preventive measures in place now:
- Set up free uptime monitoring. Services like UptimeRobot check your site every 5 minutes and alert you by email or SMS the moment it goes down. You will know before your customers do.
- Enable auto-renew on your domain. Domain expiry causes more outages than server failures. Turn on auto-renew and keep your registrar payment method current.
- Set DNS TTLs low before any planned changes. Before you migrate hosts or change nameservers, reduce your A record TTL to 300 seconds (5 minutes) 24 hours in advance. This minimises propagation delays if something goes wrong.
- Monitor disk usage with alerts. Configure server monitoring (Netdata, Munin, or your host's built-in panel) to alert you when disk usage crosses 80%.
- Keep regular off-server backups. If your server goes up in flames, you need a backup that is not stored on the same machine.
Website outages are rarely mysterious once you work through the layers systematically: DNS, network, server process, application, local machine. Start at the DNS layer, rule it out, then work inward. In most cases you will find the problem within the first three checks.