Размер буфера, очевидно, по-прежнему равен значению по умолчанию (4096), убедитесь, что вы работаете с правильным экземпляром. Вы также можете написать «-b 32k». Также убедитесь, что этот параметр (размер буфера) еще не установлен в каком-либо файле конфигурации.
Закинстер 08
Нет файла конфигурации. Все еще не работает :(
Kartik Rokde 08
8
uwsgi-docs.readthedocs.org/en/latest/ThingsToKnow.html вы пытаетесь подключиться к сокету uwsgi с использованием протокола http, в дополнение к этому параметры, указанные для императора, не наследуются, это только диспетчер процессов
roberto
@zakinster По какой-то причине формат значения с kне работал у меня. Пришлось предоставить полный номер. Не могу найти указателей на форматы, которые вы можете использовать здесь.
knowngarkin
Ответы:
214
Я также столкнулся с той же проблемой, следуя некоторому руководству. Проблема была в том, что я поставил вариант socket = 0.0.0.0:8000вместо http = 0.0.0.0:8000.
socketопция предназначена для использования с некоторыми сторонними маршрутизаторами (например, nginx), тогда как, когда httpопция установлена, uwsgi может принимать входящие HTTP-запросы и маршрутизировать их самостоятельно.
Я просто хотел бы прокомментировать это: uwsgi имеет параметры «http», «http-socket» и «socket». Я хотел вызвать скрипты cgi python; "розетка" была ответом.
NuclearPeon
В конфигурационном файле Nginx мы можем захотеть использовать это: include / etc / nginx / uwsgi_params; uwsgi_pass django_upstream;
Mennanov 03 фев.15,
4
Это неправильное решение. Что, если мы хотим использовать сокеты unix?
Фаршид,
2
@Farsheed, я только что описал, почему OP видит эту ошибку. Как это исправить, полностью зависит от вас. Это может быть socket = /tmp/myapp.sockили http = 0.0.0.0:8000что угодно, в зависимости от ваших потребностей.
Palasaty
1
Хотя этот ответ может решить проблему в некоторых ситуациях, я думаю, что правильный ответ в общем случае - это тот, который дал @Farsheed ниже.
Аугусто Дестреро
153
Правильное решение - не переходить на протокол HTTP. Вам просто нужно увеличить размер буфера в настройках uWSGI.
buffer-size=32768
или в режиме командной строки:
-b 32768
Цитата из официальной документации:
По умолчанию uWSGI выделяет очень маленький буфер (4096 байт) для заголовков каждого запроса. Если вы начнете получать «неверный размер блока запроса» в своих журналах, это может означать, что вам нужен больший буфер. Увеличьте его (до 65535) с помощью параметра размера буфера.
Если вы получаете «21573» в качестве размера блока запроса в своих журналах, это может означать, что вы используете протокол HTTP для связи с экземпляром, говорящим по протоколу uwsgi. Не делай этого.
Иногда вам нужно использовать протокол http, поскольку сокеты unix доступны только на локальном компьютере. Рассмотрим ситуацию, когда у вас есть несколько машин и отдельный балансировщик на них - вы должны использовать http-socketздесь.
Palasaty
@Palasaty или IP-сокет и uwsgiпротокол, тогда вы также можете получить ту же ошибку, что и OP
Андрей
2
@Palasaty, в любом случае, исправление размера буфера решит проблему!
Фаршид 01
При использовании nginx в качестве обратного прокси мне пришлось использовать http-socket. Все остальное выдавало «502 Bad Gateway», даже когда размер буфера был увеличен.
Hubro
Что касается цитируемой документации: «Если вы получаете '21573' в качестве размера блока запроса в своих журналах, это может означать, что вы используете протокол HTTP для связи с экземпляром, говорящим по протоколу uwsgi. Не делайте этого». Итак, ясно, что предложение неверное .... Кроме того, пользователь @Kartic уже пытался использовать опцию "-b" ...
LittleEaster
14
Я столкнулся с той же проблемой, пытаясь запустить ее под nginx, и следил за документами здесь . Важно отметить, что после переключения на nginx вы должны убедиться, что вы не пытаетесь получить доступ к приложению через порт, указанный параметром --socket, а скорее порт "прослушивания" в nginx.conf. Хотя ваша проблема описана по-разному, заголовок в точности совпадает с моей проблемой.
да я столкнулся с тем же самым. другими словами, я получил ошибку, когда локально скрутил порт, тогда как я мог успешно перейти к «местоположению» моего обратного прокси-сервера wsgi, как указано в моем `nginx.conf ', потому что протокол сервера wsgi на я выбрал сокет wsgi, а не http
danyamachine
14
Я мог бы исправить это, добавив --protocol = http в uwsgi
Как я могу настроить это в ini-файле настроек uWSGI? Моя конфигурация работает с вашим предложением, но только в командной строке.
Генри Линкс
2
@HenryLynx, просто добавьте protocol=httpв свой .iniфайл
151291
8
Эта ошибка отображается, когда сервер uWSGI использует uwsgiпротокол и пытается получить к нему доступ через httpпротокол curlнапрямую или через веб-браузер. Если вы можете, попробуйте настроить сервер uWSGI для использования httpпротокола, чтобы вы могли получить к нему доступ через веб-браузер или curl.
Существует также простой обратный прокси-сервер, uwsgi_proxyесли вам нужно получить доступ к своим приложениям через веб-браузер и т. Д. См. Более развернутый ответ https://stackoverflow.com/a/32893520/179581
Если вы получаете «21573» в качестве размера блока запроса в своих журналах, это может означать, что вы используете протокол HTTP для связи с экземпляром, говорящим по протоколу uwsgi. Не делай этого.
Если вы используете Nginx, это произойдет, если у вас есть эта конфигурация (или что-то подобное):
proxy_pass http://unix:/path/to/socket.sock
это говорит HTTP с uWSGI (что делает его сварливым). Вместо этого используйте:
gzip дальше; gzip_comp_level 2; gzip_min_length 1000; gzip_proxied с
истекшим сроком действия частной аутентификации без кеширования без хранилища; gzip_types text / plain application / x-javascript text / xml text / css application / xml; gzip_vary on;
#gzip_proxied любой; #gzip_comp_level 6; gzip_buffers 16 8k; gzip_http_version 1.1; #gzip_types text / plain text / css application / json application / javascript text / xml application / xml application / xml + rss text / javascript;
k
не работал у меня. Пришлось предоставить полный номер. Не могу найти указателей на форматы, которые вы можете использовать здесь.Ответы:
Я также столкнулся с той же проблемой, следуя некоторому руководству. Проблема была в том, что я поставил вариант
socket = 0.0.0.0:8000
вместоhttp = 0.0.0.0:8000
.socket
опция предназначена для использования с некоторыми сторонними маршрутизаторами (например, nginx), тогда как, когдаhttp
опция установлена, uwsgi может принимать входящие HTTP-запросы и маршрутизировать их самостоятельно.источник
socket = /tmp/myapp.sock
илиhttp = 0.0.0.0:8000
что угодно, в зависимости от ваших потребностей.Правильное решение - не переходить на протокол HTTP. Вам просто нужно увеличить размер буфера в настройках uWSGI.
или в режиме командной строки:
Цитата из официальной документации:
Отсюда: https://uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html
источник
http-socket
здесь.uwsgi
протокол, тогда вы также можете получить ту же ошибку, что и OPhttp-socket
. Все остальное выдавало «502 Bad Gateway», даже когда размер буфера был увеличен.Я столкнулся с той же проблемой, пытаясь запустить ее под nginx, и следил за документами здесь . Важно отметить, что после переключения на nginx вы должны убедиться, что вы не пытаетесь получить доступ к приложению через порт, указанный параметром --socket, а скорее порт "прослушивания" в nginx.conf. Хотя ваша проблема описана по-разному, заголовок в точности совпадает с моей проблемой.
источник
Я мог бы исправить это, добавив --protocol = http в uwsgi
источник
protocol=http
в свой.ini
файлЭта ошибка отображается, когда сервер uWSGI использует
uwsgi
протокол и пытается получить к нему доступ черезhttp
протоколcurl
напрямую или через веб-браузер. Если вы можете, попробуйте настроить сервер uWSGI для использованияhttp
протокола, чтобы вы могли получить к нему доступ через веб-браузер или curl.Если вы не можете (или не хотите) изменять его, вы можете использовать обратный прокси (например
nginx
) перед локальным или удаленным сервером uWSGI, см. Https://uwsgi-docs.readthedocs.org/en/latest/Nginx .htmlЕсли кажется, что работы слишком много, попробуйте
uwsgi-tools
пакет python:Существует также простой обратный прокси-сервер,
uwsgi_proxy
если вам нужно получить доступ к своим приложениям через веб-браузер и т. Д. См. Более развернутый ответ https://stackoverflow.com/a/32893520/179581источник
Как указано в другом комментарии из документов:
Если вы используете Nginx, это произойдет, если у вас есть эта конфигурация (или что-то подобное):
это говорит HTTP с uWSGI (что делает его сварливым). Вместо этого используйте:
источник
человек, у меня такая же проблема; так что я сделал это ... посмотрите, используя UWSGI + DJANGO + NGINX + REACT +
1 - нано /etc/uwsgi/sites/app_plataform.ini [uwsgi]
2 - сделать серьезный апгрейд производительности на nginx ... пользовательские www-данные;
3 - затем ... перезапустите службы или сервер reebot ...
источник