Миф: nginx всегда быстрее Apache

MAATRIX

Если вы искали, какой веб-сервер поставить под новый проект, почти наверняка натыкались на однозначное «бери nginx, Apache — прошлый век». Формулировка звучит убедительно и часто оказывается правдой на практике, но как техническое обобщение она неверна: оба сервера в 2026 году умеют держать серьёзную нагрузку, и выбор между ними определяется не репутацией, а тем, что именно вы обслуживаете.

Откуда взялся миф про nginx

История мифа простая и в целом обоснованная. nginx появился в 2004 году как прямой ответ на C10K problem — проблему обслуживания десяти тысяч одновременных соединений на одном сервере. Классический Apache тех лет работал по модели prefork: один процесс (или поток) на каждое соединение. При росте числа одновременных клиентов росло и потребление памяти — линейно, соединение за соединением, — а переключение контекста между сотнями процессов съедало CPU. nginx с самого начала строился вокруг событийного цикла (event loop): один воркер-процесс мог обслуживать тысячи соединений, не создавая под каждое отдельный поток ОС.

На фоне тогдашнего Apache это было настоящим архитектурным прорывом, и разница в потреблении памяти при большом числе keep-alive-клиентов была видна невооружённым глазом. Отсюда и родилась формула «nginx технически превосходит Apache», которая с тех пор транслируется по форумам и чек-листам почти без изменений — хотя сам Apache за 20 лет успел обзавестись собственными событийными режимами.

Проблема не в том, что вывод был неверным для 2005 года. Проблема в том, что его перенесли на 2026-й без поправок на то, что изменилось у обоих серверов и что вообще определяет скорость реального сайта.

Как на самом деле устроены nginx и Apache

Ключевое отличие — это модель обработки соединений (worker MPM — Multi-Processing Module):

Важный нюанс, который часто теряется в спорах: у Apache тоже есть событийный MPM — event, дефолтный в современных дистрибутивах Ubuntu/Debian уже много лет. Он структурно похож на модель nginx: отдельный поток обрабатывает I/O ожидание, не блокируя воркер на время, пока keep-alive-соединение простаивает. Прямое противопоставление «nginx = событийный / Apache = процесс на соединение» описывает Apache с MPM prefork, который остаётся дефолтным только там, где всё ещё используется mod_php (сам mod_php несовместим с многопоточными MPM). Проверить, какой MPM реально работает на сервере:

apache2ctl -M | grep mpm
# или
apache2ctl -V | grep -i mpm

Если видите mpm_prefork_module — вы на процессной модели, и разговор о памяти на соединение действительно не в вашу пользу. Если mpm_event_module — архитектурный разрыв с nginx для сценария простаивающих соединений намного меньше, чем принято думать.

Где nginx правда быстрее: много одновременных соединений

Есть паттерн нагрузки, где преимущество nginx реальное, измеримое и не зависит от настроек Apache: тысячи одновременных, преимущественно бездействующих соединений. Это типично для:

• раздачи статики (картинки, CSS, JS, видео) большому числу параллельных клиентов;
• реверс-прокси перед бэкендами — настройки nginx как реверс-прокси рассчитаны именно на этот паттерн;
• долгоживущих keep-alive-соединений (SPA, мобильные клиенты с постоянным polling);
• терминации TLS перед пулом бэкендов.

Причина в архитектуре событийного цикла: каждое соединение — это файловый дескриптор в структуре данных epoll (Linux), а не отдельный поток ОС со своим стеком памяти. nginx может держать открытыми десятки тысяч TCP-соединений при пуле буквально из нескольких воркер-процессов (обычно по числу ядер CPU):

worker_processes auto;
events {
    worker_connections 1024;
    use epoll;
}

С такой конфигурацией один воркер способен обслужить порядка тысячи одновременных соединений практически без прироста памяти на каждое новое — они простаивают в очереди epoll, а не занимают отдельный процесс. Именно этот сценарий и должен иметь в виду человек, который формулирует «nginx быстрее»: он прав для конкретного паттерна, но обобщает его на все паттерны сразу.

