---
title: "err_ssl_protocol_error in Chrome und Edge beheben"
description: "err_ssl_protocol_error („Diese Website kann keine sichere Verbindung bereitstellen“): Der TLS-Handshake ist gescheitert. Liegt es an Gerät, Netz oder Website?"
url: https://proxynet.io/de/blog/err-ssl-protocol-error
date: 2026-10-05
author: "Acar Diveroli"
category: "Anleitungen"
lang: de
---

# err_ssl_protocol_error in Chrome und Edge beheben

Sie klicken auf den Link zu einem Onlineshop, und Chrome zeigt stattdessen eine schlichte graue Seite: „Diese Website kann keine sichere Verbindung bereitstellen“, darunter die Zeile „shop.example hat eine ungültige Antwort gesendet.“, einen Vorschlag, die Windows-Netzwerkdiagnose auszuführen, und ganz unten `ERR_SSL_PROTOCOL_ERROR`. Neu laden bringt dieselbe Seite zurück, und Edge zeigt denselben Code.

Vielleicht ist der Shop tatsächlich defekt, doch genauso oft ist etwas auf Ihrem Computer oder in Ihrem Netz dazwischengekommen. Dieser Leitfaden erklärt, was der Code bedeutet und an welcher Stelle des sicheren Handshakes er auftritt, welche Ursachen wir auf Testservern nachgestellt haben, welche Lösungen Sie in welcher Reihenfolge ausprobieren, was Sie prüfen, wenn die Website Ihnen gehört, und welche Rolle Proxys und VPNs spielen.

> **Hinweis: Kurzantwort**
>
> `ERR_SSL_PROTOCOL_ERROR` bedeutet, dass der Browser den Server der Website erreicht hat, der TLS-Handshake aber gescheitert ist, weil die Antwort ungültig war; der Handshake ist der erste Austausch, der eine verschlüsselte Verbindung aufbaut. Scheitert eine Website auf jedem Gerät und in jedem Netz, ist diese Website falsch eingerichtet, oft liefert sie auf ihrem sicheren Port unverschlüsseltes HTTP aus, und nur ihr Betreiber kann das beheben. Scheitern viele Websites auf einem Computer oder in einem Netz, versuchen Sie ein Inkognitofenster, schalten Sie Erweiterungen, VPN und Filter-Apps aus, pausieren Sie den HTTPS-Scan Ihres Virenschutzes für ein einziges Neuladen und aktualisieren Sie den Browser. Bei `localhost` oder der Adresse Ihres Routers tippen Sie stattdessen `http://` ein. Die Seite bietet keinen Weg zum Weitermachen, und Sie sollten auch keinen suchen.

## Was bedeutet ERR_SSL_PROTOCOL_ERROR?

Websites, deren Adresse mit `https://` beginnt, nutzen TLS (Transport Layer Security), die Verschlüsselung hinter dem Schloss-Symbol; der ältere Name SSL lebt in Fehlercodes wie diesem weiter. Bevor eine Seite übertragen wird, führen Browser und Server einen kurzen Handshake durch: Sie einigen sich auf eine TLS-Version und ein Verschlüsselungsverfahren, der Server weist seine Identität nach, und beide Seiten erzeugen die Schlüssel. Der Standard für TLS 1.3, [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446.html), legt fest, dass ein gescheiterter Handshake die Verbindung beendet.

