Как исправить, что nginx выбрасывает 400 неверных заголовков запросов на любые инструменты тестирования заголовков?

У меня есть мой сайт, который использует nginx, и сайт тестирования с инструментами для тестирования заголовков, например, http://www.webconfs.com/http-header-check.php но каждый раз, когда он говорит, что 400 плохих запросов ниже - это результат работы инструмента, Хотя все мои страницы прекрасно загружаются в браузере, и когда я вижу в консоли Chrome, он говорит код состояния 200OK.

HTTP/1.1 400 Bad Request => 
Server => nginx
Date => Fri, 07 Sep 2012 09:40:09 GMT
Content-Type => text/html
Content-Length => 166
Connection => close

Я действительно не понимаю, в чем проблема с моим сервером конфигурации?

Немного поиска в Google предлагает увеличить размер буфера с помощью, и я увеличил его до следующего:

large_client_header_buffers 4 16k;

Те же результаты сохраняются.

Кто-нибудь может направить меня в правильном направлении?

Источник

9 ответов

Решение

Как заявил Максим Дунин в комментариях выше:

Когда nginx возвращает 400 (Bad Request), он регистрирует причину в журнале ошибок на уровне "info". Следовательно, очевидный способ выяснить, что происходит, - это настроить error_log для регистрации сообщений на уровне "info" и просматривать журнал ошибок при тестировании.

Источник

Да, изменив уровень error_to отладки, как предложил Эммануэль Джубо (edit /etc/nginx/sites-enabled/default):

        error_log /var/log/nginx/error.log debug;

Затем после перезапуска nginx я попал в журнал ошибок с моим приложением Python, используя uwsgi:

        2017/02/08 22:32:24 [debug] 1322#1322: *1 connect to unix:///run/uwsgi/app/socket, fd:20 #2
        2017/02/08 22:32:24 [debug] 1322#1322: *1 connected
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream connect: 0
        2017/02/08 22:32:24 [debug] 1322#1322: *1 posix_memalign: 0000560E1F25A2A0:128 @16
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream send request
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream send request body
        2017/02/08 22:32:24 [debug] 1322#1322: *1 chain writer buf fl:0 s:454
        2017/02/08 22:32:24 [debug] 1322#1322: *1 chain writer in: 0000560E1F2A0928
        2017/02/08 22:32:24 [debug] 1322#1322: *1 writev: 454 of 454
        2017/02/08 22:32:24 [debug] 1322#1322: *1 chain writer out: 0000000000000000
        2017/02/08 22:32:24 [debug] 1322#1322: *1 event timer add: 20: 60000:1486593204249
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http finalize request: -4, "/?" a:1, c:2
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http request count:2 blk:0
        2017/02/08 22:32:24 [debug] 1322#1322: *1 post event 0000560E1F2E5DE0
        2017/02/08 22:32:24 [debug] 1322#1322: *1 post event 0000560E1F2E5E40
        2017/02/08 22:32:24 [debug] 1322#1322: *1 delete posted event 0000560E1F2E5DE0
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http run request: "/?"
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream check client, write event:1, "/"
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream recv(): -1 (11: Resource temporarily unavailable)

Затем я взглянул на свой журнал uwsgi и обнаружил, что:

        Invalid HTTP_HOST header: 'www.mysite.local'. You may need to add u'www.mysite.local' to ALLOWED_HOSTS.
        [pid: 10903|app: 0|req: 2/4] 192.168.221.2 () {38 vars in 450 bytes} [Wed Feb  8 22:32:24 2017] GET / => generated 54098 bytes in 55 msecs (HTTP/1.1 400) 4 headers in 135 bytes (1 switches on core 0)

И добавление www.mysite.local в settings.py ALLOWED_CONFIGS устранило проблему:)

        ALLOWED_HOSTS = ['www.mysite.local']
Источник

У меня была такая же проблема, и я пробовал все. Этот 400произошло для прокси-сервера верхнего уровня. Журнал отладки абсолютно ничего не показал.

Проблема была в двух экземплярах proxy_set_header Host $http_hostдиректива, которую я изначально не заметил. Удаление дубликата сразу решило проблему. Хочу nginx говорил что-то кроме 400 в этом сценарии, как nginx -t вообще не жаловался.

PS это произошло при переходе со старого nginx 1.10 к новее 1.19. Раньше это, видимо, терпели.

Источник

Просто чтобы прояснить, в /etc/nginx/nginx.conf вы можете поместить в начале файла строку

error_log /var/log/nginx/error.log debug;

А затем перезапустите nginx:

sudo service nginx restart

Таким образом, вы можете подробно описать, что делает nginx и почему он возвращает код состояния 400.

Источник

Причиной может быть неправильная кодировка в запросе URL. Например,% передается в незашифрованном виде.

Источник

Когда nginx возвращает 400(неверный запрос), он записывает причину в журнал ошибок на уровне "информации" и просматривает журнал ошибок при тестировании.

Источник

В моем случае проблема заключалась в том, что порт 443 не был открыт в маршрутизаторе.

Источник

Если вы получаете журнал так же, как это:

      client xx.xx.xx.xx closed keepalive connection

Для этой проблемы:«Подключение: обновление» вызывает ошибку 400, которая никогда не достигает кода приложения. Запускается общей конфигурацией nginx. №17081

просто установитеproxy_set_header Connection $http_connection

Источник

Обычно метод Максима Донни может найти причину. Но я столкнулся с одним 400 плохим запросом не будет входить в err_log. Я нашел причину с помощью tcpdump

Источник
Другие вопросы по тегам