Während ich an meiner Kunden-Website arbeitete, die auf WooCommerce basiert, sah ich zufällig, dass die Checkout-Seite mit der Fehlermeldung „502 Bad Gateway“ fehlschlug. Ich vermutete, dass das Problem auf NGINX zurückzuführen sein könnte, und es stimmte zufällig. Das NGINX-Fehlerprotokoll lautete als 'Upstream hat zu großen Header gesendet, während der Antwortheader von der Upstream-Anfrage gelesen wurde:GET /checkout/ HTTP/1.1, Upstream:fastcgi://unix:/var/run/php-fpm/php- fpm.sock ‘. In diesem Tutorial werde ich erklären, worum es bei dem Fehler geht und wie man ihn behebt.
Was bedeutet der Fehler „Upstream hat beim Lesen einen zu großen Header gesendet Response Header von Upstream“ bedeuten?
Ich verstehe, dass die Seite einen zu großen Header zu senden scheint als die Kapazität des empfangenden Endes. Aber was war die Header-Größe, die für den Server zu groß war? Als die Seite, die ich erhielt, war der Fehler die Checkout-Seite, die 10 Artikel enthielt, die dem Warenkorb hinzugefügt wurden. Daher waren die Cookies und der Inhalt der Seite alle hoch und das hätte zu einer größeren Header-Größe führen können. Wie kann man also herausfinden, was die Antwortheader enthalten? Ganz einfach.
- Starten Sie den Chrome-Browser, klicken Sie mit der rechten Maustaste und wählen Sie
Inspect - Klicken Sie auf
NetworkRegisterkarte - Seite neu laden
- Wählen Sie eine der HTTP-Anforderungen im linken Bereich aus und sehen Sie sich die HTTP-Header im rechten Bereich an.
Das ist in Ordnung, Sie wissen, dass Sie die HTTP-Header anzeigen müssen. Aber warum ist der Server mit einem Fehler „Upstream hat zu großen Header gesendet, während der Antwortheader von Upstream gelesen wurde“ fehlgeschlagen? Nun, die Antwort ist, dass jeder Webserver eine maximale Header-Größe festgelegt hat und die gesendeten HTTP-Anforderungs-Header zu groß waren als die im Webserver festgelegte. Nachfolgend finden Sie die maximale Header-Größenbeschränkung auf verschiedenen Webservern.
- Apache-Webserver – 8K
- NGINX – 4K bis 8K
- IIS (je nach Version unterschiedlich) – 8 KB bis 16 KB
- Tomcat (je nach Version unterschiedlich):8K bis 48K.
Da der von mir verwendete Webserver NGINX ist, beträgt die Standardbeschränkung für die Header-Größe 4 KB bis 8 KB. Standardmäßig verwendet NGINX die Systemseitengröße, die in den meisten Systemen 4 KB beträgt. Sie können dies mit dem folgenden Befehl finden:
# getconf PAGESIZE 4096
Hier ist ein Ausschnitt, der die Größe des Antwortpuffers von NGINX FastCGI erklärt.
Wenn Nginx beginnt, eine Antwort von einem FastCGI-Backend (z. B. PHP-FPM) zu empfangen, puffert es die Antwort standardmäßig im Arbeitsspeicher, bevor sie an den Client gesendet wird. Jede Antwort, die größer als die festgelegte Puffergröße ist, wird in einer temporären Datei auf der Festplatte gespeichert.
Die beiden Parameter, die sich auf die Pufferung von FastCGI-Antworten beziehen, sind:
fastcgi_buffers
fastcgi_buffer_sizefastcgi_buffers – steuert die Anzahl und Speichergröße der Puffersegmente, die für die Nutzlast der FastCGI-Antwort verwendet werden.
fastcgi_buffer_size – steuert die Puffergröße, die früher den ersten Teil der fastCGI-Antwort aus den HTTP-Antwort-Headern enthielt.
Laut der NGNIX-Dokumentation müssen Sie den Standardwert der fastCGI-Antwortparameter nicht anpassen, da NGINX standardmäßig die kleinste Seitengröße von 4 KB verwendet und für die meisten HTTP-Header-Anfragen geeignet sein sollte. Allerdings scheint es in meinem Fall nicht zu passen. Dieselbe Dokumentation besagt, dass einige der Frameworks möglicherweise große Mengen an Cookie-Daten über Set-Cookie übertragen HTTP-Header und das könnte den Puffer sprengen, was zu einem HTTP 500-Fehler führt. In solchen Fällen müssen Sie möglicherweise die Puffergröße auf 8 KB/16 KB/32 KB erhöhen, um größere Upstream-HTTP-Header aufzunehmen.
Ermittlung der durchschnittlichen und maximalen vom Web empfangenen FastCGI-Antwortgrößen Server?
Das lässt sich herausfinden, indem Sie die NGINX-Zugriffsprotokolldateien durchsuchen. Führen Sie dazu den folgenden Befehl aus, indem Sie das access_log angeben Datei als Eingabe
$ awk '($9 ~ /200/) { i++;sum+=$10;max=$10>max?$10:max; } END { printf("Maximum: %d\nAverage: %d\n",max,i?sum/i:0); }' access.log
Probe auf meinem Webserver:
Maximum: 3501304 Average: 21065
Hinweis :Die HTTP 200-OK-Antwort wurde nur berücksichtigt.
Aus dem obigen Schnappschuss geht hervor, dass die durchschnittliche Puffergröße mehr als 21 KB beträgt. Daher müssen wir die Puffergröße etwas höher als die durchschnittliche Anforderung festlegen, die wahrscheinlich 32 KB betragen kann. Öffnen Sie dazu die Datei nginx.conf und fügen Sie die folgenden Zeilen unter location hinzu Abschnitt – location ~ \.php$ { }
fastcgi_buffers 32 32k; fastcgi_buffer_size 32k;
Hinweis :Möglicherweise müssen Sie einen niedrigeren Pufferwert festlegen. Ich hatte 32 KB eingestellt, da die durchschnittliche Größe über 21 KB lag.
Erfahren Sie hier mehr über FastCGI-Antwortpuffer.