Ускорение Nginx: основные буферы, сжатие и советы по кэшированию

Nginx быстр из коробки, но настройки по умолчанию намеренно консервативны. Они подходят для небольшого сайта, тестового сервера или обратного прокси с умеренным трафиком. Они не всегда являются лучшим выбором, когда вы начинаете обрабатывать большие куки, медленные апстримы, большие ответы API или статические ресурсы, которые загружаются тысячи раз в час.

Полезная настройка обычно сводится к трем областям: буферы, сжатие и кэширование. Буферы определяют, может ли Nginx хранить данные запроса и ответа в памяти или вынужден сбрасывать их во временные файлы. Сжатие определяет, сколько текстовых данных вы отправляете по сети. Кэширование определяет, могут ли Nginx и браузер избежать повторного выполнения той же работы. Ни одна из этих настроек не является магией. Плохое правило кэширования может привести к утечке приватного контента, а слишком большие буферы могут тратить память. Цель состоит в том, чтобы настраивать осознанно, тестировать с вашим реальным шаблоном трафика и поддерживать конфигурацию читаемой, чтобы следующий человек мог ее понять.

Оптимизация буферов Nginx для эффективной обработки данных

Nginx использует различные буферы для временного хранения данных во время обработки запросов и ответов. Правильный размер этих буферов имеет решающее значение для производительности. Неправильно подобранные буферы могут привести либо к чрезмерному потреблению памяти, либо к частой записи на диск (спулинг), что ухудшает производительность. Мы рассмотрим буферы, связанные с клиентом, и буферы прокси/FastCGI.

Буферы, связанные с клиентом

Эти буферы управляют данными, поступающими от клиента к Nginx.

• client_body_buffer_size: Эта директива устанавливает размер буфера для чтения тела запроса клиента. Если тело запроса превышает этот размер, оно будет записано во временный файл на диске. Хотя это предотвращает исчерпание памяти для больших загрузок, частая запись на диск может замедлить производительность.

  • Совет: Для типичных веб-приложений, которые не обрабатывают очень большие загрузки файлов через POST-запросы, 8k или 16k часто достаточно. Увеличьте, если вы обрабатываете большие формы или небольшие загрузки файлов напрямую через Nginx.

  http {
      client_body_buffer_size 16k;
      # ...
  }
  

• client_header_buffer_size: Определяет размер буфера для чтения заголовка запроса клиента. Один буфер выделяется для каждого соединения.

  • Совет: 1k является значением по умолчанию и обычно достаточно для большинства заголовков. Увеличивайте только в случае ошибок "client sent too large header", часто из-за большого количества куки или сложных заголовков аутентификации.

  http {
      client_header_buffer_size 1k;
      # ...
  }
  

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

  • Совет: 4 8k (4 буфера по 8 КБ каждый) является распространенной настройкой. Отрегулируйте, если вы постоянно видите ошибки заголовков после увеличения client_header_buffer_size.

  http {
      large_client_header_buffers 4 8k;
      # ...
  }
  

Буферы прокси и FastCGI

Эти буферы управляют данными, когда Nginx действует как обратный прокси или взаимодействует с бэкендом FastCGI (например, PHP-FPM).

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

• proxy_buffer_size: Размер буфера для первой части ответа, полученного от проксируемого сервера. Обычно он содержит заголовок ответа.

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

• proxy_busy_buffers_size: Устанавливает максимальный размер буферов, которые могут быть активными (занятыми) в любой момент времени, либо отправляя данные клиенту, либо читая с бэкенда. Это помогает предотвратить потребление Nginx слишком большого объема памяти за счет слишком долгого удержания буферов.

  • Пример для Proxy Pass: Для типичного веб-приложения proxy_buffer_size может соответствовать ожидаемому размеру заголовка, а proxy_buffers можно настроить для обработки средних размеров контента без записи на диск.

  http {
      proxy_buffer_size          128k;
      proxy_buffers              4 256k; # 4 буфера, каждый по 256 КБ
      proxy_busy_buffers_size    256k;
      # ...
  }
  

