Why Won't a Website Load? Diagnose IP, DNS, Port and Status Code

#Establish which layer is broken

Network troubleshooting follows a fixed order: address, resolution, port, then application protocol. You work upward, because each layer depends on the one below it — and a lower-layer failure often produces a misleading error higher up.

A browser timeout, for example, could mean the domain never resolved, or that it resolved fine but the port is blocked. The browser message alone cannot tell you which — each layer answers a different question:

#Step one: the address itself is wrong

Private and loopback addresses can never be reached from the public internet. If your server address falls in one of these ranges, the investigation stops here.

These ranges are reserved for internal networks:

If the address starts with 169.254., the machine never obtained a valid IP, and every network request from it will fail.

#Step two: does the domain resolve

The signature of a DNS problem is "the IP works but the domain does not." When you see that, go straight to the DNS records.

Each record type answers a different question, and querying the wrong one leads to false conclusions:

#Step three: is the port reachable

An unreachable port has exactly two causes: a firewall dropping traffic, or nothing listening on it. First confirm the port number is right.

Default ports are easy to misremember:

Use Common Ports to look up a port by number or find the port for a service by name — it covers 68 common ports across databases, middleware and containers. Once the port is confirmed, check the firewall rules and the listening socket on the server.

#Step four: what did the service return

The HTTP status code carries more diagnostic value than anything else, because it tells you whether the fault is on the request side or the server side.

• 2xx success — the request was handled; look at page logic or front-end assets
• 3xx redirect — watch for redirect loops, or a jump to http that triggers a certificate warning
• 4xx client — 401 unauthenticated, 403 forbidden, 404 wrong path, 429 rate limited
• 5xx server — 500 unhandled exception, 502 invalid upstream response, 503 unavailable, 504 upstream timeout

Look up individual codes in HTTP Status Codes, which lists the common 1xx to 5xx responses with plain-language explanations.

#Test long-lived connections separately

A WebSocket handshake rides on HTTP, but it fails for entirely different reasons — HTTP tools will not show you the cause.

The differences that matter:

• The handshake needs an Upgrade header, which an intermediary proxy may strip
• wss:// must pass certificate validation, so a self-signed cert fails outright
• Many gateways do not support long-lived connections and treat the upgrade as a plain HTTP request
• Browsers validate cross-origin WebSocket connections differently from AJAX calls

Use WebSocket Test to connect to a ws:// or wss:// endpoint:

1. Connect to a public echo server first to confirm your network and the tool work
2. Switch to the real target and watch whether the handshake succeeds
3. Send a message and check whether a reply comes back
4. Read the connection log — a socket that closes immediately after opening usually means authentication failed

#Which tool for which job

#Frequently asked questions

#The IP works but the domain does not. Why?

That is a DNS problem. Either the domain does not point at the right address, or a CDN or intermediate resolver is serving a cached answer. Query the A record and its TTL with DNS Lookup and compare it against the real server IP. If you changed the record recently, wait for the TTL to expire.

#Why does a site load on some networks but not others?

Three common causes: the domain has both A and AAAA records but only one family actually works; a CDN resolves to different edge nodes and one is unhealthy; or a local DNS resolver is returning bad answers. Check AAAA first, then compare across networks.

#Is an unreachable port a firewall problem or a dead service?

Check both, but check the service first. On the server, confirm a process is listening on that port (ss or netstat will show it). If something is listening but external connections fail, it is the firewall or security group.

#What is the difference between 502 and 504?

502 Bad Gateway means the reverse proxy received an invalid response from the backend — typically a crashed process or a wrong port. 504 Gateway Timeout means the proxy gave up waiting — typically a slow or stalled backend. The first calls for checking processes, the second for checking performance and timeout settings.

#Why does a WebSocket connection close right after opening?

Usually failed authentication: the server rejects the token or header and closes the connection itself. Less often it is a protocol mismatch, or an intermediary gateway that does not support long-lived connections and treats it as a normal HTTP request. Confirm the network with a public echo server first, then check auth and gateway configuration.