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

У меня есть мой сайт, который использует nginx и сайт тестирования с инструментами тестирования заголовков, например. http://www.webconfs.com/http-header-check.php, но каждый раз, когда он говорит о 400 плохих запросах ниже, выдается из инструмента. Хотя все мои страницы загружаются отлично в браузере, и когда я вижу в консоли хром, он указывает код состояния 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

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

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

large_client_header_buffers 4 16k;

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

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

Ответ 1

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

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

Ответ 2

Да, изменение уровня ошибки на уровне отладки, как предложил Emmanuel Joubaud (изменить/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']

Ответ 3

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

Ответ 4

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

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

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

sudo service nginx restart

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

Ответ 5

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

Ответ 6

IP - - [20/Jun/2019: 15: 36: 59 +0500] "." 400 166 "-" "-"

Я сталкиваюсь с ошибкой выше, я делаю все изменения в /user.loval/nginx/con.d/nginx.com файл, но проблема