Nginx uwsgi (104: Соединение reset от однорангового узла) при чтении заголовка ответа от восходящего потока

Ответ 1

Потратив много времени на это, я наконец понял это. Есть много ссылок на Nginx и сброс соединения по пиру. Большинство из них, похоже, были связаны с PHP. Я не смог найти ответ, относящийся к Nginx и uwsgi.

Я наконец нашел ссылку на fastcgi и ошибку 502 неверного шлюза (https://support.plesk.com/hc/en-us/articles/213903705). Это привело меня к поиску ограничения размера буфера в конфигурации uwsgi, которое существует как размер буфера. Значение по умолчанию 4096. Из документации написано:

Если вы планируете получать большие запросы с большим количеством заголовков, вы можете увеличить это значение до 64 КБ (65535).

Есть много способов настроить uwsgi, я использую файл .ini. Итак, в моем файле .ini я попытался:

buffer-size=65535

Это решило проблему. Вы можете настроить это по вкусу. Возможно, начните с максимума и продолжайте работу до тех пор, пока не получите приемлемое значение, или просто оставьте его на максимуме.

Это было неприятно отследить, потому что не было никакой ошибки в uwsgi стороне вещей.

Ответ 2

Мы просто увеличиваем значение атрибута "output_buffering" в php.ini до большего значения, например 65535, или другого подходящего значения.

Ответ 3

Я получал ту же ошибку nginx, а также не было информации в журнале uwsgi. Проблема заключалась в том, что в некоторых случаях приложение не потребляло весь орган запроса, как указано в http://uwsgi-docs.readthedocs.org/en/latest/ThingsToKnow.html:

Если HTTP-запрос имеет тело (например, POST-запрос, сгенерированный формой), вы должны его прочитать (использовать) в своем приложении. Если вы этого не сделаете, сокет связи с вашим веб-сервером может быть заблокирован. Если вы ленивы, вы можете использовать опцию пост-буферизации, которая автоматически будет считывать данные для вас. Для приложений Rack это автоматически активируется.

Конечно, это не проблема в вашем случае, но может быть полезно для тех, кто получает ту же ошибку nginx.

Ответ 4

Когда мы получаем сообщение типа (104: Connection reset by peer) while reading response header from upstream, чаще всего, мы можем обвинить вышеописанную сторону такого рода ошибок.

Как описано выше, соединение было reset с восходящим одноранговым узлом, а не с самим nginx. Nginx как клиент не может ничего сделать, чтобы сделать это правильно.

Я подозреваю, что изменение размера буфера сделает магию. В основном команда изменяет размер буфера, в котором кэшируются заголовки ответов. Это вступает в силу, если заголовок ответа слишком велик, и в этом случае мы получаем сообщение с сообщением upstream sent too big header while reading response header from upstream, и это совершенно другое дело от connection reset by peer.

Поскольку такой тип ошибки запускается случайным образом, я бы предложил вам проверить, использует ли nginx keepalive при обращении к восходящим потокам. Если это было так, соединение могло бы быть reset сервером восходящего потока, когда тайм-аут в режиме ожидания, в то время как nginx не знал, что соединение было удалено, следовательно, пересылка запроса с использованием того же соединения.

Там нет элегантного решения, чтобы исправить это, насколько я знаю. Вы можете повторить попытку или установить значение keepalive_timeout для пула соединений вверх по потоку в nginx, чтобы избежать проблемы.

реферирование:

Временная ошибка Apache HttpClient: NoHttpResponseException

http://tengine.taobao.org/document/http_upstream_keepalive_timeout.html

Ответ 5

--post-buffering 32768 работал у меня, как было предложено (и обескуражено) здесь NGINX + uWSGI Connection Reset by Peer

У меня нет времени, чтобы исследовать его дальше в настоящий момент (быстрый режим прототипирования:), но так как мне потребовалось много времени, чтобы найти этот хак, возможно, стоит опубликовать здесь.

Ответ 6

Вам нужно переустановить PHP:

apt-get install --reinstall php5-fpm