Ответ сервера прерывается на полпути

Ответ 1

У меня была та же проблема:

Nginx отключил некоторые ответы от бэкэнда FastCGI. Например, я не смог создать надлежащую резервную копию SQL из PhpMyAdmin. Я проверил журналы и нашел это:

2012/10/15 02:28:14 [crit] 16443 # 0: * 14534527 open() "/usr/local/nginx/fastcgi_temp/4/81/0000004814" не удалось (13: Разрешение denied) при чтении вверх по течению, клиент: *, сервер:, запрос: "POST/ HTTP/1.1", вверх по течению: "fastcgi://127.0.0.1: 9000", хост: "", referrer: "http:// */server_export.php? токен = **"

Все, что я должен был сделать, чтобы исправить это, это предоставить правильные разрешения для папки /usr/local/nginx/fastcgi_temp, а также client_body_temp.

Исправлено!

Спасибо большое samvermette, ваш вопрос и ответ поставили меня на правильный путь.

Ответ 2

Посмотрел мой nginx error.log файл и нашел следующее:

13870 open() "/var/lib/nginx/tmp/proxy/9/00/0000000009" failed (13: Permission denied) while reading upstream...

Похоже, прокси-сервер nginx пытался сохранить содержимое ответа (передано тонким) в файл. Это происходит только тогда, когда размер ответа превышает proxy_buffers (по 64 кбайт по умолчанию на платформе 64 бит). Таким образом, в конце ошибка была связана с моим размером ответа запроса.

Я закончил исправление моей проблемы, установив proxy_buffering в off в мой конфигурационный файл nginx вместо того, чтобы поднимать proxy_buffers или исправлять проблему с разрешением файла.

Все еще не уверен в цели буфера nginx. Я был бы признателен, если бы кто-нибудь мог это добавить. Отключает буферизацию полностью плохую идею?

Ответ 3

У меня была похожая проблема с сокращением ответа от сервера.

Это произошло только тогда, когда я добавил заголовок json перед возвратом ответа header('Content-type: application/json');

В моем случае gzip вызвал проблему.

Я решил это, указав gzip_types в nginx.conf и добавив application/json в список перед включением gzip:

gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript application/json;
gzip on;

Ответ 4

Возможно, у вас закончилось inodes, что предотвращает неправильное использование NginX каталога fastcgi_temp.

Попробуйте df -i, и если у вас есть 0% inodes бесплатно, эта проблема.

Попробуйте find /tmp -mtime 10 (старше 10 дней), чтобы узнать, что может заполнить ваш диск.

Или, может быть, это другой каталог со слишком большим количеством файлов. Например, перейдите в /home/www -data/example.com и посчитайте файлы:

find . -print | wc -l

Ответ 5

Спасибо за вопрос и отличные ответы, это спасло меня много времени. В конце концов, ответ clement и sam помог мне решить мою проблему, поэтому кредиты идут к ним.

Просто хочу отметить, что после прочтения немного о теме, кажется, не рекомендуется отключать proxy_buffering, поскольку это может привести к остановке вашего сервера, если у клиентов (пользователя вашей системы) плохое подключение к Интернету для пример.

Я нашел эту дискуссию, очень полезную для понимания большего. Пример Фрэнсиса Дейли дал мне понять:

Возможно, легче всего рассматривать весь процесс как цепочку процессов.

веб-браузер ведет переговоры с nginx по ссылке 1 МБ/с.  nginx говорит о восходящем сервере, более 100 Мбит/с.  сервер upstream возвращает 100 МБ контента в nginx.  nginx возвращает 100 МБ контента в веб-браузер.

При использовании proxy_buffering on nginx может содержать 100 МБ, поэтому   Соединение nginx-upstream может быть закрыто через 1 с, а затем nginx может   потратить 100 секунд на отправку контента в веб-браузер.

Если proxy_buffering выключен, nginx может принимать контент только с   той же скоростью, которую nginx может отправить в веб-браузер.

Веб-браузер не заботится о разнице - ему все еще требуется 100 s для получения всего содержимого.

nginx не заботится о разнице - ему все еще требуется 100 с отправьте контент в браузер, но он должен удерживать соединение до восходящего потока на 99 секунд.

Upstream действительно заботится о различии - что могло бы принять это 1 s на самом деле занимает 100 с; и за дополнительные 99 с, что восходящий сервер не обслуживая никаких других запросов.

Обычно: связь nginx-upstream быстрее, чем ссылка browser-nginx; и вверх по течению - более "тяжеловес", чем nginx; поэтому разумно позволить как можно быстрее.

Ответ 6

У нас была аналогичная проблема. Это было вызвано нашим сервером REST (DropWizard) с включенным SO_LINGER. При загрузке DropWizard отключил NGINX, прежде чем у него появилась возможность сбросить его буферы. JSON был > 8kb, и передний конец получил бы его усеченный.

Ответ 7

У меня также была эта проблема - разбор на стороне клиента JSON был неисправен, ответ был отрезан или еще хуже, ответ был устаревшим и был прочитан из некоторого случайного буфера памяти.

Пройдя несколько руководств - Обслуживание статического контента через POST из Nginx, а также Nginx: исправить ошибку "405 не разрешено" при использовании POST, обслуживающей статические, пытаясь настроить nginx для обслуживания простого файла JSON.

В моем случае мне пришлось использовать:

max_ranges 0;

чтобы браузер не получал смешных идей, когда nginx добавляет Accept-Ranges: bytes в заголовок ответа) , а также

sendfile off;

в моем блоке server для прокси-сервера, который обслуживает статические файлы. Добавление его в блок location, который, наконец, будет служить найденному файлу JSON, не помогло.

Другой способ защиты статического JSON также не должен забывать тип ответа:

charset_types application/json;
default_type application/json;
charset utf-8;

Другие поисковые запросы дали проблемы с правами на доступ к папке - nginx сокращает конец динамических страниц и кэширует их или проблемы с буферизацией прокси - Получение chunked запроса через nginx, но это было не мое дело.