---
title: "How to Fix err_ssl_protocol_error in Chrome and Edge"
description: "err_ssl_protocol_error means Chrome or Edge reached the site, but the secure handshake failed. How to tell if your device, network or the site is to blame."
url: https://proxynet.io/blog/err-ssl-protocol-error
date: 2026-10-05
author: "Acar Diveroli"
category: "Tutorial"
lang: en
---

# How to Fix err_ssl_protocol_error in Chrome and Edge

You click a link to an online shop, and Chrome shows a plain grey page instead: "This site can't provide a secure connection", the line "shop.example sent an invalid response.", a suggestion to try Windows Network Diagnostics and, at the bottom, `ERR_SSL_PROTOCOL_ERROR`. Reloading brings the same page back, and Edge shows the same code.

The shop may well be broken, but just as often something on your computer or network got in the way. This guide explains what the code means and where in the secure handshake it appears, the causes we rebuilt on test servers, the fixes in the order worth trying, what to check if the site is yours, and where proxies and VPNs fit in.

> **Note: Short answer**
>
> `ERR_SSL_PROTOCOL_ERROR` means the browser reached the site's server, but the TLS handshake, the opening exchange that sets up an encrypted connection, failed because the reply was not valid. If one site fails on every device and network, that site is misconfigured, often serving plain HTTP on its secure port, and only its owner can fix it. If many sites fail on one computer or network, try an Incognito window, turn off extensions, VPN and filtering apps, pause your antivirus's HTTPS scanning for one reload and update the browser. On `localhost` or your router's address, type `http://` instead. The page offers no way to continue, and you should not look for one.

## What does ERR_SSL_PROTOCOL_ERROR mean?

Sites whose address starts with `https://` use TLS (Transport Layer Security), the encryption behind the padlock; its older name, SSL, lives on in error codes like this one. Before any page travels, the browser and the server run a short handshake: they agree on a TLS version and an encryption method, the server proves its identity, and both sides create the keys. The TLS 1.3 standard, [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446.html), says a failed handshake ends the connection.

Chromium's [list of network errors](https://github.com/chromium/chromium/blob/main/net/base/net_error_list.h), the source code behind Chrome and Edge, describes error -107 in five words: "An SSL protocol error occurred." The [code that converts TLS failures](https://github.com/chromium/chromium/blob/main/net/ssl/openssl_ssl_util.cc) into these numbers explains the vagueness: any handshake failure without a more specific code ends up as -107. The code says the handshake broke, not who broke it.

It is also not a certificate warning. "Your connection is not private" and codes starting with `NET::ERR_CERT_` come later, when the browser judges the site's certificate; here the handshake stopped before that point. Certificate problems are covered in [Your Connection Is Not Private](/blog/your-connection-is-not-private).

## What does the error page tell you?

| Line on the screen | What it means |
|---|---|
| "This site can't provide a secure connection" | Chrome's heading for handshake failures |
| "example.com sent an invalid response." | The answer to the browser's first message was not valid TLS. Chrome names the site but cannot tell whether the site or a device in between sent it |
| "Try running Windows Network Diagnostics." | A link to the system troubleshooter; the server did answer, so it rarely finds anything |
| `ERR_SSL_PROTOCOL_ERROR` and **Reload** | The code, and a button that simply tries again |

We checked these lines against Chromium's text files and saw them on screen in Chromium 145 on Windows 11; on a Mac the link says "Network Diagnostics". Edge is built on Chromium and shows the same code, though its wording may differ. Unlike a certificate warning, the page has no **Advanced** button, because no secure connection exists to continue on.

## Where in the handshake does it break?

A secure page load passes these stops in a fraction of a second:

