ERR_SSL_PROTOCOL_ERROR: So beheben Sie den Fehler (Chrome, Edge, alle Browser)

Was ist ERR_SSL_PROTOCOL_ERROR?

ERR_SSL_PROTOCOL_ERROR ist ein Browser-Fehler, der auftritt, wenn der SSL/TLS-Handshake zwischen Ihrem Browser und dem Webserver fehlschlägt. Der Browser kann keine sichere verschlüsselte Verbindung herstellen und blockiert die Seite vollständig, um Sie vor der Übertragung von Daten über einen unsicheren Kanal zu schützen.

Jede HTTPS-Verbindung beginnt mit einem TLS-Handshake — einer Aushandlung, bei der Browser und Server sich auf ein Verschlüsselungsprotokoll (TLS 1.2 oder 1.3) einigen, Zertifikate austauschen und die Identität des jeweils anderen überprüfen. ERR_SSL_PROTOCOL_ERROR bedeutet, dass diese Aushandlung abgebrochen wurde, bevor sie abgeschlossen werden konnte.

Der Fehler ist kein serverseitiger HTTP-Statuscode — er tritt in Ihrem Browser auf, bevor eine HTTP-Anfrage gesendet wird. Der zugrunde liegende Chromium-Fehlercode ist net::ERR_SSL_PROTOCOL_ERROR (Fehlercode -107), der im Chromium-Quellcode als Fehler bei der Aushandlung akzeptabler Sicherheitsparameter definiert ist.

Wie ERR_SSL_PROTOCOL_ERROR aussieht

Chrome und andere Chromium-basierte Browser zeigen diesen Fehler als ganzseitige Warnung mit der Meldung "Diese Website kann keine sichere Verbindung bereitstellen" an. Darunter sehen Sie den spezifischen Fehlercode. Hier sind die häufigsten Varianten, die Ihnen begegnen können.

• ERR_SSL_PROTOCOL_ERROR — der Standard-Fehlercode in der Adressleiste von Chrome

• net::ERR_SSL_PROTOCOL_ERROR — der vollständige interne Fehlercode, der in der Chrome DevTools-Konsole angezeigt wird

• Diese Website kann keine sichere Verbindung bereitstellen — die für den Nutzer sichtbare Überschrift in Chrome

• [domain] hat eine ungültige Antwort gesendet — der detaillierte Fehlertext, den Chrome unter der Überschrift anzeigt

• ERR_SSL_PROTOCOL_ERROR in allen Browsern — wenn der Fehler gleichzeitig in Chrome, Edge, Brave und Opera auftritt (weist auf ein serverseitiges oder systemweites Problem hin, nicht auf einen browserspezifischen Fehler)

Was verursacht ERR_SSL_PROTOCOL_ERROR?

Dieser Fehler hat sowohl clientseitige (Ihr Gerät) als auch serverseitige (die Website) Ursachen. Die Identifizierung, auf welcher Seite das Problem liegt, ist der erste Schritt zur Behebung. Wenn der Fehler auf jeder Website auftritt, liegt das Problem auf Ihrer Seite. Wenn er nur auf einer bestimmten Website auftritt, ist die Ursache wahrscheinlich serverseitig.

• Falsche Systemdatum/-uhrzeit — Die häufigste nutzerseitige Ursache. SSL-Zertifikate sind zeitabhängig — wenn die Uhr Ihres Computers auch nur um wenige Minuten falsch geht, schlägt die Zertifikatsvalidierung fehl und der TLS-Handshake bricht ab.

• Abgelaufenes oder ungültiges SSL-Zertifikat — Das SSL-Zertifikat der Website ist abgelaufen, selbstsigniert oder wurde für eine andere Domain ausgestellt. Sie können jedes Zertifikat sofort mit unserem SSL-Checker überprüfen.

• Veraltetes TLS-Protokoll — Der Server unterstützt nur veraltete Protokolle (SSL 3.0, TLS 1.0, TLS 1.1), die moderne Browser nicht mehr verwenden. Chrome, Edge und Firefox haben die Unterstützung für TLS 1.0/1.1 im Jahr 2020 eingestellt.

• Beschädigter Browser-SSL-Status — Ihr Browser hat alte SSL-Sitzungsdaten, HSTS-Einstellungen oder Zertifikatsinformationen zwischengespeichert, die mit dem aktuellen Verbindungsversuch in Konflikt stehen.

