2015-11-23 14 views
5

Io e alcuni dei miei colleghi abbiamo ricevuto l'errore net::ERR_SPDY_PROTOCOL_ERROR.Che cosa significa ERR_SPDY_PROTOCOL_ERROR in nginx?

Utilizziamo ngnix versione 1.8.0. L'errore non è stabile (difficile da replicare) e il log degli errori di Ngnix non presenta questo errore.

Come consiglieresti di prendere e risolvere?

risposta

2

Ho avuto lo stesso problema, controlla se hai spazio sufficiente nella partizione Nginx/HDD, ne aggiungiamo alcuni e ha funzionato per noi.

0

Questo è un problema noto che esiste tra i browser Chromium e alcuni programmi antivirus come AVG e Avast, specialmente quando si utilizza una connessione SSL. Non può essere risolto alla fine dell'utente. Spetta agli sviluppatori del sito Web evitare che questo problema si verifichi.

La documentazione per gli sviluppatori web è qui: http://dev.chromium.org/spdy/spdy-best-practices

Ecco alcuni suggerimenti utili per gli sviluppatori che non sono specificamente menzionati in tale articolo:

  • Fare molta attenzione quando si utilizzano intestazioni e redirect, in particolare 301 e 302's
  • Mantieni tutti gli include nella o nella stessa directory dell'accesso al nome di dominio, non sopra la directory nel server. L'antivirus non può accedervi da lì. Per proteggere i file di inclusione, creare un file .htaccess nella directory includes e scrivere semplicemente una riga: Nega da tutti
  • Abilita compressione Gzip. Se usi cPanel, questo può essere fatto nelle impostazioni di ottimizzazione del sito web.
  • Mantieni il tuo file .htaccess semplice. La commutazione degli output del server per creare estensioni di file diverse e il reindirizzamento dei client utente creerà conflitti non necessari.

Nella mia esperienza, questo problema sembra verificarsi solo quando si utilizzano sessioni per archiviare e trasmettere dati. I cookie, Get e Post sembrano non essere interessati.

Spero che questo aiuti.

+0

SSL e gzip non sono compatibili. – Metagrapher

0

Avevo un sito che lo faceva, si è scoperto che qualcuno si è dimenticato di mettere "Location:" in un reindirizzamento PHP sulla prima riga di index.php, invalidando l'intestazione. A quanto pare, a differenza di Chrome, il resto dei browser lo ha comunque caricato bene.

+0

Comprendo che Chrome è estremamente esigente su intestazioni non valide ... – Metagrapher

1

Sembra che ci siano molte cause potenziali. Uno che ho colpito oggi era la riga di intestazione

add_header X-Frame-Options: deny;

L'attuale chrome sfogherà su quello con ssl + http2 per qualche motivo. Altre intestazioni X-Frame non sembrano essere un problema.

+0

chrome: // net-internals è stato molto utile nel debug – Metagrapher

0

Come con l'OP, questo era un problema intermittente per me e si verificava solo su richieste AJAX> 2mb di dimensioni.

Il problema si è verificato dopo il passaggio da un ELB classico AWS ad ALB.

Ho risolto questo problema disinstallando Chrome, cancellando il mio profilo utente (su mac cancella il contenuto di ~/Library/Application Support/Google/Chrome), quindi reinstallando.

0

Ho visto questo errore recentemente dopo un aggiornamento del server.

Lo vedevo per tutti gli utenti in Chrome, ma solo a intermittenza.

Sono stato in grado di risolverlo per tutti gli utenti inducendoli a utilizzare la funzione di aggiornamento "Svuota cache e hard-load" di Chrome per il sito. (F12 per gli strumenti di Chrome, tasto destro del mouse sul pulsante di aggiornamento)

Sospetto che si riferisca a qualcosa memorizzato nella cache dei certificati SSL utilizzati.