Здесь стоит сразу оговориться: конкретные цифры «на сколько именно быстрее» сильно зависят от железа, версий ПО, типа нагрузки и настроек TLS/keep-alive конкретного сервера — универсального числа не существует, и любой сайт, который приводит голую цифру без методологии теста, скорее всего просто перепечатывает чужой бенчмарк. Если хотите понять разницу на своей нагрузке — измеряйте сами, на своём VPS, своим трафиком.

Почему скорость динамики чаще решает не веб-сервер, а бэкенд

Вот где обобщение «nginx всегда быстрее» технически ломается сильнее всего. Для статики и простаивающих соединений веб-сервер — это почти вся работа. Но для динамического контента (WordPress, Laravel, Django, любое CMS или API) веб-сервер — это тонкая обвязка перед реальным исполнителем кода: PHP-FPM, Python WSGI/ASGI-сервером, Node.js-процессом.

Возьмём типичный запрос к WordPress-странице:

1. TCP-соединение принимает веб-сервер — доли миллисекунды что у nginx, что у Apache.
2. Запрос передаётся в PHP-FPM (у nginx — всегда, у Apache — тоже всегда, если это не легаси-связка с mod_php) по FastCGI или через Unix-сокет.
3. PHP-FPM разбирает запрос, инициализирует WordPress, обращается к MySQL/MariaDB, рендерит HTML — это 90%+ времени ответа на не закэшированной странице.
4. Результат уходит обратно через веб-сервер клиенту.

Шаг 3 практически не зависит от того, что стоит перед PHP-FPM — nginx или Apache с mod_proxy_fcgi. Разница между обвязками измеряется в единицах-десятках миллисекунд накладных расходов на запрос, тогда как медленный SQL-запрос без индекса или отсутствие OPcache легко добавляет сотни миллисекунд-секунды. Если сайт тормозит, разбор обычно стоит начинать не с замены веб-сервера, а с профилирования самого приложения — так же, как в материале про ускорение WordPress на слабом VPS: там первые узкие места — это OPcache, кэш объектов и запросы к БД, а не выбор фронтового сервера.

Практический вывод: если ваш бэкенд не оптимизирован, замена Apache на nginx часто даёт прирост в пределах погрешности измерения — потому что бутылочное горлышко было не в веб-сервере.

Что Apache умеет такого, чего у nginx нет «из коробки»

Обратная сторона мифа — тезис «Apache устарел, использовать не стоит». Это тоже обобщение, которое разваливается в конкретных сценариях, особенно шаред-хостинге и легаси-инфраструктуре:

• .htaccess на уровне директории. Apache позволяет переопределять конфигурацию (rewrite-правила, заголовки, ограничения доступа) прямо в директории сайта, без перезапуска сервера и без доступа к главному конфигу. Для shared-хостинга, где сотни клиентов не имеют root-доступа, это не архитектурный недостаток, а единственный практичный способ дать им контроль над своим сайтом. У nginx такого механизма нет принципиально — вся конфигурация только централизованная, и это осознанный компромисс в пользу производительности парсинга конфига на каждый запрос.
• mod_php. В классической связке Apache может исполнять PHP прямо внутри воркер-процесса, без отдельного FastCGI-пула. Это упрощает деплой на один шаг (нет отдельного сервиса PHP-FPM, которым нужно управлять и который может упасть отдельно от веб-сервера), хотя и работает только с MPM prefork, что возвращает к процессной модели и её накладным расходам на память. Материал про частые ошибки Apache с mod_php разбирает эти компромиссы подробнее.
• Богатая экосистема модулей. mod_security, mod_rewrite с полным набором флагов, mod_ssl, десятки модулей аутентификации — многие из них существуют дольше и в некоторых нишах (корпоративные legacy-приложения, старые панели управления) документированы лучше, чем аналоги для nginx.
• Прозрачная диагностика по логам процессов. Модель "процесс на запрос" при отладке иногда проще: видно, какой именно PID завис на конкретном запросе, через apache2ctl status — при событийной модели nginx такая привязка запроса к конкретному системному ресурсу не всегда так наглядна.

Ни один из этих пунктов не делает Apache быстрее nginx в сценарии множества простаивающих соединений — но все они реальные причины, по которым конкретный проект может обоснованно остаться на Apache, а не «просто отстал от жизни».

Apache с MPM event: когда разрыв в производительности почти стирается