• QUIC-Protokollkonflikt — Das experimentelle QUIC-Protokoll (HTTP/3) von Chrome kann manchmal die TLS-Aushandlung auf Servern beeinträchtigen, die es nicht ordnungsgemäß unterstützen.

• Antivirus-SSL/HTTPS-Scanning — Sicherheitssoftware, die HTTPS-Datenverkehr abfängt (Avast, Kaspersky, Bitdefender, ESET), kann den TLS-Handshake stören, indem sie ihr eigenes Zertifikat in die Verbindung einfügt.

• Unvollständige Zertifikatskette — Der Server sendet sein SSL-Zertifikat, aber nicht die Zwischenzertifikate, die zur Überprüfung der Vertrauenskette bis zur Stammzertifizierungsstelle erforderlich sind.

• VPN- oder Proxy-Störung — VPNs und Unternehmens-Proxys, die HTTPS-Datenverkehr inspizieren, können den TLS-Handshake beschädigen, insbesondere beim Wechsel zwischen Netzwerken.

• Browser-Erweiterungen — Datenschutz-Erweiterungen, Werbeblocker und Sicherheits-Add-ons, die HTTPS-Anfragen modifizieren, können den SSL-Handshake beeinträchtigen.

• Firewall blockiert Port 443 — Eine Netzwerk-Firewall oder ein Router blockiert den Standard-HTTPS-Port (443) und verhindert so den Abschluss des TLS-Handshakes.

ERR_SSL_PROTOCOL_ERROR beheben (Für Nutzer)

Wenn Sie diesen Fehler beim Surfen sehen, beginnen Sie mit den einfachsten Lösungen. Die meisten Fälle werden durch die ersten drei Lösungen unten behoben.

Lösung 1: Systemdatum und Uhrzeit überprüfen

Eine falsche Systemuhr ist die häufigste Ursache für ERR_SSL_PROTOCOL_ERROR. SSL-Zertifikate haben einen Gültigkeitszeitraum (Nicht-Vor- / Nicht-Nach-Datum), und wenn Ihre Systemzeit außerhalb dieses Zeitraums liegt, schlägt der Handshake fehl. Selbst eine Abweichung von wenigen Minuten kann bei strenger Zertifikatsvalidierung Probleme verursachen.

Stellen Sie sicher, dass Ihr Computer die Zeit automatisch synchronisiert.

• Windows: Einstellungen → Zeit und Sprache → Datum und Uhrzeit → Schalten Sie "Uhrzeit automatisch festlegen" und "Zeitzone automatisch festlegen" ein

• Mac: Systemeinstellungen → Allgemein → Datum und Uhrzeit → Schalten Sie "Datum und Uhrzeit automatisch einstellen" ein

• Linux: Führen Sie sudo timedatectl set-ntp true aus, um die NTP-Synchronisierung zu aktivieren

Lösung 2: SSL-Status leeren (Windows)

Windows verwaltet einen eigenen SSL-Zertifikatscache, der vom Browser getrennt ist. Veraltete oder beschädigte Einträge in diesem Cache können zu einem dauerhaften ERR_SSL_PROTOCOL_ERROR führen, selbst nachdem der Browser-Cache geleert wurde.

Um den SSL-Status unter Windows zu leeren: Öffnen Sie die Internetoptionen (suchen Sie im Startmenü danach oder geben Sie inetcpl.cpl im Ausführen-Dialog ein) → klicken Sie auf die Registerkarte Inhalte → klicken Sie auf SSL-Status löschen → klicken Sie auf OK. Starten Sie dann Ihren Browser neu.

Lösung 3: Browser-Cache und Cookies leeren

Beschädigte zwischengespeicherte Daten oder veraltete HSTS-Einträge (HTTP Strict Transport Security) können Ihren Browser zwingen, Verbindungen mit veralteten Parametern herzustellen, was den SSL-Protokollfehler auslöst.

• Schritt 1: Öffnen Sie Chrome-Einstellungen → Datenschutz und Sicherheit → Browserdaten löschen (oder drücken Sie Strg+Umschalt+Entf)

• Schritt 2: Wechseln Sie zur Registerkarte Erweitert

• Schritt 3: Stellen Sie den Zeitraum auf Gesamte Zeit ein

• Schritt 4: Aktivieren Sie Bilder und Dateien im Cache, Cookies und andere Websitedaten und Gehostete App-Daten

