Cum să remediați ERR_SPDY_PROTOCOL_ERROR în Chrome
ERR_SPDY_PROTOCOL_ERROR este o eroare de rețea Chrome care apare atunci când browserul nu reușește să stabilească sau să mențină o sesiune SPDY sau HTTP/2 validă cu un server web. Aceasta se manifestă ca o încărcare eșuată a paginii, însoțită de obicei de ecranul standard de eroare al Chrome, și poate fi declanșată de conexiuni socket expirate, date de cache corupte, nepotriviri TLS/SSL, extensii interferente sau negociere de protocol configurată greșit pe server.
Numele erorii face referire la SPDY — protocolul de transport multiplexat al Google, acum depreciat, care a precedat HTTP/2. Deși Chrome a renunțat la suportul nativ SPDY după versiunea 51, stratul intern de gestionare a socket-urilor și sesiunilor folosește în continuare terminologia derivată din SPDY, motiv pentru care codul de eroare persistă chiar și pe conexiunile moderne HTTP/2 și HTTP/3. Înțelegerea acestei distincții este esențială pentru diagnosticarea precisă a cauzei principale.
Ce cauzează de fapt ERR_SPDY_PROTOCOL_ERROR
Înainte de a aplica soluții la întâmplare, este util să cunoașteți modurile precise de eșec din spatele acestei erori:
- Sesiuni socket SPDY/HTTP2 expirate stocate în pool-ul de conexiuni Chrome care nu mai corespund stării TLS actuale a serverului
- Certificate SSL/TLS expirate sau reemise pe server care invalidează o sesiune existentă fără o resetare curată a handshake-ului
- Nepotriviri ALPN (Application-Layer Protocol Negotiation) în care serverul anunță suport HTTP/2, dar handshake-ul TLS eșuează în mijlocul sesiunii
- Date de profil de browser corupte, inclusiv cache, cookie-uri sau fișierul de stare a rețelei
- Proxy, VPN sau software de securitate care efectuează inspecție TLS și întrerupe stratul de cadre HTTP/2
- Versiuni Chrome învechite cu erori cunoscute în implementarea HTTP/2 sau QUIC
- Configurare greșită pe server — de exemplu, o instanță Nginx sau Apache cu un modul
h2defect, sau un certificat expirat pe un nod CDN edge
Soluția 1: Golirea directă a socket-urilor SPDY
Aceasta este cea mai țintită soluție și ar trebui să fie prima dvs. acțiune. Chrome menține un pool persistent de sesiuni socket SPDY/HTTP2. Dacă o sesiune devine coruptă — de exemplu, după repornirea unui server sau reemiterea unui certificat — Chrome va continua să reutilizeze sesiunea defectă până când aceasta este golită explicit.
- Deschideți un tab nou în Chrome.
- Navigați la
chrome://net-internals/#sockets - Faceți clic pe Flush socket pools.
- Apoi navigați la
chrome://net-internals/#dns - Faceți clic pe Clear host cache.
- Închideți tab-ul și reîncărcați pagina cu probleme.
Această golire în doi pași curăță atât pool-ul de sesiuni de la nivelul transportului, cât și cache-ul de rezoluție DNS simultan, abordând cele mai frecvente două cauze din browser într-o singură operațiune.
De ce vechiul URL nu mai funcționează: Multe ghiduri fac în continuare referire la chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active. Chrome a eliminat tab-ul Events în versiunile mai noi. Utilizați direct #sockets și #dns.
Soluția 2: Ștergerea cache-ului și cookie-urilor browserului
Răspunsurile HTTP stocate în cache, cookie-urile salvate și starea HSTS (HTTP Strict Transport Security) expirată pot intra în conflict cu configurația TLS sau de protocol actuală a unui server.
- Deschideți Chrome și apăsați
Ctrl+Shift+Delete(Windows/Linux) sauCmd+Shift+Delete(macOS). - Setați Intervalul de timp la Tot timpul.
- Bifați Cookie-uri și alte date de site și Imagini și fișiere stocate în cache.
- Faceți clic pe Ștergeți datele.
Pentru o abordare mai chirurgicală — dacă doriți să ștergeți datele doar pentru un anumit domeniu fără a șterge întreaga stare a browserului — utilizați următoarele:
- Navigați la
chrome://settings/siteData - Căutați domeniul afectat.
- Ștergeți doar cookie-urile și stocarea acelui site.
În plus, ștergeți starea HSTS pentru domeniu la chrome://net-internals/#hsts introducând numele de gazdă sub Delete domain security policies. O intrare HSTS expirată poate forța Chrome pe o cale de upgrade care intră în conflict cu un server care și-a schimbat configurația TLS.
Soluția 3: Actualizarea Google Chrome
Implementările HTTP/2 și QUIC ale Chrome primesc patch-uri frecvente. Rularea unei versiuni învechite poate însemna că purtați erori cunoscute de gestionare a protocolului care au fost deja remediate upstream.
- Faceți clic pe meniul cu trei puncte și accesați Ajutor > Despre Google Chrome.
- Chrome va verifica și descărca actualizările automat.
- Faceți clic pe Relansare pentru a aplica actualizarea.
Pentru a verifica versiunea curentă din bara de adrese, navigați la chrome://version/. Comparați numărul versiunii cu blogul Chrome Releases pentru a confirma că utilizați cel mai recent canal stabil.
Soluția 4: Dezactivarea VPN, Proxy și a instrumentelor de inspecție TLS
VPN-urile, proxy-urile corporative și produsele antivirus care efectuează inspecție profundă SSL/TLS (numită și interceptare HTTPS) sunt o cauză frecventă și subdiagnosticată a ERR_SPDY_PROTOCOL_ERROR. Aceste instrumente termină conexiunea TLS la client, o re-criptează cu propriul certificat și o transmit serverului. Dacă implementarea HTTP/2 a instrumentului este incompletă sau lanțul său de certificate nu este de încredere, Chrome va respinge sesiunea.
Pentru a dezactiva setările proxy pe Windows:
- Apăsați
Win+Ipentru a deschide Setările. - Accesați Rețea și Internet > Proxy.
- Setați Detectare automată a setărilor la Activat și Utilizare server proxy la Dezactivat.
Pentru a dezactiva setările proxy prin Command Prompt:
netsh winhttp reset proxyPentru a verifica dacă un proxy este activ în prezent:
netsh winhttp show proxyDacă vă aflați pe o rețea corporativă, consultați administratorul IT înainte de a dezactiva setările proxy, deoarece acest lucru poate încălca politica de rețea. În schimb, întrebați dacă instrumentul de inspecție SSL suportă modul de trecere HTTP/2.
Soluția 5: Resetarea stivei TCP/IP și golirea cache-ului DNS
Intrările corupte din stiva TCP/IP sau un cache DNS otrăvit pot cauza eșecuri de conexiune care se manifestă ca erori de protocol. Această soluție operează la nivelul rețelei OS, sub Chrome însuși.
Deschideți Command Prompt ca Administrator (apăsați Win+R, tastați cmd, apoi apăsați Ctrl+Shift+Enter), apoi rulați următoarele comenzi în ordine:
netsh int ip reset
netsh winsock reset
ipconfig /flushdns
ipconfig /release
ipconfig /renewReporniți computerul după rularea acestor comenzi. Comanda netsh winsock reset este deosebit de importantă — un catalog Winsock corupt poate cauza erori de protocol intermitente și aparent aleatorii, dificil de urmărit până la sursă.
Pe macOS, comanda echivalentă de golire DNS este:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderSoluția 6: Dezactivarea sau izolarea extensiilor de browser
Extensiile care interceptează solicitările de rețea — blocante de reclame, instrumente de confidențialitate, extensii antivirus, extensii VPN și comutatoare de proxy personalizate — pot corupe cadrele HTTP/2 sau injecta anteturi care încalcă specificația HTTP/2, declanșând o eroare de protocol.
Metodă sistematică de izolare:
- Deschideți
chrome://extensions/ - Dezactivați toate extensiile simultan.
- Reîncărcați pagina cu probleme.
- Dacă eroarea dispare, reactivați extensiile una câte una, reîncărcând pagina după fiecare, până când este identificat vinovatul.
Alternativ, deschideți Chrome în modul Incognito (Ctrl+Shift+N), care dezactivează toate extensiile implicit (cu excepția cazului în care le-ați permis explicit în Incognito). Dacă pagina se încarcă corect în Incognito, o extensie este definitiv cauza.
Soluția 7: Repornirea routerului sau modemului
Tabelele NAT (Network Address Translation) și inspecția stateful a pachetelor pe routerele de consum pot păstra intrări de sesiune TCP expirate care împiedică noile conexiuni HTTP/2 să finalizeze handshake-ul. Un ciclu complet de alimentare — nu doar o repornire software — curăță aceste tabele.
- Opriți complet routerul și modemul.
- Așteptați 60 de secunde (nu 30 — condensatoarele au nevoie de timp pentru a se descărca complet și a șterge starea volatilă).
- Porniți mai întâi modemul, așteptați să se sincronizeze complet, apoi porniți routerul.
- Așteptați o conexiune completă înainte de a testa.
Soluția 8: Dezactivarea temporară a antivirusului sau firewall-ului
Software-ul de securitate cu funcții de scanare HTTPS sau web shield funcționează similar cu un proxy de inspecție TLS corporativ. Acesta interceptează handshake-ul TLS, ceea ce poate întrerupe negocierea sesiunii HTTP/2 dacă motorul software-ului de securitate nu suportă complet extensia ALPN sau cadrele HTTP/2.
Produsele cunoscute că provoacă această problemă includ Avast, AVG, Kaspersky și ESET când modulele lor de protecție web sunt active.
- Dezactivați temporar funcția Web Shield sau Scanare HTTPS în mod specific (nu întregul antivirus).
- Testați URL-ul cu probleme.
- Dacă eroarea se rezolvă, căutați o opțiune pentru a adăuga site-ul afectat la o listă de excludere a scanării HTTPS, în loc să dezactivați protecția global.
Soluția 9: Crearea unui profil Chrome nou
Un profil de utilizator Chrome corupt — în special subdosarul Network din directorul de profil — poate cauza ERR_SPDY_PROTOCOL_ERROR persistente care supraviețuiesc ștergerii cache-ului și golirii socket-urilor. Fișierul de stare a rețelei din profil stochează date HSTS, jurnale de transparență a certificatelor și rezultate ale negocierii de protocol stocate în cache.
Pentru a testa cu un profil nou:
- Navigați la
chrome://settings/ - Derulați la Persoane și faceți clic pe Adăugare persoană (sau Adăugare profil).
- Creați un profil de test minimal.
- Deschideți URL-ul cu probleme în noul profil.
Dacă URL-ul se încarcă corect în noul profil, problema este izolată la starea de rețea stocată a profilului original. Puteți șterge manual dosarul Network din directorul de profil fără a pierde marcajele sau parolele:
- Windows:
%LOCALAPPDATA%GoogleChromeUser DataDefaultNetwork - macOS:
~/Library/Application Support/Google/Chrome/Default/Network - Linux:
~/.config/google-chrome/Default/Network
Ștergeți dosarul Network cu Chrome închis, apoi relansați.
Soluția 10: Diagnosticarea și escaladarea problemelor de pe server
Dacă toate soluțiile de pe client eșuează, eroarea provine de pe server. Cauzele comune de pe server includ:
- Certificat SSL/TLS expirat sau recent reemis fără repornirea serverului pentru a prelua noul certificat
- Configurare HTTP/2 defectă în Nginx (directiva
http2configurată greșit) sau Apache (mod_http2încărcat, darProtocols h2 http/1.1nesetat corect) - Configurare greșită CDN sau reverse proxy unde nodul edge și serverul de origine au setări de protocol conflictuale
- Nepotrivire de versiune TLS — de exemplu, un server configurat să utilizeze doar TLS 1.3, în timp ce un proxy intermediar suportă doar TLS 1.2
Exemplu de configurare corectă Nginx HTTP/2:
server {
listen 443 ssl;
http2 on;
ssl_certificate /etc/ssl/certs/your_domain.crt;
ssl_certificate_key /etc/ssl/private/your_domain.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
}Notă: În Nginx 1.25.1+, http2 on înlocuiește sintaxa mai veche listen 443 ssl http2. Utilizarea sintaxei depreciate pe versiuni mai noi poate cauza eșecuri de negociere ALPN.
Exemplu de configurare corectă Apache HTTP/2:
Protocols h2 http/1.1
SSLEngine on
SSLCertificateFile /etc/ssl/certs/your_domain.crt
SSLCertificateKeyFile /etc/ssl/private/your_domain.keyDacă gestionați propria infrastructură de server, asigurarea că Certificatele SSL sunt valide, corect înlănțuite și reînnoite înainte de expirare elimină cel mai frecvent declanșator de pe server al acestei erori. Mediile de hosting care rulează pe VPS Hosting corect întreținut vă oferă acces direct la fișierele de configurare ale serverului, facilitând aplicarea acestor soluții fără a aștepta un furnizor de hosting partajat.
Pentru echipele care rulează aplicații web pe Servere Dedicate, verificarea că mod_http2 sau modulul HTTP/2 al Nginx este compilat și activat corect ar trebui să facă parte din orice listă de verificare post-implementare.
Instrumente de diagnosticare pentru identificarea mai rapidă a cauzei principale
Înainte de a parcurge fiecare soluție secvențial, utilizați aceste instrumente pentru a restrânge sursa:
| Instrument | Ce diagnostichează | Cum se accesează |
|---|---|---|
chrome://net-internals/#sockets | Sesiuni socket active și din pool | Bara de adrese Chrome |
chrome://net-internals/#dns | Intrări din cache-ul DNS | Bara de adrese Chrome |
chrome://net-internals/#hsts | Politici HSTS stocate per domeniu | Bara de adrese Chrome |
chrome://net-export/ | Export jurnal de rețea complet pentru analiză aprofundată | Bara de adrese Chrome |
| SSL Labs Server Test | Configurația TLS/certificat a serverului | ssllabs.com/ssltest |
| Wireshark | Inspecția handshake-ului TLS la nivel de pachete | wireshark.org |
curl -v --http2 https://example.com | Negocierea HTTP/2 din linia de comandă | Terminal |
Comanda curl este deosebit de utilă pentru a confirma dacă problema este specifică browserului sau la nivel de server:
curl -v --http2 https://your-domain.com 2>&1 | grep -E "ALPN|HTTP|SSL|error"Dacă curl eșuează de asemenea în negocierea HTTP/2, problema este definitiv de pe server. Dacă curl reușește, dar Chrome eșuează, problema se află în starea sesiunii browserului sau într-un instrument local de interceptare.
ERR_SPDY_PROTOCOL_ERROR vs. erori de rețea Chrome înrudite
| Cod de eroare | Cauza principală | Prima soluție de încercat |
|---|---|---|
ERR_SPDY_PROTOCOL_ERROR | Sesiune HTTP/2 expirată sau nepotrivire ALPN | Goliți pool-urile de socket |
ERR_HTTP2_PROTOCOL_ERROR | Încălcarea cadrelor HTTP/2 de către server sau proxy | Verificați configurația HTTP/2 a serverului |
ERR_SSL_PROTOCOL_ERROR | Eșec handshake TLS | Verificați validitatea certificatului |
ERR_CONNECTION_RESET | Conexiune TCP întreruptă în mijlocul sesiunii | Reporniți routerul, resetați TCP/IP |
ERR_CERT_AUTHORITY_INVALID | Certificat neîncrezut sau autosemnat | Verificați lanțul de certificate |
ERR_QUIC_PROTOCOL_ERROR | Eșec sesiune QUIC/HTTP3 | Dezactivați QUIC în flagurile Chrome |
Pentru site-urile unde QUIC cauzează instabilitate, îl puteți dezactiva la chrome://flags/#enable-quic setând flag-ul la Disabled. Aceasta forțează Chrome să revină la HTTP/2 bazat pe TCP sau HTTP/1.1.
Matrice de decizie tehnică: Ce soluție să aplicați mai întâi
Utilizați această matrice pentru a prioritiza depanarea în funcție de contextul în care apare eroarea:
| Scenariu | Cauza cea mai probabilă | Prima acțiune recomandată |
|---|---|---|
| Eroare pe un singur site specific | Sesiune socket expirată sau problemă de pe server | Goliți pool-urile de socket, apoi testați cu curl |
| Eroare pe mai multe site-uri simultan | Rețea locală sau corupție a profilului de browser | Resetați TCP/IP, goliți DNS, reporniți routerul |
| Eroare doar în Chrome, nu în alte browsere | Conflict de profil Chrome sau extensie | Testați în Incognito, apoi cu profil nou |
| Eroare apărută după actualizarea antivirusului | Inspecția TLS întrerupe HTTP/2 | Dezactivați scanarea HTTPS în antivirus |
| Eroare pe rețea corporativă/de birou | Proxy sau dispozitiv de inspecție SSL | Consultați IT; solicitați trecerea HTTP/2 |
| Eroare după reînnoirea certificatului serverului | Serverul nu a fost reîncărcat după schimbarea certificatului | Reîncărcați procesul serverului (nginx -s reload) |
| Eroare pe VPS sau server gestionat propriu | Configurare greșită a modulului HTTP/2 | Auditați directivele HTTP/2 Nginx/Apache |
Dacă gestionați propriul server web și aveți nevoie de un panou de control pentru a simplifica gestionarea SSL și a protocolului, Panourile de control VPS oferă interfețe GUI pentru instalarea certificatelor și configurarea serverului web, reducând riscul de configurare manuală greșită. Pentru proiectele mai mici pe Hosting Web Partajat, setările de protocol sunt gestionate la nivel de infrastructură — contactați suportul dacă suspectați o configurare greșită HTTP/2 pe server.
Listă de verificare acționabilă înainte de escaladare
Parcurgeți această listă de verificare în ordine. Opriți-vă la pasul care rezolvă eroarea.
- [ ] Goliți pool-urile de socket la
chrome://net-internals/#sockets - [ ] Ștergeți cache-ul DNS al gazdei la
chrome://net-internals/#dns - [ ] Ștergeți politica HSTS a domeniului la
chrome://net-internals/#hsts - [ ] Ștergeți tot cache-ul și cookie-urile browserului (Tot timpul)
- [ ] Testați în modul Incognito pentru a exclude extensiile
- [ ] Testați într-un al doilea browser (Firefox, Edge) pentru a exclude problemele specifice Chrome
- [ ] Dezactivați temporar scanarea HTTPS a antivirusului
- [ ] Dezactivați VPN sau proxy
- [ ] Rulați
netsh winsock resetșiipconfig /flushdnsca Administrator - [ ] Ciclați alimentarea routerului și modemului (descărcare completă de 60 de secunde)
- [ ] Creați un profil Chrome nou și ștergeți dosarul
Networkdin profilul vechi - [ ] Rulați
curl -v --http2 https://your-domain.compentru a determina dacă problema este de pe server - [ ] Dacă este de pe server: auditați validitatea certificatului SSL, configurația modulului HTTP/2 și reîncărcați procesul serverului
- [ ] Actualizați Chrome la cea mai recentă versiune stabilă
Întrebări frecvente
Ce este ERR_SPDY_PROTOCOL_ERROR și de ce apare în continuare dacă SPDY este depreciat?
Stiva de rețea internă a Chrome a moștenit coduri de eroare din era SPDY care nu au fost niciodată redenumite. Eroarea apare acum pentru orice eșec în stratul de sesiune HTTP/2 sau QUIC — inclusiv eșecuri de negociere ALPN, handshake-uri TLS defecte și intrări expirate din pool-ul de conexiuni — chiar dacă SPDY în sine nu a mai fost utilizat de la Chrome 51.
De ce apare eroarea doar pe un site web și nu pe altele?
Aceasta indică aproape întotdeauna fie o sesiune socket Chrome expirată specifică acelui domeniu, fie o problemă de pe server pe acea gazdă particulară — cum ar fi un certificat recent reemis care a invalidat sesiunile existente, sau o configurare HTTP/2 defectă pe acel server. Golirea pool-urilor de socket și testarea cu curl --http2 vor confirma care dintre ele este cauza.
Poate software-ul antivirus să cauzeze cu adevărat ERR_SPDY_PROTOCOL_ERROR?
Da. Produsele de securitate care efectuează inspecție HTTPS (Avast, AVG, Kaspersky, ESET și altele) acționează ca un proxy TLS man-in-the-middle. Dacă implementarea lor HTTP/2 este incompletă sau certificatul lor injectat nu este de încredere pentru magazinul de certificate Chrome, sesiunea HTTP/2 va eșua cu exact această eroare. Dezactivarea doar a componentei de scanare HTTPS — nu a întregului antivirus — este soluția țintită corectă.
Cum știu dacă problema este de partea mea sau a serverului?
Rulați curl -v --http2 https://your-domain.com din linia de comandă. Dacă curl eșuează de asemenea în negocierea HTTP/2, serverul este configurat greșit. Dacă curl reușește, dar Chrome eșuează, problema este locală — fie o sesiune Chrome expirată, o extensie, sau un instrument de securitate care interceptează.
Această eroare afectează SEO sau performanța site-ului?
Pentru utilizatorii finali, da — eroarea împiedică complet încărcarea paginii. Pentru proprietarii de site-uri, un ERR_SPDY_PROTOCOL_ERROR persistent cauzat de o configurare greșită HTTP/2 pe server sau un certificat expirat va duce la eșecuri ale tentativelor de crawl Googlebot, ceea ce poate afecta negativ acoperirea crawl-ului și indexarea. Asigurarea că certificatul SSL este valid și că configurația HTTP/2 este corectă este o cerință de bază pentru SEO tehnic.
