10 Common Network Errors and How to Fix Them

What it means: The domain name doesn't exist in DNS. "NXDOMAIN" literally means "Non-Existent Domain."

Common causes:

• Typo in the URL (googel.com instead of google.com)
• The domain has expired or been deleted
• DNS records haven't propagated yet after a change
• Your DNS server is having issues

How to fix:

1. Double-check the URL for typos
2. Try the website in a different browser or device
3. Flush your DNS cache: Windows ipconfig /flushdns, macOS sudo dscacheutil -flushcache
4. Try a different DNS server (switch to 1.1.1.1 or 8.8.8.8)
5. Use LookMyIP's DNS Lookup to check if the domain has valid DNS records
6. If it's your own domain, check the DNS propagation status at lookmyip.com/propagation

What it means: Your browser reached the server, but the server actively refused the connection. The server is online but not accepting connections on the requested port.

Common causes:

• The web server (Apache, Nginx, etc.) is stopped or crashed
• The server is running on a different port than expected
• A firewall on the server is blocking the connection
• The server's IP has changed but DNS hasn't updated

How to fix:

1. Check if the site is down for everyone or just you (try from a different network or device)
2. Clear your browser cache and cookies for the site
3. If it's your server: check that the web server process is running, check firewall rules, verify the server is listening on the correct port
4. Use LookMyIP's Port Checker to verify port 80/443 is open on the server

What it means: Your browser sent a request but the server didn't respond within the timeout period. Unlike ERR_CONNECTION_REFUSED (server actively rejecting), a timeout means no response at all.

Common causes:

• The server is down or overloaded
• A firewall is silently dropping packets
• Network congestion between you and the server
• Your ISP is having routing issues

How to fix:

1. Wait a minute and try again — the server may be temporarily overloaded
2. Check your own internet connection (can you reach other sites?)
3. Try from a different network (mobile data vs Wi-Fi)
4. Run a traceroute to identify where the connection breaks
5. Check the server's IP using LookMyIP — has the IP changed? Is the server reachable?

What it means: Your browser and the server couldn't agree on an SSL/TLS protocol version or cipher suite for the encrypted connection.

Common causes:

• The server's SSL certificate is misconfigured
• The server only supports outdated TLS versions (TLS 1.0/1.1) that modern browsers reject
• The server's SSL certificate has expired
• Browser or antivirus software is interfering with SSL

How to fix:

1. Check the site's SSL certificate using LookMyIP's SSL Checker (lookmyip.com/ssl)
2. Try disabling your antivirus's HTTPS scanning feature temporarily
3. Clear your browser's SSL state (Chrome: Settings > Privacy > Security > Manage certificates)
4. If it's your server: update your TLS configuration to support TLS 1.2 and 1.3, renew expired certificates, and ensure the full certificate chain is installed

What it means: Similar to NXDOMAIN — DNS couldn't resolve the domain name to an IP address.

Common causes:

• DNS server is unreachable or malfunctioning
• Local DNS cache is corrupted
• Your network connection has DNS issues
• The domain genuinely doesn't exist

How to fix:

1. Check if other websites work — if nothing loads, your DNS server may be down
2. Switch to a public DNS server (1.1.1.1 or 8.8.8.8)
3. Flush your DNS cache
4. Restart your router
5. Check the domain with LookMyIP's DNS Lookup — if it resolves there, the issue is on your end

What they mean: These are server-side errors. A reverse proxy or load balancer (Nginx, Cloudflare, AWS ALB) couldn't get a valid response from the upstream server.

• 502 Bad Gateway: The proxy received an invalid response from the upstream server
• 503 Service Unavailable: The server is temporarily overloaded or down for maintenance
• 504 Gateway Timeout: The upstream server didn't respond within the time limit

Common causes:

• The application server behind the proxy has crashed
• High traffic is overwhelming the server
• The server is undergoing maintenance
• A deployment or configuration change went wrong

How to fix (as a visitor):

1. Wait and retry — these are usually temporary
2. Check the site's status page or social media for announcements
3. Clear your browser cache (sometimes stale cached pages show these errors)

How to fix (as the server operator):

1. Check that all application processes are running
2. Review server logs for crashes or resource exhaustion
3. Check if you've hit resource limits (CPU, memory, connections)
4. Verify database connectivity — a downed database causes cascading 502/503 errors

What it means: The website is stuck in a redirect loop — page A redirects to page B, which redirects back to page A, endlessly.

Common causes:

• Misconfigured HTTP-to-HTTPS redirect (each version redirects to the other)
• Conflicting redirect rules in the web server, application, and CDN
• WordPress site URL and home URL misconfigured
• Cloudflare SSL mode set to "Flexible" when the origin server also forces HTTPS

How to fix:

1. Clear your cookies for the site (redirect loops often involve cookie-based redirects)
2. Try in an incognito/private window
3. If it's your site: check for conflicting redirects in your web server config, .htaccess, application code, and CDN settings. Use curl -v -L to trace the redirect chain manually.

What they mean:

• 401 Unauthorized: The server requires authentication. You need to log in or provide valid credentials.
• 403 Forbidden: You're authenticated (or not required to be), but you don't have permission to access this resource.

Common causes:

• Directory listing is disabled and no index file exists
• File permissions are too restrictive on the server
• IP-based access restrictions are blocking you
• Your IP is flagged by a WAF (Web Application Firewall)
• Geographic restrictions or VPN blocking

How to fix:

1. Check if you need to log in
2. If you're being blocked, try from a different IP or disable your VPN
3. Check your IP's reputation using LookMyIP's IP Reputation Checker — you may be on a shared IP with a bad reputation
4. If it's your server: check file permissions (should be 644 for files, 755 for directories), verify .htaccess rules, and check WAF logs