• Schritt 5: Klicken Sie auf Daten löschen und starten Sie Chrome neu

Für eine einzelne Website können Sie auch nur die Daten dieser Seite löschen: Gehen Sie zu chrome://settings/content/all → suchen Sie nach der Domain → klicken Sie auf das Papierkorb-Symbol.

Lösung 4: QUIC-Protokoll deaktivieren

Chrome verwendet standardmäßig das QUIC-Protokoll (HTTP/3 über UDP) für schnellere Verbindungen. Einige Server, Firewalls und Netzwerkgeräte können QUIC jedoch nicht richtig verarbeiten, was zu SSL-Handshake-Fehlern führen kann. Das Deaktivieren von QUIC zwingt Chrome, Standard-TCP-basierte TLS-Verbindungen zu verwenden.

• Schritt 1: Geben Sie chrome://flags/#enable-quic in die Adressleiste ein

• Schritt 2: Suchen Sie Experimentelles QUIC-Protokoll

• Schritt 3: Ändern Sie es von Standard auf Deaktiviert

• Schritt 4: Klicken Sie auf Neu starten, um Chrome neu zu starten

Wenn der Fehler nach dem Deaktivieren von QUIC verschwindet, liegt das Problem an der HTTP/3-Implementierung des Servers oder daran, dass Ihr Netzwerk den UDP-Port 443 blockiert. Sie können QUIC ohne negative Auswirkungen deaktiviert lassen — Seiten werden über Standard-HTTPS (HTTP/2 über TCP) geladen.

Lösung 5: Browser-Erweiterungen deaktivieren

Erweiterungen, die Webdatenverkehr abfangen oder modifizieren — Werbeblocker, VPN-Erweiterungen, Datenschutz-Schutzschilde und HTTPS Everywhere — können den TLS-Handshake beeinträchtigen. Einige Erweiterungen fügen eigene Zertifikate ein oder ändern Anfrage-Header auf eine Weise, die die SSL-Aushandlung stört.

Gehen Sie zu chrome://extensions/, deaktivieren Sie alle Erweiterungen und laden Sie die Seite neu. Wenn der Fehler verschwindet, aktivieren Sie die Erweiterungen nacheinander wieder, um den Verursacher zu finden. Die häufigsten Übeltäter sind: uBlock Origin (selten), Avast Online Security, Norton Safe Web und HTTPS Everywhere.

Lösung 6: Antivirus-SSL/HTTPS-Scanning deaktivieren

Viele Antivirenprogramme (Avast, Kaspersky, Bitdefender, ESET, Norton) verfügen über eine Funktion namens "HTTPS-Scanning" oder "SSL-Inspektion", die verschlüsselte Verbindungen abfängt, indem sie als Man-in-the-Middle-Proxy agiert. Dies kann TLS-Handshakes stören, insbesondere bei Websites, die Certificate Pinning oder neuere TLS-1.3-Funktionen verwenden.

Suchen Sie in Ihrem Antivirenprogramm nach Einstellungen namens Web-Schutz, HTTPS-Scanning, SSL-Scanning oder Scanning verschlüsselter Verbindungen und deaktivieren Sie diese vorübergehend. Wenn der Fehler behoben ist, können Sie die betroffene Domain zur Ausnahmeliste Ihres Antivirenprogramms hinzufügen.

Lösung 7: Browser aktualisieren

Ältere Browser-Versionen unterstützen möglicherweise nicht die TLS-Protokolle oder Cipher Suites, die von modernen Websites benötigt werden. Chrome aktualisiert regelmäßig seine Sicherheitsanforderungen — beispielsweise hat Chrome 98 die Unterstützung für TLS 1.0 und 1.1 vollständig eingestellt.

Chrome aktualisieren: Gehen Sie zu chrome://settings/help oder Menü → Hilfe → Über Google Chrome. Chrome lädt Updates automatisch herunter, erfordert jedoch einen Neustart, um sie anzuwenden. Für Edge: edge://settings/help. Für Firefox: Menü → Hilfe → Über Firefox.

Lösung 8: DNS-Cache leeren

Veraltete DNS-Einträge können Ihren Browser auf den falschen Server oder eine veraltete IP-Adresse verweisen, die kein gültiges SSL-Zertifikat mehr hat. Das Leeren Ihres DNS-Caches erzwingt eine neue DNS-Abfrage.

