Временные каталоги Nginx: client_body_temp, proxy_temp и быстрые диски

Если у вас высоконагруженный сайт, API с загрузками или обратным проксированием крупных ответов, то работу Nginx с временными файлами нельзя оставлять «по умолчанию». Вопрос не только в корректности загрузок, но и в производительности диска, задержках ответов, а также в управляемости рисками переполнения и OOM. Ниже разложим по полочкам, что такое client_body_temp, proxy_temp_path, fastcgi_temp, когда они задействуются и как оптимально их размещать на быстрых дисках и в tmpfs.

Зачем Nginx пишет во временные каталоги

Nginx буферизует и иногда временно сохраняет на диск данные запроса и ответа. Это делается по нескольким причинам:

• Защита приложения от «длинного» клиента: тело запроса (например, загрузка файла) можно принять полностью, а затем передать в upstream, не удерживая соединение надолго.
• Сглаживание скоростей: клиент медленный, а upstream быстрый (или наоборот). Буферы и временные файлы позволяют не блокировать обработку.
• Контроль памяти: большие тела и ответы не держатся полностью в RAM, а сбрасываются на диск при превышении порогов.

В основе лежат несколько каталогов:

• client_body_temp — для тел клиентских запросов (загрузки файлов, большие POST/PUT).
• proxy_temp, fastcgi_temp, uwsgi_temp, scgi_temp — для временного хранения ответов от соответствующих upstream-подсистем.

Где эти каталоги находятся «по умолчанию»

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

# Показать опции сборки, включая temp-path
nginx -V 2>&1 | tr ' ' '\n' | grep temp-path

# Проверить текущую конфигурацию на наличие явных директив путей
grep -R "_temp_path" /etc/nginx

Если явных директив в конфигурации нет, Nginx использует значения, зашитые на этапе сборки. Практика показывает: для прогнозируемости лучше явно задать каталоги в nginx.conf.

Когда создаются временные файлы

• Тело запроса (client body). Если размер тела больше client_body_buffer_size или включена буферизация запроса, Nginx пишет продолжение в client_body_temp. Это критично для загрузок.
• Ответ от upstream. При включённой буферизации (proxy_buffering on, аналогично для fastcgi_*) и недостатке буферов, части ответа могут уходить в proxy_temp или fastcgi_temp. Порог ограничивается proxy_max_temp_file_size и fastcgi_max_temp_file_size.

Важно понимать: дисковая активность возникает не только при огромных файлах. Даже «умеренные» размеры, помноженные на конкурентность, создают заметную нагрузку на i/o.

Базовая разметка: явные пути и каталоги

Задайте каталоги в секции http, создайте их и выставьте права под системного пользователя Nginx (чаще всего nginx или www-data):

http {
    client_body_temp_path /var/cache/nginx/client_temp 1 2;
    proxy_temp_path       /var/cache/nginx/proxy_temp 1 2;
    fastcgi_temp_path     /var/cache/nginx/fastcgi_temp 1 2;
    uwsgi_temp_path       /var/cache/nginx/uwsgi_temp 1 2;
    scgi_temp_path        /var/cache/nginx/scgi_temp 1 2;
}

# Создать каталоги и выдать права
install -d -m 0700 -o nginx -g nginx /var/cache/nginx/client_temp
install -d -m 0700 -o nginx -g nginx /var/cache/nginx/proxy_temp
install -d -m 0700 -o nginx -g nginx /var/cache/nginx/fastcgi_temp
install -d -m 0700 -o nginx -g nginx /var/cache/nginx/uwsgi_temp
install -d -m 0700 -o nginx -g nginx /var/cache/nginx/scgi_temp

Числа после путей — уровни подкаталогов для распределения сотен тысяч временных файлов равномерно по дереву директорий, снижая накладные расходы на файловую таблицу.

Диск против tmpfs: что выбрать

Есть три основных варианта хранения временных файлов:

• HDD. Дёшево, но высокая латентность и низкий IOPS. Подойдёт для редких крупных загрузок и невысокой конкурентности. Риск «узкого горла» при всплесках.
• SSD/NVMe. Оптимальный баланс латентности и стоимости. Нагрузка на i/o распределяется хорошо, особенно при большом количестве одновременных тел/ответов.
• tmpfs (RAM). Максимальная скорость и минимальная латентность. Но это оперативная память, т.е. вы расходуете RAM, рискуете OOM при неверной оценке размеров и теряете содержимое при перезапуске.

Правило: если объём временных данных предсказуем и ограничен, а задержки критичны — имеет смысл tmpfs. Если объём непредсказуем (публичные загрузки), надёжнее быстрый SSD/NVMe с чёткими limit-параметрами.

Как оценить требуемый объём

Прикиньте одновременное количество запросов, которые могут попасть во временное хранилище, и средний размер тела/сегмента ответа, который Nginx пишет на диск. Формула грубая, но полезная:

Объём = concurrency_uploads × avg_body_size × safety_factor

Где safety_factor не меньше 2. Для ответов от upstream используйте вероятные максимумы сегментов, которые не вместятся в буферы, учитывая proxy_buffers, proxy_buffer_size, proxy_busy_buffers_size и аналогичные fastcgi_*.

