Веб-серверы
nginx: веб-сервер, который масштабируется за счёт событийного цикла
nginx обрабатывает больше веб-трафика, чем любой другой сервер, по структурной причине: он решает C10K с помощью событийной асинхронной модели, а не потока на каждое соединение. На практике он одновременно служит лёгким файловым сервером и отраслевым обратным прокси по умолчанию. Конфигурационная дисциплина, наблюдение за логами и автоматизация TLS определяют, будет ли он тихим или хрупким.
Главное
- Вся суть — событийный цикл: небольшое число рабочих процессов обрабатывает тысячи соединений с дешёвыми переключениями контекста, поэтому nginx хорошо проксирует множество медленных клиентов, не тратя память на каждое соединение.
- Две роли в одном бинарнике: блоки server отдают статику и выполняют rewrite, а proxy_pass завершают TLS и передают запросы в upstream; max_fails, timeouts и buffering — это конфигурация, а не модули.
- Дисциплина конфигурации обязательна: nginx -t после каждого изменения, отдельный include на сайт для точного отката, reload вместо restart для живых изменений; публикация конфига, не прошедшего проверку синтаксиса, — авария, которую можно предотвратить.
- TLS — полноценный уровень: современные протоколы, session resumption, OCSP stapling и автоматическая выдача через acme.sh или certbot; hook продления, молча падающий 60 дней, — классическая авария nginx, поэтому следите за возрастом сертификата.
- Честные ограничения: нет динамической экосистемы модулей, как у Apache; сторонние функции требуют пересборки или пакетов дистрибутива; обратный прокси намеренно минималистичен, и сложность часто решают дополнительным слоем вроде rate limiting и WAF.
- Оптимизация начинается с реальной нагрузки: worker_processes = auto, worker_connections по памяти и нагрузке, понимание proxy_buffering (обычно включён и для API), gzip/brotli для текста и просмотр логов на всплески 499/504 до срабатывания алертов.
Заметка из практики
Конфиг nginx, который научил клиента большему всего, был одним файлом: обратный прокси с HSTS, честными заголовками кеширования и отдельными server-блоками, меньше 200 строк. До этого у них было 4 000 строк дублированных include и reload, ломавший что-то каждый квартал. Работа с конфигурацией — тоже инженерия.
Частые вопросы
nginx против Apache: когда nginx явно лучше?
Высококонкурентный обратный прокси, статичный трафик и TLS-терминация в масштабе — там событийный цикл окупается. Для shared-хостинга с .htaccess и конфигурацией по каталогам Apache остаётся удобнее.
Каково правило reload и restart?
reload — ежедневное действие: старые worker завершают текущие соединения, новый конфиг вступает в силу; restart нужен для смены версии движка и того, что не покрывает reload; перед обоими запускайте nginx -t.
Почему некоторые сайты ставят Apache за nginx?
Классический гибрид: nginx завершает TLS, быстро отдаёт статику и проксирует динамику в Apache, где .htaccess и mod_php ожидают традиционного поведения; цена — ещё один компонент для мониторинга.
Какие три ошибки настройки избегать в первую очередь?
Копировать параметры worker и буферов из статей без нагрузочного теста; отключать proxy_buffering, услышав, что он медленный (обычно наоборот); пропускать nginx -t перед reload.
Как мы берём на себя веб-серверы
Честно: чаще всего к нам приходят после того, как команда попробовала справиться сама. Настройка, оптимизация и безопасность веб-серверов в производственной среде и при разработке. Услуга Оптимизация скорости сайтов и Администрирование серверов существует как раз затем, чтобы не изучать веб-серверы на своих ошибках: настройку, ночные сюрпризы и постоянное наблюдение мы берём на себя.