ERR_SSL_PROTOCOL_ERROR: what it means and how to fix it

What ERR_SSL_PROTOCOL_ERROR means

A TLS connection starts with a handshake: the client sends a ClientHello listing the protocol versions and cipher suites it supports, and the server is supposed to answer with a ServerHello choosing one of them, followed by its certificate. ERR_SSL_PROTOCOL_ERROR fires when that exchange breaks down before the certificate step is reached, most often because whatever answered on the port was not speaking TLS at all, or the two sides could not agree on how to speak it. This is Chrome's single highest-traffic error-code search term, and the volume reflects how many different root causes collapse into the same generic message rather than one common failure.

How the error appears

Chrome and Edge show ERR_SSL_PROTOCOL_ERROR with no certificate details, because no certificate was ever presented to show. Firefox typically shows "Secure Connection Failed" with a code such as SSL_ERROR_RX_MALFORMED_HANDSHAKE or SSL_ERROR_PROTOCOL_VERSION_ALERT depending on how the handshake broke.

From the command line, both curl and openssl identify the failure precisely, which is the fastest way to move past a guess:

curl -v https://example.com/
...
* TLSv1.3 (OUT), TLS handshake, Client hello
* OpenSSL/3.x: error:0A000126:SSL routines::unexpected eof while reading
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL

openssl s_client -connect example.com:443 -servername example.com
...
140... error:1408F10B:SSL routines:ssl3_get_record:wrong version number

"Wrong version number" almost always means port 443 answered with plain HTTP, not TLS, since the first bytes of an HTTP response look like garbage to a TLS parser expecting a ServerHello. A connection that hangs and times out with no error at all, rather than failing fast, usually means a firewall or proxy is silently dropping packets instead of the server actively refusing them.

What causes ERR_SSL_PROTOCOL_ERROR

• Port 443 is serving plain HTTP, or the wrong service entirely. A misconfigured reverse proxy, a crashed service that left a fallback listener behind, or a NAT rule pointing at the wrong backend all produce a non-TLS response on the TLS port.
• TLS version or cipher mismatch. A server locked to TLS 1.0 or 1.1 for legacy compliance shares no common protocol with a browser that requires TLS 1.2 or higher, so the handshake fails outright.
• Server Name Indication (SNI) is missing or misconfigured. On a server hosting several certificates on one IP, a missing SNI match can make it present the wrong certificate or refuse the handshake.
• QUIC and HTTP/3 experiments. Chrome sometimes tries QUIC first and falls back to TLS over TCP; a network that mishandles QUIC's UDP traffic can surface as a protocol error on the fallback attempt.
• Antivirus or corporate proxy HTTPS scanning. Software that intercepts TLS to inspect traffic starts its own handshake in place of the real one, and a broken interception certificate breaks that substitute.
• HSTS forcing HTTPS onto a host whose TLS is broken. Once a browser has cached an HSTS policy for a domain, it will not attempt plain HTTP, so a host that used to fall back gracefully now hard-fails instead.
• An old or broken certificate chain, on an old client. Very old operating systems and browsers that predate a newer root or intermediate can fail the handshake in ways indistinguishable from a version mismatch.
• The client's clock is badly wrong. A clock far enough off can make a client refuse to negotiate a session at all, not just reject the certificate afterward.

How to tell whose fault it is

Run the same request from a second network, for example a phone on mobile data instead of the office Wi-Fi. If the site loads cleanly there, the problem is local: a corporate proxy, antivirus interception, or a captive portal on the first network. If the handshake fails identically everywhere you try it, the server's TLS configuration is the cause. An SSL check run from several locations at once answers this in a single request instead of borrowing a second device, and it reports the exact protocol and cipher the server negotiated (or refused) from each vantage point.

How to fix ERR_SSL_PROTOCOL_ERROR

If you are a visitor

1. Clear Chrome's TLS state at chrome://net-internals/#hsts and chrome://restart, or simply clear browsing data for "cached images and files" plus "cookies and site data" for the affected site, which also clears cached HSTS and SSL session state.
2. Disable the QUIC experiment at chrome://flags/#enable-quic, set it to Disabled, and restart the browser. If the site loads afterward, a QUIC-unfriendly network or proxy was the cause.
3. Check the system date and time and set it to sync automatically; a clock far enough off can break the handshake outright, not just the certificate check that comes after it.
4. Turn off HTTPS scanning in your antivirus (commonly under a "web protection" or "SSL/TLS scanning" setting) and retry. If that fixes it, either update the antivirus or add the site to its exclusion list rather than leaving scanning off entirely.
5. Try another network, such as mobile data. A corporate proxy or a broken piece of network hardware that only affects one connection is a common cause that has nothing to do with the site itself.