# Windows (Command Prompt as Admin)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Linux
sudo systemd-resolve --flush-caches

# Chrome internal DNS cache
# Visit chrome://net-internals/#dns → Click "Clear host cache"

Überprüfen Sie nach dem Leeren, ob die Domain zur richtigen IP aufgelöst wird, mit dem DNS-Lookup-Tool von DNS Robot. Wenn die IP-Adresse falsch aussieht, hat die Website möglicherweise den Hosting-Anbieter gewechselt und die DNS-Propagierung ist noch nicht abgeschlossen.

Lösung 9: Inkognito-/Privatmodus testen

Der Inkognito-Modus startet mit einem sauberen Browser-Zustand — keine zwischengespeicherten Daten, keine Cookies, keine Erweiterungen (es sei denn, Sie haben sie explizit im Inkognito-Modus zugelassen). Wenn die Website im Inkognito-Modus funktioniert, aber nicht im normalen Modus, wird das Problem durch eine Browser-Erweiterung, zwischengespeicherte Daten oder ein beschädigtes Browser-Profil verursacht.

Öffnen Sie ein Inkognito-Fenster: Strg+Umschalt+N (Chrome/Edge) oder Strg+Umschalt+P (Firefox). Navigieren Sie zur gleichen Website. Wenn sie geladen wird, leeren Sie Ihren Browser-Cache (Lösung 3) oder überprüfen Sie die Erweiterungen (Lösung 5).

Lösung 10: VPN oder Proxy deaktivieren

VPNs und HTTP-Proxys befinden sich zwischen Ihrem Browser und dem Webserver. Einige VPNs inspizieren HTTPS-Datenverkehr, fügen eigene Zertifikate ein oder leiten Verbindungen über Server mit fehlkonfiguriertem SSL weiter. Unternehmens-Proxys verwenden häufig SSL-Interception (ähnlich wie Antivirus-HTTPS-Scanning), die TLS-Handshakes stören kann.

Trennen Sie vorübergehend Ihr VPN und versuchen Sie, die Website zu laden. Wenn sie ohne VPN funktioniert, liegt das Problem daran, wie Ihr VPN SSL-Verbindungen verarbeitet. Versuchen Sie einen anderen VPN-Server oder kontaktieren Sie Ihren VPN-Anbieter.

Lösung 11: Netzwerkeinstellungen zurücksetzen (Letzte Maßnahme)

Wenn nichts anderes hilft, setzen Sie Ihren Netzwerk-Stack zurück. Dies löscht alle benutzerdefinierten Netzwerkkonfigurationen und setzt alles auf die Standardwerte zurück — einschließlich DNS-Einstellungen, Proxy-Konfigurationen und Socket-Verbindungen.

# Windows (Command Prompt as Admin)
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

# Then restart your computer

# macOS — reset DNS settings
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux — restart NetworkManager
sudo systemctl restart NetworkManager

ERR_SSL_PROTOCOL_ERROR beheben (Für Website-Betreiber)

Wenn mehrere Nutzer ERR_SSL_PROTOCOL_ERROR auf Ihrer Website melden, liegt das Problem auf der Serverseite. Die häufigsten serverseitigen Ursachen sind abgelaufene Zertifikate, fehlende Zwischenzertifikate und veraltete TLS-Konfigurationen.

SSL-Zertifikat überprüfen

Der erste Schritt besteht darin, zu überprüfen, ob Ihr SSL-Zertifikat gültig, ordnungsgemäß installiert und nicht abgelaufen ist. Verwenden Sie den SSL-Checker von DNS Robot, um sofort den Zertifikatsstatus, das Ablaufdatum, den Aussteller und die Zertifikatskette zu überprüfen.

Häufige Zertifikatsprobleme, die ERR_SSL_PROTOCOL_ERROR verursachen:

• Abgelaufenes Zertifikat — Let's-Encrypt-Zertifikate laufen alle 90 Tage ab. Wenn die automatische Verlängerung fehlgeschlagen ist (Certbot-Cron läuft nicht, DNS-Challenge defekt), läuft Ihr Zertifikat stillschweigend ab.

• Falsche Domain — Das Zertifikat wurde für example.com ausgestellt, aber die Website wird unter www.example.com bereitgestellt (oder umgekehrt). Das Zertifikat muss mit der genauen Domain übereinstimmen oder einen Wildcard-Eintrag (*.example.com) enthalten.