tmpfs: настройка и риски

Выделяем отдельный tmpfs для каждого типа временных файлов, чтобы одна очередь не вытеснила другую:

# /etc/fstab
# tmpfs для тел запросов
tmpfs /var/cache/nginx/client_temp tmpfs size=2g,mode=0700,noatime,nodev,nosuid,noexec 0 0
# tmpfs для proxy-ответов
tmpfs /var/cache/nginx/proxy_temp  tmpfs size=2g,mode=0700,noatime,nodev,nosuid,noexec 0 0
# tmpfs для fastcgi-ответов
tmpfs /var/cache/nginx/fastcgi_temp tmpfs size=1g,mode=0700,noatime,nodev,nosuid,noexec 0 0

mount -a

Обязательно задайте size= на уровне fstab, чтобы исключить неограниченный рост до всей RAM. Повесьте мониторинг на заполнение и логи Nginx: признак переполнения — ошибки с кодом 500 и записи вида «No space left on device».

Плюсы tmpfs — мгновенная запись и чтение, отсутствие износа дисков. Минусы — расход оперативной памяти, риск отказа при пике загрузок, потеря содержимого при перезапуске (обычно безопасно для временных файлов).

SSD/NVMe: отдельный раздел и опции монтирования

Если решено использовать диск, вынесите временные каталоги на отдельный раздел быстрых носителей (SSD/NVMe). Это даст:

• Изоляцию по пространству: переполнение не затронет систему и основной контент.
• Предсказуемое i/o и меньшую латентность по сравнению с HDD.

Рекомендации по монтированию:

• noatime,nodiratime — убирают обновление времени доступа.
• nodev,nosuid,noexec — базовая безопасность, исполнять тут нечего.
• Подходящая ФС: ext4 или xfs; обе отлично работают на SSD/NVMe. Для мелких файлов иногда удобнее xfs за счёт предсказуемости аллокаций, но ext4 тоже хороша.

Если нужен гарантированно быстрый NVMe и root-доступ для такой разметки, проще сразу брать VDS — вы сможете вынести temp-пути на отдельный раздел, задать монтирования и лимиты без ограничений типичного shared-хостинга.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Ключевые директивы Nginx, влияющие на запись на диск

Тела запросов

• client_max_body_size — максимальный размер тела запроса. Ограничьте, чтобы не принимать чрезмерные загрузки.
• client_body_buffer_size — объём RAM-буфера для тела. Увеличение снижает вероятность записи мелких тел на диск.
• client_body_temp_path — путь и структура каталогов для временных файлов тела запроса.
• client_body_in_file_only — принудительная запись тела в файл (обычно не требуется; полезно в специфичных сценариях).
• proxy_request_buffering и fastcgi_request_buffering — если off, Nginx стримит тело напрямую в upstream, минимизируя запись в client_body_temp, но увеличивая связность по времени между клиентом и upstream.

Ответы upstream

• proxy_buffering / fastcgi_buffering — включенная буферизация уменьшает backpressure на upstream, но может писать на диск при нехватке буферов.
• proxy_buffer_size, proxy_buffers, proxy_busy_buffers_size — размеры и количество буферов в памяти.
• proxy_max_temp_file_size / fastcgi_max_temp_file_size — ограничение размера временных файлов. 0 отключает запись ответа на диск (только RAM-буферы), что опасно при больших ответах.
• proxy_temp_file_write_size — размер порции записи во временный файл (влияет на паттерн i/o).
• proxy_temp_path, fastcgi_temp_path — пути к временным каталогам для ответов.

Шаблоны настройки под разные сценарии

1) Публичные загрузки файлов (форма на сайте)

• Оставьте буферизацию запросов включенной, чтобы не держать приложение открытым на «медленного клиента».
• Разместите client_body_temp на SSD/NVMe или в tmpfs с чётким лимитом.
• Настройте разумные пределы размера файла и буферов.

server {
    client_max_body_size 200m;
    client_body_buffer_size 128k;
    proxy_request_buffering on;
    location /upload {
        proxy_pass http://app;
    }
}

Здесь мелкие загрузки целиком пройдут через RAM-буфер, а крупные — частично уйдут в client_body_temp.

2) API с небольшими JSON, но высокой RPS

• Увеличьте client_body_buffer_size, чтобы исключить запись на диск в типовом случае.
• Можно включить proxy_request_buffering off, если приложение готово принимать поток и выдерживает «медленных клиентов».

server {
    client_body_buffer_size 64k;
    proxy_request_buffering off;
}

Так вы минимизируете i/o на client_body_temp, снизив задержки.

3) Проксирование больших ответов (отдача медиаконтента, архивов)

• Оставьте proxy_buffering on для сглаживания скоростей между upstream и клиентом.
• Повысьте размеры буферов и вынесите proxy_temp на быстрый носитель.
• Не ставьте proxy_max_temp_file_size 0, если возможны ответы больше суммарных буферов — получите 502/очереди.

