Why Can't I Reach This?

1

START Is It Just You?

Before diving deep, check if the problem is widespread or isolated to your machine. This determines your entire troubleshooting path.

# Quick check — is the site down for everyone? $ curl -s -o /dev/null -w "%{http_code}" https://example.com 200 # ← You got a response, so it's reachable # Compare against a third-party status checker $ curl -s "https://isitdown.site/example.com" | head -5

!

Don't just open another browser tab — browsers cache DNS and may show stale results. Use curl or ping from the terminal for a clean test.

2

DNS Can You Resolve the Domain?

DNS translates human-readable domain names to IP addresses. If this fails, nothing else matters — you can't even start a connection.

# Does the domain resolve to an IP? $ nslookup example.com Server: 1.1.1.1 Address: 1.1.1.1#53 Non-authoritative answer: Name: example.com Address: 93.184.216.34 # Try multiple DNS servers to rule out your resolver $ dig @8.8.8.8 example.com +short 93.184.216.34 # Check if YOUR DNS is the problem $ dig @127.0.0.1 example.com +short ;; connection timed out; no servers could be reached

i

SERVFAIL = your DNS server is broken. NXDOMAIN = domain doesn't exist (typo?). connection timed out = DNS server unreachable. Try switching to 1.1.1.1 or 8.8.8.8.

3

NETWORK Can You Reach the IP?

DNS worked — you have an IP. Now can your machine actually route packets to it? This tests your network path.

# Basic connectivity test $ ping -c 4 93.184.216.34 64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=12.3 ms 64 bytes from 93.184.216.34: icmp_seq=2 ttl=56 time=11.8 ms # Trace the route to find where packets die $ traceroute 93.184.216.34 1 192.168.1.1 1.2 ms 2 10.0.0.1 5.4 ms 3 * * * # ← Packets stop here 4 * * *

i

Request timeout = firewall or routing issue. Destination host unreachable = no route exists. 100% packet loss = something is blocking ICMP (or the host is down). Use traceroute to pinpoint the failing hop.

4

PORT Is the Port Open?

The IP is reachable, but is the specific service listening? A server can be up but have its port firewalled or service crashed.

# Test if the specific port is accepting connections $ nc -zv 93.184.216.34 443 Connection to 93.184.216.34 443 port [tcp/https] succeeded! # Or use nmap for a more detailed scan $ nmap -Pn -p 80,443 93.184.216.34 PORT STATE SERVICE 80/tcp open http 443/tcp filtered https # ← Filtered = firewall is blocking # Check what's listening locally (if testing your own server) $ ss -tlnp | grep :443 LISTEN 0 128 0.0.0.0:443 users:(("nginx",pid=1234,fd=6))

i

Connection refused = port is closed (no service listening). filtered = firewall is dropping packets. Connection timed out = packets are being silently dropped. Check both local and remote firewalls.

5

TLS Is the Certificate Valid?

The port is open, but can you complete the TLS handshake? Certificate issues are one of the most common causes of "connection refused" in browsers.

# Inspect the certificate chain $ openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates notBefore=Jan 15 00:00:00 2025 GMT notAfter=Feb 14 23:59:59 2026 GMT # Check for certificate errors specifically $ curl -vI https://example.com 2>&1 | grep -i "SSL\|certificate\|expire" * SSL certificate verify ok. # Common error: hostname mismatch $ curl -vI https://wrong.example.com 2>&1 | grep -i error * SSL: certificate subject name 'example.com' does not match

i

Certificate has expired = server cert needs renewal. Hostname mismatch = cert is for a different domain. self-signed certificate = not trusted by your CA store. certificate verify failed = missing intermediate cert.

6

HTTP Is the Application Responding?

TLS handshake succeeded, but the application layer may return errors. The server is reachable — but is it doing what you expect?

# Full HTTP request with verbose output $ curl -v https://api.example.com/health > GET /health HTTP/2 > Host: api.example.com > Authorization: Bearer eyJhbG... < HTTP/2 403 # ← Forbidden < {"error": "Invalid API key"} # Check response headers for clues $ curl -sI https://api.example.com/health HTTP/2 429 # ← Rate limited Retry-After: 30 X-RateLimit-Limit: 100 X-RateLimit-Remaining: 0

