Nginx vs Apache: холивар, который пора закрыть (или нет)

Зайдите в любой тематический форум, чат сисадминов или комментарии под статьёй о веб-серверах, и вы наткнётесь на спор, которому больше пятнадцати лет. Одни доказывают, что Apache устарел и его давно пора на пенсию. Другие, что nginx переоценён, а нормальный человек берёт проверенное. Тон местами такой, будто речь о выборе религии, а не программы.

Разберёмся спокойно. И nginx, и Apache решают одну задачу: принять HTTP-запрос от браузера и отдать обратно страницу, картинку или ответ приложения. В этом они одинаковы. Вся разница в том, как они обслуживают много запросов одновременно. Это одно архитектурное различие тянет за собой всё остальное: и скорость, и аппетит к памяти, и то, кому какой сервер подходит.

Откуда вообще взялся спор

Apache появился в 1995 году и на годы стал стандартом по умолчанию. В начале 2000-х он держал больше 70% рынка, фактически «веб-сервер вообще» для большинства. На нём вырос классический стек LAMP (Linux, Apache, MySQL, PHP), и львиная доля старых проектов до сих пор живёт именно на нём.

Nginx написал Игорь Сысоев в середине 2000-х под конкретную боль, так называемую «проблему C10K»: как одной машине держать десять тысяч одновременных соединений и не захлебнуться. Apache тех лет под таким напором начинал есть память и тормозить. Nginx подошёл к задаче с другой стороны, и именно с этого решения начинается всё дальнейшее.

Главное различие: как они держат соединения

Представьте ресторан в час пик.

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

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

Здесь важная оговорка, без которой холивар и не утихает. Современный Apache умеет работать в режиме event MPM: он давно не обязан выделять поток на каждое соединение и подтянул поведение под высокую нагрузку. Так что фраза «Apache раздаёт по процессу на клиента» - это правда про старые конфигурации, а не приговор движку. Разрыв есть, но он не пропасть.

Где у каждого сила

У nginx:

• Статика. CSS, JS, картинки, видео он отдаёт прямо с диска с минимальными накладными расходами, под нагрузкой в разы быстрее Apache.
• Роль фронта. Обратный прокси, балансировщик, терминатор SSL перед приложением - это его родная стихия. Принял трафик, разобрался с шифрованием, раздал статику, остальное передал дальше.
• Экономия. Мало памяти, высокая конкурентность: идеален для VPS и контейнеров, где ресурсы на счету.

У Apache:

• .htaccess. Файлы поддиректорной настройки, которые позволяют менять поведение сервера в отдельной папке без правки общего конфига, без перезапуска и без root-доступа. Именно поэтому Apache до сих пор царит на виртуальном хостинге: каждый клиент в своей «комнате» настраивает что хочет, не трогая соседей.
• Встроенный PHP. Через mod_php Apache обрабатывает динамику сам, без отдельной прослойки, привычный, отлаженный за десятилетия LAMP.
• Зрелость и модули. Огромная экосистема расширений, динамическая загрузка модулей на лету и репутация рабочей лошадки, которую видели в любой ситуации.

Почему «или» - неправильный вопрос

Самое интересное, что в реальном продакшене эти двое чаще стоят не вместо, а вместе. Распространённый паттерн: nginx спереди, Apache сзади. Nginx встречает трафик, занимается шифрованием и статикой, держит толпу соединений, а динамические запросы передаёт Apache, который спокойно отрабатывает свой PHP со всеми привычными .htaccess. На выходе вы получаете скорость и экономичность одного плюс гибкость второго.

То есть вопрос «nginx ИЛИ Apache» во многих случаях просто неверно поставлен. Это не дуэль, а распределение ролей.

Так кто всё-таки победил

Если смотреть на голые цифры, перевес очевиден. По данным W3Techs на 2026 год nginx занимает около трети рынка известных веб-серверов (примерно 33%), Apache около четверти (порядка 24%), и разрыв продолжает медленно расти. Для сравнения: с пиковых 70%+ начала 2000-х Apache спускался годами, отдавая долю nginx и более новым игрокам вроде Caddy.

Но «победил» - слово с двойным дном. Apache по-прежнему доминирует там, где сильны его козыри: на shared-хостинге с .htaccess, в legacy-проектах и корпоративных системах, завязанных на конкретные модули. Оба сервера живы и развиваются: nginx выпустил версию 1.30 весной 2026-го, Apache 2.4.66 в конце 2025-го. Единственный пункт, где разрыв реально велик: HTTP/3: у nginx он уже готов к продакшену, у Apache всё ещё в статусе эксперимента.

Вывод по холивару такой. Как спор «что объективно лучше» он действительно выдохся: для большинства новых проектов nginx - разумный выбор по умолчанию. Но это не значит, что Apache «умер»: у него прочные ниши, и попасть в одну из них проще, чем кажется.

Что выбрать: короткая шпаргалка

Холивар в формате «один движок против другого» можно спокойно закрывать: для нового проекта ответ чаще всего nginx. А вот как практичный вопрос «что взять под мою конкретную задачу» он совершенно живой и нормальный. Вы выбираете не лагерь, а инструмент под нагрузку. И, как видите, никто не запрещает взять сразу оба.