DEV Community: Baleeghuddin shaikh

ERR_SSL_PROTOCOL_ERROR: What It Means and How to Fix It

Baleeghuddin shaikh — Fri, 06 Nov 2026 13:42:37 +0000

The most useful thing to know about this error is what it is not.

It is not a certificate problem. Expired certificates, name mismatches and untrusted issuers all produce a different family of errors — the ones beginning NET::ERR_CERT_ — and every one of those means the connection got far enough for the browser to examine a certificate and reject it.

ERR_SSL_PROTOCOL_ERROR means it never got that far. The two sides could not agree on how to speak TLS at all, so no certificate was ever evaluated.

That single distinction eliminates most of what people try first. Reissuing the certificate will not help, because the certificate was never the problem.

Where you will see it

Chrome and Edge:

This site can't provide a secure connection
example.com sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

Firefox words the same failure differently:

Secure Connection Failed
SSL_ERROR_RX_RECORD_TOO_LONG

curl:

curl: (35) error:0A00010B:SSL routines::wrong version number

Those last two are worth memorising. wrong version number and SSL_ERROR_RX_RECORD_TOO_LONG almost always mean one specific thing, and it is the first cause below.

What actually causes it

The server is not speaking TLS on that port

The most common cause, and the easiest to miss.

If a server is configured to serve plain HTTP on port 443, the browser opens a TLS handshake and receives an HTTP response instead. It has no idea what to do with that, so it reports a protocol error.

That is exactly what wrong version number is telling you: the bytes that came back were not TLS at all.

Typical when a virtual host was set up on 443 without SSL enabled, when a reverse proxy forwards to a backend expecting HTTP, or when a site has just moved and the SSL configuration did not come with it.

TLS version mismatch

Browsers removed support for TLS 1.0 and 1.1 in 2020. A server that still offers only those protocols can no longer negotiate with any current browser.

The symptom is distinctive: the site works in an old browser, on an old phone, or from a tool that still permits legacy protocols, and fails everywhere modern. Nothing on the server changed — the browsers did.

The same happens in reverse on hardened servers configured for TLS 1.3 only, when something old tries to connect.

No shared cipher suite

The two sides support overlapping TLS versions but no common cipher. Chrome has its own error for this — ERR_SSL_VERSION_OR_CIPHER_MISMATCH — but a protocol error can surface for the same underlying reason depending on where negotiation breaks.

Usually a server configured with a restrictive cipher list, often copied from a hardening guide written years earlier.

Something is intercepting the connection

Antivirus products with HTTPS scanning, corporate proxies and some VPN clients insert themselves into TLS connections by design. When that interception is misconfigured or outdated, the result is a protocol error.

The giveaway: the site fails on one machine and works on every other device on the same network.

How to diagnose it

1. Try another device on the same network

Works elsewhere → the problem is on that one machine. Antivirus, a browser extension, or the browser's own TLS state.

Fails everywhere → the problem is the server.

Thirty seconds, and it splits the problem in half. Do it first.

2. Ask the server directly what it supports

openssl s_client -connect example.com:443 -servername example.com

Read the reply:

wrong version number → the server is not serving TLS on 443
A handshake that completes, showing a protocol and cipher → the server is fine and your client is the problem
no protocols available or an immediate close → version or cipher mismatch

3. Pin down which TLS versions work

openssl s_client -tls1_2 -connect example.com:443 -servername example.com
openssl s_client -tls1_3 -connect example.com:443 -servername example.com

If 1.2 fails and 1.3 succeeds — or the reverse — you have found the mismatch, and the fix is in the server's protocol configuration.

4. Confirm the port is actually open

If nothing answers at all, you do not have a TLS problem — you have a connectivity problem wearing a TLS error.

How to fix it

If it is only your machine:

Disable HTTPS scanning in your antivirus temporarily and retest
Try an incognito window to rule out extensions
Clear the browser's SSL state — chrome://net-internals/#hsts can hold stale entries for a specific domain
Test in a different browser. Chrome failing where Firefox works points at Chrome's own state

If it is the server:

Confirm SSL is actually enabled on the listening block for 443 — this resolves the wrong version number case outright
Enable TLS 1.2 alongside 1.3. Serving only 1.3 excludes a meaningful share of clients; serving only 1.0 or 1.1 excludes every current browser
Review the cipher list, especially if it was copied from an old hardening guide
Verify the certificate and private key are a matching pair, and that the configuration was actually reloaded

How it differs from the other SSL errors

ERR_SSL_PROTOCOL_ERROR — the handshake failed. No certificate was examined.

NET::ERR_CERT_DATE_INVALID, ERR_CERT_AUTHORITY_INVALID, ERR_CERT_COMMON_NAME_INVALID — the handshake succeeded and a certificate was presented, then rejected.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH — same family as a protocol error, but Chrome has identified the specific reason. Treat it as a protocol error with a head start.

ERR_CONNECTION_RESET on port 443 — not TLS at all. Something closed the TCP connection before TLS began, usually a firewall.

The practical rule: a CERT error is about the certificate. Everything else is about whether a TLS conversation could happen in the first place.

One thing worth knowing

An expired certificate does not cause this. That produces NET::ERR_CERT_DATE_INVALID, and the browser offers a bypass option.

A protocol error has no bypass — there is nothing to bypass, because no secure channel was ever established.

The short version

Test another device first: if the site works there, the fault is on your machine, usually antivirus HTTPS scanning. If it fails everywhere, run openssl s_client — wrong version number means the server is serving plain HTTP on 443, and a handshake that completes means the server is fine and your client is not.

If you want to check what a server is actually presenting from outside your own network — chain, covered names, expiry — I keep a free checker at webtoolsrealm.com/tool/ssl-checker. Full disclosure, that's my own site.

Originally published at webtoolsrealm.com

SERVFAIL: What It Means and How to Diagnose It

Baleeghuddin shaikh — Tue, 03 Nov 2026 17:59:42 +0000

SERVFAIL is a DNS response code, and it is the least specific one you can get:

The resolver tried to answer your query and could not produce a valid result.

That is deliberately vague, because SERVFAIL covers everything from a broken cryptographic signature to a name server that is simply switched off. The domain probably exists. Something between you and the authoritative answer went wrong.

This makes it harder to diagnose than NXDOMAIN — but there is one command that splits the possibilities in half immediately, and most explanations never mention it.

Where you will see it

dig example.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18442

nslookup example.com
** server can't find example.com: SERVFAIL

host example.com
Host example.com not found: 2(SERVFAIL)

That 2 is the numeric code. NXDOMAIN is 3, SERVFAIL is 2, NOERROR is 0.

In browsers it usually surfaces as DNS_PROBE_FINISHED_NXDOMAIN or ERR_NAME_NOT_RESOLVED — browsers collapse DNS failures into one message, which is exactly why people end up diagnosing the wrong problem. The browser text does not tell you which response code came back. Only a direct query does.

The one command that narrows it immediately

dig +cd example.com

+cd means checking disabled — it tells the resolver to skip DNSSEC validation and hand you whatever it gets.

Works with +cd, fails without it → DNSSEC validation failure. The data is there; the signatures do not check out
Fails both ways → the resolver genuinely cannot reach or get a usable answer from the authoritative name servers

That one comparison eliminates roughly half the possible causes. Do it before anything else.

What actually causes it

DNSSEC validation failure

The most common cause on domains that were working yesterday.

DNSSEC signs DNS records cryptographically. If the chain breaks — an expired signature, a DS record at the registry that no longer matches the zone's key, a key rotation done incorrectly, or DNSSEC left enabled after moving to a provider that does not sign — validating resolvers refuse to serve the answer at all.

Refusing is correct behaviour: the alternative is serving data that may have been tampered with.

Those signatures carry expiry dates, so a zone that stops being re-signed breaks at a predictable moment without anyone touching anything. A domain that "broke overnight with no changes" is very often this.

Non-validating resolvers still answer normally, which is why the domain works for some people and not others.

The authoritative name servers are unreachable

Nothing exotic — servers down, host offline, or a firewall blocking port 53. The resolver asked, nothing usable came back.

Lame delegation