• Selbstsigniertes Zertifikat — Entwicklungszertifikate werden von Browsern in der Produktionsumgebung nicht als vertrauenswürdig eingestuft.

• Widerrufenes Zertifikat — Die Zertifizierungsstelle hat das Zertifikat widerrufen (wegen Schlüssel-Kompromittierung, Fehlausstellung oder Änderung des Domain-Eigentümers).

# Check certificate from command line
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates -subject -issuer

# Check certificate chain completeness
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | grep -E "(depth|verify)"

# Renew Let's Encrypt certificate
sudo certbot renew --force-renewal

TLS 1.2 und TLS 1.3 aktivieren

Alle modernen Browser erfordern mindestens TLS 1.2. Wenn Ihr Server nur TLS 1.0 oder 1.1 unterstützt, verweigern Browser die Verbindung und zeigen ERR_SSL_PROTOCOL_ERROR an. TLS 1.3 ist der neueste Standard und deutlich schneller als TLS 1.2 — aktivieren Sie beide für maximale Kompatibilität und Leistung.

# Nginx — ssl_protocols in nginx.conf or site config
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;

# Apache — in httpd.conf or ssl.conf
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder on

Starten Sie nach der Aktualisierung Ihrer TLS-Konfiguration Ihren Webserver neu (sudo systemctl restart nginx oder sudo systemctl restart apache2) und testen Sie mit dem SSL-Checker von DNS Robot, ob die Protokolle aktiv sind.

Vollständige Zertifikatskette installieren

Eine unvollständige Zertifikatskette ist eine häufige, aber schwer zu diagnostizierende Ursache für ERR_SSL_PROTOCOL_ERROR. Ihr Server muss nicht nur Ihr SSL-Zertifikat senden, sondern auch die Zwischenzertifikate, die Ihr Zertifikat mit der vertrauenswürdigen Stammzertifizierungsstelle verbinden. Ohne sie können einige Browser und Geräte das Zertifikat nicht überprüfen.

Die meisten Zertifizierungsstellen stellen eine "CA-Bundle"- oder "Full-Chain"-Datei zur Verfügung. Für Let's Encrypt verwenden Sie fullchain.pem (nicht nur cert.pem). Bei anderen Zertifizierungsstellen laden Sie das Zwischenzertifikat aus deren Dokumentation herunter und verketten es mit Ihrem Zertifikat.

# Nginx — use fullchain, not just cert
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

# Apache
SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem

HSTS-Konfiguration überprüfen

HSTS (HTTP Strict Transport Security) weist Browser an, für Ihre Domain immer HTTPS zu verwenden. Wenn Ihre HSTS-Richtlinie eine lange max-age hat und Ihr SSL-Zertifikat später ausfällt, verweigern Browser die Verbindung — sie können nicht auf HTTP zurückfallen, und das defekte HTTPS löst ERR_SSL_PROTOCOL_ERROR aus.

Überprüfen Sie Ihren HSTS-Header mit dem HTTP-Headers-Tool von DNS Robot. Wenn Sie eine sehr lange max-age (wie 2 Jahre) gesetzt haben und Ihr Zertifikat abgelaufen ist, sind Nutzer, die Ihre Website zuvor besucht haben, auf HTTPS ohne Rückfallmöglichkeit festgelegt. Um dies zu beheben, erneuern Sie zunächst Ihr SSL-Zertifikat, dann verbinden sich Browser wieder normal.

Serverkonfiguration überprüfen

Fehlkonfigurierte Webserver können ERR_SSL_PROTOCOL_ERROR verursachen, selbst bei einem gültigen Zertifikat. Häufige Fehlkonfigurationen sind:

• Falscher Port — SSL/TLS sollte auf Port 443 laufen. Wenn Ihr Server auf einem anderen Port lauscht, kann der Handshake des Browsers fehlschlagen.

• Gemischtes HTTP/HTTPS — Das Bereitstellen einiger Ressourcen über HTTP auf einer HTTPS-Seite löst Mixed-Content-Warnungen aus und kann den Handshake für Unterressourcen stören.

• SNI (Server Name Indication) nicht konfiguriert — Wenn mehrere Domains eine IP-Adresse teilen, muss der Server SNI unterstützen, um das richtige Zertifikat für jede Domain bereitzustellen.

• Cipher-Suite-Inkompatibilität — Der Server unterstützt nur Cipher Suites, die der Browser nicht akzeptiert. Verwenden Sie starke moderne Verschlüsselungsverfahren wie AES-GCM und ChaCha20.

