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