Две трети веб-серверов в мире работают либо на Nginx, либо на Apache — и вопрос «nginx или apache» встаёт при каждой настройке нового VPS. Оба работают, оба надёжны, оба активно поддерживаются. Разница — в архитектуре, потреблении памяти и в том, как именно каждый справляется с PHP, статикой и высокой нагрузкой. Ниже — сравнение с примерами конфигов и без мифов.
Если вы только настраиваете первый сервер — начните с гайда по настройке VPS с нуля. Если выбираете, где взять сам сервер — смотрите каталог VPS-провайдеров.
Nginx — архитектура и принцип работы

Nginx использует event-driven архитектуру: один рабочий процесс (worker) обрабатывает тысячи соединений одновременно через событийный цикл (event loop). Новое соединение — не новый процесс и не новый поток, а событие в очереди. Это позволяет держать тысячи активных соединений при минимальном расходе памяти.
Nginx создавался как reverse proxy и раздатчик статических файлов — и в этих ролях он до сих пор вне конкуренции. PHP он не выполняет напрямую: передаёт запросы процессу PHP-FPM по протоколу FastCGI.
Количество worker-процессов задаётся параметром worker_processes — обычно равным числу CPU-ядер. Каждый worker однопоточен, нет mutex-блокировок, нет накладных расходов на переключение контекста потоков.
Сильные стороны Nginx
- Скорость на статике — CSS, JS, картинки, видео отдаются напрямую из памяти или кеша файловой системы без вызова PHP.
- Низкое потребление RAM — 2–5 MB на worker-процесс против 20–50 MB у Apache prefork на каждый процесс.
- Стабильность под параллельной нагрузкой — при тысячах одновременных соединений поведение предсказуемо, новые процессы не создаются.
- Reverse proxy из коробки — балансировка нагрузки, upstream, кеширование ответов бэкенда.
Где Nginx сложнее
- Нет .htaccess — все правила пишутся в конфигурационный файл server-блока. Для каждого изменения нужен
nginx -s reload. - Перевод правил mod_rewrite — если вы переезжаете с Apache, правила из .htaccess придётся переписать на синтаксис Nginx вручную.
- Модули компилируются в бинарь — добавить модуль без пересборки не получится (если не использовать динамические модули, появившиеся в Nginx 1.9.11).
Apache — архитектура и принцип работы
Apache работает по модели MPM (Multi-Processing Module). Три варианта: prefork (один процесс на запрос), worker (несколько потоков в процессе), event (гибридная модель, близкая к Nginx). По умолчанию на большинстве дистрибутивов — event, но исторически prefork встречается чаще на shared-хостингах.
При prefork каждый входящий запрос обслуживает отдельный процесс. Это надёжно с точки зрения изоляции — упавший PHP-скрипт не уронит остальные, — но при росте числа соединений количество процессов растёт линейно, и RAM уходит быстро.
PHP при использовании mod_php запускается прямо внутри Apache-процесса — не нужно настраивать отдельный FPM. Для shared-хостингов и начинающих это упрощает первичную настройку.
Сильные стороны Apache
- .htaccess — файл конфигурации на уровне директории. Читается при каждом запросе, позволяет менять правила без перезагрузки сервера. Принципиально важно для CMS, где плагины пишут собственные rewrite-правила.
- Богатая экосистема модулей — mod_rewrite, mod_security, mod_ssl, mod_cache и сотни других, большинство подключаются динамически (DSO).
- Широкая совместимость с CMS — особенно с 1С-Битрикс и legacy-системами, которые рассчитаны на mod_rewrite и .htaccess.
- Панели управления — ISPManager, cPanel, Plesk исторически ориентированы на Apache.
Слабые места Apache
- Расход памяти под нагрузкой — при prefork и 200+ одновременных соединениях Apache занимает 300–500 MB RAM. На VPS с 1–2 GB это уже проблема.
- Статика медленнее — Apache обрабатывает статические файлы через тот же механизм, что и динамику. Nginx здесь быстрее на 15–30%.
Сравнительная таблица — Nginx vs Apache
| Параметр | Nginx | Apache |
|---|---|---|
| Архитектура | Event-driven, async | MPM (prefork / worker / event) |
| Обработка статики | Очень быстрая | Хорошая, на 15–30% медленнее |
| Обработка PHP | Только через PHP-FPM (FastCGI) | mod_php или PHP-FPM |
| Поддержка .htaccess | Нет | Да (per-directory конфигурация) |
| Потребление RAM | ~2–5 MB на worker | ~20–50 MB на процесс (prefork) |
| Reverse proxy | Из коробки, производительный | Через mod_proxy |
| Модульность | Компилируются в бинарь (DSO с 1.9.11) | Динамические модули (DSO) |
| Конфигурация | server {} и location {} блоки | VirtualHost + Directory + .htaccess |
| Совместимость с Битрикс | Требует ручной настройки | Из коробки (mod_rewrite) |
| Совместимость с WordPress | Отличная | Отличная |
| Документация | nginx.org + активное сообщество | httpd.apache.org + обширные legacy-доки |
Данные актуальны для Nginx 1.26 и Apache 2.4, май 2026.
Производительность под нагрузкой — цифры без мифов
Benchmark-тесты (ab, wrk) стабильно показывают: на раздаче статики Nginx обгоняет Apache. При 1000 запросов в секунду на статические файлы Nginx удерживает CPU на 15–20% ниже, время ответа на пиках — стабильнее.
На динамике картина меняется. Когда в цепочку добавляется PHP — через FPM у обоих, — узкое место смещается на PHP-процессы, а не на веб-сервер. Разница в производительности между Nginx и Apache при одинаковой нагрузке на PHP-приложение составляет 5–10% — в пределах погрешности измерений. На реальных сайтах это незаметно.
RAM — ключевое преимущество Nginx
На типовом VPS с 2 GB RAM стек Nginx + PHP-FPM займёт ~150 MB. Apache с mod_php в режиме prefork при той же нагрузке — 300–400 MB. Разница в 150–250 MB принципиальна для small VPS: это ресурс, который можно отдать под базу данных или Redis.
При переходе Apache на MPM event с PHP-FPM разрыв сокращается, но Nginx остаётся экономнее по памяти на базовом уровне.
C10K и выше
C10K — задача держать 10 000 одновременных соединений. Nginx создан именно для этого: worker-процессы не плодятся, событийный цикл обрабатывает новые соединения без создания потоков. Apache prefork при C10K создаёт тысячи процессов и упирается в память. Apache event справляется лучше, но всё равно уступает Nginx при экстремальной параллельности.
Для типового сайта с сотнями одновременных посетителей эта разница несущественна. Для highload API или агрегаторов с тысячами RPS — критична.
Примеры конфигов — как выглядит разница

