Es gibt viele Situationen, in denen 499-Fehler im HTTP-Statuscode in den Protokolldatensätzen angezeigt werden. Eine Situation, auf die ich gestoßen bin, war, dass Nginx zu einem Backend zurückkehrte, das nie geöffnet werden konnte. Das war es Wort Die Anzahl der Abschnitte beträgt 0.
Es gibt immer wieder Benutzer, die berichten, dass das Website-System nicht mehr funktioniert, da die Online-Produkte schon lange nicht mehr geändert wurden, kann das Problem mit dem Frontend-Programm im Grunde genommen behoben werden, also dachte ich Die von der Get-Methode aufgerufene Schnittstelle ist nicht korrekt. Ich habe das zuständige Personal gefragt und sie sagten, es gäbe kein Problem. Um eindeutige Beweise zu erhalten, habe ich das zuständige Personal nach der Protokolldatei des Nginx-Servers gefragt Nach der Analyse stellte ich fest, dass es viele Fehler mit dem Fehlercode 499 im Protokoll gab, die etwa 1 % der Protokolldateien ausmachten, und dass dieser nur etwa 70 % aller Fehlerberichte ausmacht (siehe Abbildung unten). für alle Fehlerberichte), dann wird die Summe aller Fehlerberichte 1 % überschreiten, was immer noch eine sehr große Menge ist.
Was ist der 499-Fehler? Werfen wir einen Blick auf die Definition im Quellcode von NGINX:
ngx_string(ngx_http_error_495_page), /* 495, https-Zertifikatfehler */
ngx_string(ngx_http_error_496_page), /* 496, https kein Zertifikat * /
ngx_string(ngx_http_error_497_page), /* 497, http zu https */
ngx_string(ngx_http_error_404_page), /* 498, abgebrochen */
ngx_null_string, /* 499 , Client hat Verbindung geschlossen */
Sie können sehen, dass 499 „Client hat Verbindung geschlossen“ entspricht. Dies liegt höchstwahrscheinlich daran, dass die serverseitige Verarbeitungszeit zu lang ist und der Client „ungeduldig“ ist.
Gründe und Lösungen für den Nginx 499-Fehler
Öffnen Sie das access.log von Nginx und stellen Sie fest, dass HTTP1.1 499 0 in der letzten Übermittlung angezeigt wurde – ein solcher Fehler, suchen Sie nach Nginx 499 auf Baidu Error, the Das Ergebnis ist, dass der Client die Verbindung aktiv getrennt hat.
Aber nach meinem Test ist dies offensichtlich kein Client-Problem, da die Verwendung von Port + IP für den direkten Zugriff auf den Back-End-Server dieses Problem nicht aufweist. Später, als ich Nginx testete, stellte ich fest, dass der Beitrag Wird zweimal zu schnell übermittelt, wird 499 angezeigt, es scheint, dass Nginx die Verbindung des Clients aktiv ablehnt.
Aber ich kann bei der Suche nach verwandten Problemen keine Lösung finden. Ich habe bei Google gesucht und ein englisches Forum dazu gefunden:
proxy_ignore_client_abort on;
Ich weiß nicht, ob das sicher ist.
Das bedeutet, den Parameter zu konfigurieren Proxy_ignore_client_abort on;
bedeutet, dass der Proxyserver die Clientverbindung nicht aktiv schließen sollte.
Starten Sie Nginx mit dieser Konfiguration neu und das Problem ist tatsächlich gelöst. Es mangelt zwar ein wenig an Sicherheit, aber es ist viel besser, als den Server immer nicht finden zu können.
Ein weiterer Grund ist, dass ich später getestet habe, dass der Client die Verbindung tatsächlich geschlossen hat oder dass die Verbindung abgelaufen ist. Egal wie viel Zeitüberschreitung Sie eingestellt haben, es stellt sich heraus, dass dies nicht der Fall ist Genügend PHP-Prozesse. Bitte verbessern Sie das Problem der Anzahl der PHP-Prozesse. In der Standardtestumgebung werden nur 5 untergeordnete Prozesse geöffnet.
Das obige ist der detaillierte Inhalt vonVergleichende Erklärung des 499-Statuscodes in HTTP und des 499-Fehlers unter Nginx. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
