Where exactly is the error code on the page?

Underneath the grey explanation line, in capitals, usually the last thing on the page. If you only see the friendly sentence, click Details or reload once - Chrome sometimes fills the code in on the second attempt. Other browsers show the same underlying failure with different wording: Firefox says \u201cWe\u2019re having trouble finding that site\u201d, Safari says \u201cSafari can\u2019t find the server\u201d.

Does 'This site can't be reached' mean the website is down?

Not on its own. The same headline appears when your own Wi-Fi is off, when a VPN is misrouting, when your ISP's resolver is failing, and when a certificate expired on an otherwise perfectly healthy server. Load the site on a phone using mobile data - if it works there, the site is up and the problem is on your side.

Why does the site load on my phone but not on my laptop?

Your laptop is using a different DNS resolver, a different cache, and possibly a VPN or extension your phone is not. Flush Chrome's host cache at chrome://net-internals/#dns, flush the OS resolver, then retest. If it still fails, switch the adapter to 1.1.1.1 to rule out your ISP's resolver.

Is ERR_CONNECTION_REFUSED different from ERR_CONNECTION_TIMED_OUT?

Yes, and the difference is the most useful clue you get. Refused means the server actively said no - the packet arrived and nothing was listening on that port. Timed out means nothing answered at all, which normally points at a firewall dropping packets silently rather than a stopped service.

Chrome shows the error but the site works in Firefox. What now?

That almost always narrows it to Chrome's own state: its separate DNS cache, its socket pool, an extension, or a QUIC/HTTP-3 issue Firefox is not hitting. Clear the host cache and socket pools at chrome://net-internals, then retest in an incognito window with extensions disabled. If that fixes it, re-enable extensions one at a time to find the culprit.

Should I turn off my antivirus or firewall to test this?

Temporarily, and only as a diagnostic. Security software that inspects HTTPS traffic injects its own certificate into the chain and is a common source of ERR_CERT_AUTHORITY_INVALID and ERR_CONNECTION_RESET. Turn it off, load the page once, and turn it straight back on - if the error disappeared, the fix is an exception in that software, not leaving it off.

This Site Can't Be Reached: Every Chrome Code

"This site can't be reached" is not an error. It is a headline Chrome prints above about fifteen different errors, and the small grey line underneath it is the part that tells you what actually went wrong. This page decodes that line, so you can stop guessing and go straight to the fix.

Read the code, not the headline

Chrome shows the same big message whether your Wi-Fi is off, a domain does not exist, a server refused the connection, or a certificate expired. Those are four completely different problems with four completely different fixes, and the only thing separating them on screen is a short capitalised string near the bottom of the page:

This site can't be reached

www.example.com's server IP address could not be found.

ERR_NAME_NOT_RESOLVED

That last line is the error. Everything above it is decoration. If you scroll and cannot see a code at all, click Details or reload once - Chrome sometimes shows the friendly text first and fills in the code on the retry.

The first question: is it you, or is it the site?

Before you look up your code, spend ten seconds ruling out your own machine. Open the same URL on a phone with Wi-Fi turned off, on mobile data. Different device, different network, different DNS resolver.

Works on mobile data, fails on your computer - the problem is local: your browser cache, your OS resolver, your router, or your ISP. Nothing on the server side needs touching.
Fails on both - the problem is the domain, the DNS records, or the server. That is the half worth spending real time on.

Skipping this step is how people spend an afternoon editing DNS records to fix a stale cache on one laptop.

The codes, grouped by what is actually broken

DNS: the name could not be turned into an address

Nothing has been dialled yet. The browser asked "what is the IP for this hostname?" and did not get a usable answer.

ERR_NAME_NOT_RESOLVED - the lookup failed or returned nothing. Usually missing records, wrong nameservers, or a resolver that cannot reach them.
DNS_PROBE_FINISHED_NXDOMAIN - the lookup got an explicit "this name does not exist". Chrome retried and got the same answer.
DNS_PROBE_FINISHED_BAD_CONFIG - the resolver itself is misconfigured or unreachable, so no lookup completed at all.
DNS_PROBE_FINISHED_NO_INTERNET - Chrome could not reach any resolver, which normally means the connection is down rather than the domain being wrong.

Connection: the address was found, the conversation failed

DNS worked. Something went wrong between the packet leaving and a reply coming back.

