ERR_SSL_PROTOCOL_ERROR: vad felet betyder och hur du åtgärdar det

Du klickar på en länk och Chrome stoppar dig tvärt: "Webbplatsen kan inte tillhandahålla en säker anslutning", följt av koden ERR_SSL_PROTOCOL_ERROR. Det finns ingen knapp för att fortsätta ändå, ingen förklaring och ingen uppenbar orsak. Sidan vägrar helt enkelt att laddas.

Den goda nyheten: felet går nästan alltid att åtgärda, ofta på under fem minuter. Den dåliga nyheten: det har fler möjliga orsaker än de flesta SSL-fel, eftersom det täcker allt som kan gå snett under själva TLS-handskakningen. Den här guiden förklarar vad felet betyder, de snabbaste lösningarna för besökare och en systematisk felsökning för webbplatsägare som ser det på sin egen domän.

Vad ERR_SSL_PROTOCOL_ERROR faktiskt betyder

Varje HTTPS-anslutning inleds med en TLS-handskakning: webbläsaren och servern enas om protokollversion, väljer chiffersvit, utbyter nycklar och först därefter verifieras webbplatsens certifikat. ERR_SSL_PROTOCOL_ERROR betyder att handskakningen bröt samman. Förhandlingen misslyckades innan certifikatvalideringen ens hann börja.

Det är det som skiljer felet från de mer kända certifikatvarningarna. När Chrome visar "Din anslutning är inte privat" fungerade handskakningen, men certifikatet klarade inte en kontroll. Vid ERR_SSL_PROTOCOL_ERROR kunde webbläsare och server inte ens slutföra förhandlingen. Typiska orsaker: servern talar inte TLS alls på porten, den erbjuder bara protokollversioner som webbläsaren vägrar använda, eller så har något mellan de två (en antivirusproxy, en mellanliggande företagsenhet, en krånglande router) förvanskat handskakningen på vägen.

Moderna webbläsare är strikta med protokollversioner. Chrome, Firefox, Edge och Safari tog alla bort stödet för TLS 1.0 och 1.1 under 2020, och IETF avvecklade formellt båda versionerna i RFC 8996 i mars 2021. En server som fortfarande kräver TLS 1.0 ger exakt den här typen av fel i en modern webbläsare.

Så skiljer sig felet från närliggande fel

Ser du någon av koderna NET::ERR_CERT_* i stället? Börja då med vår guide till varningen "Din anslutning är inte privat", som går igenom certifikatproblem på djupet.

Är du besökare? Åtta lösningar, snabbast först

1. Ladda om sidan och testa sedan i inkognitofönster. En gammal cachad handskakning eller ett krånglande tillägg utesluts på tio sekunder.
2. Prova ett annat nätverk eller en annan enhet. Laddar sidan via mobildata men inte via Wi-Fi sitter problemet i din router, brandvägg eller ditt nätverk, inte i webbplatsen.
3. Kontrollera enhetens datum och tid. TLS är tidskänsligt. En klocka som går fel med månader kan avbryta handskakningar på oväntade sätt. Aktivera automatisk tid.
4. Rensa SSL-tillstånd och webbläsarens cache. I Windows: Internetalternativ, fliken Innehåll, "Rensa SSL-tillstånd". I Chrome: Inställningar, Integritet och säkerhet, Rensa webbinformation.
5. Inaktivera QUIC-experimentet. Öppna chrome://flags/#enable-quic, välj Disabled och starta om webbläsaren. QUIC kör HTTP/3 över UDP; vissa brandväggar och routrar hanterar det dåligt, och att tvinga Chrome tillbaka till TCP med klassisk TLS löser envisa fall.
6. Inaktivera tillägg, börja med VPN- och integritetsverktyg. Allt som skriver om trafiken kan förstöra en handskakning.
7. Stäng tillfälligt av HTTPS-skanning i ditt antivirusprogram. Många säkerhetspaket avlyssnar TLS genom att signera om trafiken i farten. En buggig avlyssnare bryter handskakningar på varje webbplats du besöker. Försvinner felet uppdaterar eller konfigurerar du om programmet och slår sedan på skanningen igen.
8. Uppdatera Chrome och operativsystemet. Mycket gamla webbläsare saknar stöd för de protokollversioner som moderna servrar kräver.