1. **Connection.** The browser connects to the server, usually on port 443, the standard port for secure sites. If this fails, you see "This site can't be reached" instead ([This Site Can't Be Reached](/blog/this-site-cant-be-reached)).
2. **Client Hello.** The browser lists the TLS versions and encryption methods it supports and names the site it wants.
3. **Server Hello.** The server picks one version and one method. Most cases in this guide break here: the browser receives something it cannot read as TLS, such as an ordinary web page, a block page or scrambled bytes. Section 5 of RFC 8446 requires TLS software to end the connection when such an unexpected message arrives.
4. **Certificate.** The server sends its certificate. A failure here produces a certificate warning instead.
5. **Finished.** Both sides confirm the keys, the padlock appears and the page request goes out.

If browser and server share no TLS version at stop 3, typically because the server offers only TLS 1.0 or 1.1, the heading stays the same but the code becomes `ERR_SSL_VERSION_OR_CIPHER_MISMATCH`.

## What causes ERR_SSL_PROTOCOL_ERROR?

| Cause | Who sees it | Who can fix it |
|---|---|---|
| The site serves plain HTTP on its secure port | Everyone, on every device | The site owner |
| `https://` typed for a device or test server that only speaks HTTP | Only that address | You: use `http://` for your own device |
| Antivirus that scans encrypted traffic fails | Many sites, one computer | You: update or reconfigure it |
| A VPN, ad-blocking or "protection" app that filters traffic | Many sites, one device | You: turn it off to test |
| A network filter answers with its own unencrypted page | Blocked sites, the whole network | The network's administrator |
| A browser extension that handles traffic | One browser | You: turn it off |

We rebuilt the main cases with small test servers on our own computer. In Chromium 145, a server speaking plain HTTP on its secure port and a server answering the Client Hello with junk bytes both produced `ERR_SSL_PROTOCOL_ERROR`. A server limited to TLS 1.0 and 1.1 produced `ERR_SSL_VERSION_OR_CIPHER_MISMATCH`, and a connection cut mid-handshake produced `ERR_CONNECTION_CLOSED` or `ERR_CONNECTION_RESET`.

## Is the problem on your side or the site's?

1. **Open two or three other secure sites.** If they fail too, the cause is your device or network.
2. **Open the failing site on your phone with Wi-Fi off.** If it fails on mobile data as well, the site is broken; wait or tell its owner.
3. **If it works on mobile data, try another device on your Wi-Fi.** A second failure points to the network; a success points to software on your computer.
4. **Open an Incognito window** with **More > New Incognito window** in Chrome. Extensions run there only if you allowed them, so a page that loads in Incognito points to an extension.

## How do you fix it on a computer?

Reload the page after each step.

1. **Turn off extensions.** In Chrome, select **More > Extensions > Manage extensions** at the top right and switch off VPN, proxy, ad-blocking and "security" extensions ([Google's steps](https://support.google.com/chrome/answer/2664769?hl=en)). In Edge, select **Extensions** to the right of the address bar, then **Manage extensions**, and use the toggle next to each one ([Microsoft's steps](https://support.microsoft.com/en-us/microsoft-edge/add-turn-off-or-remove-extensions-in-microsoft-edge-9c0ec68c-2fbc-2f2c-9ff0-bdc76f46b026)). If the error disappears, turn them back on one at a time.
2. **Test your security software.** Programs with HTTPS scanning, SSL scanning or web protection place themselves in the middle of every handshake. Pause only that feature, reload once, then switch it back on. If the pause helped, update the program or contact its support instead of leaving protection off.
3. **Switch off VPN and filtering apps,** including apps that block ads by routing traffic through themselves. Check that no forgotten proxy is set in Windows: [How to Remove a Proxy from Chrome and Windows](/blog/remove-proxy-chrome-windows).
4. **Update the browser.** In Chrome, select **More > Help > About Google Chrome**, then **Relaunch** if it appears ([Google's steps](https://support.google.com/chrome/answer/95414?hl=en)). In Edge, select **Settings and more > Help and feedback > About Microsoft Edge**, or type `edge://settings/help` in the address bar. Security software must understand the handshake the browser sends, so a large version gap between the two can break inspection.
5. **Close the browser completely and reopen it.** Chrome and Edge keep recent handshake details in memory; a full restart wipes them.

## Why does it appear only on one network?

Schools, offices, hotels, parental-control routers and some internet providers filter websites. When a filter blocks a secure site by answering in its place with an ordinary, unencrypted page, the browser receives a web page where it expected a Server Hello, the same situation our plain-HTTP test server created.

On a work or school network, ask the IT team; the block is the network owner's decision, not a fault. How organisations inspect encrypted traffic is explained in [What Is Deep Packet Inspection?](/blog/what-is-deep-packet-inspection).

## Why does localhost or a router page show it?

A development server on your computer listens on, say, `http://localhost:3000`, but the browser opens `https://localhost:3000`. The server answers the Client Hello in plain HTTP, and Chrome reports `ERR_SSL_PROTOCOL_ERROR`, exactly as in our test. Routers, printers, cameras and network drives at addresses such as `192.168.1.1` can behave the same way.

For your own device on your own network, type `http://` in front of the address, with the port if there is one. If the test server should use HTTPS, turn it on in the server's settings with a certificate your computer trusts. Never do this for a public website: `http://` sends everything unencrypted.

## If it's your site: how to fix the server

When visitors report the error and you can reproduce it from a phone on mobile data, check the server:

1. **Run an outside test.** Qualys' [SSL Server Test](https://www.ssllabs.com/ssltest/) lists the TLS versions your public site offers and the certificate chain it sends.
2. **Make sure port 443 really speaks TLS.** In nginx, the [`ssl` parameter must be on the `listen` line](https://nginx.org/en/docs/http/configuring_https_servers.html); `listen 443;` alone serves plain HTTP on the secure port. In Apache, mod_ssl's [`SSLEngine`](https://httpd.apache.org/docs/2.4/mod/mod_ssl.html) is off by default, so a `<VirtualHost *:443>` block needs `SSLEngine on`.
3. **Offer TLS 1.2 and 1.3.** [RFC 8996](https://www.rfc-editor.org/rfc/rfc8996.html) deprecated TLS 1.0 and 1.1 in 2021, and a server limited to them gets `ERR_SSL_VERSION_OR_CIPHER_MISMATCH`. nginx has offered TLS 1.2 and 1.3 by default since version 1.23.4.
4. **Check every server behind the name.** Behind a load balancer or a CDN, one misconfigured machine causes the error only for some visitors or regions. To see what visitors in another country get, test from an IP address there, for example through a [Residential Proxy](https://proxynet.io/residential-proxy).
5. **Reload the configuration** after each change.

A minimal nginx block; the `ssl_protocols` line repeats the default and matters only if something else changed it:

```nginx
server {
    listen 443 ssl;
    server_name example.com www.example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
}
```

An expired certificate, a mismatched name or a missing intermediate certificate shows the certificate warning, not this page.

## Advanced: check whether port 443 speaks TLS

This check is for site owners who use a command line. `curl` ships with Windows 10, Windows 11 and macOS; in Windows PowerShell type `curl.exe`, since `curl` there is an alias for another command. This sends an unencrypted request to the secure port on purpose:

```bash
curl -I http://example.com:443
```

Use your own domain and read the first line of the answer:

- **A normal status line, such as `HTTP/1.1 200 OK` or a redirect:** port 443 answers in plain HTTP, so TLS is off. Our plain-HTTP test server answered `HTTP/1.0 200 OK`.
- **`400 Bad Request`:** nginx's reply when plain HTTP reaches a TLS port; its page says "The plain HTTP request was sent to HTTPS port". TLS is on.
- **`curl: (52) Empty reply from server`:** the server dropped the unencrypted request, as our TLS test server did. TLS is on.

## What if you use a proxy or VPN?

A normal proxy is rarely the cause. For an `https://` site, the browser asks the proxy for a tunnel and runs the handshake with the site through it, while the proxy passes the encrypted bytes on without reading them. In our test, a site speaking plain HTTP on its secure port gave the same `ERR_SSL_PROTOCOL_ERROR` with and without a proxy, and a correctly configured site went through untouched. Changing proxies or VPN servers cannot repair a broken site.

Proxy problems show other codes: a refused tunnel gives `ERR_TUNNEL_CONNECTION_FAILED` ([How to Fix err_tunnel_connection_failed](/blog/err-tunnel-connection-failed)), and an HTTP proxy entered as an HTTPS proxy in a proxy extension gave us `ERR_PROXY_CONNECTION_FAILED` ([What Is a Proxy Error?](/blog/proxy-server-not-responding)). The exception is software that opens encrypted traffic on purpose, such as debugging proxies and free VPN apps that ask you to install a certificate; it sits inside the handshake and can break it ([What Is a MITM Proxy?](/blog/mitm-proxy)).

Proxynet's gateway relays tunnels without decrypting them, so you install no certificate from us; to use an [HTTPS Proxy](https://proxynet.io/https-proxy) in a browser, see [How to Set Up Proxy Settings in Windows and Chrome](/blog/windows-chrome-proxy-settings). In scripts, Playwright reported `net::ERR_SSL_PROTOCOL_ERROR` in our test, and in Python an `SSLError` with `WRONG_VERSION_NUMBER` often means an HTTP proxy written with `https://` ([Max Retries Exceeded With URL](/blog/max-retries-exceeded-with-url)).

## Common mistakes

- **Looking for a way to skip the page.** No encrypted connection exists, so there is nothing to click through. `http://` sends your data unencrypted; keep it for your own router or test server.
- **Leaving the antivirus off.** Pause only the scanning, only for one test.
- **Clearing the cache and cookies again and again.** Neither takes part in the handshake.
- **Pressing Clear SSL state in Windows.** That Internet Options button dates from Internet Explorer and empties Windows' own cache; Chrome and Edge keep theirs inside the browser, which a full restart clears.
- **Switching off QUIC in chrome://flags.** QUIC, the transport behind HTTP/3, has its own code, `ERR_QUIC_PROTOCOL_ERROR`.
- **Fixing the clock for this error.** A wrong date breaks the certificate check, which brings a clock or certificate warning instead.

## Decision guide

| Situation | What to do |
|---|---|
| One site fails on every device and network | The site is broken; wait or tell its owner |
| Every secure site fails on one computer | Extensions, then security software, then VPN or filtering apps |
| Only one Wi-Fi network shows it | A network filter; ask whoever runs the network |
| The page loads in an Incognito window | Turn extensions off one by one |
| The address is `localhost` or `192.168.x.x` | Use `http://` for your own device |
| It's your site | Check `listen 443 ssl` or `SSLEngine on`, and TLS 1.2 and 1.3 |

## Frequently asked questions

### Why do I get ERR_SSL_PROTOCOL_ERROR on all browsers?

The cause sits outside the browser: security software, a VPN or filtering app, or the network. Extensions don't carry over between Chrome, Edge and Firefox, but antivirus scanning and network filters affect them all. If one site fails everywhere, the site itself is misconfigured.

### How do I fix ERR_SSL_PROTOCOL_ERROR on an Android phone?

Switch between Wi-Fi and mobile data, turn off VPN and ad-blocking apps (many run as a VPN on the phone), update Chrome from Google Play and restart the phone. If the site still fails on mobile data, the problem is on the site's side.

### Can I bypass ERR_SSL_PROTOCOL_ERROR?

No, and there is nothing to bypass. The encrypted connection never formed, so Chrome offers no way to proceed. Typing `http://` would send your data unencrypted, which is acceptable only for your own router or test server.

### Why does localhost show ERR_SSL_PROTOCOL_ERROR?

Your development server speaks plain HTTP and the browser opened it with `https://`. Use `http://localhost` with the port number, or turn on HTTPS in the server's settings.

### Is ERR_SSL_PROTOCOL_ERROR a sign that my computer is hacked?

Usually not; most cases trace back to security software, filters, extensions or a misconfigured site. If software you never installed is intercepting encrypted traffic, run a malware scan, and never install a certificate that a website or app asks for.

### Can a VPN or proxy fix ERR_SSL_PROTOCOL_ERROR?

Not when the site is broken: a VPN or proxy carries the same handshake to the same server. If a filter on your network causes it, that is the network owner's decision, so ask them.

## Summary

`ERR_SSL_PROTOCOL_ERROR` means the TLS handshake broke before the certificate was even checked, usually because the browser received something other than a valid Server Hello. Find out whether one site or every site fails, then work through extensions, security software, VPN and filtering apps and the network; on `localhost` or a router page, use `http://`. If the site is yours, make sure port 443 speaks TLS 1.2 or 1.3. A normal proxy tunnel leaves the handshake untouched; [our proxy page](/proxy) explains the proxy types and what each one is for.