• fastcgi_buffer_size, fastcgi_buffers, fastcgi_busy_buffers_size: Эти директивы функционируют идентично своим аналогам proxy_, но применяются специально к ответам от серверов FastCGI.

  • Пример для FastCGI: Здесь применяется та же логика, адаптируйте под размеры ответов вашего PHP/FastCGI приложения.

  http {
      fastcgi_buffer_size        128k;
      fastcgi_buffers            4 256k;
      fastcgi_busy_buffers_size  256k;
      # ...
  }
  

Предупреждение: Установка слишком больших буферов приведет к потреблению большего объема ОЗУ на каждое соединение, что может быстро исчерпать память на загруженных серверах. Установка слишком маленьких буферов заставит Nginx записывать временные файлы на диск, что приведет к накладным расходам ввода-вывода. Следите за памятью вашего сервера и дисковым вводом-выводом, чтобы найти оптимальный баланс.

Включение эффективного сжатия с помощью Gzip

Сжатие контента, в основном с помощью Gzip, может значительно уменьшить размер передаваемых данных, что приводит к более быстрой загрузке страниц и снижению потребления пропускной способности. Модуль gzip Nginx является высококонфигурируемым.

Основные директивы Gzip

Добавьте эти директивы в блок http или конкретный блок server или location.

• gzip on;: Активирует сжатие Gzip.

