This Site Can't Be Reached: What Each Error Means

The heading is the same for eight unrelated problems. The line underneath it in small capitals is the one that tells you which stage of the connection failed.

"This site can't be reached" is Chrome's heading for about eight unrelated failures. The useful part is the line underneath it in small capitals — ERR_CONNECTION_TIMED_OUT, DNS_PROBE_FINISHED_NXDOMAIN and the rest. That string names which stage of the connection failed, and each stage has a different cause and a different fix.

First, what this class of error is not

If you are seeing one of these, no server sent your browser a response. That is the single most useful thing to know, because it rules out a large category of problem immediately.

A 502, 503 or 504 is the opposite situation: a server was reachable, answered, and the answer was a complaint. Those point at the application behind the server. The errors on this page point at everything before that — the name lookup, the route, the port, the handshake.

Check which of the two you have with the Website Down Checker. It requests the site from our server rather than from your machine, so if it comes back with a status code, the site is serving and your problem is local. If it fails the same way, the problem is at the site's end.

The four stages, and which error belongs to each

A browser connection happens in order, and it can only fail at one stage at a time:

Resolve the name to an IP address → DNS_PROBE_FINISHED_NXDOMAIN
Open a connection to that address → ERR_CONNECTION_TIMED_OUT, ERR_CONNECTION_REFUSED
Negotiate TLS, on HTTPS → ERR_SSL_PROTOCOL_ERROR, ERR_CERT_*
Exchange the request and response → ERR_CONNECTION_RESET, ERR_EMPTY_RESPONSE

Reading the error tells you how far the connection got. Everything before the failing stage worked, which is as valuable as knowing what broke.

DNS_PROBE_FINISHED_NXDOMAIN

The name does not resolve. NXDOMAIN is the DNS response code for "no such domain" — a definite answer, not a timeout.

The connection never started, so nothing about the server, its certificate or its software is implicated. Only the name is.

On a site you do not control, the usual causes are a typo, a domain that has expired, or a subdomain that was never created.

On your own site, in order of likelihood:

The domain expired. Check it with the WHOIS Lookup — an expired record is unmistakable, and the expiry timeline tells you what recovery costs at each stage.
The nameservers are wrong or empty, usually after a change. See what to do when a site goes down after a DNS change.
The record was deleted at the DNS provider. Confirm with the DNS Checker: if several public resolvers all return nothing, the record is genuinely absent rather than slow to arrive.

One variant worth separating: if the bare domain fails but www works, or the reverse, only one of the two has a record. That is a five-minute fix at the DNS provider, not an outage.

ERR_CONNECTION_TIMED_OUT

The name resolved. Your browser opened a connection to that address and nothing came back at all — no acceptance, no refusal, just silence until the browser gave up.

Silence is the diagnostic detail. A machine that is running and not serving that port sends a refusal, which is a different error. Silence usually means something is dropping the packets without replying, and that is what a firewall does by design.

Common causes:

A firewall is dropping the traffic, at the server, at the host's edge, or at the network you are on.
Your IP has been blocked, frequently after repeated failed logins. This is the cause behind err_connection_timed_out for one website — everything else works, one site is silent. Test on mobile data with Wi-Fi off; if it loads there, your home IP is blocked and your host can lift it.
DNS points at an address with nothing on it. After a server move, an old A record sends you to an IP that no longer answers.
The server is overloaded enough that connections are not being accepted.

ERR_CONNECTION_REFUSED

The address answered, and the answer was no.

Something is running at that IP, but nothing is listening on the port you asked for. On a website that means the web server process — nginx, Apache, Caddy — is stopped or has crashed, or it is listening on a different port than you are requesting.

This is a more informative error than a timeout, because it proves the machine is up and reachable. The fix is almost always restarting the web server, and the thing worth checking first is why it stopped: a configuration test that failed on reload will stop a server and leave it stopped.

ERR_CONNECTION_RESET

The connection opened and was then cut mid-exchange.

Unlike a timeout, something deliberately terminated it. Usual suspects are a firewall or DDoS filter that inspected the request and decided against it, a protocol mismatch — an HTTPS request reaching a port serving plain HTTP is a classic — or genuine packet loss on the route.

If it resets consistently on one page and not others, look at what that page sends. Requests with large uploads or unusual headers trip security rules that ordinary requests never touch.

ERR_SSL_PROTOCOL_ERROR and the certificate errors

The connection opened but TLS negotiation failed, so the browser closed it before any HTTP request was sent.

The connection got further here than in any error above. The name resolved, the port answered — only the encrypted handshake failed. Causes include a certificate that has expired, a server offering only protocol versions the browser has dropped, and HTTPS being served on a port that is not configured for it.

Run the SSL Checker for the actual certificate state. And note the distinction from a padlock warning: a warning means the browser completed the handshake and does not trust the result, which you can click through. These errors mean the handshake did not complete, and there is nothing to click through.

Worth ruling out first: a device clock that is badly wrong makes every valid certificate look expired or not yet valid. It is a one-line check and it explains a surprising share of these.

ERR_NAME_NOT_RESOLVED and ERR_EMPTY_RESPONSE

Two that come up often enough to name.

ERR_NAME_NOT_RESOLVED is close to NXDOMAIN but means your resolver returned nothing usable rather than a definite "no such domain". Often your DNS server rather than the domain — test with the DNS Checker, which queries several public resolvers, and if they all answer fine, the problem is the resolver your machine is using.

ERR_EMPTY_RESPONSE means the server accepted the request, sent nothing, and closed. Usually the application crashed mid-request. Server error logs will have it; nothing external can see more than the silence.

Ruling out your own machine first

Every error above can be produced entirely locally. Two minutes of checks saves contacting a host about a working server.

Try mobile data with Wi-Fi off. This is the highest-value single test, because it changes your IP, your DNS resolver and your route at once. If the site loads, the site is fine.

Try a private window. Eliminates extensions and cached redirects.

Try a different browser. Different certificate store, different DNS cache.

Then, if those point at your network:

Flush the DNS cache — ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS.
Change your DNS server to 1.1.1.1 or 8.8.8.8. ISP resolvers do go stale, and this is the fix behind a lot of "works for everyone else" reports.
Turn off the VPN, and any proxy or filtering software. A VPN exit node can be blocked by a site that has no issue with you.
Check the clock, for the TLS errors specifically.

If the site loads from our server and not from yours, stop debugging the site. The answer is on your side, and it is nearly always DNS or an IP block.

When it is your own site and it is genuinely down

Work the full diagnostic checklist, which covers this in order. The short version, once you know which error you have:

NXDOMAIN is a domain or DNS problem — nothing on the server can cause or fix it. A timeout is a firewall or a wrong IP. A refusal is a stopped web server. A TLS error is the certificate or the protocol configuration. In every case the error names the layer, and fixing the wrong layer is the most common way an outage lasts longer than it needed to.

One thing these errors never mean: a site that loads but does not appear in Google. That is an indexing question, not a reachability one, and no error code here relates to it.

Start with the Website Down Checker to establish whether anyone else can reach the site at all.