This Site Can't Be Reached: Fix by Error Code (Chrome, Android)

"This site can't be reached" is Chrome's generic page for a connection that failed before any web page was sent: the name did not resolve, the server refused or ignored the connection, or something on the path dropped it. The ERR_* code under the heading tells you which, and so whether to fix your device, your network or the server.

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 data center that lost power. Real diagnosis starts with the error subcode: the gray ERR_* text under the heading, sometimes followed by a line such as "example.com refused to connect" or "example.com took too long to respond".

Every cause falls into one of three buckets: your device (stale DNS cache, VPN client, antivirus, extensions, hosts file), your network (router, ISP, the ISP's DNS resolver, a corporate firewall), or the site itself (server down, expired domain, broken DNS records, a firewall rule). The goal of the first few minutes is to find the bucket, 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.

Other browsers show the same failures in their own words. Knowing the equivalent helps when you compare browsers:

Browser	What you see	Where the detail is
Chrome (Windows, macOS, Linux, ChromeOS)	This site can't be reached	ERR_* code under the heading; "Details" is not shown for all codes
Chrome on Android	This site can't be reached	Same ERR_* codes, in smaller text
Microsoft Edge	Hmmm… can't reach this page	Same Chromium ERR_* codes
Firefox	Hmm. We're having trouble finding that site / Unable to connect / The connection has timed out	The heading itself names the failure type
Safari	Safari Can't Find the Server / Safari Can't Open the Page	A short sentence under the heading

Chrome error codes: the full table

These are the subcodes most often hiding behind "This site can't be reached". The names come from Chromium's own network error list, so they are identical in Chrome, Edge, Brave and Opera.

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, a dead route	Try another network; ping and traceroute the domain
ERR_CONNECTION_REFUSED	Host is up, but the port rejected the connection	Web server not running or not listening on 80/443; wrong port in the URL	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, try resolver 1.1.1.1 or 8.8.8.8
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
DNS_PROBE_FINISHED_NO_INTERNET	Chrome's DNS probe found no working connection	Wi-Fi without internet, captive portal not accepted, adapter problem	Open any other site; re-join the network
ERR_ADDRESS_UNREACHABLE	No route to the IP address	Broken routing, VPN conflict, private IP in a DNS record	Disconnect the VPN; traceroute to the host
ERR_CONNECTION_RESET	Connection established, then dropped	TLS failure, MTU issues, antivirus or middlebox intercepting HTTPS	Turn off HTTPS scanning in the antivirus; test another network
ERR_CONNECTION_CLOSED / ERR_EMPTY_RESPONSE	The server closed the connection without an answer	Crashed backend, misconfigured proxy, TLS terminator without a certificate	curl -v to see where the exchange stops
ERR_NETWORK_ACCESS_DENIED	The operating system refused Chrome network access	Firewall or security software blocking the browser	Check the firewall's per-app rules for Chrome

We have dedicated deep dives for the most common codes: DNS_PROBE_FINISHED_NO_INTERNET, ERR_ADDRESS_UNREACHABLE and ERR_CONNECTION_RESET.

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, covered in "How to check if a website is down for everyone". If a major service is failing, look at the outage tracker: mass incidents show up there before the news catches on.

Laptop on Wi-Fi	Phone on same Wi-Fi	Phone on mobile data	Where the problem is
Fails	Loads	Loads	The laptop: DNS cache, VPN, antivirus, extension, hosts file, proxy settings
Fails	Fails	Loads	The home network: router, ISP resolver, ISP-level block
Fails	Fails	Fails	The site (or a regional block): confirm with an external check
Loads	Fails	Fails	The phone: Private DNS, VPN app, content filter profile

Why does Google always say this site can't be reached?

Strictly speaking, it is Google Chrome saying it, not Google Search: the page is Chrome's error screen for any failed connection. If you see it for every site you open, the site is not the problem, your connection is. Check in this order:

1. Is the device actually online? On Windows, the network icon should not show "No internet"; on public Wi-Fi, open http://neverssl.com to trigger a captive portal login page you may have missed.
2. Is a proxy configured? On Windows open Settings → Network & internet → Proxy and turn off "Use a proxy server" unless your organization requires it. netsh winhttp show proxy shows the system-wide WinHTTP proxy. On macOS: System Settings → Network → your connection → Details → Proxies.
3. Does DNS work at all? Run nslookup google.com. A timeout here means the resolver your device uses is dead; switch to a public one such as 1.1.1.1 or 8.8.8.8 in the adapter settings.
4. Is a VPN client half-connected? Quit it completely, not just "disconnect", and retry.
5. As a last resort on Windows, reset the network stack and reboot: netsh winsock reset and netsh int ip reset from an elevated Command Prompt.

A common variant is "every site says this site can't be reached except YouTube" (or except Google). Sites you visited recently still have cached DNS answers and open connections, so they keep working while new lookups fail. That pattern points to DNS, not to the sites.

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.com

On Windows, ping sends four packets by default (no -c), and PowerShell has a direct port test:

Test-NetConnection example.com -Port 443
Resolve-DnsName example.com

How to read the results: nslookup errors out, so 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). Keep in mind many servers block ICMP, so a failed ping alone proves nothing. ping works but curl hangs or is refused: the host is alive, but the web service on port 443 isn't answering, and that one belongs to the site owner.

