Обратный прокси-сервер NGINX: много ответов html-кода статуса 400, почему?

Question

Недавно мы внедрили обратный прокси на основе nginx.

Пока мы отлаживаем наши журналы доступа, мы видим довольно много результатов с кодом состояния 400.

Они выглядят примерно так:

[07/Sep/2011:05:49:04 -0700] - "400" 0 "-" "-" "-"

Мы включили ведение журнала ошибок отладки, и они обычно соответствуют примерно так:

2011/09/07 05:09:28 [info] 5937#0: *30904 client closed prematurely connection while reading client request line

Мы попытались увеличить число буферов, как упоминалось на нескольких страницах.мы смогли погуглить.

http://www.ruby -forum.com / topic / 173362

или

http://blog.craz8.com/articles/2009/06/17/nginx-400-bad-request-errors-due-to-cookies-and-what-to-do-about-them

Безрезультатно.

Почему это происходит?

Это стандартный обратный прокси-сервер nginx -> внутренний сервер apache.

Стоит упомянуть уникальный тип контентана нашем сайте достаточно минимально.Мы проверили это с использованием многих браузеров и лично не получили ни одного из этих 400 результатов.

Спасибо!

---

Дополнительные ссылки с подробным описанием аналогичных записей в их журналах:

http://blog.rayfoo.info/2009/10/weird-web-server-access-log-entries

Answer 1

Я обнаружил, что это было вызвано использованием Chrome, которое иногда открывает дополнительные соединения без отправки каких-либо данных.

Вот еще немного информации: http://www.ruby -forum.com / topic / 2953545

Теперь вопрос в том, что с ними делать - ответ при условии, что это не очень удовлетворительно.

Answer 2

Вы обрабатываете SSL-соединения?Можете ли вы добавить $ssl_cipher $ssl_protocol в ваш журнал доступа?

Answer 3

Во-первых, вполне вероятно, что ваши клиенты отправляют запросы с действительно большими http-заголовками или URL-адресами. Возможно, старая версия вашего приложения установила некоторые (возможно, большие) файлы cookie, которые сейчас не используются, и некоторые клиенты все еще пытаются отправить их обратно.

Я бы установил действительно большие значения для буферов заголовков и на стороне приложения регистрировал бы размер заголовков / запросов и полный запрос, если они больше, чем обычно. Или полностью выньте nginx из цепочки и запишите заголовок / запрос с теми же условиями. Если вы можете, используйте nginx только для тех IP-адресов / подсетей, из которых произошли 400 ошибок. Я полагаю, что nginx может зарегистрировать IP-адрес источника для этих 400 ошибок.