The parent zone points at name servers that do not host the zone. They are reachable and they respond — they just have no authoritative data for this domain.

Happens after a migration where name servers were changed at one end but not the other, or where a hosting account was closed while the registrar still points at it.

Inconsistent name servers

A domain lists four name servers; two have the zone, two do not, or they hold different versions. Resolvers pick whichever they like, so the domain resolves intermittently — with no pattern anyone can reproduce.

Query each one individually and compare. If they disagree, you have found it.

EDNS and packet size

DNSSEC-signed responses regularly exceed the 512-byte limit of classic DNS. Some firewalls and older middleboxes drop oversized UDP responses or block fragments outright.

Symptom: small queries work, large ones fail.

dig +bufsize=512 example.com

Succeeds where the default fails → packet size, not DNS data.

SERVFAIL vs NXDOMAIN

They point in opposite directions, and treating one as the other wastes hours.

SERVFAIL — no usable answer arrived. The domain probably exists. The problem is DNSSEC, the name servers, or the path to them.

NXDOMAIN — an authoritative server answered, and the answer was that the name does not exist. The problem is the name itself.

The rule: NXDOMAIN is an answer you should believe. SERVFAIL means try again, against a different resolver, and look at the infrastructure.

How to diagnose it, in order

1. dig +cd. DNSSEC or not. Halves the problem.

2. Try different resolvers.

dig example.com @1.1.1.1
dig example.com @8.8.8.8
dig example.com @9.9.9.9

Some answer and others do not → almost certainly DNSSEC. Cloudflare, Google and Quad9 all validate, but they cache independently, and a resolver holding a pre-breakage answer keeps serving it until that entry expires.

3. Query each delegated name server.

dig NS example.com
dig example.com @ns1.provider.com
dig example.com @ns2.provider.com

All should agree. Any that times out, refuses, or disagrees is the fault.

4. Trace from the root.

dig +trace example.com

Walks root → TLD → authoritative, showing exactly which step fails. Fastest way to spot a lame delegation.

5. Check what the registry actually has. If the registry's name servers do not match the ones you expect, the delegation was never updated. A DNS lookup from outside your own network shows the delegation as the rest of the internet sees it — full disclosure, that's a free tool I built, and the reason it helps here is that it removes your own resolver's cache from the picture.

If it is DNSSEC

Two options, depending on whether you control the zone.

Fix the chain. Re-sign the zone, or correct the DS record at the registrar so it matches the key the zone actually publishes. This is the proper fix.

Remove DNSSEC. Delete the DS record at the registrar, wait for it to expire from caches, and the domain resolves again unsigned. This is the usual emergency measure, and it removes the protection entirely.

What you cannot do is tell other people's resolvers to ignore the problem. Validation failing is them doing their job.

The short version

SERVFAIL means no usable answer arrived, not that the name is missing — the opposite of NXDOMAIN, which is why people troubleshoot the wrong thing.

Start with dig +cd: if that works and a normal query does not, it is DNSSEC, and the fix is the DS record rather than anything in the zone. If both fail, query each delegated name server individually — one that times out, refuses, or disagrees with the others is your answer.

Originally published at webtoolsrealm.com

Connection Refused vs Connection Timed Out: What Each Error Actually Means

Baleeghuddin shaikh — Sun, 18 Oct 2026 06:16:10 +0000

Two of the most common networking errors look identical from the outside — in both cases you can't reach the server. But they're opposites, and knowing which one you're looking at narrows the cause from dozens of possibilities to two or three.

Connection refused means something answered you and said no.
Connection timed out means nothing answered at all.

What's actually happening

Every TCP connection starts with a three-step handshake. You send SYN. The server replies SYN-ACK. You send ACK. Connection established.

What you see when that fails depends on where it broke:

Server sends back an RST packet → connection refused
Nothing comes back at all, and your machine eventually gives up → connection timed out

An RST is an active reply. Your packet reached a real machine, that machine processed it, and it deliberately rejected you. A timeout means your packet vanished somewhere and no reply ever arrived.

Connection refused

ERR_CONNECTION_REFUSED
curl: (7) Failed to connect to example.com port 443: Connection refused
ssh: connect to host 203.0.113.5 port 22: Connection refused

