This site can't be reached: what Chrome is actually telling you

Chrome shows "This site can't be reached" for at least half a dozen unrelated problems. A dead server, a typo in the address, an expired domain, a firewall, a DNS resolver having a bad day, a site that simply is not configured for the name you typed. Same heading every time.

Which is why most advice about it is useless. Lists that tell you to flush DNS, clear your cache, disable your firewall and restart your router are covering every possible cause at once, so at best one step applies and the rest is noise.

The useful information is already on your screen. It is the line underneath the heading, and the code in small capitals at the bottom.

Read the second line, not the heading

Chrome builds the error page from two separate strings. The heading is generic. The summary beneath it is chosen by what actually failed, and it is the one that tells you where to look.

The code at the bottom of the page is the same information in a more precise form, and it comes straight from Chrome's internal network error list:

• ERR_CONNECTION_REFUSED, numbered -102, "A connection attempt was refused"
• ERR_NAME_NOT_RESOLVED, -105, "The host name could not be resolved"
• ERR_CONNECTION_TIMED_OUT, -118, "A connection attempt timed out"
• ERR_CONNECTION_RESET, -101, "A connection was reset (corresponding to a TCP RST)"
• ERR_ADDRESS_UNREACHABLE, -109, "The IP address is unreachable"
• DNS_PROBE_FINISHED_NXDOMAIN, which is the DNS lookup completing and reporting that the name does not exist

Note what is not on that list. "No internet" is a different Chrome error page entirely, with its own heading and the offline dinosaur. If you are seeing "This site can't be reached" then your connection is working, and the failure is more specific than being offline.

Thirty seconds that tell you whose problem it is

Before changing anything, answer one question: is it this site, or every site?

Open two or three other sites. If they load, stop troubleshooting your computer. Nothing you clear, flush or reset will fix a machine you do not control.

Then load the failing page on your phone over mobile data, with wifi off. That takes it off your network, off your router and off your DNS resolver in one move. If it works there and not at home, the problem is in your own setup. If it fails on both, it is the site.

Those two checks take under a minute and they decide which half of this article applies to you.

If it is every site

Now the usual advice is worth something, because your machine really is involved.

A proxy or VPN that is set but not running. This is the most common genuine client-side cause and it produces a flat refusal instantly. If your system is pointed at a local proxy that has stopped, every connection fails. On Windows the setting is under Settings, then Network and internet, then Proxy.

Your DNS resolver. If ERR_NAME_NOT_RESOLVED or DNS_PROBE_FINISHED_NXDOMAIN is on screen for everything, names are not resolving. Flushing the DNS cache clears stale answers, and switching to a public resolver tests whether your ISP's is the problem.

Security software inspecting HTTPS. Suites that sit in the middle of encrypted traffic can break connections in ways that look exactly like this. Turning that feature off for a minute is a clean test.

Here is one check worth knowing, because it splits the problem neatly. If you can ping 8.8.8.8 but no website loads by name, your connection is fine and DNS is the broken part. Pinging an address skips DNS entirely; loading a site does not. When the numeric address answers and names do not, you have found your layer.

If it is one site, and that site is yours

This is where the second line earns its keep, because each one sends you somewhere different.

Refused to connect

The machine is up and nothing is listening on the port your browser asked for. A web server that crashed or never started, a service bound to 127.0.0.1 instead of every interface, the wrong port, or no HTTPS configured so port 443 refuses while port 80 answers. ERR_CONNECTION_REFUSED covers the five causes and the order to check them.

Server IP address could not be found

DNS never produced an address, so nothing was ever attempted. Check that the domain has not expired, that an A or AAAA record exists for the exact hostname being requested, and that the nameservers are the ones you think they are. On a recent change, the records may exist and simply not have reached you yet, which is what DNS propagation actually describes. It is also worth checking your own hosts file, because a line left there from an old test overrides DNS completely and silently.

Took too long to respond

