10

Below are little part of my 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 "-" "-"

And the volume was very huge, some like one hundred thousand of these 400 request per second. And I'm pretty sure there are no errors on my site in that period of time.(No error report and I didn't change the source code)

Improve this question

2 Answers 2

Reset to default
5

Someone was Fuzzing your server. Also see Wikipedia.

Basically involves sending rapid blocks of invalid data to see if anything breaks.

Nginx is set to return a 400 error error when no request data is sent.

Don't worry about it. Nginx can just keep on bouncing them forever without breaking a sweat.

Improve this answer
2
  • The only thing he'll have to worry about is the log files absorbing disk space. This is where proper log rotation is helpful.
    – Justin Pearce
    Commented Dec 19, 2011 at 19:29
  • Same problem here. The amount of different IP addresses does not make an attack (fuzzing) very probable in my opinion. Still looking for a better explanation.
    – Oliver
    Commented May 2, 2013 at 9:31
2

Check and see if the ip address causing the 400 is using Google Chrome. Chrome uses pre-connection to establish several connection with server, and close them if not used.

Since no request is made in the connection, nginx will record this error.

Improve this answer
2
  • I'm seeing the same problem here, and I have exactly the same log file format so I assume that the OP didn't change the default. Which means that the user agent string is being logged - it just so happens that it does not contain any value. So I'm not sure how to check whether those clients are using Chrome. I myself couldn't reproduce this error in the log using Chrome 26 just now. Any other hints?
    – Oliver
    Commented May 2, 2013 at 9:25
  • User agent is sent as a request header, unless/until a request is made, nginx has no means to know and log the user agent string. You can, however, check other log records that came from that IP address and, if any actual request were in fact made by that client, learn whether it was Chrome or not.
    – Ivan Anishchuk
    Commented Jan 17, 2016 at 22:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.