Was verursacht einen 400 Bad Request-Fehler für null ("") und warum sollten unsere Nginx-Protokolle so viele haben?

Tägliche Protokolle von Logwatch melden regelmäßig 400 fehlerhafte Anfragen, null: 1744 Zeit (en) aus unseren Nginx-Protokollen.

Die Protokolleinträge sehen folgendermaßen aus:

123.123.123.123 - - [25/Jan/2011:14:44:19 -0500] "-" 400 173 "-" "-"

Kann jemand erklären, wie diese erzeugt werden und warum es so viele gibt? Es scheint nichts zu tun, aber wir haben bis zu 8000 pro Tag erscheinen lassen. Wir hosten eine mittelgroße Rails-Anwendung, die auf Unicorn und Nginx ausgeführt wird.

Es gibt einige Diskussionen im Nginx-Forum, aber ich habe keine echte Lösung gefunden, die die Anzahl der 400 protokollierten Bad Reqeusts verringert.

— Johnml
quelle

Welche IP-Adressen stellen die fehlerhaften Anfragen? Wie im Thread angegeben, handelt es sich möglicherweise um ein Überwachungsprogramm, das nur eine TCP-Verbindung öffnet.

— Mark Wagner

Es gibt viele IP-Adressen. Die meisten haben eine Sitzung, die normalen Webverkehr mit diesen 400 gemischt enthält. Ich glaube, ich habe die Aktivitäten von IE-Browsern nur in Beispielen gesehen, in denen ich mich auf den Datenverkehr einer Sitzung konzentriert habe.

— Johnml

Ich habe auf meinem Server festgestellt, dass die Verwendung von Firefox für den Zugriff auf eine Seite immer genau 5 Sekunden nach der letzten gültigen Anforderung eines dieser leeren 400 Protokolle ergibt, während Firebug keine Fehler anzeigt. Dies verleiht der Antwort von @ Avleen Glaubwürdigkeit.

— Phrogz

Dies ist häufig der Fall, wenn ein Browser Keep-Alive verwendet und das Keep-Alive-Timeout erreicht. Es ist ganz normal.

Wenn Sie 400 Fehler mit einem URI / Pfad / einer Methode wie GET oder POST usw. sehen, haben Sie ein berechtigtes Problem mit einem Benutzer, der eine schlechte Anfrage stellt. Aber das sollte selten sein.

— Avleen
quelle