“This site can’t be reached”: what it means and how to fix it

“This site can’t be reached” is Chrome’s generic message for connection failures that happen before any HTTP response. The browser tried to connect to the server and could not establish a connection at all. No response was received. No error page was served. The server was simply unreachable from the browser’s perspective.

This is different from errors like 500, 502, or 503 where the server responds with an error. With “This site can’t be reached,” there is no response at all. The failure is at the network or DNS level, not the application level. Firefox shows a similar message as “Unable to connect” or “The connection has timed out.” Safari displays “Safari can’t open the page.”

Chrome includes a more specific error code below the main message. That code is the key to diagnosing the issue.

The error codes and what they mean#

ERR_NAME_NOT_RESOLVED

The browser could not resolve the domain name to an IP address. DNS lookup failed entirely. The browser does not know where to connect because it has no IP address for the domain.

Common causes:

The domain does not exist in DNS. The domain was never configured, the DNS records were deleted, or the domain expired and the registrar removed the DNS entries. Check whether the domain resolves at all:

dig +short example.com
nslookup example.com

If these return nothing, the domain has no A record. Check your DNS provider’s dashboard to verify the records exist. If the domain recently expired, renew it at your registrar. DNS records may take a few hours to propagate after renewal.

You can also check using SiteProbe’s DNS lookup to verify from an external perspective.

Nameservers are misconfigured. The domain is registered but its nameservers point to the wrong provider. If you moved your hosting but forgot to update the nameservers at your registrar, DNS queries go to the old provider which no longer has records for your domain.

dig NS example.com

Verify the nameservers match your current hosting or DNS provider.

Your local DNS is failing. Your device’s configured DNS server is not responding or is returning incorrect results. This affects all sites, not just one. If multiple sites fail to load, the problem is your DNS resolver, not any specific domain.

Fix: Try a different DNS server. Change your device’s DNS to a public resolver like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google):

# Test with a specific DNS server
nslookup example.com 1.1.1.1

If this works but your default DNS does not, your configured DNS server is the problem. For a complete walkthrough of DNS resolution failures, see DNS server not responding: what it means and how to fix it. For the related NXDOMAIN variant, see dns_probe_finished_bad_config: what it means and how to fix it.

Stale DNS cache. Your device or browser cached a DNS record that is no longer valid. After a DNS change (new hosting, new IP), the old record can persist locally until the TTL expires.

Fix: Flush your DNS cache. On Windows:

ipconfig /flushdns

On macOS:

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

On Linux:

sudo systemd-resolve --flush-caches

For a full guide on clearing DNS cache across all platforms, see How to flush DNS cache on Linux, Mac, and Windows.

ERR_CONNECTION_REFUSED

The browser resolved the domain to an IP address and reached the server, but the server actively refused the connection. Something is listening on that IP, but nothing is accepting connections on port 80 (HTTP) or 443 (HTTPS).

This is distinct from a timeout. Connection refused is an immediate rejection. The server is reachable and responsive, it just is not accepting web traffic.

Common causes:

The web server is stopped. Nginx, Apache, or whatever serves your site is not running. The server is online but no process is listening for web requests.

# Check via SSH if you have access
systemctl status nginx
ss -tlnp | grep -E ':80|:443'

If nothing is listening on ports 80 and 443, start the web server:

systemctl start nginx

Check the logs for why it stopped. Common reasons: a configuration error after a change, a certificate file that was removed, or the OOM killer terminating processes during a memory spike.

Firewall blocking the port. The web server is running but a firewall rule is blocking inbound connections on port 80 or 443. This can happen after a firewall rule change, a security hardening script, or a cloud provider security group misconfiguration.

iptables -L -n | grep -E '80|443'

Wrong port. The web server is listening on a non-standard port (like 8080 or 8443) but the browser is trying the standard ports. Check your server configuration to verify which ports the web server is bound to.

The IP address is wrong. The DNS record points to an IP that is not your server. After a migration or server change, if the A record was not updated, the browser connects to the old IP which may not have a web server running.

The same set of checks applies when SSH connections are refused, since the underlying mechanism is the same: nothing is listening on the expected port, or a firewall is blocking it.

If your site is behind Cloudflare and Cloudflare cannot reach your origin, visitors see a 521 error instead of ERR_CONNECTION_REFUSED, because Cloudflare handles the browser connection and returns its own error page.

ERR_CONNECTION_TIMED_OUT

The browser resolved the domain, sent a connection request, and got no response at all. The request went out and nothing came back within the timeout period (typically 30 seconds in Chrome).

This is different from connection refused. A timeout means the packets disappeared into the void. Either they never reached the server, or the server never responded.

Common causes:

The server is completely offline. The machine is powered off, rebooting, or has a network outage. It cannot respond because it is not running.

A firewall is silently dropping packets. Unlike connection refused (which actively rejects the connection), a firewall configured to DROP rather than REJECT causes timeouts. The server receives the packet and silently discards it. The browser waits for a response that never comes.