ERR_CONNECTION_REFUSED - the server answered, and the answer was "no". Nothing is listening on that port, or a firewall sent an active rejection.
ERR_CONNECTION_TIMED_OUT - no answer at all. Packets went out and nothing came back before the clock ran out.
ERR_ADDRESS_UNREACHABLE - the network said it has no route to that address. Common on mobile data, on VPNs, and when a DNS record points at an IP that no longer exists.
ERR_CONNECTION_RESET - the connection was established and then killed mid-sentence.
ERR_CONNECTION_CLOSED - the server hung up cleanly without sending a response.
ERR_EMPTY_RESPONSE - the server accepted the request and then sent zero bytes back.
ERR_NETWORK_CHANGED - your network changed underneath the request, usually Wi-Fi handing over to mobile data or a VPN connecting.
ERR_SOCKET_NOT_CONNECTED - Chrome's own socket died before the request was sent, very often a proxy or extension.

TLS: the connection worked, the certificate did not

You got all the way to the server and the encrypted handshake failed. These are the ones that show a red padlock rather than a blank page.

ERR_CERT_DATE_INVALID - the certificate has expired, has not started yet, or your device's clock is wrong.
ERR_CERT_AUTHORITY_INVALID - the certificate is not signed by an authority the browser trusts. Self-signed certificates and missing intermediate certificates both land here.
ERR_CERT_COMMON_NAME_INVALID - the certificate is valid but issued for a different hostname.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH - client and server share no TLS version or cipher they both accept.
ERR_SSL_PROTOCOL_ERROR - the handshake broke in a way that does not fit the categories above.

Protocol: the transport itself went wrong

ERR_QUIC_PROTOCOL_ERROR - the HTTP/3 (QUIC) connection failed. Frequently a middlebox or firewall interfering with UDP.
ERR_HTTP2_PROTOCOL_ERROR - the HTTP/2 stream was rejected, usually by a proxy or an origin sending malformed frames.
ERR_TOO_MANY_REDIRECTS - the server sent the browser in a loop.

The four fixes that clear most local cases

If your phone on mobile data loads the site fine, work through these in order before anything else. They cost nothing and they resolve the majority of single-device cases.

Flush Chrome's own DNS cache. Visit chrome://net-internals/#dns and click "Clear host cache", then chrome://net-internals/#sockets and "Flush socket pools". Chrome caches separately from your operating system, which is why an OS-level flush alone often changes nothing.
Flush the OS resolver. On Windows, ipconfig /flushdns in an elevated Command Prompt. On macOS, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. On most Linux desktops, resolvectl flush-caches.
Try a different resolver. Set your adapter to 1.1.1.1 or 8.8.8.8 and retest. If that fixes it, your ISP's resolver was the problem and nothing about the site was ever broken.
Test in an incognito window with extensions off. Ad blockers, VPN extensions and corporate security extensions cause a surprising share of ERR_SOCKET_NOT_CONNECTED and ERR_CONNECTION_RESET reports.

If it fails everywhere, check these three in order

When the site is down for everyone, the diagnosis order that wastes the least time is DNS, then reachability, then the application.

# 1. Does the name resolve, and to what?
dig +short yourdomain.com

# 2. Is anything listening on that address?
curl -sS -o /dev/null -w '%{http_code}\n' https://yourdomain.com

# 3. What is the TLS layer saying?
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>&1 | head -20

An empty answer to the first command is a DNS problem and no amount of restarting the web server will help. A resolved IP with a refused or timed-out connection is a firewall or a stopped service. A completed connection with a TLS complaint is a certificate problem, and the site is otherwise healthy.

What this looks like on a server you control

On a VPS, the difference between "refused" and "timed out" is the single most useful signal you get. Refused means the packet reached the machine and nothing was listening - your web server is stopped, or bound to 127.0.0.1 instead of the public interface. Timed out usually means the packet never arrived at all, which points at a firewall rule or a security group rather than the application.

Check what is actually bound before restarting anything:

ss -tlnp | grep -E ':(80|443)\s'

If that prints 127.0.0.1:80 rather than 0.0.0.0:80, the service is running perfectly and simply is not reachable from outside the box. That is a configuration change, not a restart.

"This Site Can't Be Reached" in Chrome: Every Code Decoded