Short answer. "This site can't be reached" is a catch-all Chrome error hiding a specific code: ERR_NAME_NOT_RESOLVED (DNS), ERR_CONNECTION_REFUSED (closed port), ERR_CONNECTION_TIMED_OUT (no reply), or ERR_CONNECTION_RESET (dropped connection). Read the code under the heading, flush your DNS cache, test the site from another network — then work through the checklist below, which covers both visitors and site owners.
What "This site can't be reached" actually means
Chrome shows this page when the connection failed at the network level — before a single HTTP request was exchanged. That is why the same heading covers a dozen unrelated problems, from a typo in the address to a burning data center. Real diagnosis starts with the error subcode: the gray ERR_* text under the heading.
Every cause falls into one of three buckets: your device (stale DNS cache, VPN, antivirus, extensions), your network (router, ISP, the ISP's DNS resolver), or the site itself (server down, expired domain, broken DNS records). The goal of the first few minutes is to figure out which bucket you are in — so you don't spend an hour fixing something that was never broken.
Don't treat the symptom — read the error code under the heading first. ERR_NAME_NOT_RESOLVED and ERR_CONNECTION_REFUSED demand completely different actions: the first is often fixed by switching the DNS resolver on your machine, the second can only be fixed on the server.
Chrome error codes: the full table
The six most common subcodes hiding behind "This site can't be reached":
| Error | What it means | Likely cause | First action |
|---|---|---|---|
| ERR_CONNECTION_TIMED_OUT | The server never replied in time | Server overload, a firewall silently dropping packets, slow network | Try another network; ping the domain |
| ERR_CONNECTION_REFUSED | Host is up, but the port rejected the connection | Web server not running or not listening on 80/443 | curl -I https://example.com; owner: check the service |
| ERR_NAME_NOT_RESOLVED | The domain never resolved to an IP | Stale DNS cache, unreachable DNS server, broken domain records | Flush DNS cache, switch resolver to 1.1.1.1 |
| DNS_PROBE_FINISHED_NXDOMAIN | DNS replied: "no such domain" | Typo in the address, expired or deleted domain | Check the spelling; nslookup example.com 8.8.8.8 |
| ERR_ADDRESS_UNREACHABLE | No route to the IP address | Broken routing, VPN conflict, private IP in a DNS record | Disable VPN; traceroute to the host |
| ERR_CONNECTION_RESET | Connection established, then dropped | TLS failure, MTU issues, antivirus intercepting HTTPS | Turn off HTTPS scanning in the antivirus |
We have dedicated deep dives for the DNS-related codes: DNS_PROBE_FINISHED_NO_INTERNET and ERR_ADDRESS_UNREACHABLE.
Is the site down for everyone or just me?
Before fixing anything, answer the single most important question. Turn off Wi-Fi on your phone and open the site over mobile data (LTE/5G). If it loads, the problem is local — your computer, your router, or your ISP — so continue with the DNS-cache and router sections below. If it fails there too, the site itself is most likely down, and nothing on your side will help: wait, or notify the owner.
The second method is an external check from an independent location — we covered it in "How to check if a website is down for everyone". And if a major service is failing, look at the outage tracker: mass incidents show up there before the news catches on.
Baseline diagnostics: nslookup, ping, and curl
Three terminal commands tell you in about a minute which layer breaks — DNS, network, or the web server itself:
# 1. Does the domain resolve to an IP?
nslookup example.com
dig +short example.com
# 2. Do packets reach the host?
ping -c 4 example.com
# 3. Is the port open and does the server answer?
curl -I -v https://example.comHow to read the results: nslookup errors out — it's DNS, jump to the cache-flush section. The domain resolves but ping and curl stay silent — packets don't arrive: firewall, routing, or a powered-off server. ping works but curl hangs or is refused — the host is alive, but the web service on port 443 isn't answering: that one belongs to the site owner.
How to flush the DNS cache on Windows, macOS, and Linux
A stale record in the local DNS cache is the most common reason a site is "down" only for you: the domain moved to a new IP while your system keeps knocking on the old one. Flushing is safe and takes seconds.
Windows
ipconfig /flushdns
:: if that didn't help — reset the network stack and reboot
netsh winsock resetmacOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponderLinux (systemd-resolved)
sudo resolvectl flush-caches
# on older distributions:
sudo systemd-resolve --flush-cachesChrome also keeps its own internal DNS cache. Open chrome://net-internals/#dns and click "Clear host cache", then on chrome://net-internals/#sockets click "Flush socket pools". Restart the browser and retry the site in incognito mode.
VPN, antivirus, firewall, and router issues
If DNS is fine but the site still won't open, the culprit is almost always a middleman between the browser and the network:
- VPN and proxies. They change your route and DNS server; some sites block entire VPN IP ranges, and a half-disconnected VPN leaves dead routes behind. Fully quit the client and retry.
- Antivirus. "HTTPS protection" modules pipe TLS traffic through themselves and produce ERR_CONNECTION_RESET when they fail. Temporarily disable web shields or encrypted-connection scanning.
- Firewall. An overly strict rule can cut outbound connections to port 443 for specific apps — check whether Chrome is blocked.
- Browser extensions. Ad blockers and "boosters" interfere with requests. Open the site in incognito with extensions off.
- Router. It keeps its own DNS cache and can wedge after weeks of uptime. A power-cycle fixes a surprising share of cases.
The site works on mobile data but not on Wi-Fi
A classic symptom: the site is alive, and the problem sits inside your network. In order: reboot the router; change the DNS server on your device to 1.1.1.1 or 8.8.8.8 to bypass the ISP resolver; check the router's parental controls and block lists; if nothing helps, ask your ISP whether the resource is blocked on their side.
The fastest way to localize the problem is to compare three environments: your computer on Wi-Fi, your phone on the same Wi-Fi, and your phone on LTE. Two minutes, and you know exactly where to look — the device, the home network, or the site itself.
What to do if you own the site
If the site is down for everyone, check the layers top-down: domain, DNS, server, web service, network.
DNS records and domain expiry
Verify that the A/AAAA records point to the current server IP and the NS records point to working name servers — a DNS lookup makes this quick. The classic failure is an expired domain: the registrar drops delegation and every visitor suddenly gets DNS_PROBE_FINISHED_NXDOMAIN. Check the expiry date via whois and enable auto-renewal. Mind the TTL too: after an IP change, the old record lives in caches until the TTL runs out, so part of your audience keeps hitting the old address for a while.
Server and web service
# Is the web server running and listening?
sudo systemctl status nginx
sudo ss -tlnp | grep -E ':80|:443'
# Does the firewall allow inbound 80/443?
sudo ufw status
sudo iptables -L INPUT -n | head -20If nginx or Apache isn't running, read the log: journalctl -u nginx -n 50. The usual suspects are a broken config after a deploy, a full disk, or the OOM killer taking the process down under load.
Hosting, billing, and geo-blocks
Your host may have suspended the account for non-payment or resource overuse — check the control panel and your inbox, warnings land there first. Regional blocks and CDN-level filters are a separate story: a site can be unreachable from one country and perfectly fine from another, so always test availability from at least two regions.
Monitoring: know before your users do
A one-off check only tells you what is happening right now; it will never tell you about last night's outage. Set up uptime monitoring that probes the site every few minutes from several regions and alerts you via Telegram or email — then you'll be the first to see "This site can't be reached", not your customers. The free tier is enough to start.
FAQ
Where do I start when I see "This site can't be reached"?
With the code under the heading (ERR_*): it immediately narrows the search to DNS, port, timeout, or reset. Then test from your phone on LTE to learn whether the problem is local or global.
Is it a Chrome problem or a site problem?
Chrome only displays a network-level error. Try the site in another browser and from another device: if it fails everywhere, the network or the site is at fault — not the browser.
Why does the site open in another browser but not in Chrome?
Chrome keeps its own DNS cache and socket pools. Clear them via chrome://net-internals/#dns, turn off "Secure DNS" (DNS-over-HTTPS) in settings, and test extensions in incognito.
How long should I wait if the site is down for everyone?
Depends on the cause: a service restart takes minutes, data-center recovery takes hours, and an expired domain can need up to a day to return because of DNS caching. Follow the status via an outage tracker or monitoring.
How does a site owner find out about downtime first?
Only through continuous monitoring: external checks every 1–5 minutes from several regions with instant alerts. Anything else means your visitor discovers the error before you do.
Final checklist
- Read the error code under the heading (ERR_*) and find it in the table above.
- Open the site from your phone on LTE — down for everyone or just you?
- Verify with an external checker and the outage tracker.
- Flush the OS and Chrome DNS caches (
chrome://net-internals/#dns). - Switch the DNS resolver to 1.1.1.1 or 8.8.8.8.
- Disable VPN, proxy, antivirus web shield, and extensions (test in incognito).
- Reboot the router; if you suspect the ISP — try another network.
- Owners: check the DNS records, domain expiry, server state, and firewall.
- Set up continuous monitoring so the next outage doesn't go unnoticed.
- If the site loads but with errors, run the general website-not-loading checklist.