# "This site can't be reached": every variant of the Chrome error

> "This site can't be reached" is Chrome's cover page for several different failures, and the sub-code underneath decides the fix. Match your code in the table, jump to its fix, or run the checklist that clears most cases.

Updated 2026-10-15 · Best practices · HTML version: https://getreport.app/guides/this-site-cant-be-reached

"This site can't be reached" is not one error: it is Chrome's cover page for every failure that stops a connection before any page loads. The real diagnosis is the code in capitals underneath: DNS_PROBE_FINISHED_NXDOMAIN, ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUT and their siblings each point at a different layer, from the name lookup ([what DNS is and how a lookup travels](https://getreport.app/guides/what-is-dns) covers that layer in full) to a server that never answered. This guide is the router: find your sub-code in the table, read what it means, and jump to its fix, or run the checklist that clears most cases whatever the code says.

## Quick answer

- **Read the sub-code first.** The capitals under "This site can't be reached" are the real error; the headline is the same for all of them.
- A **name** code (DNS_PROBE_FINISHED_NXDOMAIN, ERR_NAME_NOT_RESOLVED) means the lookup failed: the browser never had an address to connect to. A **connection** code (ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUT, ERR_ADDRESS_UNREACHABLE) means the address was found and the server never answered. ERR_CONNECTION_RESET means the connection started and was cut.
- **Visitor**: load the site on a phone over mobile data. If it works there, the problem is on your side; restart the router, flush DNS, switch your DNS server, pause the VPN, check proxy settings.
- If it fails on every device and every network, the site is broken for everyone and only its owner can act.
- **Owner**: test from outside your own network first, then let the sub-code point you at DNS, a firewall, the server process or a broken IPv6 record.

## The sub-code decides the fix

Chrome shows "This site can't be reached" whenever the network layer fails: the browser could not turn the name into an address, or could not get a working connection to that address. Nothing from the website itself has loaded; the page you see is Chrome's own. The sub-code at the bottom says which step failed:

