Как да решим проблеми с вашата интернет връзка

По-долу има малка част от моя 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 '-' '-' 

И обемът беше много огромен, някои като сто хиляди от тези 400 заявки в секунда. И съм почти сигурен, че няма грешки на сайта ми през този период от време. (Няма отчет за грешка и не съм променил изходния код)

Някой смущава сървъра ви. Вижте и Уикипедия.

По принцип включва изпращане на бързи блокове от невалидни данни, за да се види дали нещо се прекъсва.

Nginx е настроен да връща грешка от 400 грешки, когато не се изпращат данни за заявка.

Не се тревожете за това. Nginx може просто да ги подскача завинаги, без да се поти.

  • Единственото нещо, за което ще трябва да се притеснява, е регистрационните файлове, поглъщащи дисково пространство. Тук е полезно правилното завъртане на дневника.
  • Същият проблем тук. Размерът на различните IP адреси не прави атака (размиване) много вероятна според мен. Все още търся по-добро обяснение.

Проверете и вижте дали ip адресът, причиняващ 400, използва Google Chrome.Chrome използва предварителна връзка, за да установи няколко връзки със сървъра и да ги затвори, ако не се използва.

Тъй като не се прави заявка във връзката, nginx ще запише тази грешка.

  • Тук виждам същия проблем и имам абсолютно същия формат на регистрационния файл, така че предполагам, че OP не е променил подразбирането. Което означава, че низът на потребителския агент се регистрира - случва се така, че не съдържа никаква стойност. Така че не съм сигурен как да проверя дали тези клиенти използват Chrome. Аз самият не можах да възпроизведа тази грешка в дневника с помощта на Chrome 26 точно сега. Някакви други намеци?
  • Потребителският агент се изпраща като заглавка на заявка, освен ако / докато не бъде направена заявка, nginx няма средства да знае и регистрира низа на потребителския агент. Можете обаче да проверите други записи в дневника, които идват от този IP адрес, и ако всъщност е направена някаква действителна заявка от този клиент, да научите дали това е Chrome или не.

е работил за вас: Charles Robertson | Искате ли да се свържете с нас?