Error-specific fixes are useful once you know which error you have. When the symptom is vaguer than that — "the site will not load" — a fixed order resolves things faster than guessing, because each step eliminates a whole layer.

1. Is it just you? Try the site on mobile data with Wi-Fi off. If it works, the problem is your network, not the site. This single check saves more time than any other and takes ten seconds.

2. Is it just this device? Try another device on the same network. If others work, the problem is local — DNS cache, browser extension, proxy setting, or a host-file entry.

3. Is it DNS? Resolve the name explicitly:

dig example.com +short
dig @1.1.1.1 example.com +short

No answer from your resolver but a correct answer from 1.1.1.1 means your resolver is the problem. No answer from either means the record genuinely does not exist.

4. Is it reachable? Connect to the address directly, skipping DNS:

curl -sI --resolve example.com:443:192.0.2.10 https://example.com

That forces the hostname to a specific IP, which distinguishes a name resolution problem from a connectivity one.

5. Is it TLS?

echo | openssl s_client -connect example.com:443 -servername example.com 2>&1 | tail -20

6. Is it the application? A response arriving with a 5xx status means the network is fine and the server has a problem. That is a different investigation entirely.

The value of the order is that it moves outward one layer at a time. Jumping straight to "the server must be down" when the actual cause was a stale DNS cache on one laptop is the most common way an afternoon disappears.

A cluster of errors look like connectivity failures and are actually TLS problems. They share a diagnostic: the TCP connection succeeds and the handshake does not.

`NET::ERR_CERT_AUTHORITY_INVALID` on some clients only. The classic missing-intermediate symptom. Desktop Chrome works because it cached the intermediate from another site; curl, Java clients and older Android fail because they do not fetch it. Confirm what the server sends:

openssl s_client -connect example.com:443 -servername example.com | head -20

If the certificate chain block shows only entry 0, install the fullchain file rather than the leaf certificate alone.

`NET::ERR_CERT_COMMON_NAME_INVALID`. The hostname is not in the certificate's SAN list. Note that the Common Name field is ignored by every modern browser — only SANs count. Check them:

echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'

A wildcard covers exactly one label, so *.example.com does not match example.com itself. Both must be listed.

`NET::ERR_CERT_DATE_INVALID` on one machine only. The certificate is fine and the client's clock is wrong. Check the system time before renewing anything.

`ERR_SSL_PROTOCOL_ERROR` immediately on connect. Frequently a server listening with plain HTTP on port 443, or a load balancer terminating TLS and forwarding to a backend that also expects TLS.

Handshake works in a browser, fails in a script. Usually SNI. Older clients and some libraries do not send the server name, so a host serving multiple certificates returns the default one. openssl s_client requires -servername explicitly for this reason.

Run the domain through the SSL certificate checker for a full chain and expiry view without assembling openssl invocations by hand.

The hardest problems are the ones that happen sometimes. Three causes account for most of them.

Path MTU black holes. The connection establishes, small requests work, and anything large hangs forever. This is Path MTU Discovery failing: a router on the path needs to send an ICMP "Fragmentation Needed" message, a firewall somewhere is dropping ICMP, and the sender never learns to reduce its packet size. Test by pinging with a large payload and the do-not-fragment bit set:

ping -M do -s 1472 example.com          # Linux
ping -D -s 1472 example.com             # macOS
ping -f -l 1472 example.com             # Windows

1472 plus 28 bytes of headers is 1500, the standard ethernet MTU. If that fails but -s 1400 succeeds, something on the path has a smaller MTU. PPPoE connections commonly need 1492, and VPN tunnels often less. The fix is to lower the interface MTU or enable MSS clamping on the router — and to stop dropping ICMP type 3.

Broken IPv6. Because Happy Eyeballs falls back to IPv4 in about 250ms, a broken IPv6 path produces "sometimes slow" rather than "broken", which is why it goes unnoticed for months. Test each family explicitly:

curl -6 -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://example.com
curl -4 -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://example.com

An AAAA record pointing at a host that no longer listens on IPv6 costs every IPv6-capable visitor that delay on every connection.

Idle connection timeouts. A load balancer, NAT device or firewall silently drops an idle connection while both endpoints believe it is still open. The next request hangs until TCP gives up. This is why long-lived database connections in a pool fail after periods of low traffic. The fix is TCP keep-alive set below the shortest timeout in the path, or connection validation before use in the pool. AWS ALB defaults to 60 seconds idle; most NAT devices to a few minutes.

Why does a site work in one browser but not another?

Most often an extension, a cached HSTS entry, or a stale service worker. Test in a private window with extensions disabled to isolate it. A site that works in private browsing but not normally is an extension or a cache problem, not a network one.

What does "the connection was reset" actually mean?

A TCP RST arrived — something actively refused or terminated the connection, rather than dropping it silently. Common causes are the service crashing, a firewall configured to REJECT rather than DROP, a load balancer with no healthy backends, or a proxy rejecting the request. It is distinct from a timeout, which means nothing responded at all.

Should I flush DNS when troubleshooting?

It is cheap and rules out one layer, so yes, early. ipconfig /flushdns on Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS, sudo resolvectl flush-caches on Linux. Remember the browser has its own cache — Chrome's is at chrome://net-internals/#dns.

How do I tell whether a problem is my ISP or the destination?

Run mtr to the destination and check where loss begins and whether it persists to the final hop. Loss appearing at hop 3 and continuing to the end points at your ISP; loss appearing only in the last few hops points at the destination's network. Test a few unrelated sites — if all of them show problems at the same hop, it is your side.

Why do errors clear themselves after a few minutes?

Usually a DNS TTL expiring, a load balancer removing an unhealthy backend, or a BGP route converging after a link failure. Transient errors that resolve without intervention are normal on the internet; ones that recur on a schedule are worth investigating.