| Sub-code | What happened | Where the problem usually is |
| --- | --- | --- |
| DNS_PROBE_FINISHED_NXDOMAIN | A name server answered "this name does not exist" | A typo, an expired domain or a missing DNS record: [the NXDOMAIN guide](https://getreport.app/guides/dns-probe-finished-nxdomain) covers it in depth |
| ERR_NAME_NOT_RESOLVED | The lookup produced no address at all | Your resolver, network or VPN; sometimes the domain's DNS |
| ERR_CONNECTION_REFUSED | The server answered "no" to the connection | Nothing listening on the port, or a firewall rejecting it |
| ERR_CONNECTION_TIMED_OUT | No answer at all within the time limit | A firewall silently dropping packets, a down server, or DNS pointing at the wrong address |
| ERR_ADDRESS_UNREACHABLE | Your device found no route to the address | A local network or router problem, or a broken IPv6 record |
| ERR_CONNECTION_RESET | The connection was cut mid-conversation | Something in the middle: proxy, filter, antivirus, CDN |

One close relative shows a different page: when the connection works but the secure handshake fails, Chrome says "This site can't provide a secure connection" with ERR_SSL_PROTOCOL_ERROR. That is a different problem with its own causes, covered in [fixing ERR_SSL_PROTOCOL_ERROR](https://getreport.app/guides/err-ssl-protocol-error).

![Diagram: the "This site can't be reached" page at the top branching into its sub-codes, grouped by layer; name errors (NXDOMAIN, ERR_NAME_NOT_RESOLVED) branch to DNS, connection errors (REFUSED, TIMED_OUT, ADDRESS_UNREACHABLE) branch to the server and firewall, and ERR_CONNECTION_RESET branches to middleboxes between the two](https://getreport.app/guides/img/this-site-cant-be-reached/diagram.svg "One umbrella page, three layers of failure: the sub-code tells you which branch you are on.")

### ERR_CONNECTION_REFUSED

DNS worked: the browser got an address, reached the machine, and the machine actively said no; there is nothing accepting connections on that port. For a visitor this is rarely fixable locally; occasionally a proxy or security tool on your side answers the refusal, so the checklist below is still worth a pass. For an owner it usually means the web server process has stopped, is listening on the wrong port, or a firewall is set to reject rather than allow.

### ERR_CONNECTION_TIMED_OUT

The browser sent its request into silence: no refusal, no answer, nothing, until it gave up. Timeouts are the most ambiguous code, because silence has many causes; a firewall dropping packets without replying, a server that is down or overloaded, a DNS record pointing at an address where nothing lives any more, or simply a bad network between you and the site. The visitor checklist clears the local causes; an outside test separates the rest.

### ERR_ADDRESS_UNREACHABLE

The browser has an address but your device cannot find any route to it. This one usually sits close to you: a router with a broken route, a VPN that swallowed part of the network, or an IPv6 address your network advertises but cannot actually deliver. Restarting the router and disconnecting the VPN fix most cases; if the error follows one site only, that site may be publishing an IPv6 record it does not serve.

### ERR_NAME_NOT_RESOLVED

The name lookup produced no address: the broader cousin of NXDOMAIN. Where NXDOMAIN is a definite "that name does not exist" from a name server, ERR_NAME_NOT_RESOLVED often means no usable answer arrived at all: the resolver is unreachable, timing out, or blocked. That makes your own DNS setup the first suspect: flushing the cache and switching to a public resolver, both in the checklist below, fix the majority of cases.

### ERR_CONNECTION_RESET

The connection was established and then cut: one side sent a reset mid-conversation. DNS and routing are fine, which rules the name layer out. Resets usually come from something between you and the server (a proxy, antivirus software inspecting traffic, a corporate or national firewall, an MTU mismatch) or from a server or CDN that drops certain requests. Trying another network tells you quickly whether the middle of your path is the problem.

## The checklist that fixes most cases

Whatever the sub-code, these six steps clear the great majority of visitor-side causes. Work down the list and stop when the page loads.

1. **Try another device and another network.** Load the site on your phone with Wi-Fi off, over mobile data. If it works there, everything below is worth doing; if it fails there too, skip to the owner section: the site is likely down for everyone.

2. **Restart the router.** The router hands itself out as the DNS server for every device on the network and keeps its own cache and routing table. Power it off for 30 seconds and back on. If every device in the house shows the error, start here.

3. **Flush your DNS cache.** On Windows, open Command Prompt and run:

   ```
   ipconfig /flushdns
   ```

   On macOS, open Terminal and run:

   ```
   sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   ```

   Then clear Chrome's own host cache: paste `chrome://net-internals/#dns` into the address bar and click **Clear host cache**.

4. **Switch your DNS server to a public resolver.** If your provider's resolver is slow, stale or filtered, Cloudflare's `1.1.1.1` or Google's `8.8.8.8` usually is not.

   - **Windows 11**: Settings → Network & internet → Wi-Fi (or Ethernet) → your connection's properties → **DNS server assignment** → Edit → Manual → turn on IPv4 → Preferred DNS `1.1.1.1`, Alternate `8.8.8.8` → Save.
   - **macOS**: System Settings → Network → select your connection → Details… → DNS → click **+** and add `1.1.1.1` and `8.8.8.8` → OK.

5. **Pause the VPN, and the firewall or antivirus web protection.** A VPN reroutes both DNS and traffic; security suites sit in the middle of connections and can refuse or reset them. Disconnect the VPN and temporarily pause the third-party firewall or the antivirus module named "web protection" or "HTTPS scanning". If the site then loads, add an exception rather than leaving the protection off.

6. **Check the proxy settings.** A leftover proxy (from old software, a removed VPN or malware) sends every request to a server that no longer answers.

   - **Windows 11**: Settings → Network & internet → **Proxy** → under Manual proxy setup, "Use a proxy server" should be **Off** unless your workplace requires one; leave "Automatically detect settings" on.
   - **macOS**: System Settings → Network → your connection → Details… → **Proxies** → every toggle off unless your network requires one.

If all six fail on your network but the site loads on mobile data, the remaining suspect is the network itself: a company, school or hotel network that blocks the site, or your provider. There is nothing more to fix on the device.

## If you own the site: down for everyone, or just for them?

One visitor reporting "this site can't be reached" proves little: their cache, VPN or network may be the cause. The first question is whether the site fails from outside your own machine and network, where your logged-in sessions, hosts file and local cache cannot flatter the result.

> **Free tool:** [Bulk redirect checker: status of 1,000 URLs](https://getreport.app/tools/bulk-url-checker): Free bulk redirect checker. Paste up to 1,000 URLs and get each status code, final URL, redirect hops, noindex and canonical in one table, with CSV export.

Paste your home page and a few key URLs. Each one is requested from getReport's servers (an outside view of your site, the way a stranger's browser reaches it) and comes back with its status code, final URL and response time, or an **unreachable** label when no connection could be made. All your URLs unreachable from outside while the site works at your desk means the problem is real and server-side; all of them answering 200 means the complaining visitor's device or network is the cause, and the checklist above is what to send them.

When the outside test fails too, the sub-code your visitors report points at the layer:

- **DNS_PROBE_FINISHED_NXDOMAIN or ERR_NAME_NOT_RESOLVED**: the domain's DNS: an expired domain, changed name servers or a missing record. Work through [the NXDOMAIN owner's checklist](https://getreport.app/guides/dns-probe-finished-nxdomain), starting with `whois` and `dig`.
- **ERR_CONNECTION_REFUSED**: the machine is up but nothing accepts the connection. Check the web server process (`systemctl status nginx` or the equivalent) and that something listens on the right ports: `ss -tlnp | grep -E ':80|:443'`. A firewall rule set to *reject* also produces this.
- **ERR_CONNECTION_TIMED_OUT**: packets are being dropped. The usual suspects are a cloud firewall or security group missing an allow rule for ports 80 and 443, a server that is down, or DNS still pointing at an old IP address after a migration.
- **ERR_CONNECTION_RESET**: something between the visitor and your origin is cutting connections: a misconfigured CDN or proxy layer, or a server that drops certain requests. Test with the CDN bypassed to see which side resets.
- **ERR_ADDRESS_UNREACHABLE, or "it fails only on phones"**: often IPv6. If your DNS publishes an AAAA record but the server does not actually answer on IPv6, visitors on IPv6 networks (many mobile carriers) fail while IPv4 users are fine. Compare `curl -6 https://example.com` with `curl -4 https://example.com`; if only the first fails, fix the IPv6 setup or remove the AAAA record until it works.

Verify the way a stranger would: the outside check green on every URL, plus the page loading on a phone over mobile data.

## Questions people ask

### What does "This site can't be reached" mean?

It means Chrome could not open a connection to the site at all: nothing from the website itself has loaded, and the page you see is Chrome's own. It is an umbrella message covering several failures; the real diagnosis is the code in capitals underneath, such as DNS_PROBE_FINISHED_NXDOMAIN (the name lookup failed) or ERR_CONNECTION_TIMED_OUT (the server never answered). That code decides whether the fix is on your device, your network, or the site's server.

### How do I fix "This site can't be reached" on Chrome?

Start with another device on another network: if the site loads on your phone over mobile data, the cause is on your side. Then restart your router, flush DNS (`ipconfig /flushdns` on Windows), clear Chrome's host cache at `chrome://net-internals/#dns`, switch your DNS server to `1.1.1.1` or `8.8.8.8`, pause your VPN and antivirus web protection, and check that no proxy is configured. If the site fails everywhere, only its owner can fix it.

### Why can't my phone reach a site my laptop can?

Because they rarely take the same path. On Wi-Fi they share a network, but the phone keeps its own DNS cache and its own Private DNS setting; on mobile data it uses the carrier's network, and many carriers run IPv6-only networks. A site that publishes an IPv6 (AAAA) record without actually answering on IPv6 fails on those phones while every IPv4 laptop loads it fine. Toggle Wi-Fi on the phone to see which network is the odd one out.

### Is "This site can't be reached" my internet or the website?

A two-minute test answers it: load the site on a phone over mobile data with Wi-Fi off. If it works there, the problem is your computer, router or DNS, and the visitor checklist in this guide will clear it. If it fails there too, confirm from a second outside vantage point; a URL checker that requests the page from another network. When an outside check cannot reach it either, the website is down for everyone and only its owner can act.

### What does ERR_CONNECTION_RESET mean?

The connection was established and then cut mid-conversation: one side sent a TCP reset. DNS and routing worked, which rules the name lookup out. Typical causes are a proxy, VPN, antivirus or restrictive firewall interfering with the traffic, an MTU mismatch on the connection, or a server or CDN that drops certain requests. As a visitor, try another network and pause anything that inspects your traffic; as an owner, test from outside and check the proxy or CDN layer.

### What is the difference between ERR_NAME_NOT_RESOLVED and DNS_PROBE_FINISHED_NXDOMAIN?

Both mean the browser never got an IP address, but NXDOMAIN is a definite answer (a name server replied that the name does not exist) while ERR_NAME_NOT_RESOLVED is the broader "the lookup produced no address": the resolver may be unreachable, timing out or blocked. NXDOMAIN points first at the domain itself (a typo, an expired domain, a missing record); ERR_NAME_NOT_RESOLVED points first at your own DNS setup, network or VPN.