Compare resolvers when you suspect DNS. If your default resolver fails and a public one answers, the problem is your ISP's or router's DNS, not the domain:

nslookup example.com          # your default resolver
nslookup example.com 1.1.1.1  # Cloudflare
nslookup example.com 8.8.8.8  # Google

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. The full per-system list is in our DNS cache flush guide.

Windows

ipconfig /flushdns
:: if that didn't help, reset the network stack and reboot
netsh winsock reset

macOS

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Linux (systemd-resolved)

sudo resolvectl flush-caches
# on older distributions:
sudo systemd-resolve --flush-caches

Chrome's own cache

Chrome also keeps an 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 an Incognito window (Ctrl + Shift + N on Windows and Linux, Cmd + Shift + N on macOS).

One more Chrome setting matters here: Settings → Privacy and security → Security → "Use secure DNS". With it on, Chrome may send lookups over DNS-over-HTTPS to a provider other than your system resolver. If a site fails only in Chrome, toggle this setting and retry; if a site fails only outside Chrome, the reverse is true.

This site can't be reached for only one website

When every other site works and one does not, the cause is either that site or something that singles it out on your side:

• Hosts file. An old entry can pin the domain to a dead IP. Check C:\Windows\System32\drivers\etc\hosts on Windows or /etc/hosts on macOS and Linux for the domain name and remove the line.
• Broken IPv6. If the site publishes an AAAA record but its IPv6 path is broken, clients that prefer IPv6 fail while others succeed. Compare curl -4 -I https://example.com with curl -6 -I https://example.com.
• Stale DNS after a migration. The site moved hosts; your resolver still hands out the old address until the TTL expires. Flush caches or try a public resolver.
• A block on your network. Parental controls, DNS filtering (on the router or in a filtering DNS service), a school or office firewall, or an ISP-level block.
• Your IP is blocked by the site. Covered in the next section.

Why am I suddenly denied access to a website?

When access disappears overnight for one site, the site's firewall often made a decision about your IP address. How it shows depends on where the block happens:

What you see	Where the block is	Typical reason
ERR_CONNECTION_TIMED_OUT for that site only	Server or network firewall silently dropping your packets	Automatic ban after repeated failed logins or too many requests (for example fail2ban), a country-level rule
ERR_CONNECTION_REFUSED or ERR_CONNECTION_RESET	Firewall rejecting instead of dropping	Same bans, configured to reject
403 Forbidden, "Access denied", Cloudflare 1020	Web server or CDN (the connection itself worked)	WAF rule, bot protection, IP reputation
"This site can't be reached" on a whole network	ISP, school or office filtering	Content policy or a legal block in that country

A 403 page is not "This site can't be reached": if you get an HTTP error page, the network part worked. See our 403 Forbidden guide for that case. For a firewall ban, the honest fix is to contact the site owner with your public IP address and the time it started; a shared IP (mobile carrier, office NAT) sometimes inherits a ban caused by someone else.

Why is Chrome suddenly blocking websites?

Chrome itself blocks pages in a few specific ways, and each has its own screen and code, not the generic one:

• ERR_BLOCKED_BY_CLIENT: an extension (usually an ad or tracker blocker) cancelled the request. Test in Incognito, where extensions are off by default.
• ERR_BLOCKED_BY_ADMINISTRATOR: a policy set by your organization or by software on the machine blocks the URL. Open chrome://policy and look for URLBlocklist; on a personal computer, an unexpected policy often comes from unwanted software.
• A red "Dangerous site" warning: Google Safe Browsing flagged the site for malware or phishing. That is not a connection error; if it is your own site, check it with a malware scan.
• ERR_NETWORK_ACCESS_DENIED: not Chrome at all, but a firewall or security suite that stopped Chrome from using the network after an update changed the executable.