Verwenden Sie den HTTP-Headers-Checker von DNS Robot, um die Antwort-Header Ihres Servers zu inspizieren und zu überprüfen, ob Ihre SSL-Konfiguration die richtigen Header sendet.

ERR_SSL_PROTOCOL_ERROR auf Android

Android-Nutzer stoßen auf ERR_SSL_PROTOCOL_ERROR sowohl in Chrome für Android als auch in WebView-basierten Apps. Die Lösungen unterscheiden sich leicht von denen am Desktop, da Android Zertifikate und Netzwerkeinstellungen anders verwaltet.

• Datum und Uhrzeit überprüfen — Einstellungen → System → Datum und Uhrzeit → "Automatisches Datum und Uhrzeit" und "Automatische Zeitzone" aktivieren

• Chrome-Daten löschen — Einstellungen → Apps → Chrome → Speicher → Cache leeren (dann Daten löschen, wenn das Cache-Leeren nicht geholfen hat)

• Chrome aktualisieren — Öffnen Sie den Google Play Store → Meine Apps → Chrome auf die neueste Version aktualisieren

• Netzwerkanmeldedaten löschen — Einstellungen → Sicherheit → Anmeldedaten löschen (dies entfernt alle vom Nutzer installierten Zertifikate)

• Netzwerkeinstellungen zurücksetzen — Einstellungen → System → Zurücksetzen → WLAN, mobile Daten und Bluetooth zurücksetzen

• Für WebView-Apps — Entwickler sollten sicherstellen, dass android:usesCleartextTraffic="false" gesetzt ist und die Netzwerksicherheitskonfiguration den richtigen Zertifizierungsstellen vertraut

ERR_SSL_PROTOCOL_ERROR in anderen Browsern

ERR_SSL_PROTOCOL_ERROR ist ein Chromium-spezifischer Fehlercode. Andere Browser zeigen für denselben zugrunde liegenden SSL-Handshake-Fehler unterschiedliche Fehlermeldungen an.

Wenn der Fehler in allen Browsern gleichzeitig auftritt, ist das Problem entweder systemweit (falsche Uhrzeit, Antivirenprogramm, Netzwerk) oder serverseitig (abgelaufenes Zertifikat, TLS-Fehlkonfiguration). Wenn er nur in einem Browser auftritt, ist das Problem browserspezifisch — versuchen Sie, den Cache und den SSL-Status dieses Browsers zu leeren.

ERR_SSL_PROTOCOL_ERROR auf Localhost (Entwickler)

Entwickler stoßen häufig auf localhost sent an invalid response. ERR_SSL_PROTOCOL_ERROR, wenn sie lokale Entwicklungsserver ausführen. Dies geschieht, weil Ihr Browser ein gültiges SSL-Zertifikat für HTTPS-Verbindungen erwartet, aber localhost ein selbstsigniertes oder gar kein Zertifikat verwendet.

• HTTP für lokale Entwicklung verwenden — Ändern Sie https://localhost:3000 zu http://localhost:3000, es sei denn, Sie benötigen ausdrücklich HTTPS

• Lokales Zertifikat generieren — Verwenden Sie mkcert, um lokal vertrauenswürdige SSL-Zertifikate zu erstellen: mkcert -install && mkcert localhost 127.0.0.1

• Node.js — Setzen Sie NODE_TLS_REJECT_UNAUTHORIZED=0 nur für die Entwicklung (niemals in der Produktion)

• Chrome-Flag — Geben Sie chrome://flags/#allow-insecure-localhost ein und aktivieren Sie "Ungültige Zertifikate für von localhost geladene Ressourcen zulassen"

• Next.js / Vite / Webpack — Diese Frameworks unterstützen --https-Flags, die automatisch Entwicklungszertifikate generieren

Verwandte SSL/TLS-Fehlercodes

Chrome hat mehrere SSL-bezogene Fehlercodes. Sie alle weisen auf unterschiedliche TLS-Handshake- oder Zertifikatsprobleme hin.

Für alle SSL-Fehler können Sie das Problem schnell mit dem SSL-Checker von DNS Robot diagnostizieren — er zeigt den Zertifikatsstatus, die Ketten-Vollständigkeit, unterstützte TLS-Versionen und das Ablaufdatum in einem einzigen Scan.