Visas felet på varje enhet och varje nätverk ligger problemet på serversidan. Skicka den här artikeln till webbplatsens ägare.

Är det din webbplats? Diagnostisera på några minuter

Börja med en enda fråga: talar servern över huvud taget TLS på port 443? Ett kommando ger svaret, från valfri dator med OpenSSL installerat:

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

Ett friskt svar skriver ut förhandlat protokoll, chiffer och certifikatkedjan. Ser du i stället "wrong version number", "handshake failure" eller rå HTML är själva TLS-lagret trasigt. Du kan också testa specifika protokollversioner:

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

Vill du hellre slippa kommandoraden? En gratis FortifyNet-skanning läser av ditt TLS-protokollstöd, certifikatkedjan, säkerhetsheaders, DNS och e-postautentisering på cirka 60 sekunder och pekar ut exakt var felet sitter.

Två av fallen förtjänar en närmare titt.

Ren HTTP på port 443. Efter en migrering eller en stressad konfigurationsändring är det förvånansvärt vanligt att ett serverblock lyssnar på 443 utan parametern ssl. Webbläsaren öppnar anslutningen och väntar sig ett TLS ServerHello men får ett HTTP-svar. Handskakningen dör omedelbart med exakt det här felet.

Cloudflare och fel 525. Med proxade DNS-poster gör besökarna TLS-handskakning med Cloudflare, och Cloudflare öppnar en andra TLS-anslutning till din originserver. Misslyckas den andra handskakningen returnerar Cloudflare fel 525, och webbläsare visar ofta felet som ett protokollfel. Lösningen är ett giltigt certifikat på origin och SSL-läget "Full (strict)" i Cloudflare.

Konfigurera protokollen som att det är 2026

TLS 1.3 är inte exotiskt längre: det bär redan ungefär 60% av den krypterade trafik som mäts vid Cloudflares kant i mitten av 2025, enligt Cloudflare Radar, medan TLS 1.2 står för nästan hela resten.

Andel av krypterad webbtrafik per TLS-version, mitten av 2025. Källa: Cloudflare Radar.

En säker modern grund för nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

Generera hela konfigurationen, inklusive chiffersviter anpassade till din exakta serverversion, med Mozillas SSL Configuration Generator. Passa samtidigt på att lägga till HSTS så att webbläsare aldrig mer försöker med ren HTTP; vår HSTS-guide förklarar headern i detalj.

Vanliga frågor

Är ERR_SSL_PROTOCOL_ERROR ett tecken på att webbplatsen är farlig? Nej. Felet signalerar ett tekniskt haveri, inte en attack. Men eftersom ingen säker kanal kunde upprättas vägrar webbläsaren att skicka någon data. Försök inte kringgå felet på en webbplats där du skulle logga in eller betala.

Varför visas felet i Chrome men inte i Firefox? Webbläsarna använder olika TLS-stackar och standardinställningar; Chrome är dessutom mer aggressivt med QUIC och HTTP/3. En webbplats som fallerar i en stor webbläsare är ändå felkonfigurerad, även om en annan webbläsare klarar sig.

Varför får bara jag felet, på en enda enhet? Det pekar på en lokal orsak: fel klocka, TLS-avlyssnande antivirus, ett trasigt tillägg eller korrupt SSL-tillstånd. Gå igenom besökarlösningarna 3 till 7 ovan.

Kan ett utgånget certifikat utlösa ERR_SSL_PROTOCOL_ERROR? Utgångna certifikat ger normalt NET::ERR_CERT_DATE_INVALID i stället. Men vissa serverstackar hanterar utgångna eller trasiga certifikat så illa att hela handskakningen avbryts. Att kontrollera utgångsdatum tar sekunder, så uteslut det först.

Relaterade guider

• "Din anslutning är inte privat": vad felet betyder och hur du åtgärdar det
• SSL-certifikat A+ betyg i SSL Labs: Komplett guide 2026
• Vad är HSTS? HTTP Strict Transport Security förklarat

Hitta felkällan på 60 sekunder

ERR_SSL_PROTOCOL_ERROR har ett dussin möjliga orsaker, men din webbplats har exakt en av dem. Kör en gratis FortifyNet-skanning: den testar dina TLS-protokollversioner, certifikatkedjan, säkerhetsheaders, DNS och e-postautentisering, helt utan registrering, och berättar på klarspråk vad du ska åtgärda först.