This site can't be reached: what each Chrome error code means and how to fix it

Short answer: “This site can’t be reached” is the heading Chrome and Edge show when the page never loaded because the browser could not get a connection to the server at all. The line under the heading and the code at the bottom of the page, such as DNS_PROBE_FINISHED_NXDOMAIN or ERR_CONNECTION_REFUSED, name the step that failed: finding the address, reaching it, or getting an answer on the port. Open the same address on your phone over mobile data. If it loads there, the problem is on your computer or network; if it fails everywhere, the site or its server is down or misconfigured.

Firefox words the same failures differently: Hmm. We’re having trouble finding that site for a name that does not resolve, Unable to connect for a refusal, The connection has timed out for a timeout. The causes and fixes below apply to every browser.

Which code is under the message?

The heading is shared; the code is what tells the cases apart. These are the ones you will meet, with the line Chrome prints under the heading:

Four pages look similar but are different errors. No internet (ERR_INTERNET_DISCONNECTED) means your device has no network connection at all. This page isn’t working means the server did answer, but with a 5xx error or no data, which is a problem inside the site, such as an nginx 502 Bad Gateway. This site can’t provide a secure connection is a broken TLS handshake, covered in ERR_SSL_PROTOCOL_ERROR. And Your connection is not private is a certificate the browser does not accept, covered in its own guide.

Is it you, or the site?

Answer this before changing anything, because it halves the list. Try the address on a second device on a different network (a phone with Wi-Fi off is the easiest), and try a second well-known site on the computer that fails.

• Every site fails on your computer: your connection, DNS resolver, proxy or security software is the problem. Start with the visitor fixes.
• Only this site fails, and only on your network: a filter on your network, a stale DNS answer, a hosts file entry, or the site’s firewall has blocked your IP address.
• This site fails from everywhere: the site’s DNS or server is the problem. Nothing on your side will fix it; if it is your site, go to the site owner checks.

A terminal gives the same answer with less guessing. These are the messages curl prints for the two most common cases, from a Debian 12 machine with curl 7.88.1 (the address .invalid is reserved and never resolves, and nothing listens on port 9 there):

$ curl -sS -o /dev/null http://no-such-host.invalid/
curl: (6) Could not resolve host: no-such-host.invalid

$ curl -sS -o /dev/null http://127.0.0.1:9/
curl: (7) Failed to connect to 127.0.0.1 port 9 after 0 ms: Couldn't connect to server

$ curl -sv -o /dev/null http://127.0.0.1:9/ 2>&1 | grep refused
* connect to 127.0.0.1 port 9 failed: Connection refused

Exit code 6 is a DNS failure (Chrome’s NXDOMAIN or NAME_NOT_RESOLVED). Exit code 7 is a failed connection; the verbose line says whether it was Connection refused or No route to host. Exit code 28, which the curl man page calls Operation timeout, is a timeout (set a limit with --connect-timeout 10, otherwise a dropped connection can hang for minutes). On Windows, PowerShell’s Test-NetConnection example.com -Port 443 answers the same question with TcpTestSucceeded : True or False.

Visitor fixes, most likely first

1. 1Check the address itself

   A typo in the name, a port number left in from a bookmark (:8080), or http:// versus https:// on a site that only answers one of them. Type the bare domain again by hand instead of reusing an autocomplete entry.

2. 2Turn off the VPN, proxy and filtering software for one test

   A VPN that has lost its tunnel, a proxy set in the system settings (Chrome uses the system proxy), parental filters and antivirus web shields all produce this page. On Windows check Settings, Network & internet, Proxy; on macOS, System Settings, Network, Details, Proxies. The VPN and security software section of our DNS guide lists the usual suspects.

3. 3Clear Chrome's DNS cache and the system's

   Chrome keeps its own cache: open chrome://net-internals/#dns, click Clear host cache, then chrome://net-internals/#sockets and Flush socket pools. Then flush the operating system’s cache, which is ipconfig /flushdns on Windows; every system is in how to flush the DNS cache. This fixes the case where a site moved to a new server and your machine still holds the old address.

4. 4Look for a hosts file entry

   A line in C:\Windows\System32\drivers\etc\hosts (Windows) or /etc/hosts (macOS, Linux) pins a name to a fixed address and overrides DNS. Old development entries and some ad blockers leave lines there that send a domain to 127.0.0.1 or to a server that no longer exists. Remove the line for the site, save, and retry.

5. 5Try another DNS resolver

   If names fail on every site, or only through your provider’s resolver, set the network adapter to a public resolver, or turn on Use secure DNS in Chrome’s privacy and security settings. The steps for each system are in changing your DNS servers.

6. 6Restart the router, then reset the network stack

   Restart the router and the computer. On Windows, if that does not help, run netsh winsock reset and netsh int ip reset in an administrator terminal and restart. That clears a damaged Winsock catalog and settings left behind by uninstalled VPN clients and security software.

7. 7Still blocked on one network only?

   If the site loads on mobile data but never on your home or office connection, the block is on that path: a company or school filter, a router with parental controls, or the site’s own firewall, which may have banned your IP after failed logins. Only the site owner can lift that; send them your public IP address.

Site owner: walk the request layer by layer

If your own site shows this page to everyone, follow the request in the order a browser makes it. Stop at the first step that fails; that layer is your fix.

1. Does the name point at your server?

dig +short example.com A
dig +short example.com AAAA
dig +short www.example.com A

Compare each answer with the addresses of your server, which ip -br addr lists on the server itself. No answer at all means a missing record or a lapsed domain (the NXDOMAIN case). An address you do not recognise means an old record from a previous host. Check AAAA as carefully as A: browsers on IPv6 networks try that address first and fall back to IPv4 only after a delay, and some clients never do. Remember that example.com and www.example.com are separate names that each need a record.