A less obvious case produced a lot of "suddenly" reports: newer Chrome versions use a post-quantum hybrid key exchange in TLS 1.3, which makes the first TLS message larger. Some outdated firewalls and middleboxes mishandle it and drop the connection, which appears as ERR_CONNECTION_RESET or a timeout on HTTPS sites. Users found that disabling the "TLS 1.3 hybridized Kyber support" flag in chrome://flags helped; treat that only as a diagnostic, since the real fix is updating the firmware of the device that fails. The background is in our article on post-quantum TLS.

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, test, and turn them back on.
• Firewall. An overly strict rule can cut outbound connections to port 443 for specific apps. Check whether Chrome is blocked in Windows Defender Firewall → "Allow an app through firewall", or in your third-party firewall.
• Browser extensions. Ad blockers, privacy tools 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 (off for 30 seconds) fixes a surprising share of cases.
• MTU. If small sites load but large pages hang or reset, test the path MTU. A 1472-byte payload plus 28 bytes of headers equals the standard 1500:

# Windows: -f = don't fragment, -l = payload size
ping -f -l 1472 8.8.8.8
# macOS: -D = don't fragment
ping -D -s 1472 8.8.8.8
# Linux
ping -M do -s 1472 8.8.8.8

If these fail while smaller sizes succeed, something on the path (often a VPN or PPPoE link) has a smaller MTU; that is a router or ISP setting.

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.

This site can't be reached on Android and mobile Chrome

On a phone the same codes apply, but the settings live elsewhere:

1. Toggle airplane mode on and off. This drops the connection and the system DNS cache along with it.
2. Switch between Wi-Fi and mobile data to see which one fails.
3. Check Private DNS: Settings → Network & internet → Private DNS (the path differs slightly by manufacturer). A mistyped or dead hostname here breaks name resolution for every app. Set it to "Automatic" to test.
4. Open chrome://net-internals/#dns in Chrome for Android and clear the host cache, the same as on desktop.
5. Pause VPN, ad-blocking and "security" apps: many work as a local VPN and filter all traffic.
6. If only Chrome fails, clear its cache: Settings → Apps → Chrome → Storage → Clear cache. Clearing storage also signs you out of sites, so try the cache first.

On iPhone and iPad the Safari wording differs, but the approach is the same: compare Wi-Fi with cellular, check Settings → Wi-Fi → (i) → Configure DNS, and remove VPN or DNS profiles under Settings → General → VPN & Device Management.

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 with 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 -20

If nginx or Apache isn't running, read the log: journalctl -u nginx -n 50 (or journalctl -u apache2 / httpd, depending on the distribution). Validate the configuration before restarting with sudo nginx -t or sudo apachectl configtest. The usual suspects are a broken config after a deploy, a full disk (df -h), or the OOM killer taking the process down under load (journalctl -k | grep -i oom).

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. If your own firewall bans aggressive clients, review the ban list before assuming the internet is broken; a single overly broad rule can lock out a whole mobile carrier.

How to check

A browser only shows you your own view. To see the site from outside your network:

• HTTP headers and availability check: confirms whether the server answers, with which status code and how fast, from an external location.
• DNS lookup: shows the A, AAAA and NS records the world sees, which catches expired domains and wrong IPs after a migration.
• Traceroute: shows where on the path packets stop, the key test for ERR_CONNECTION_TIMED_OUT and ERR_ADDRESS_UNREACHABLE.

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, so you are the first to see "This site can't be reached", not your customers. The free tier is enough to start.

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; toggle Chrome's secure DNS.
• Check the hosts file and the proxy settings.
• 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.

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 mobile data 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 and may use secure DNS. Clear them via chrome://net-internals/#dns, toggle "Use secure DNS" in settings, and test extensions in Incognito.

How can I fix the ERR_ADDRESS_UNREACHABLE error?

Disconnect any VPN, restart the router, and check that the domain doesn't resolve to a private address such as 192.168.x.x or 10.x.x.x. Run traceroute (tracert on Windows) to see where the route ends. Details are in our ERR_ADDRESS_UNREACHABLE guide.

Why am I suddenly denied access to a website?

Most often the site's firewall or CDN blocked your IP after too many requests or failed logins, or the site restricted your country. A timeout for one site only suggests a silent firewall ban; a 403 page means the server received you and refused.

How long should I wait if the site is down for everyone?

It depends on the cause: a service restart takes minutes, data-center recovery takes hours, and a renewed domain can take up to a day to return everywhere because of DNS caching. Follow the status via an outage tracker or monitoring.