Ci-dessous une petite partie de mon access_log
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
05
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
06
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
07
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
08
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
09
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
10
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
11
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
12
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
13
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
14
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
Et le volume était très énorme, environ cent mille de ces 400 demandes par seconde. Et je suis à peu près sûr qu'il n'y a pas d'erreur sur mon site pendant cette période (aucun rapport d'erreur et je n'ai pas changé le code source).
Quelqu'un était Fuzzing votre serveur. Voir aussi Wikipedia .
Cela consiste essentiellement à envoyer des blocs rapides de données non valides pour voir si quelque chose se brise.
Nginx est configuré pour renvoyer une erreur d'erreur 400 lorsqu'aucune demande de données n'est envoyée.
Ne t'inquiète pas pour ça. Nginx peut simplement continuer à les faire rebondir pour toujours sans se mettre à suer.
Vérifiez si l'adresse IP à l'origine du 400 utilise Google Chrome. Chrome utilise la pré-connexion pour établir plusieurs connexions avec le serveur et les ferme si elles ne sont pas utilisées.
Comme aucune demande n’est faite dans la connexion, nginx enregistrera cette erreur.