it-swarm.com.de

Was bedeutet ERR_SPDY_PROTOCOL_ERROR in nginx?

Ich und einige meiner Kollegen haben den net::ERR_SPDY_PROTOCOL_ERROR-Fehler erhalten. 

Wir verwenden ngnix Version 1.8.0. Der Fehler ist nicht stabil (schwer zu replizieren) und das Fehlerprotokoll von Ngnix hat diesen Fehler nicht.

Wie würdest du raten, dass wir das fangen und lösen?

20
TheMrbikus

TL; DR: Wenn Sie Assets zwischenspeichern, überprüfen Sie den Speicherplatz auf Ihrem Nginx-Server.

Unser Szenario

Ich bin mir nicht sicher, wo ich meine Antwort darauf veröffentlichen soll, da es sich möglicherweise um einen Edge-Fall handelt, wenn der ERR_SPDY_PROTOCOL_ERROR In Chrome (und der entsprechende Fehler "Fehler beim Laden der Ressource") angezeigt wird Aber dieser Beitrag hat mir geholfen, den Schuldigen einzugrenzen. Es waren keine Header, Gzip, Redirects oder Adblock/ublock.

Auf dem Computer wurden zwei Webanwendungen bereitgestellt, und beide liefen einwandfrei. Kürzlich haben wir eine der Anwendungen mit Änderungen an zwischengespeicherten Assets bereitgestellt. Sobald die Bereitstellung abgeschlossen ist, haben wir sofort den ERR_SPDY_PROTOCOL_ERROR Von Chrome erhalten. Interessanterweise erhielt es einen HTTP 200 Und wenn Sie direkt zu dem Asset navigierten, würde Chrome) das Asset rendern. Das Laden des Assets auf einer Seite würde jedoch dazu führen, dass es fehlschlägt .

Interessanterweise war die andere Webanwendung vollkommen in Ordnung. Bei der Untersuchung der Internet-Interna in Chrome haben wir festgestellt, dass der Server die Verbindung beendet. Nach einigen Stunden stellten wir fest, dass auf unserem Nginx-Server nicht mehr genügend Speicherplatz vorhanden war. Ich weiß nicht, warum das dazu führen würde, dass die Assets ordnungsgemäß geladen werden, wenn Sie direkt zu ihnen navigieren. Wenn Sie jedoch eine Seite laden, schlägt das fehl, aber das Entfernen von Speicherplatz behebt das Problem sofort.

9
Kyle Schutt

Ich hatte das gleiche Problem. Überprüfen Sie, ob Sie genügend Speicherplatz auf der Nginx-Partition/HDD haben. Wir fügen einige hinzu und es hat für uns funktioniert.

8
Simon Iribarren

Ich stieß auf diese Frage, als ich versuchte, Hilfe für das Problem zu finden, mit dem ERR_SPDY_PROTOCOL_ERROR in Chrome zu tun hatte. Dachte, das könnte anderen nützen.

Unsere Situation/Lösung: Wir verwenden einen AWS Application Load Balancer verbunden mit EC2 Instanzen. Eines der Scripts, die wir für EC2-Proxy-Anforderungen vom Client-Browser ausführen. Wir haben das Skript kürzlich aktualisiert (keine relevanten Änderungen) und festgestellt, dass sowohl Chrome- als auch Safari-Anforderungen an das Proxy-Skript fehlgeschlagen sind. Chrome zeigte den ERR_SPDY_PROTOCOL_ERROR-Fehler. Als wir uns eingehend damit befassten, konnten wir feststellen, dass diese Anfrage HTTP/2 verwendete. Firefox-Anfragen funktionierten weiterhin einwandfrei.

Unsere Lösung: Wir haben die HTTP/2-Unterstützung in der ALB deaktiviert. Löste das Problem umgehend.

AWS CLI-Befehl:

aws elbv2 modify-load-balancer-attributes --load-balancer-arn <your_load_balancer_arn> --attributes Key=routing.http2.enabled,Value=false
5
CharlesA

Wie Sie an den anderen Antworten erkennen können, können dies verschiedene Ursachen haben. Für mich hatte ich einen fehlerhaften Header, den andere Browser gerade ignorierten (ein zusätzlicher :). Die einzige Antwort auf diese Frage ist ein Debugging-Tipp: Überprüfen Sie die net-internals-Ereignisse von Chrome, während Sie die beschädigte Seite laden: chrome: // net-internals/# events

Als ich diese Zeile sah, wusste ich, dass es ein Header-Problem war

t=65422 [st=53]      HTTP_TRANSACTION_READ_HEADERS  [dt=4]
                 --> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR) 

Nachdem der zusätzliche : aus der Headerantwort entfernt wurde, begann HTTP/2 in Chrome zu arbeiten. Ich empfehle Ihnen, eine ungefähre Antwort von Ihrem Server zu erhalten und eine genaue Prüfung durchzuführen, um sicherzustellen, dass keine Syntaxfehler auftreten.

