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

Часть 2 из 12 · Серия «Свой сервер с нуля»

Зайдите в любой тематический форум, чат сисадминов или комментарии под статьёй о веб-серверах — и вы наткнётесь на спор, которому больше пятнадцати лет. Одни доказывают, что 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. А вот как практичный вопрос «что взять под мою конкретную задачу» он совершенно живой и нормальный. Вы выбираете не лагерь, а инструмент под нагрузку. И, как видите, никто не запрещает взять сразу оба.

Серия «Свой сервер с нуля»

Полный цикл — от выбора хостинга до рабочего сайта с почтой, Docker и бэкапами. Вы читаете часть 2 из 12.

1. VDS, VPS, хостинг, облако — что это
2. Nginx vs Apache: холивар, который пора закрыть — вы здесь
3. Зачем арендовать сервер, если есть хостинг за 100 ₽
4. SSH для тех, кто боится чёрного экрана
5. Как не запороть сервер в первый день: топ ошибок
6. SSH-ключи за 10 минут: вход без пароля
7. Поднимаем свой сайт на VPS за вечер
8. Ставим WordPress на свой VPS
9. Свой почтовый сервер — героизм или мазохизм?
10. Docker на VPS: спасение или пушка по воробьям
11. Настраиваем домен и SSL, чтобы браузер не ругался
12. Бэкапы, которые реально спасут

← Предыдущая: VDS, VPS, хостинг, облако — что это · Следующая: Зачем арендовать сервер, если есть хостинг за 100 ₽ →