Website error codes explained

DNS resolved and the browser tried to open a TCP connection, but nothing answered before the timeout. The server is unreachable, overloaded, or a firewall is dropping the packets silently.

Something answered the connection attempt and rejected it outright. That means the host is reachable but nothing is listening on that port — the web server is stopped, bound to the wrong interface, or on a different port.

The connection was established and then abruptly torn down before the response finished. Usually a crashing worker process, a proxy timing out, or middleware killing the connection.

The browser's connection was closed before it received a complete HTTP response. This can involve the origin, a proxy, a load balancer, or network infrastructure; connection reuse and timeout settings are common areas to investigate.

The connection succeeded and then the server returned zero bytes. Typically a fatal application error that killed the process before any headers were written, or a protocol mismatch on the port.

Two rules are bouncing the request back and forth — most often an HTTPS redirect at the application level fighting a proxy that is forwarding as plain HTTP, so each side thinks the other needs to upgrade.

DNS returned an address and the network has no route to it. Common when a DNS record points at a private, retired, or IPv6 address the client cannot reach.

The device switched networks mid-request — Wi-Fi to mobile, a VPN connecting, or an IP address changing. Almost always a client-side condition, not a server fault.

Chrome has no usable network route at all. This is a client-side state; no server configuration produces it.

The browser itself refused to send the request because an extension — usually an ad or tracker blocker — matched it against a block list. The server was never contacted.

The browser ended an HTTP/2 stream after detecting a protocol problem. Large response headers and incompatible HTTP/2 handling at an origin, CDN, proxy or WAF are common leads, but the failing hop needs to be identified before changing configuration.

The browser tried HTTP/3 over QUIC and the connection failed. Often a network path that mishandles UDP, or a CDN advertising HTTP/3 support it cannot deliver on that route.

Chrome tried to start an encrypted connection and the server answered with something that is not valid TLS. In almost every case the server is offering a protocol version or cipher the browser refuses, the certificate is broken, or something on the network is intercepting the handshake.

The certificate the server presented is outside its validity window — almost always expired. Either the certificate genuinely lapsed, or the device's clock is wrong so a valid certificate looks expired.

The browser could not build a trust path from the certificate the server sent to a root it trusts. Usually the server is serving only the leaf certificate without its intermediates, or the certificate is self-signed.

The certificate is valid and trusted, but it was issued for a different hostname than the one in the address bar. The classic case is a certificate covering example.com being served for www.example.com.

The browser and server have no protocol version or cipher suite in common, so the handshake ends before it starts. Almost always an origin still pinned to TLS 1.0/1.1 or an ancient cipher list.

A warning rather than a hard failure: the connection succeeded but negotiated TLS 1.0 or 1.1, which browsers flag as obsolete and will eventually refuse outright.

A generic handshake failure reported by servers, CDNs and API clients rather than browsers. The connection reached the server but the TLS negotiation aborted — protocol mismatch, certificate rejection, or a required client certificate.

Chrome's full-page warning shown whenever certificate validation fails. It is not a single error — the real cause is the NET::ERR_CERT_* code printed underneath it, and that code tells you which of expiry, trust, or hostname is wrong.

The CA has explicitly revoked this certificate — usually because the private key was compromised, the certificate was reissued, or the domain validation was withdrawn. Renewing is not enough; the revoked certificate must stop being served.

The server asked for a client certificate during the handshake and rejected the one presented — or none was available. This is mutual TLS, and it fails closed by design.

The DNS lookup completed and the authoritative answer was 'this name does not exist'. Either the record is genuinely missing, the domain lapsed, or a recent DNS change has not propagated to the resolver you are using.

Chrome could not turn the hostname into an IP address. Closely related to NXDOMAIN but broader: it also covers resolver failures and timeouts, not just definitive 'does not exist' answers.

A transient state Chrome shows while it retries a failed lookup with its own probe. If it sticks, the resolver is not answering at all — this usually resolves into NXDOMAIN or a resolver-unreachable failure.

The probe finished and concluded the device's DNS configuration itself is broken — a bad resolver address, a corrupted network profile, or conflicting settings from a VPN.

The DNS probe could not reach any resolver because there is no working route to the internet. The domain is irrelevant here — connectivity is the problem.

The human-readable wrapper Chrome shows around a DNS failure. The technical code underneath — usually DNS_PROBE_FINISHED_NXDOMAIN or ERR_NAME_NOT_RESOLVED — is the one that tells you which fix applies.

Cloudflare reached your origin and got back a response it could not interpret — an empty reply, a malformed header, or a connection dropped mid-response. The origin is up but misbehaving.

Cloudflare's connection to the origin was refused. The origin either has nothing listening on the expected port, or its firewall is rejecting Cloudflare's IP ranges.

Cloudflare tried to open a connection to the origin and nothing answered before the timeout. Usually a firewall silently dropping Cloudflare's traffic, an overloaded origin, or a wrong origin IP.

Cloudflare could not route to the origin at all. Typically the DNS record points at an invalid or unroutable IP, or the origin's network route has been withdrawn.

Cloudflare connected to the origin successfully, but the origin took longer than 100 seconds to send a complete response. The request is too slow, not unreachable.

Cloudflare reached the origin on port 443 but could not complete a TLS handshake. Check the origin certificate, protocol and cipher support, hostname/SNI configuration, and origin-side logs.

Cloudflare completed the handshake with the origin but refused its certificate — expired, self-signed, or not matching the hostname — because the SSL mode is Full (Strict).

A Cloudflare rate-limiting rule matched the request. Either the client genuinely exceeded a limit, or a rule is scoped too broadly and is catching normal traffic.

A Cloudflare WAF or firewall rule blocked the request. The origin never received it. The Security Events log names the exact rule that fired.

WordPress loaded but could not connect to MySQL. Either the credentials in wp-config.php are wrong, the database server is down, or connections are exhausted under load.

PHP hit a fatal error with display_errors off, so the page rendered as blank white with an HTTP 200 or 500. Nothing is visibly broken to a status-only monitor, which is what makes it dangerous.