French 
English 
The error on your screen is not one thing. It’s one of two completely different things wearing the same disguise: a blank page with some text on it.
One kind comes from the server, in the form of an HTTP status code, a number the server sends deliberately to describe what happened. The other kind comes from your own browser, and it means the request never got a proper answer at all: no server reached, no code returned, nothing to report except that the attempt itself failed.
Mixing these two up is the single most common reason people troubleshoot the wrong thing. If your browser never reached a server, there’s no application bug to fix. If the server answered with a 500, there’s no local network setting that will help. Knowing which kind you’re looking at tells you where to even start.
The tell: does it have a number, and whose number is it
HTTP status codes are three-digit numbers the server sends back as part of its response: 404, 500, 503, and so on. If you see a number like that on the error page, a server answered your request, which means the server, or something sitting directly in front of it, is reachable and working well enough to respond.
Browser error codes look different. Chrome shows things like ERR_CONNECTION_REFUSED or DNS_PROBE_FINISHED_NXDOMAIN. Firefox tends to skip codes entirely and show plain sentences like “Hmm, we’re having trouble finding that site.” Safari does the same, with messages like “Safari Can’t Find the Server.” These aren’t server responses. They’re your browser telling you it gave up before a server ever entered the picture, whether because the domain didn’t resolve, the connection timed out, or the certificate handshake failed.
That distinction, server responded versus browser gave up, is the whole diagnostic shortcut. A status code means look at the application or the server configuration. A browser error means look at DNS, the network, or the certificate, because the server was never involved.
Browser error codes, decoded
These are the ones you’ll actually run into, across Chrome, Edge, and other Chromium browsers, which show the most explicit codes of the major browsers.
| Error | What actually happened | Where to look |
|---|---|---|
ERR_CONNECTION_REFUSED | A server was found but nothing accepted the connection on that port | Web server stopped, wrong port, firewall dropping it |
ERR_CONNECTION_TIMED_OUT | The request went out and nothing answered in time | Server overloaded or down, network congestion, firewall silently dropping packets |
ERR_CONNECTION_RESET | The connection was established, then abruptly closed | Server crashed mid-response, a proxy or firewall killed the connection |
ERR_NAME_NOT_RESOLVED / DNS_PROBE_FINISHED_NXDOMAIN | The domain name couldn’t be translated to an IP address | Domain expired, DNS records missing or misconfigured, typo in the URL |
ERR_ADDRESS_UNREACHABLE | The IP address exists but there’s no route to it | Network-level routing failure, sometimes a local firewall rule |
ERR_SSL_PROTOCOL_ERROR | The encrypted handshake failed before any page data was exchanged | Misconfigured SSL on the server, an outdated browser, or security software intercepting HTTPS traffic |
NET::ERR_CERT_AUTHORITY_INVALID or similar CERT errors | The certificate presented isn’t trusted | Expired or self-signed certificate, or your device’s clock is wrong |
ERR_TOO_MANY_REDIRECTS | The site is redirecting in a loop | Misconfigured HTTPS redirect, conflicting caching rules, a plugin fighting with server config |
ERR_EMPTY_RESPONSE | The server accepted the connection then sent nothing back | Server process crashed while handling the request |
ERR_INTERNET_DISCONNECTED | Your device has no network connection at all | Local Wi-Fi or ethernet issue, nothing to do with the site |
Firefox and Safari describe most of these same underlying failures in plain language rather than a code: “Secure Connection Failed” covers the same ground as an SSL protocol error, and “This site can’t be reached” is the general-purpose message covering connection refusals, timeouts, and DNS failures alike. We’ve written a full walkthrough of that specific message and what causes it in our guide to the “this site can’t be reached” error, since it’s the single most common browser error people search for by name.
HTTP status codes, briefly
Status codes group into ranges that tell you the category before you even look at the specific number.
2xx means success. You’ll rarely see these as an error, since they mean the request worked, though a 200 with broken or incomplete content on the page is its own quiet problem worth knowing about.
3xx means redirection. The resource moved, and the browser is being told where to go instead. Usually invisible unless the redirect chain breaks or loops.
4xx means the request itself was the problem, from the browser’s side. A 404 means the specific page doesn’t exist. A 403 means access was denied. A 429 means too many requests were sent too quickly. These are not server failures; they’re the server correctly telling you that what was asked for is unavailable or not allowed.
5xx means the server tried to help and failed while doing it. A 500 means the application crashed while handling the request. A 502 means a proxy got an invalid response from whatever sits behind it. A 503 means the server is deliberately refusing, usually overload or maintenance. A 504 means the upstream took too long to answer. These are server-side, and nothing on your end will fix them.
The 502 and 504 pair trips people up constantly because both point at the same layer, the service behind your web server, and differ only in whether that layer answered badly or didn’t answer fast enough. We’ve broken down exactly what a 502 bad gateway means and how to fix it, including how it differs from a 504 timeout. If your site runs behind Cloudflare specifically, the same category of failure shows up as 521, 522, or 523, each pointing at a slightly different point in the connection to your origin server rather than a generic gateway problem.
For the complete numbered list covering every status code in regular use, our full HTTP status code reference is the place to look them up one by one; this piece is about telling the two families apart rather than cataloguing every code in each.
The one that fools everyone: a 200 that isn’t actually fine
Status codes and browser errors both assume something clear either worked or didn’t. The case that slips past both is a 200 status code on a page that’s actually broken: a blank template, a JavaScript error that stops the page rendering, missing content, or a hacked page serving something other than what it should.
Nothing in the address bar tells you this happened. The browser got a successful response and displayed it faithfully; the content is just wrong. Catching this requires checking what’s actually on the page rather than just whether a response came back at all, which is a different kind of monitoring than status codes or connection errors can offer on their own.
Diagnosing from the error alone
A short decision path, working from what you actually see:
If the error has no number and mentions DNS, the site, or “can’t be reached,” start with your own connection. Try the site on mobile data. If it loads there, the problem is local to your device, browser, or network rather than the site itself.
If the error mentions a certificate or “not secure,” check the date and time on your device first, since a wrong clock is a surprisingly common cause, then check whether the issue follows you to a different network.
If you see a 4xx number, the request reached the server and was declined or not found. Check the URL for typos, and know that this isn’t a server health problem.
If you see a 5xx number, the server is reachable but struggling or broken. Before you start debugging, it’s worth confirming the problem isn’t happening to everyone. Running the URL through an independent checker settles that in seconds and points you toward the right fix instead of a guess.
An HTTP error is a status code the server deliberately sends back, meaning the server was reached and responded. A browser error means your browser gave up before getting any response at all, usually because of a DNS failure, a connection timeout, or a certificate problem. If you see a three-digit number, the server answered. If you see a named error like a connection refused message, it never got that far.
Your browser sent a request and never received a response within the allowed time. This can mean the server is overloaded or down, that a firewall along the way is silently dropping the connection rather than rejecting it outright, or that your own network has a routing problem. It’s different from a fast, explicit refusal, which points more specifically at a stopped service.
Usually because that specific site’s SSL certificate has expired, is misconfigured, or was issued in a way your browser doesn’t trust, such as a self-signed certificate. It can also happen if your device’s date and time are wrong, since certificate validity is checked against your system clock, which is worth ruling out before assuming the site itself is at fault.
No. A 404 means the specific page you requested doesn’t exist at that address, while the server itself is working fine and responding normally to other pages. This is different from a 5xx error or a connection failure, both of which indicate a broader problem rather than one missing page.
Because a status code only confirms the server sent a response; it says nothing about whether that response was correct. A 200 can accompany a blank page, a partially loaded layout, or injected content, since the code and the content are generated separately and the browser only checks that a response arrived, not that it’s the right one.
The short version
A number means the server spoke. A named error means it never got the chance to. That single distinction points you at the right fix faster than reading the error message itself usually does.