# Test if the server is reachable at all
ping -c 3 example.com

# Test if port 443 is open
nc -zv -w 5 example.com 443

If ping succeeds but the port test times out, a firewall is blocking the web port specifically.

Network routing issue. Something between your device and the server is broken. An ISP outage, a routing misconfiguration, or a network path that drops packets. This is harder to diagnose because the problem is not on either endpoint but somewhere in between.

# Trace the network path
traceroute example.com

If traceroute stops responding at a specific hop, the issue is at that point in the network path. If it is an ISP hop, you need to wait for the ISP to fix it or try connecting from a different network.

Server is overloaded. The server is technically running but so overwhelmed that it cannot accept new connections. The TCP backlog is full and new SYN packets are being dropped. This produces the same symptom as a firewall drop: silence.

ERR_CONNECTION_RESET

The browser started establishing a connection and the connection was terminated mid-process. The server (or something between the browser and the server) sent a TCP RST packet, forcibly closing the connection.

Common causes:

A firewall or IDS is killing the connection. An intrusion detection system or web application firewall identifies the connection as suspicious and terminates it. This can happen when your IP has been flagged, when the request matches a malicious pattern, or when a rate limiter kicks in.

SSL/TLS mismatch. The browser starts a TLS handshake and the server cannot complete it, so the server resets the connection. This overlaps with “This site can’t provide a secure connection” errors, but sometimes Chrome shows connection reset instead, depending on exactly when the failure occurs.

ISP or network-level interference. Some ISPs and corporate networks actively reset connections to certain sites or services. This is more common in regions with internet censorship.

Fix: Try from a different network (mobile data vs Wi-Fi) to rule out network-level interference. Check if the site works via a VPN. If the reset only happens from your IP, you may be blocked at the server’s firewall level.

Diagnosing the root cause#

Step 1: Is it just you or everyone?

Check if the site is down for everyone or just your connection:

curl -Iv https://example.com 2>&1 | head -10

If curl succeeds, the site is up and the issue is specific to your browser or network. If curl also fails, the site is genuinely unreachable.

Test from a different device on the same network and from a completely different network (mobile data). This tells you whether the problem is your device, your network, or the server.

Step 2: Does DNS resolve?

nslookup example.com

If this returns an IP address, DNS is working. If it fails, the problem is DNS. See the ERR_NAME_NOT_RESOLVED section above.

Step 3: Is the server reachable?

ping -c 3 RESOLVED_IP
nc -zv -w 5 RESOLVED_IP 443

If ping succeeds but the port test fails, the server is online but not accepting web connections. Check the web server status and firewall.

Step 4: Does the server respond to HTTP?

curl -Iv --connect-timeout 10 https://example.com 2>&1 | head -20

If this times out, the problem is between you and the server (firewall, routing). If it returns a connection refused error, nothing is listening on the port. If it returns an HTTP response (even an error), the server is reachable and the problem is browser-specific.

Step 5: Check from an external location

Use SiteProbe’s DNS checker and an external uptime monitor to verify the site’s status from outside your network. If external tools can reach the site, the problem is on your end or your network path.

Browser-side fixes#

If the site is up for everyone else but not for you, work through these:

Flush DNS cache. Your device may have a stale DNS record. Flush the cache using the commands in the ERR_NAME_NOT_RESOLVED section.

Try a different DNS server. Switch to 1.1.1.1 or 8.8.8.8 to rule out your DNS resolver.

Disable VPN or proxy. VPNs and proxies add network hops that can fail. Disconnect and test directly.

Disable browser extensions. Some privacy or ad-blocking extensions interfere with connections. Test in an incognito window (which disables extensions by default).

Check your firewall or antivirus. Local firewall software or antivirus web protection features can block connections to specific sites. Temporarily disable and test.

Reset network settings. On Windows:

netsh winsock reset
netsh int ip reset

Then restart the computer. This resets the TCP/IP stack and can fix connection issues caused by corrupted network configuration.

Server-side fixes#

If you manage the server and it is genuinely unreachable:

Check that the web server is running and listening. systemctl status nginx and ss -tlnp | grep -E ':80|:443' are the first two commands to run.

Check the firewall. Verify that ports 80 and 443 are open for inbound connections. If you recently changed firewall rules or ran a hardening script, check what was changed.

Check server resources. A server that is out of memory, out of disk space, or at 100% CPU may stop accepting connections even though the OS is still running. Check with free -m , df -h , and uptime .

Check DNS records. Verify that the A record for your domain points to the correct server IP. If you recently migrated, the old IP may still be in DNS.

Check your hosting provider’s status. If the entire server is offline and you cannot SSH in, the issue is at the infrastructure level. Check your provider’s status page for outages.

Quick reference#

For DNS-specific troubleshooting, see DNS server not responding and dns_probe_finished_bad_config. For server-level connection issues, see SSH connection refused. For the full list of WordPress and server errors, see How to fix the most common WordPress errors.