Our DNS lookup shows the records as a resolver outside your network sees them, with their TTLs, so you know how long an old answer can linger in caches.

2. Is the server up and on the network?

Log in over SSH. If SSH times out as well, the whole machine is down or unreachable: use your provider’s console to look at it, check that it booted and that its network interface has its address and a default route (ip route show default). A firewall change that locked out everything, a full disk that stopped services, or an expired service at the provider all look the same from outside.

3. Is the web server listening on the public address?

sudo ss -tlnp '( sport = :80 or sport = :443 )'
sudo systemctl status nginx --no-pager
sudo nginx -t

You want LISTEN lines for 0.0.0.0:80, 0.0.0.0:443 and their [::] twins. Nothing on 443 means nginx is stopped or has no HTTPS server block, and 127.0.0.1:443 means it listens on the server only. nginx -t names the line that keeps a broken configuration from loading. The full walkthrough, including apps bound to localhost and Docker ports, is in ERR_CONNECTION_REFUSED.

4. Does the firewall let 80 and 443 in?

sudo ufw status verbose                 # ufw (Debian, Ubuntu)
sudo firewall-cmd --list-all            # firewalld (Rocky, AlmaLinux)
sudo nft list ruleset | grep -E 'dport' # plain nftables

sudo ufw allow 80,443/tcp               # open both with ufw

A firewall that drops the ports gives visitors a timeout, one that rejects them gives a refusal, and firewalld’s default reject can show up as ERR_ADDRESS_UNREACHABLE, as a section below explains. If the server’s own firewall is open and outside tests still fail, look for a firewall in front of it at your provider. Setting up ufw without locking yourself out is in our ufw guide.

5. Test from outside, not from the server

A request from the server to itself skips DNS, the firewall and the network, so it proves little. Test from another machine, and pin the name to the IP you expect so DNS is out of the picture (203.0.113.10 stands for your server):

curl -sv --connect-timeout 10 -o /dev/null https://example.com/
curl -sv --connect-timeout 10 -o /dev/null \
  --resolve example.com:443:203.0.113.10 https://example.com/

If the second command works and the first fails, DNS is wrong. If both fail, the problem is on the server or in front of it.

No second machine at hand? Our open port checker tries a TCP connection to any public IPv4 or IPv6 address and port from Amsterdam and tells you whether it was accepted.

ERR_ADDRESS_UNREACHABLE: no route to the address

This code has no separate guide, because it is rarer. Chromium maps the operating system errors EHOSTUNREACH, ENETUNREACH and EHOSTDOWN to it: the connection was not refused by the server, but a router, a firewall or your own system reported that there is no path to that address. curl shows the same event as No route to host or Network is unreachable. Four situations cause it:

• A device on your local network is off or on another subnet. Opening a router, printer or NAS page such as http://192.168.1.1 fails this way when the device is unplugged, when its address changed, or when you are on a different Wi-Fi (guest networks are usually separated from the main one).
• A VPN took the route. With a full-tunnel VPN, addresses on your home network can become unreachable. Disconnect the VPN, or enable its local network access option.
• An IPv6 address without IPv6 connectivity. A link to a literal IPv6 address, or a site that has only an AAAA record, cannot be reached from a network that has no IPv6. See IPv4 vs IPv6 for why that still happens.
• The server’s firewall rejects with an ICMP “prohibited” message. firewalld, the default on Rocky Linux and AlmaLinux, rejects blocked ports this way. A Linux client reports that as No route to host, which Chrome shows as unreachable even though the server is up; other systems may show a timeout instead. Open the port with sudo firewall-cmd --permanent --add-service=https and sudo firewall-cmd --reload. The same pattern behind Cloudflare is Cloudflare error 523.

ERR_CONNECTION_CLOSED: closed before any answer

Here the TCP connection did open, and then the other end closed it (a TCP FIN) before any page came back, most often in the middle of the TLS handshake. Typical causes are a server or load balancer on port 443 that has no certificate set up for the requested name and drops the handshake, a port forwarded to a service that does not speak TLS, a server that closes connections from IP addresses it has blocked, and a filter on the visitor’s network that ends the connection after reading the name in the TLS handshake (SNI). openssl s_client -connect example.com:443 -servername example.com shows how far the handshake gets before the connection closes. As a visitor, test on another network; as an owner, read the logs of whatever terminates the connection first (the proxy, not the app). The way to find which hop closes a connection is the same as for a reset, described in ERR_CONNECTION_RESET.

If the site is behind Cloudflare

A proxied site rarely shows Chrome’s page, because the browser connects to Cloudflare, which answers. When your origin is down, visitors get a Cloudflare error page instead: 521 when the origin refuses, 522 when it times out. So “This site can’t be reached” on a proxied site points at DNS (the zone or the record is missing, or the name servers at the registrar are wrong) or at the visitor’s own network, not at your server.

How do I keep it from happening again?

• Enable the web server at boot with sudo systemctl enable --now nginx, and run nginx -t before every reload, so a typo never takes the site down.
• Allow 80 and 443 before you enable a firewall, and keep SSH allowed in the same step.
• Lower the TTL before a move. A day before you change the server’s IP, drop the record’s TTL to five minutes, so old answers expire quickly. Moving a domain to a new server is shown step by step in pointing a domain to a VPS.
• Watch it from outside. A monitor on another machine that requests the page every minute finds an outage before your visitors do; our guide to Uptime Kuma on a VPS sets one up.

On a VMHeaven Linux VPS, the customer panel shows the server’s IPv4 address to compare with your DNS records, and its browser VNC console reaches the machine even when a firewall rule or a broken network config has cut off SSH.

Frequently asked