i

403 Forbidden = auth/permissions issue. 429 Too Many Requests = rate limiting. 502 Bad Gateway = upstream server is down. 503 Service Unavailable = server is overloaded or in maintenance. Check headers — they often tell you exactly what's wrong.

7

BLOCK Firewall or Proxy Blocking?

If everything above works from a terminal but your browser can't connect, a local firewall, corporate proxy, or VPN is likely intercepting traffic.

# Check if a proxy is configured $ echo $http_proxy $https_proxy http://corporate-proxy:8080 http://corporate-proxy:8080 # Check local firewall rules (Linux) $ sudo iptables -L -n | grep -i drop DROP all -- 0.0.0.0/0 0.0.0.0/0 # Check Windows firewall PS> Get-NetFirewallRule | Where {$_.Action -eq 'Block'} | Select DisplayName Block Outbound - Custom Rule # Bypass proxy for testing $ curl --noproxy '*' https://example.com 200 OK # ← Works without proxy = proxy is the problem

!

Works in terminal but not browser? Proxy issue. ERR_PROXY_CONNECTION_FAILED = proxy is down. Corporate networks often intercept HTTPS via MITM proxies — you may need to install their root CA. VPNs can also silently break routing.

8

LOCAL Local Overrides Breaking Things?

Your /etc/hosts file, browser extensions, or local DNS cache can silently redirect traffic to the wrong place.

# Check for local hosts overrides $ grep example.com /etc/hosts 127.0.0.1 example.com # ← This redirects to localhost! # Flush DNS cache (varies by OS) $ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # macOS $ sudo systemd-resolve --flush-caches # Linux PS> Clear-DnsClientCache # Windows # Check browser DNS over HTTPS settings # Chrome: chrome://net-internals/#dns → Clear host cache

i

Site works in one browser but not another? Check for extensions (ad blockers, privacy tools). /etc/hosts overrides are common in development but break things when forgotten. Stale DNS cache can point to IPs that no longer serve your domain.

Command	What It Does
nslookup domain	Basic DNS lookup
dig domain +short	Detailed DNS query
dig @8.8.8.8 domain	Query specific DNS server
host domain	Simple reverse/forward lookup
cat /etc/resolv.conf	See your DNS servers

Command	What It Does
ping -c 4 host	Test basic reachability
traceroute host	Map the network path
mtr host	Live traceroute + ping
curl -v url	Verbose HTTP request
wget -S url	Fetch with headers

Command	What It Does
nc -zv host port	Test single port
nmap -Pn host	Scan common ports
nmap -p 80,443 host	Scan specific ports
ss -tlnp	Local listening ports
lsof -i :443	What's using port 443

Command	What It Does
openssl s_client ...	Inspect TLS handshake
curl -vI https://...	Check cert in HTTP request
certbot certificates	List local certs (Let's Encrypt)
openssl x509 -dates	Check cert expiry
sslscan host:443	Full TLS analysis

Command	What It Does
iptables -L -n	List Linux firewall rules
ufw status	Ubuntu firewall status
echo $http_proxy	Check proxy config
curl --noproxy '*'	Bypass proxy
Get-NetFirewallRule	Windows firewall rules

START Is It Just You?

DNS Can You Resolve the Domain?

NETWORK Can You Reach the IP?

PORT Is the Port Open?

TLS Is the Certificate Valid?

HTTP Is the Application Responding?

BLOCK Firewall or Proxy Blocking?

LOCAL Local Overrides Breaking Things?

Scenarios

Select a Scenario

🔍 DNS Diagnosis

🔌 Connectivity

🚪 Port Scanning

🔒 TLS / Certificate

🛡️ Firewall & Proxy

📝 HTTP Status Codes

Code	Meaning & Fix
2xx	Success — no issue here
403	Forbidden — check auth / permissions
404	Not Found — check URL path
429	Rate Limited — back off, check limits
502	Bad Gateway — upstream is down
503	Unavailable — service overloaded