Die [Liste der Netzwerkfehler](https://github.com/chromium/chromium/blob/main/net/base/net_error_list.h) von Chromium, dem Quellcode hinter Chrome und Edge, beschreibt den Fehler -107 in einem kurzen Satz: „An SSL protocol error occurred.“ (Ein SSL-Protokollfehler ist aufgetreten.) Der [Code, der TLS-Fehler in diese Nummern übersetzt](https://github.com/chromium/chromium/blob/main/net/ssl/openssl_ssl_util.cc), erklärt, warum das so vage bleibt: Jeder Handshake-Fehler ohne spezifischeren Code landet bei -107. Der Code sagt also, dass der Handshake gescheitert ist, nicht, wer ihn zum Scheitern gebracht hat.

Es ist auch keine Zertifikatswarnung. „Dies ist keine sichere Verbindung“ und Codes, die mit `NET::ERR_CERT_` beginnen, kommen später, wenn der Browser das Zertifikat der Website beurteilt; hier ist der Handshake schon vorher stehen geblieben. Zertifikatsprobleme behandelt [Dies ist keine sichere Verbindung: Ursachen und Lösungen](/de/blog/your-connection-is-not-private).

## Was sagt Ihnen die Seite „Diese Website kann keine sichere Verbindung bereitstellen“?

| Zeile auf dem Bildschirm | Was sie bedeutet |
|---|---|
| „Diese Website kann keine sichere Verbindung bereitstellen“ | Die Überschrift, die Chrome bei Handshake-Fehlern zeigt |
| „example.com hat eine ungültige Antwort gesendet.“ | Die Antwort auf die erste Nachricht des Browsers war kein gültiges TLS. Chrome nennt die Website, kann aber nicht erkennen, ob die Website oder ein Gerät dazwischen die Antwort geschickt hat |
| „Versuche, die Windows-Netzwerkdiagnose auszuführen.“ | Ein Link zur Problembehandlung des Systems; da der Server geantwortet hat, findet sie selten etwas |
| `ERR_SSL_PROTOCOL_ERROR` und **Neu laden** | Der Code und eine Schaltfläche, die es einfach noch einmal versucht |

Diese Zeilen stammen aus den deutschen Sprachdateien von Chromium, und die Seite selbst haben wir in Chromium 145 unter Windows 11 nachgestellt; auf einem Mac lautet der Link „Versuche, die Netzwerkdiagnose auszuführen.“ Edge baut auf Chromium auf und zeigt denselben Code, auch wenn der Wortlaut abweichen kann. Anders als eine Zertifikatswarnung hat die Seite keine Schaltfläche **Erweitert**, denn es gibt keine sichere Verbindung, auf der es weitergehen könnte.

## An welcher Stelle des Handshakes bricht es ab?

Ein sicherer Seitenaufruf durchläuft diese Stationen in Sekundenbruchteilen:

1. **Verbindung.** Der Browser verbindet sich mit dem Server, meist auf Port 443, dem Standardport für sichere Websites. Scheitert das, sehen Sie stattdessen „Die Website ist nicht erreichbar“ ([Die Website ist nicht erreichbar: Bedeutung und Ursachen](/de/blog/this-site-cant-be-reached)).
2. **Client Hello.** Der Browser zählt die TLS-Versionen und Verschlüsselungsverfahren auf, die er beherrscht, und nennt die Website, die er erreichen will.
3. **Server Hello.** Der Server wählt eine Version und ein Verfahren. Die meisten Fälle in diesem Leitfaden brechen hier ab: Der Browser erhält etwas, das er nicht als TLS lesen kann, etwa eine gewöhnliche Webseite, eine Sperrseite oder wirre Bytes. Abschnitt 5 von RFC 8446 verlangt, dass TLS-Software die Verbindung beendet, wenn eine solche unerwartete Nachricht eintrifft.
4. **Certificate.** Der Server schickt sein Zertifikat. Ein Fehler an dieser Stelle führt stattdessen zu einer Zertifikatswarnung.
5. **Finished.** Beide Seiten bestätigen die Schlüssel, das Schloss erscheint, und die Anfrage nach der Seite geht hinaus.

Haben Browser und Server bei Station 3 keine gemeinsame TLS-Version, meist weil der Server nur TLS 1.0 oder 1.1 anbietet, bleibt die Überschrift gleich, aber der Code lautet `ERR_SSL_VERSION_OR_CIPHER_MISMATCH`.

## Was verursacht ERR_SSL_PROTOCOL_ERROR?

| Ursache | Wer es sieht | Wer es beheben kann |
|---|---|---|
| Die Website liefert auf ihrem sicheren Port unverschlüsseltes HTTP aus | Alle, auf jedem Gerät | Der Betreiber der Website |
| `https://` eingetippt für ein Gerät oder einen Testserver, der nur HTTP spricht | Nur diese Adresse | Sie: `http://` für Ihr eigenes Gerät verwenden |
| Ein Virenschutz, der verschlüsselten Datenverkehr prüft, scheitert | Viele Websites, ein Computer | Sie: ihn aktualisieren oder anders einstellen |
| Ein VPN, eine Werbeblocker- oder „Schutz“-App, die Datenverkehr filtert | Viele Websites, ein Gerät | Sie: zum Testen ausschalten |
| Ein Netzwerkfilter antwortet mit einer eigenen unverschlüsselten Seite | Gesperrte Websites, das ganze Netz | Der Administrator des Netzes |
| Eine Browsererweiterung, die Datenverkehr verarbeitet | Ein Browser | Sie: ausschalten |

Die wichtigsten Fälle haben wir mit kleinen Testservern auf unserem eigenen Computer nachgestellt. In Chromium 145 führten sowohl ein Server, der auf seinem sicheren Port unverschlüsseltes HTTP sprach, als auch ein Server, der das Client Hello mit wirren Bytes beantwortete, zu `ERR_SSL_PROTOCOL_ERROR`. Ein auf TLS 1.0 und 1.1 beschränkter Server ergab `ERR_SSL_VERSION_OR_CIPHER_MISMATCH`, und eine mitten im Handshake abgebrochene Verbindung ergab `ERR_CONNECTION_CLOSED` oder `ERR_CONNECTION_RESET`.

## Liegt das Problem bei Ihnen oder bei der Website?

1. **Öffnen Sie zwei oder drei andere sichere Websites.** Scheitern auch diese, liegt die Ursache bei Ihrem Gerät oder Ihrem Netz.
2. **Öffnen Sie die betroffene Website auf Ihrem Smartphone bei ausgeschaltetem WLAN.** Scheitert sie auch über mobile Daten, ist die Website defekt; warten Sie oder informieren Sie den Betreiber.
3. **Funktioniert sie über mobile Daten, versuchen Sie ein anderes Gerät in Ihrem WLAN.** Ein zweiter Fehlschlag deutet auf das Netz, ein Erfolg auf Software auf Ihrem Computer.
4. **Öffnen Sie ein Inkognitofenster** über **Dreipunkt-Menü > Neues Inkognitofenster** in Chrome. Erweiterungen laufen dort nur, wenn Sie es ihnen erlaubt haben; lädt die Seite im Inkognitofenster, deutet das auf eine Erweiterung.

## Wie beheben Sie den Fehler am Computer?

Laden Sie die Seite nach jedem Schritt neu.

1. **Schalten Sie Erweiterungen aus.** Wählen Sie in Chrome rechts oben **Dreipunkt-Menü > Erweiterungen > Erweiterungen verwalten** und schalten Sie VPN-, Proxy-, Werbeblocker- und „Sicherheits“-Erweiterungen aus ([die Schritte bei Google](https://support.google.com/chrome/answer/2664769?hl=de)). Wählen Sie in Edge rechts neben der Adressleiste **Erweiterungen** und dann **Erweiterungen verwalten** und nutzen Sie den Umschalter neben jeder Erweiterung ([die Schritte bei Microsoft](https://support.microsoft.com/de-de/microsoft-edge/add-turn-off-or-remove-extensions-in-microsoft-edge-9c0ec68c-2fbc-2f2c-9ff0-bdc76f46b026)). Verschwindet der Fehler, schalten Sie sie einzeln wieder ein.
2. **Testen Sie Ihre Sicherheitssoftware.** Programme mit HTTPS-Scan, SSL-Scan oder Webschutz setzen sich in die Mitte jedes Handshakes. Pausieren Sie nur diese Funktion, laden Sie einmal neu und schalten Sie sie dann wieder ein. Hat die Pause geholfen, aktualisieren Sie das Programm oder wenden Sie sich an dessen Support, statt den Schutz ausgeschaltet zu lassen.
3. **Schalten Sie VPN- und Filter-Apps aus,** auch Apps, die Werbung blockieren, indem sie den Datenverkehr durch sich selbst leiten. Prüfen Sie, dass in Windows kein vergessener Proxy eingetragen ist: [So entfernen Sie einen Proxy aus Chrome und Windows](/de/blog/remove-proxy-chrome-windows).
4. **Aktualisieren Sie den Browser.** Wählen Sie in Chrome **Dreipunkt-Menü > Hilfe > Über Google Chrome** und dann **Neu starten**, falls die Schaltfläche erscheint ([die Schritte bei Google](https://support.google.com/chrome/answer/95414?hl=de)). In Edge geben Sie `edge://settings/help` in die Adressleiste ein; zu dieser Seite gelangen Sie auch über **Einstellungen und mehr > Hilfe und Feedback**. Sicherheitssoftware muss den Handshake verstehen, den der Browser sendet; liegen die Versionen der beiden weit auseinander, kann die Prüfung scheitern.
5. **Schließen Sie den Browser vollständig und öffnen Sie ihn neu.** Chrome und Edge halten Details der letzten Handshakes im Arbeitsspeicher; ein vollständiger Neustart löscht sie.

## Warum erscheint der Fehler nur in einem Netz?

Schulen, Büros, Hotels, Router mit Kindersicherung und manche Internetanbieter filtern Websites. Sperrt ein Filter eine sichere Website, indem er an ihrer Stelle mit einer gewöhnlichen, unverschlüsselten Seite antwortet, erhält der Browser eine Webseite, wo er ein Server Hello erwartet hat. Das ist genau die Lage, die unser Testserver mit unverschlüsseltem HTTP erzeugt hat.

Fragen Sie in einem Firmen- oder Schulnetz die IT-Abteilung; die Sperre ist eine Entscheidung des Netzbetreibers, kein Defekt. Wie Organisationen verschlüsselten Datenverkehr prüfen, erklärt [Was ist Deep Packet Inspection (DPI)? So funktioniert sie](/de/blog/what-is-deep-packet-inspection).

## Warum zeigen localhost oder die Seite des Routers den Fehler?

Ein Entwicklungsserver auf Ihrem Computer lauscht zum Beispiel auf `http://localhost:3000`, der Browser öffnet aber `https://localhost:3000`. Der Server beantwortet das Client Hello mit unverschlüsseltem HTTP, und Chrome meldet `ERR_SSL_PROTOCOL_ERROR`, genau wie in unserem Test. Router, Drucker, Kameras und Netzlaufwerke unter Adressen wie `192.168.1.1` können sich genauso verhalten.

Für Ihr eigenes Gerät in Ihrem eigenen Netz tippen Sie `http://` vor die Adresse, gegebenenfalls mit Port. Soll der Testserver HTTPS nutzen, schalten Sie es in den Einstellungen des Servers ein, mit einem Zertifikat, dem Ihr Computer vertraut. Tun Sie das nie bei einer öffentlichen Website: `http://` überträgt alles unverschlüsselt.

## Wenn es Ihre Website ist: So reparieren Sie den Server

Melden Besucher den Fehler und können Sie ihn von einem Smartphone über mobile Daten nachvollziehen, prüfen Sie den Server:

1. **Lassen Sie einen Test von außen laufen.** Der [SSL Server Test](https://www.ssllabs.com/ssltest/) von Qualys listet die TLS-Versionen, die Ihre öffentliche Website anbietet, und die Zertifikatskette, die sie sendet.
2. **Stellen Sie sicher, dass Port 443 wirklich TLS spricht.** In nginx muss [der Parameter `ssl` in der `listen`-Zeile stehen](https://nginx.org/en/docs/http/configuring_https_servers.html); `listen 443;` allein liefert auf dem sicheren Port unverschlüsseltes HTTP aus. In Apache ist [`SSLEngine`](https://httpd.apache.org/docs/2.4/mod/mod_ssl.html) von mod_ssl standardmäßig aus, ein Block `<VirtualHost *:443>` braucht also `SSLEngine on`.
3. **Bieten Sie TLS 1.2 und 1.3 an.** [RFC 8996](https://www.rfc-editor.org/rfc/rfc8996.html) hat TLS 1.0 und 1.1 im Jahr 2021 für veraltet erklärt, und ein darauf beschränkter Server erhält `ERR_SSL_VERSION_OR_CIPHER_MISMATCH`. nginx bietet seit Version 1.23.4 standardmäßig TLS 1.2 und 1.3 an.
4. **Prüfen Sie jeden Server hinter dem Namen.** Hinter einem Load Balancer oder einem CDN verursacht eine einzige falsch eingerichtete Maschine den Fehler nur für manche Besucher oder Regionen. Um zu sehen, was Besucher in einem anderen Land erhalten, testen Sie von einer IP-Adresse dort, zum Beispiel über einen [Residential-Proxy](https://proxynet.io/de/residential-proxy).
5. **Laden Sie die Konfiguration neu,** nach jeder Änderung.

Ein minimaler nginx-Block; die Zeile `ssl_protocols` wiederholt nur den Standard und zählt nur, wenn etwas anderes ihn geändert hat:

```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;
}
```

Ein abgelaufenes Zertifikat, ein nicht passender Name oder ein fehlendes Zwischenzertifikat führen zur Zertifikatswarnung, nicht zu dieser Seite.

## Für Fortgeschrittene: Prüfen, ob Port 443 TLS spricht

Diese Prüfung ist für Website-Betreiber, die mit der Kommandozeile arbeiten. `curl` ist in Windows 10, Windows 11 und macOS enthalten; tippen Sie in Windows PowerShell `curl.exe`, denn dort steht `curl` für einen anderen Befehl. Der Befehl sendet absichtlich eine unverschlüsselte Anfrage an den sicheren Port:

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

Setzen Sie Ihre eigene Domain ein und lesen Sie die erste Zeile der Antwort:

- **Eine normale Statuszeile wie `HTTP/1.1 200 OK` oder eine Weiterleitung:** Port 443 antwortet mit unverschlüsseltem HTTP, TLS ist also aus. Unser Testserver mit unverschlüsseltem HTTP antwortete `HTTP/1.0 200 OK`.
- **`400 Bad Request`:** Das ist die Antwort von nginx, wenn unverschlüsseltes HTTP einen TLS-Port erreicht; auf der Seite steht „The plain HTTP request was sent to HTTPS port“. TLS ist an.
- **`curl: (52) Empty reply from server`:** Der Server hat die unverschlüsselte Anfrage verworfen, wie unser TLS-Testserver. TLS ist an.

## Was, wenn Sie einen Proxy oder ein VPN nutzen?

Ein normaler Proxy ist selten die Ursache. Bei einer `https://`-Website bittet der Browser den Proxy um einen Tunnel und führt den Handshake mit der Website durch ihn hindurch, während der Proxy die verschlüsselten Bytes weiterreicht, ohne sie zu lesen. In unserem Test ergab eine Website, die auf ihrem sicheren Port unverschlüsseltes HTTP sprach, mit und ohne Proxy denselben `ERR_SSL_PROTOCOL_ERROR`, und eine korrekt eingerichtete Website kam unverändert durch. Ein Wechsel des Proxys oder des VPN-Servers kann eine defekte Website nicht reparieren.

Proxy-Probleme zeigen andere Codes: Ein abgelehnter Tunnel ergibt `ERR_TUNNEL_CONNECTION_FAILED` ([err_tunnel_connection_failed in Chrome und Edge beheben](/de/blog/err-tunnel-connection-failed)), und ein HTTP-Proxy, der in einer Proxy-Erweiterung als HTTPS-Proxy eingetragen war, ergab bei uns `ERR_PROXY_CONNECTION_FAILED` ([Proxy-Fehler: Was tun, wenn der Proxyserver nicht reagiert?](/de/blog/proxy-server-not-responding)). Die Ausnahme ist Software, die verschlüsselten Datenverkehr absichtlich öffnet, etwa Debugging-Proxys und kostenlose VPN-Apps, die Sie bitten, ein Zertifikat zu installieren; sie sitzt mitten im Handshake und kann ihn stören ([Was ist ein MITM-Proxy? Charles, Fiddler und mitmproxy](/de/blog/mitm-proxy)).

Das Gateway von Proxynet leitet Tunnel weiter, ohne sie zu entschlüsseln, deshalb installieren Sie kein Zertifikat von uns; wie Sie einen [HTTPS-Proxy](https://proxynet.io/de/https-proxy) im Browser verwenden, zeigt [Proxy-Einstellungen in Windows und Chrome einrichten](/de/blog/windows-chrome-proxy-settings). In Skripten meldete Playwright in unserem Test `net::ERR_SSL_PROTOCOL_ERROR`, und in Python bedeutet ein `SSLError` mit `WRONG_VERSION_NUMBER` oft, dass ein HTTP-Proxy mit `https://` angegeben wurde ([Max Retries Exceeded With URL: Bedeutung und Lösung](/de/blog/max-retries-exceeded-with-url)).

## Häufige Fehler

- **Nach einem Weg suchen, die Seite zu überspringen.** Es gibt keine verschlüsselte Verbindung, also auch nichts, worauf man weiterklicken könnte. `http://` sendet Ihre Daten unverschlüsselt; nutzen Sie es nur für Ihren eigenen Router oder Testserver.
- **Den Virenschutz ausgeschaltet lassen.** Pausieren Sie nur den Scan und nur für einen Test.
- **Cache und Cookies immer wieder löschen.** Beide spielen beim Handshake keine Rolle.
- **In Windows auf Clear SSL state (SSL-Status löschen) klicken.** Diese alte Windows-Schaltfläche stammt aus dem Internet Explorer und leert den eigenen Zwischenspeicher von Windows; Chrome und Edge halten ihren im Browser, und den leert ein vollständiger Neustart.
- **QUIC in chrome://flags ausschalten.** QUIC, das Transportprotokoll hinter HTTP/3, hat einen eigenen Code, `ERR_QUIC_PROTOCOL_ERROR`.
- **Wegen dieses Fehlers die Uhr stellen.** Ein falsches Datum stört die Zertifikatsprüfung, und dann erscheint stattdessen eine Uhr- oder Zertifikatswarnung.

## Entscheidungshilfe

| Ihre Lage | Was tun |
|---|---|
| Eine Website scheitert auf jedem Gerät und in jedem Netz | Die Website ist defekt; warten oder den Betreiber informieren |
| Jede sichere Website scheitert auf einem Computer | Erweiterungen, dann Sicherheitssoftware, dann VPN- oder Filter-Apps |
| Nur ein WLAN zeigt den Fehler | Ein Netzwerkfilter; fragen Sie, wer das Netz betreibt |
| Die Seite lädt im Inkognitofenster | Erweiterungen einzeln ausschalten |
| Die Adresse ist `localhost` oder `192.168.x.x` | `http://` für Ihr eigenes Gerät verwenden |
| Es ist Ihre Website | `listen 443 ssl` oder `SSLEngine on` prüfen, dazu TLS 1.2 und 1.3 |

## Häufige Fragen

### Warum erscheint ERR_SSL_PROTOCOL_ERROR in allen Browsern?

Die Ursache liegt außerhalb des Browsers: Sicherheitssoftware, eine VPN- oder Filter-App oder das Netz. Erweiterungen gelten nicht gleichzeitig für Chrome, Edge und Firefox, der Scan eines Virenschutzes und Netzwerkfilter wirken aber auf alle. Scheitert eine Website überall, ist die Website selbst falsch eingerichtet.

### Wie behebe ich ERR_SSL_PROTOCOL_ERROR auf einem Android-Smartphone?

Wechseln Sie zwischen WLAN und mobilen Daten, schalten Sie VPN- und Werbeblocker-Apps aus (viele laufen auf dem Smartphone als VPN), aktualisieren Sie Chrome über Google Play und starten Sie das Smartphone neu. Scheitert die Website auch über mobile Daten, liegt das Problem bei der Website.

### Kann ich ERR_SSL_PROTOCOL_ERROR umgehen?

Nein, und es gibt auch nichts zu umgehen. Die verschlüsselte Verbindung ist nie zustande gekommen, deshalb bietet Chrome keinen Weg weiter an. `http://` einzutippen würde Ihre Daten unverschlüsselt senden, was nur für Ihren eigenen Router oder Testserver vertretbar ist.

### Warum zeigt localhost ERR_SSL_PROTOCOL_ERROR?

Ihr Entwicklungsserver spricht unverschlüsseltes HTTP, und der Browser hat ihn mit `https://` geöffnet. Verwenden Sie `http://localhost` mit der Portnummer oder schalten Sie HTTPS in den Einstellungen des Servers ein.

### Ist ERR_SSL_PROTOCOL_ERROR ein Zeichen, dass mein Computer gehackt wurde?

Meist nicht; die meisten Fälle gehen auf Sicherheitssoftware, Filter, Erweiterungen oder eine falsch eingerichtete Website zurück. Fängt Software, die Sie nie installiert haben, verschlüsselten Datenverkehr ab, lassen Sie einen Malware-Scan laufen, und installieren Sie nie ein Zertifikat, das eine Website oder App von Ihnen verlangt.

### Kann ein VPN oder Proxy ERR_SSL_PROTOCOL_ERROR beheben?

Nicht, wenn die Website defekt ist: Ein VPN oder Proxy trägt denselben Handshake zum selben Server. Verursacht ein Filter in Ihrem Netz den Fehler, ist das die Entscheidung des Netzbetreibers; fragen Sie ihn.

## Fazit

`ERR_SSL_PROTOCOL_ERROR` bedeutet, dass der TLS-Handshake abgebrochen ist, bevor das Zertifikat überhaupt geprüft wurde, meist weil der Browser etwas anderes als ein gültiges Server Hello erhalten hat. Finden Sie heraus, ob eine Website oder alle scheitern, und gehen Sie dann Erweiterungen, Sicherheitssoftware, VPN- und Filter-Apps und das Netz durch; bei `localhost` oder der Seite eines Routers verwenden Sie `http://`. Ist es Ihre Website, sorgen Sie dafür, dass Port 443 TLS 1.2 oder 1.3 spricht. Ein normaler Proxy-Tunnel lässt den Handshake unberührt; [unsere Proxy-Seite](/de/proxy) erklärt die Proxy-Typen und wofür sie jeweils gedacht sind.