2
lightswitch05

Es scheint viele mögliche Ursachen zu geben. Eine, die ich heute getroffen habe, war die Kopfzeile 

add_header X-Frame-Optionen: verweigern;

Der aktuelle Chrome wird dies aus irgendeinem Grund mit ssl + http2 nicht zulassen. Andere X-Frame-Header scheinen kein Problem zu sein.

2
Hal Burgiss

Für mich war es die Nginx-Konfiguration, die die OPTIONS-Methode nicht zuließ. Ich hatte nur GET | PUT | POST | DELETE auf die Positivliste gesetzt. Wenn Chrome also versucht hat, die OPTIONS-Methode zu senden, wurde der Fehler reproduziert.

Öffnen Sie Firefox und wiederholen Sie die Anforderung. Überprüfen Sie anschließend im Netzwerkinspektor, ob OPTIONS-Anforderungen gesendet werden. 

** wahrscheinlich zur Überprüfung der X-Frame-Optionen oder der HSTS-Verifizierung.

2
Nj Subedi

Dies ist ein bekanntes Problem, das zwischen Chromium-Browsern und bestimmten Antivirenprogrammen wie AVG und Avast besteht, insbesondere bei Verwendung einer SSL-Verbindung. Es kann nicht vom Benutzer gelöst werden. Es liegt an den Website-Entwicklern, dieses Problem zu verhindern.

Die Dokumentation für Webentwickler ist hier: http://dev.chromium.org/spdy/spdy-best-practices

Hier sind einige hilfreiche Hinweise für Entwickler, die in diesem Artikel nicht ausdrücklich erwähnt werden:

  • Seien Sie äußerst vorsichtig, wenn Sie Header und Weiterleitungen verwenden, insbesondere 301 und 302
  • Behalten Sie alle Ihre Includes im oder unter demselben Verzeichnis wie der Zugriff auf Ihren Domänennamen, nicht über dem Verzeichnis auf dem Server. Antivirus kann dort nicht darauf zugreifen. Um Ihre Include-Dateien zu schützen, erstellen Sie eine .htaccess-Datei im Include-Verzeichnis und schreiben Sie einfach eine Zeile: Deny from all
  • Aktivieren Sie die Gzip-Komprimierung. Wenn Sie cPanel verwenden, können Sie dies in Ihren Website-Optimierungseinstellungen vornehmen.
  • Halten Sie Ihre .htaccess-Datei einfach. Das Wechseln der Serverausgaben zum Erstellen verschiedener Dateierweiterungen und das Umleiten von Benutzerclients führen zu unnötigen Konflikten.

Nach meiner Erfahrung scheint dieses Problem nur bei der Verwendung von Sitzungen zum Speichern und Übergeben von Daten aufzutreten. Cookies, Get und Post scheinen nicht betroffen zu sein.

Hoffe das hilft.

2
AnarchyOutlaw

Ich habe diesen Fehler kürzlich nach einem Server-Upgrade festgestellt.

Ich habe es für alle Benutzer in Chrome gesehen, aber nur zeitweise.

Ich konnte es für alle Benutzer beheben, indem ich sie dazu brachte, die Aktualisierungsfunktion "Leerer Cache und hartes Nachladen" von Chrome für die Website zu verwenden. (F12 für Chrome-Tools, Rechtsklick auf Aktualisieren)

Ich habe den Verdacht, dass es etwas mit den verwendeten SSL-Zertifikaten zu tun hat.

1
Josh

Ich hatte eine Site, die das tat. Es stellte sich heraus, dass jemand vergessen hatte, "Location:" in eine PHP -Reitung in die erste Zeile von index.php zu setzen, wodurch der Header ungültig wurde. Anscheinend kümmerte sich nur Chrome um den Rest der Browser.

1
David Bell

Wie beim OP war dies ein zeitweiliges Problem für mich und wurde nur auf AJAX - Anfragen> 2 MB in der Größe ausgeführt.

Das Problem trat auf, nachdem wir von einer klassischen AWS-ALB zu ALB übergegangen waren.

Ich habe das Problem gelöst, indem ich Chrome deinstallierte, mein Benutzerprofil löschte (auf dem Mac den Inhalt von ~/Library/Application Support/Google/Chrome lösche) und dann neu installiere.

0
greg

In meinem Fall habe ich das Problem gelöst, indem ich die Blockgröße vergrößert habe:

http2_chunk_size             300k;
0
iMartin

Überprüfen Sie den Speicherort des Proxy-Cache-Pfads. Überprüfen Sie, ob er vorhanden ist, über genügend Speicherplatz verfügt und dass die Berechtigungen und der Besitzer dem Prozess nginx das Schreiben in den Pfad gestatten.

z.B. nginx.conf (snippet)

proxy_cache_path /proxy_cache levels=1:2 keys_zone=danger_zone:10m inactive=60m;

... dann prüfen, ob der /proxy_cache-Pfad von nginx besessen und beschreibbar ist.

0
Nick Grealy