У меня есть мой сайт, который использует 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;
Те же результаты сохраняются.
Может ли кто-нибудь привести меня в правильном направлении?
Как заявил Максим Дунин в комментариях выше:
Когда nginx возвращает 400 (Bad Request), он будет регистрировать причину в ошибке log, на уровне "info". Отсюда очевидный способ узнать, что происходит заключается в настройке error_logдля регистрации сообщений на уровне "информация" и просмотра журнала ошибок, когда тестирование.
Да, изменение уровня ошибки на уровне отладки, как предложил 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']
Причиной может быть некорректная кодировка в запросе URL. Например,% пропускается без кодирования.
Просто чтобы прояснить, в /etc/nginx/nginx.conf вы можете поместить в начале файла строку
error_log /var/log/nginx/error.log debug;
А затем перезапустите nginx:
sudo service nginx restart
Таким образом, вы можете подробно описать, что делает nginx и почему он возвращает код состояния 400.
Обычно метод Максима Донни может найти причину. Но я столкнулся с одним 400 неудачным запросом, который не регистрируется в err_log. Я нашел причину с помощью tcpdump
IP - - [20/Jun/2019: 15: 36: 59 +0500] "." 400 166 "-" "-"
Я сталкиваюсь с ошибкой выше, я делаю все изменения в /user.loval/nginx/con.d/nginx.com файл, но проблема