Если взять современный Apache 2.4.x, настроенный с MPM event и PHP через mod_proxy_fcgi + PHP-FPM (то есть без mod_php), архитектурная разница с nginx для большинства реальных нагрузок сайта уходит на второй план. Пример рабочей конфигурации event MPM:

# /etc/apache2/mods-available/mpm_event.conf
<IfModule mpm_event_module>
    StartServers             3
    MinSpareThreads         75
    MaxSpareThreads        250
    ThreadsPerChild         25
    MaxRequestWorkers      400
    MaxConnectionsPerChild   0
</IfModule>

sudo a2dismod mpm_prefork php8.3
sudo a2enmod mpm_event proxy_fcgi
sudo a2enconf php8.3-fpm
sudo systemctl restart apache2

В такой конфигурации Apache тоже не создаёт отдельный процесс ОС на каждое keep-alive соединение — простаивающие клиенты обслуживаются пулом потоков через тот же принцип асинхронного ожидания I/O, что и у nginx. Оставшаяся разница по факту сводится к деталям реализации (модель потоков против модели процессов-воркеров, тонкости работы epoll) и на типичной нагрузке сайта — блог, интернет-магазин, корпоративный сайт — редко становится узким местом раньше, чем упирается сам бэкенд или диск.

Практический вывод, который подтверждают и независимые обсуждения архитектуры обоих серверов (без привязки к конкретным цифрам, которые сильно гуляют от теста к тесту): на большинстве реальных нагрузок разница на практике чаще определяется качеством конфигурации конкретного сервера, а не тем, какой продукт выбран. Плохо настроенный nginx (например, без кэширования, с избыточным логированием на диск на каждый запрос) вполне может проигрывать хорошо настроенному Apache с event MPM. И наоборот.

Если задача — именно балансировка нагрузки между несколькими бэкендами, а не выбор фронтового веб-сервера как такового, тот же вопрос архитектуры стоит смотреть отдельно — сравнение разобрано в статье nginx или Apache: что выбрать для сервера.

Как выбрать: тестируйте свой сценарий, а не чужой бенчмарк

Практическая рекомендация вместо религиозного выбора одной стороны:

1. Определите профиль нагрузки. Много параллельных клиентов и статика/прокси — architecturally в пользу nginx. Управляемый шаред-хостинг с множеством независимых сайтов на .htaccess — в пользу Apache. CPU-интенсивная динамика с грамотным бэкендом — веб-сервер почти не влияет, выбирайте по удобству эксплуатации.
2. Проверьте, какой MPM реально работает, если уже используете Apache (команда выше) — сравнение с nginx без event MPM просто нечестное.
3. Измерьте на своей машине и своём трафике, а не верьте синтетическим бенчмаркам из интернета. Простой стресс-тест на самом сервере:

# ab — простой и достаточный для грубой оценки инструмент из apache2-utils
ab -n 10000 -c 200 -k https://ваш-домен.example/

Смотрите на Requests per second и Time per request, но помните: цифры зависят от железа VPS, диска, версии PHP/PHP-FPM и настроек кэша — сравнивать имеет смысл только результаты, полученные на одном и том же сервере при разных конфигурациях, а не с чужими показателями из статей в интернете.

1. Не переезжайте только ради веб-сервера, если бэкенд не профилирован. Часто «сайт тормозит» решается настройкой OPcache, пула PHP-FPM или индексов в БД — без единой замены Apache на nginx.
2. Учитывайте операционную стоимость перехода. Смена веб-сервера — это переписывание всех правил rewrite/redirect, пересборка логики .htaccess в nginx.conf, риск сломать SEO-редиректы. Если текущий Apache работает стабильно и не является узким местом по метрикам — миграция ради абстрактной «скорости nginx» может стоить дороже, чем экономит.

Для нового проекта на VPS с нуля, где нет legacy-ограничений, nginx действительно чаще становится разумным выбором по умолчанию — не потому что он «быстрее», а потому что его модель конфигурации лучше сочетается с современным стеком (реверс-прокси перед контейнерами, TLS-терминация, раздача статики CDN-подобным образом). Но это выбор под сценарий, а не универсальный закон производительности.

Частые вопросы