What causes it

Nothing is listening on that port. By far the most common cause. The host is up and reachable, but nothing is bound to the port you asked for. The service crashed, never started, or you're hitting the wrong port.

The service is bound to the wrong interface. A service listening on 127.0.0.1 accepts connections only from the machine itself. From anywhere else they get refused. To accept outside traffic it needs 0.0.0.0 or the server's actual IP.

This one catches everyone during development. Works perfectly on localhost, fails the moment someone else tries.

A firewall set to REJECT rather than DROP. Firewalls dispose of unwanted packets two ways. REJECT sends back an RST → refused. DROP silently discards → timeout. Most server firewalls use DROP; many consumer routers and corporate appliances use REJECT.

How to check

ss -tlnp        # what's listening, and which process owns it

If your port isn't in that list, nothing is running. If it shows 127.0.0.1:3306 rather than 0.0.0.0:3306, you've found the bind-address problem.

Connection timed out

ERR_CONNECTION_TIMED_OUT
curl: (28) Failed to connect to example.com port 443 after 130000 ms
ssh: connect to host 203.0.113.5 port 22: Operation timed out

What causes it

A firewall silently dropping your packets. The most common cause by a wide margin. Security groups on AWS, firewall rules on GCP, NSGs on Azure. Your packet arrives, the rule matches, the packet is discarded, nothing is sent back.

Missing or misconfigured port forwarding. When the service sits behind NAT, traffic hitting the public IP has to be forwarded inward. Without that rule, packets reach the router and stop.

The host isn't reachable at all. Powered off, or the IP no longer points at it. A dynamic IP that changed overnight is a common culprit — and if that IP was in a whitelist somewhere, the whitelist now points at a stranger.

Your ISP blocks the port. Residential providers routinely block outbound 25 (SMTP), and sometimes 80, 443 and 445. The block is silent, so it shows up as a timeout rather than a refusal.

The shortcut

Fails fast → refused → the host is alive, the service is the problem
Fails slow (20–130 seconds) → dropped → a firewall, NAT rule or route is the problem

If you remember nothing else from this post, remember that. The speed of the failure tells you which half of the stack to stop looking at, before you even read the error text.

Common ports, common causes

Port 22 (SSH)
Refused usually means sshd isn't running, or it's listening on a non-standard port. Timed out usually means a security group never allowed your IP.

Port 25 (SMTP)
Refused means no MTA is listening. Timed out from a home connection is almost always your ISP blocking outbound mail — use port 587 with authentication instead.

Ports 80 and 443 (HTTP / HTTPS)
Refused means the web server is down. Timed out means a firewall never let you near it.

Ports 3306 (MySQL) and 5432 (PostgreSQL)
Refused is nearly always the bind address, since both ship listening on localhost only. Timed out means a firewall, or the database was never exposed.

Port 3389 (RDP)
Refused means the service is disabled. Timed out is usually the Windows Firewall profile, which blocks by default on public networks.

A practical order of checks

Note whether the failure was fast or slow — this alone splits the problem in half
Confirm DNS resolves to the IP you expect. If it doesn't, you're timing out against the wrong machine entirely
Ping the host, keeping in mind many servers block ICMP, so silence here isn't conclusive
Test the specific port from outside your own network — testing from the server bypasses every firewall between you and it
If the port opens but the site still fails, the network layer is fine. Move up to the application

For step 4 I use an online port checker — full disclosure, that's a free tool I built — since the whole point is testing the path a real visitor takes, not the path from your own machine. A ping test covers step 3 the same way.

FAQ

Why does refused happen instantly but timeout take 30 seconds?
A refusal is an active reply, so the RST comes back at network speed. A timeout is the absence of a reply, so your system waits out a timer — typically 20 to 130 seconds depending on the OS and client.

Does connection refused mean the server is down?
Usually the opposite. Something on that machine was awake enough to reject you. The host is up; the specific service isn't listening on that specific port.

Why does it work locally but not from outside?
Almost always bind address or firewall. Test externally, not from the server.

Originally published at webtoolsrealm.com