NGINX Reverse Proxy: много html-кода состояния 400 ответов, почему?

Недавно мы реализовали обратный прокси на основе 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

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

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 результатов.

Спасибо!

Другие URL-адреса, детализирующие похожие записи в их журналах:

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

Ответ 1

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

Здесь дополнительная информация: http://www.ruby-forum.com/topic/2953545

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

Ответ 2

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

Ответ 3

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

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