Something is swallowing the traffic rather than answering it. A firewall rule set to drop packets produces exactly this, as does a cloud security group that never opened the port, or a server that is overloaded. The distinction from a refusal matters: a refusal is an answer and arrives instantly, a timeout is silence. If the page hangs before failing, stop looking at the web server and look at what sits in front of it.

The connection was reset

The connection opened and was then cut part way through. That points at something interfering mid-stream rather than a configuration problem at either end, often a middlebox, a filtering appliance, or an unstable link.

It loads over HTTP but not HTTPS

Different problem, and one of the most common on a new server. If the handshake itself breaks you get ERR_SSL_PROTOCOL_ERROR, and if the two sides have no TLS version or cipher in common you get ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Both mean something is listening on 443 and the encrypted conversation failed, which is a long way from nothing listening at all.

On a phone, and on Android in particular

The error page is the same on mobile, with the same second line and the same codes, so everything above still applies. But phones add three causes that desktops mostly do not have, and they are worth knowing before you start reinstalling Chrome.

Private DNS. Android lets you set an encrypted DNS provider system-wide, usually under the network settings, and it is easy to set and then forget. If that provider is unreachable, blocks the domain, or was typed with a typo, every name lookup fails and you get the DNS flavour of this error on every app that uses the browser engine. Setting it back to automatic is a clean test, and if the site loads immediately afterwards you have your answer.

Captive portals. On public wifi in a cafe, hotel or airport, you are connected to the network but not yet past its sign-in page. Some portals handle this gracefully and some simply break every request until you authenticate. If the error appeared the moment you joined someone else's wifi, open any plain HTTP address and see whether the sign-in page appears.

Mobile data versus wifi. This is the same test as before but it is far easier on a phone, and it is still the fastest way to split the problem. Turn wifi off, load the page on mobile data, and you have moved off your router, your network and your DNS resolver in a single flick. Works on the failing site, and the fault is your network rather than the site.

One thing that is usually a waste of time on mobile: clearing Chrome's cache and app data. The error happens before any page is fetched, so there is nothing cached to be at fault. The exception is if you are being sent somewhere stale by a saved redirect, which is rare and will not survive the mobile data test above anyway.

The version that shows up the day you change hosting

There is one scenario that produces this heading more reliably than any other, and it is worth naming because it is entirely avoidable.

You set up a new server. You change the DNS record. Your domain now resolves to a machine that is running and has no idea it is supposed to serve your site. There is no virtual host for your domain, so depending on how it is configured you get a refusal, a default page, or someone else's site. Usually there is no certificate either, so HTTPS fails on top.

Two things make it harder to diagnose than it should be. DNS does not switch for everyone at once, so the site is broken for part of your audience and fine for the rest, which makes it look intermittent and random rather than like a configuration problem. And most certificate authorities want the hostname pointing at the machine before they will issue a certificate, so you cannot finish HTTPS until DNS moves, and you should not move DNS until HTTPS works.

The way out is to load the new server under its real domain before you change any records. DNS Previewer does that free, and it will reach your server over plain HTTP while the certificate question is still open, so you can confirm the site is being served correctly and deal with TLS separately. The WordPress migration checklist covers the rest of the pre-flight list, and if the server answers but the application behind it does not, you get a 502 Bad Gateway instead of this page.

The order I'd work through it

1. Read the line under the heading and note the code at the bottom. Everything depends on which one it is.
2. Open two other sites. If they load, stop troubleshooting your computer.
3. Load the failing page on mobile data with wifi off. That rules your network in or out in one move.
4. Every site failing, names not resolving: flush DNS and try a public resolver.
5. Every site failing, instant refusals: check for a proxy or VPN that is configured but not running.
6. One site, refused: nothing is listening. Check the service, the bind address and the port.
7. One site, IP address not found: check the domain, the DNS records and your own hosts file.
8. One site, timing out: look at firewalls and security groups, not the web server.
9. It started the day DNS moved: the new server almost certainly is not configured for your domain yet.

The heading is vague on purpose, because Chrome genuinely does not know which of these it is. The line underneath does. Read that one first and most of the usual advice becomes unnecessary.