Один и тот же PHP-сайт на двух веб-серверах. Nginx требует явно описать каждый шаг обработки запроса. Apache достаточно разрешить .htaccess — остальное CMS сделает сама.
Nginx — server-блок для PHP-сайта (документация nginx.org):
server {
listen 80;
server_name example.com www.example.com;
root /var/www/example;
index index.php;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}
Apache — VirtualHost для того же сайта (документация httpd.apache.org):
<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/example
<Directory /var/www/example>
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
Apache-конфиг короче и понятнее для новичка: указали директорию, разрешили .htaccess — и WordPress сам пропишет правила permalinks. Nginx-конфиг длиннее, зато явный: видно каждый шаг от запроса до PHP-FPM, нет скрытых механизмов.
.htaccess — главная разница для веб-разработчика
.htaccess — это файл Apache, который читается при каждом запросе к директории. Он позволяет менять конфигурацию сервера без права на редактирование главного httpd.conf и без перезагрузки. WordPress использует .htaccess для правил permalinks, плагины пишут туда редиректы, защиту директорий, заголовки кеширования.
Nginx .htaccess не поддерживает. Все правила — в server-блоке конфига. Для изменения нужен перезапуск: nginx -s reload. На практике это несекундное дело, но требует SSH-доступа к серверу.
Когда .htaccess критичен
На shared-хостинге у вас нет доступа к конфигу сервера — .htaccess единственный способ управлять поведением. Для VPS с полным root-доступом это ограничение несущественно: вы в любой момент можете отредактировать конфиг Nginx.
Для 1С-Битрикс .htaccess критичен: система генерирует сложные rewrite-правила, которые при переезде на Nginx придётся переводить вручную. Для WordPress это уже не проблема — существуют стандартные nginx-конфиги с поддержкой всех популярных плагинов.
Nginx + Apache в связке — популярный вариант для VPS
На нагруженных проектах с legacy-кодом используют оба сервера одновременно: Nginx принимает все входящие запросы, отдаёт статику самостоятельно, а динамику проксирует на Apache, который слушает на порту 8080 (не 80).
Получается: производительность Nginx на фронте — быстрая раздача статики, обработка SSL — плюс совместимость Apache на бэкенде — .htaccess, mod_rewrite, mod_security.
Когда связка оправдана
- Legacy-приложение или CMS, которая активно использует .htaccess и нет ресурсов переписывать конфиги
- Высокая нагрузка на статику при сохранении Apache-совместимости
- Постепенная миграция с Apache на Nginx — связка позволяет переводить хосты поочерёдно
Минус: цепочка усложняет отладку. При проблемах с запросом нужно смотреть логи двух серверов, разбираться, где именно что-то пошло не так.
Что выбрать под конкретные задачи
WordPress / Joomla / типовой сайт на PHP
Nginx + PHP-FPM. Меньше памяти, быстрее статика, стандартная конфигурация для любого хостера. Поддержка WordPress permalink rules — несколько строк в конфиге. Детально — в гайде по настройке VPS с нуля.
1С-Битрикс
Apache или связка Nginx + Apache. Битрикс активно использует .htaccess и mod_rewrite; чистый Nginx работает, но требует ручного переноса всех rewrite-правил. Для production-Битрикса без опытного администратора — берите Apache или связку.
Highload API / микросервисы
Nginx как reverse proxy и балансировщик нагрузки. Нативная поддержка upstream, кеширование ответов, low memory footprint под тысячи соединений. Провайдеры с хорошей инфраструктурой под такие задачи — серверы Selectel и Timeweb Cloud.
Shared-хостинг / панель управления ISPManager, cPanel
Apache — большинство панелей исторически ориентированы именно на него. Nginx там либо не поддерживается, либо работает в связке автоматически.
Под разные VPS-задачи — AdminVPS и VPS Aeza для классических сценариев, раздел сравнений поможет выбрать по параметрам.
Ну и в заключение
Для нового VPS под PHP-сайт — Nginx + PHP-FPM. Меньше памяти, быстрее, и это давно стало стандартом индустрии. SSL через Certbot ставится без разницы какой сервер — установка SSL через Certbot одинакова для обоих.
Apache не устарел и не собирается: он оправдан для Битрикса, legacy-CMS и панелей управления. Связка Nginx + Apache — рабочий компромисс, но усложняет обслуживание.
Если интересно разобраться глубже в том, как устроена виртуализация под VPS — читайте что такое виртуализация на сервере.
Выбрали веб-сервер — теперь нужен надёжный VPS под него. В каталоге free-hosting.ru — провайдеры с NVMe, KVM и поддержкой Nginx/Apache из коробки.