If you run the site

1. Confirm port 443 is actually TLS with the openssl command above. "Wrong version number" or a plain-text response means the wrong service is bound to that port; fix the proxy or listener configuration before touching certificates at all.
2. Set explicit supported protocol versions. On nginx:

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers HIGH:!aNULL:!MD5;

   Dropping TLS 1.0 and 1.1 fixes modern-client handshakes but will break access from very old clients still relying on them; decide that trade-off deliberately rather than by accident.
3. Confirm the server block is actually listening for TLS on the port you expect: listen 443 ssl; (or listen 443 ssl http2;) and that the certificate and key directives point at files that exist and match each other.
4. Check the certificate chain order. The leaf certificate must come first, followed by intermediates in order up to (but not including) the root; a chain served out of order or missing an intermediate causes handshake failures on some clients while working on others that cache the missing intermediate elsewhere.
5. If the domain sits behind Cloudflare, check the SSL/TLS mode. Flexible mode terminates TLS at the edge and talks plain HTTP to the origin, which fails outright if the origin only accepts HTTPS; Full mode requires any certificate at the origin; Full (strict) requires a valid, trusted certificate at the origin and will itself produce handshake failures if the origin certificate is self-signed or expired.
6. Reload, do not just edit, after any configuration change: nginx -t && systemctl reload nginx validates the config before applying it.

ERR_SSL_PROTOCOL_ERROR versus similar-looking errors

• ERR_CERT_DATE_INVALID happens after a certificate was received and read; the handshake got that far and then failed a date comparison. ERR_SSL_PROTOCOL_ERROR never gets that far at all.
• ERR_CERT_AUTHORITY_INVALID also happens after a certificate was received; the browser read it and did not trust whoever signed it. Again, a protocol error means no certificate was ever judged.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH is the more specific sibling of this error: it fires when the handshake did proceed far enough to compare supported versions and ciphers, and found no overlap at all, typically an old server offering only SSLv3 or TLS 1.0 against a modern browser that refuses them. ERR_SSL_PROTOCOL_ERROR is the broader, less specific failure that covers everything else, including a non-TLS response on the port, malformed handshake data, and interception software gone wrong.

How to prevent ERR_SSL_PROTOCOL_ERROR

A handshake failure introduced by a config change, a proxy update, or a Cloudflare SSL mode flip does not show up in a normal HTTP status check, since the connection never gets far enough to produce one. A dedicated SSL check reads the negotiated protocol and cipher directly and, run from 300+ checkpoints in 158 cities, shows whether the handshake fails everywhere or only from one network, the same split this guide walks through by hand. Run an SSL certificate check against the domain, and set up ongoing SSL and domain expiry monitoring so a broken handshake alerts before visitors report it.

Frequently asked questions

Does ERR_SSL_PROTOCOL_ERROR mean my certificate is bad?

Not necessarily. The error fires before the browser reaches the certificate, so the certificate itself may be completely fine while the underlying TLS negotiation still fails.

Why does this only happen on one computer or one network?

Antivirus HTTPS scanning, a corporate proxy, or a broken QUIC path on that specific network are the usual reasons a handshake fails in one place and succeeds everywhere else. Testing from a second network is the fastest way to confirm it.

I just moved my site behind Cloudflare and now visitors see this. What changed?

Check the SSL/TLS mode in the dashboard. Flexible mode expects the origin to accept plain HTTP and fails if it only serves HTTPS; Full (strict) expects a valid, trusted origin certificate and fails on a self-signed or expired one.

Does disabling TLS 1.0 and 1.1 on my server break anything?

It can, for visitors on very old browsers that never got a TLS 1.2 update. For most current traffic it fixes more handshakes than it breaks, but check your own client mix first.

Why did curl say "wrong version number"?

That message means curl sent a TLS ClientHello and got back bytes that do not parse as a TLS ServerHello, almost always because the port is serving plain HTTP or another non-TLS protocol.