location /download/ {
    proxy_pass http://files;
    proxy_buffering on;
    proxy_buffer_size 32k;
    proxy_buffers 64 64k;
    proxy_busy_buffers_size 256k;
    proxy_max_temp_file_size 2g;
}

Для раздачи больших файлов дополнительно пригодится материал про HTTP Range в Nginx и кешах, а для защиты ссылок — разбор secure_link с TTL и кешированием.

Обслуживание и мониторинг i/o

Проблемы с временными каталогами чаще всего проявляются как:

• Ошибки 500/502 при пиках трафика.
• Сообщения в error.log: «writev() failed (28: No space left on device)». Это прямой индикатор переполнения тома.
• Высокие задержки ответов и рост «зависших» соединений при медленных дисках.

Что мониторить регулярно:

• Заполненность разделов с client_body_temp и proxy_temp (df -h), особенно для tmpfs.
• Активность i/o по устройствам и ФС, латентность и очередь (например, утилиты системного мониторинга и метрики ядра).
• Количество временных файлов и скорость их создания/удаления.

# Быстрые проверки
df -h
iostat -x 1 5
iotop -oPa

Отдельно полезно сравнить поведение до и после изменения буферов (proxy_buffers, client_body_buffer_size) и местоположения каталогов.

Безопасность и изоляция

• Права 0700 на каталоги временных файлов. Внутри хранится потенциально чувствительное содержимое загрузок и ответа upstream.
• Разделяйте каталоги по типам: client_body_temp отдельно от proxy_temp, чтобы одно не вытеснило другое при пике.
• Если используете отдельный диск/раздел — монтируйте с nodev,nosuid,noexec.
• Не используйте общий /tmp без строгих ограничений — есть риск коллизий и непредсказуемого заполнения.

Частые ошибки

• Отключение дисковой буферизации без расчётов. Параметры вроде proxy_max_temp_file_size 0 и proxy_request_buffering off хороши в узких случаях. Для больших ответов/тел без достаточных RAM-буферов получатся 502 и очереди.
• Смешивание временных файлов и постоянного контента на одном разделе. Заполнение или деградация i/o ударит по всему сайту.
• Завышенные буферы в памяти. Большие значения «съедят» RAM. При тысячи одновременных соединений умножение сработает против вас.
• Недооценка конкуренции. 100 запросов по 10 МБ — это уже 1 ГБ потенциальных временных данных, не считая оверхеда.

Практический чек-лист

1. Явно задайте client_body_temp_path, proxy_temp_path, fastcgi_temp_path.
2. Вынесите их на SSD/NVMe или на tmpfs с ограничением size=. Для публичных загрузок предпочтительнее SSD/NVMe.
3. Поставьте права 0700, опции монтирования noatime,nodev,nosuid,noexec.
4. Ограничьте размеры: client_max_body_size, proxy_max_temp_file_size, fastcgi_max_temp_file_size.
5. Подберите буферы: client_body_buffer_size, proxy_buffers, proxy_buffer_size, proxy_busy_buffers_size.
6. Включите мониторинг заполнения разделов и ошибок i/o.
7. Нагрузочное тестирование: измерьте задержки с разными носителями и буферами.

Пример комплексной конфигурации

Вариант для проекта с публичными загрузками и крупными ответами от upstream. Временные каталоги — на отдельном SSD-разделе.

http {
    client_body_temp_path /mnt/ngx-temp/client 1 2;
    proxy_temp_path       /mnt/ngx-temp/proxy  1 2;
    fastcgi_temp_path     /mnt/ngx-temp/fcgi   1 2;

    client_max_body_size 200m;
    client_body_buffer_size 128k;

    server {
        listen 80;
        server_name example.local;

        # Загрузки
        location /upload {
            proxy_pass http://app;
            proxy_request_buffering on;
        }

        # Крупные ответы
        location /download/ {
            proxy_pass http://files;
            proxy_buffering on;
            proxy_buffer_size 32k;
            proxy_buffers 64 64k;
            proxy_busy_buffers_size 256k;
            proxy_max_temp_file_size 2g;
        }
    }
}

Плюс соответствующая разметка файловой системы, мониторинг заполнения /mnt/ngx-temp и тесты под нагрузкой.

Что с fastcgi_temp и PHP-FPM

В проектах на PHP большинство больших тел (загрузки) упираются в client_body_temp. Но ответы от PHP-FPM тоже могут буферизоваться и попадать во временные файлы при недостатке RAM-буферов. Для высокой конкурентности:

• Разместите fastcgi_temp на том же быстром носителе или в tmpfs с ограничением.
• Настройте fastcgi_buffer_size и fastcgi_buffers под средний размер HTML/JSON-ответов.
• Используйте fastcgi_max_temp_file_size для страховки по дисковому пространству.

Итоги

Временные каталоги Nginx — это не «мусорная корзина», а важный элемент конвейера i/o, влияющий на задержки и устойчивость сервисов. Явно задавайте пути, изолируйте по типам, используйте быстрые носители или аккуратный tmpfs, настраивайте буферы и жёсткие лимиты, не забывая о мониторинге. Такой подход убирает класс проблем «внезапно всё стало медленно» и даёт запас прочности при пиковых нагрузках.