Nginx 502 Bad Gateway. Решается путем увеличения буфера. Зачем?

Я собираюсь создать стек LEMP для запуска Drupal. Я установил Nginx и PHP-FastCGI.

Nginx работал нормально, но любые попытки запустить PHP дали мне ошибку "502 Bad Gateway".

Быстрый Google показал: nginx 502 bad gateway, и увеличение размера буфера решило проблему.

Из предыдущей ссылки, казалось бы, nginx отправлял запросы на PHP-FastCGI, и он не отвечал. Как насчет этих запросов сделали тайм-аут?

У него не было достаточно времени, чтобы ответить, потому что php был сложным (это было не так, это было phpinfo();). Теперь я увеличил буфер, когда мне следует беспокоиться о необходимости повторного увеличения буфера?

Ответы

Ответ 1

Если вы проверите журнал ошибок nginx, скорее всего, вы увидите это сообщение:
upstream sent too big header while reading response header from upstream

fastcgi_buffers устанавливает количество и размер памяти сегментов буфера, используемых для ответа восходящего потока FastCGI.

Значения по умолчанию, представленные в документации:
fastcgi_buffers 8 4k|8k;
где размер буфера по умолчанию равен PAGESIZE вашей операционной системы.
getconf PAGESIZE позволяет получить текущий размер страницы памяти.

Например, в Ubuntu 14.01 значение PAGESIZE по умолчанию составляет 4 КБ. Это означает, что у вас есть 8 сегментов по 4 КБ каждый. Всего 32 КБ. Ответ FastCGI больше этого числа, поэтому мы получаем код ответа 502 - server received

Это не очень хорошее объяснение, но оно поможет вам лучше понять, я надеюсь.

Ответ 2

На самом деле, проблема напрямую связана только с fastcgi_buffer_size. Это очень специальный буфер, который содержит только заголовки HTTP из ответа.

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

Чтобы понять, как вам нужно увеличить его, вы можете прочитать мою сверхдетальную запись здесь - это о proxy_buffer_size, но буферы fastcgi_ ведут себя очень похоже. Процитируем основную команду:

curl -s -w \%{size_header} -o /dev/null https://example.com

Убедитесь, что вы проверили правильный URL-адрес, и добавьте заголовки запросов через -H, если это необходимо.

Это даст вам размер заголовка в байтах. Затем вам нужно будет выровнять полученное значение до 4 Кб (типичный размер страницы памяти).

Так что, если вы получили, например, 14342 байта, тогда его необходимо установить:

fastcgi_buffer_size 16k;

Сложная задача не в этом, а в том, что когда вы увеличиваете этот размер буфера, вам нужно увеличить либо fastcgi_buffer_size и/или fastcgi_busy_buffers_size, так как NGINX использует/вычисляет значение по умолчанию для последнего.

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