• gzip_types: Указывает типы MIME, которые должны сжиматься. Только определенные текстовые типы значительно выигрывают от сжатия.

  • Лучшая практика: Включайте распространенные веб-типы, но избегайте сжатия изображений (image/*), видео (video/*) и уже сжатых файлов (.zip, .rar, .gz), так как это тратит циклы процессора без выгоды.

  gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
  

• gzip_proxied: Включает сжатие для проксируемых запросов на основе условий ответа и запроса. В основном полезно, когда Nginx находится перед сервером приложений или другим прокси.

  • any: сжимать проксируемые ответы, когда они в остальном подходят.
  • no-cache, no-store, private, expired, auth: сжимать только тогда, когда ответ или запрос соответствует этим условиям. Эти токены не являются флагами "не сжимать"; это условия, которые разрешают сжатие для проксируемых ответов.

  gzip_proxied any;
  

• gzip_min_length: Устанавливает минимальную длину тела ответа, которое Nginx будет сжимать. Небольшие файлы не сильно выигрывают от сжатия и могут даже стать больше из-за накладных расходов на сжатие.

  • Совет: Значение 1000 байт (1 КБ) или 256 байт является хорошей отправной точкой.

  gzip_min_length 1000;
  

• gzip_comp_level: Устанавливает уровень сжатия (1-9). Более высокие уровни обеспечивают лучшее сжатие, но потребляют больше ресурсов процессора. Более низкие уровни быстрее, но сжимают менее эффективно.

  • Совет: 4-6 является хорошим балансом между степенью сжатия и использованием процессора для большинства серверов.

  gzip_comp_level 5;
  

• gzip_vary on;: Указывает прокси кэшировать как сжатую, так и несжатую версии файла, в зависимости от заголовка Accept-Encoding, отправленного клиентом. Это важно для правильного кэширования и доставки.

  gzip_vary on;
  

• gzip_disable: Отключает сжатие для определенных браузеров или пользовательских агентов, которые могут иметь проблемы с Gzip.

  gzip_disable "MSIE [1-6]\."; # Пример: отключить для старых Internet Explorer
  

Соображения: Хотя Gzip очень полезен, сжатие потребляет циклы процессора. Для статических файлов, обслуживаемых непосредственно с диска (например, предварительно сжатых файлов .gz), Nginx может обслуживать их напрямую без повторного сжатия, что еще более эффективно. Для динамического контента Gzip обычно является чистым выигрышем.

Реализация умных стратегий кэширования

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

Кэширование в браузере (HTTP-заголовки)

Кэширование в браузере полагается на HTTP-заголовки, чтобы указать клиентским браузерам, как долго хранить статические ресурсы. Это предотвращает повторные загрузки неизменяемых ресурсов, таких как изображения, CSS и файлы JavaScript.

• expires: Простая директива для установки заголовков Expires и Cache-Control: max-age.

  location ~* \.(jpg|jpeg|gif|png|webp|ico|css|js|woff|woff2|ttf|otf|eot)$ {
      expires 365d; # Кэшировать на один год
      add_header Cache-Control "public, no-transform";
      # Опционально: отключить логи для статических файлов
      access_log off;
      log_not_found off;
  }
  

• add_header Cache-Control: Обеспечивает более детальный контроль над политиками кэширования. Распространенные значения включают:

  • public: Кэшируется любым кэшем (браузер, прокси).
  • private: Кэшируется только частным кэшем клиента (например, браузер).
  • no-cache: Должен повторно проверяться на сервере перед использованием, но может хранить копию.
  • no-store: Не кэшировать вообще.
  • max-age=<seconds>: Указывает, как долго ресурс считается свежим.

• Условные запросы (Etag и If-Modified-Since): Nginx автоматически обрабатывает заголовки Etag и Last-Modified для статических файлов, позволяя браузерам отправлять условные запросы (If-None-Match или If-Modified-Since). Если контент не изменился, Nginx отвечает 304 Not Modified, экономя пропускную способность.

Прокси-кэширование Nginx

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

1. Определение зоны кэша

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

http {
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m inactive=60m max_size=1g;
    # levels=1:2: Создает двухуровневую иерархию каталогов для файлов кэша (например, /var/cache/nginx/c/29/...). Помогает распределять файлы.
    # keys_zone=my_cache:10m: Определяет общую зону памяти с именем 'my_cache' размером 10 МБ для хранения ключей кэша и метаданных. Это важно для быстрого поиска.
    # inactive=60m: Кэшированные элементы, к которым не было доступа в течение 60 минут, будут удалены с диска.
    # max_size=1g: Устанавливает максимальный размер кэша на диске. При превышении Nginx удаляет наименее недавно использованные данные.
    # ...
}

2. Включение кэширования для местоположения

Внутри блока server или location вы включаете кэш и определяете его поведение.

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend_upstream; # Или http://127.0.0.1:8000;
        proxy_cache my_cache; # Использовать зону кэша, определенную выше
        proxy_cache_valid 200 302 10m; # Кэшировать успешные ответы (200, 302) на 10 минут
        proxy_cache_valid 404 1m;      # Кэшировать ответы 404 на 1 минуту
        proxy_cache_revalidate on;     # Использовать заголовки If-Modified-Since и If-None-Match для повторной проверки
        proxy_cache_min_uses 1;       # Кэшировать только если элемент был запрошен хотя бы один раз
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
                                       # Обслуживать устаревший контент, если бэкенд недоступен или обновляется

        # Добавить заголовок, чтобы увидеть, был ли ответ кэширован
        add_header X-Cache-Status $upstream_cache_status;

        # Опционально: обходить кэш для определенных условий
        # proxy_cache_bypass $http_pragma $http_authorization;
        # proxy_no_cache $http_pragma $http_authorization;
    }
}

Важные директивы кэширования

• proxy_cache_valid: Определяет правила кэширования на основе кодов состояния HTTP и продолжительности. Вы можете указать несколько правил.

• proxy_cache_revalidate on;: Позволяет Nginx использовать заголовки If-Modified-Since и If-None-Match при проверке, является ли кэшированный контент все еще свежим. Это более эффективно, чем просто позволить кэшу истечь.

• proxy_cache_use_stale: Мощная директива, которая указывает Nginx обслуживать устаревший (просроченный) контент из кэша, если бэкенд недоступен или медленный. Это значительно улучшает пользовательский опыт во время проблем с бэкендом.

• proxy_cache_bypass / proxy_no_cache: Используйте их для определения условий, при которых кэш должен быть обойден (например, для аутентифицированных запросов или определенных параметров запроса).

  # Пример: не кэшировать запросы с определенными параметрами запроса или куки
  # if ($request_uri ~* "(\?|&)nocache") { set $no_cache 1; }
  # if ($http_cookie ~* "SESSIONID") { set $no_cache 1; }
  # proxy_cache_bypass $no_cache;
  # proxy_no_cache $no_cache;
  

Очистка кэша

Чтобы вручную очистить кэш Nginx, вы можете просто удалить файлы в каталоге proxy_cache_path. Для более контролируемой инвалидации рассмотрите возможность использования модуля, такого как ngx_cache_purge, или настройте конкретное location для обработки запросов на инвалидацию кэша.

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

Практический план развертывания

Самый безопасный способ настройки Nginx — изменять по одному слою за раз. Начните с заголовков и статических ресурсов, потому что риск низок, а выгода очевидна. Добавляйте длительное время жизни кэша браузера только для версионированных файлов, таких как /app.8f3a2c.js или /styles.2025-11-02.css. Если имена ваших ресурсов не меняются при изменении файла, не кэшируйте их на год. Используйте более короткое значение expires или сначала исправьте конвейер сборки.

Затем включите Gzip для текстовых форматов и убедитесь, что он работает:

curl -I -H 'Accept-Encoding: gzip' https://example.com/app.js

Вы должны увидеть Content-Encoding: gzip для сжимаемых ответов и Vary: Accept-Encoding. Если изображения или ZIP-файлы отображаются как сжатые, ужесточите gzip_types; эти форматы уже сжаты и обычно будут тратить процессор.

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

Прокси-кэширование должно быть последним. У него самый большой потенциал и самый простой режим отказа. Начните с контента, который явно безопасен: публичные страницы документации, страницы анонимного каталога продуктов, ответы преобразования изображений, метаданные пакетов или ответы API, которые идентичны для каждого посетителя. Избегайте кэширования чего-либо, привязанного к куки сессии, заголовку Authorization, корзине покупок, панели управления пользователя, странице администратора или персонализированным рекомендациям, если ваше приложение не было специально разработано для этого.

Вот более осторожный шаблон обхода кэша, чем короткие примеры, которые вы часто видите:

map $http_authorization $skip_cache_auth {
    default 1;
    ""      0;
}

map $http_cookie $skip_cache_cookie {
    default 0;
    ~*"(session|sid|auth|token)" 1;
}

server {
    location / {
        proxy_pass http://backend_upstream;
        proxy_cache my_cache;
        proxy_cache_valid 200 10m;
        proxy_cache_bypass $skip_cache_auth $skip_cache_cookie;
        proxy_no_cache $skip_cache_auth $skip_cache_cookie;
        add_header X-Cache-Status $upstream_cache_status always;
    }
}

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

За чем следить после изменений

Не оценивайте настройку Nginx только по одному бенчмарку. Следите за сервером в течение нескольких нормальных циклов трафика. Полезные сигналы включают запись на диск в /var/lib/nginx или /var/cache/nginx, время ответа апстрима, коэффициент попадания в кэш, использование процессора после включения сжатия, ошибки 499/502/504 и использование памяти на рабочий процесс. Если процессор подскакивает после Gzip, а пропускная способность едва меняется, уменьшите gzip_comp_level или ограничьте типы MIME. Если коэффициент попадания в кэш низкий, кэш может обходиться из-за куки, строк запроса или заголовков ответа от приложения.

Также протестируйте поведение при сбоях. Остановите или замедлите апстрим в промежуточной среде и убедитесь, что proxy_cache_use_stale делает то, что вы ожидаете. Устаревшая публичная страница во время короткого сбоя бэкенда может быть нормальной. Устаревший баланс счета, счет-фактура или страница администратора — нет.

Заключительные замечания

Хорошая работа по производительности Nginx — это в основном тщательное ведение хозяйства. Используйте буферы достаточно большие, чтобы избежать ненужного дискового ввода-вывода, но не настолько большие, чтобы каждый занятой рабочий процесс стал дорогим. Сжимайте текст, а не уже сжатые ресурсы. Сначала кэшируйте публичные, повторяемые ответы, а приватный контент должен явно отказываться от кэширования. Затем продолжайте измерять, потому что правильные настройки для небольшого PHP-приложения, статического сайта документации и загруженного API-шлюза не будут одинаковыми.