Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

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)

share|improve this question
add comment

migrated from stackoverflow.com Dec 19 '11 at 18:49

This question came from our site for professional and enthusiast programmers.

2 Answers

up vote 4 down vote accepted

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.

share|improve this answer
    
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 Dec 19 '11 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 May 2 '13 at 9:31
add comment

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.

share|improve this answer
    
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 May 2 '13 at 9:25
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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