Nginx или Apache: сравнение архитектуры, RAM и производительности
⚖️ Сравнения

Чем отличается Nginx от Apache и что выбрать для сайта

Марина
Марина
📅 27 мая 2026 👁 25 просмотров
Чем отличается Nginx от Apache и что выбрать для сайта

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

Если вы только настраиваете первый сервер — начните с гайда по настройке VPS с нуля. Если выбираете, где взять сам сервер — смотрите каталог VPS-провайдеров.

Nginx — архитектура и принцип работы

Чем отличается Nginx от Apache и что выбрать для сайта — иллюстрация

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 — критична.

Примеры конфигов — как выглядит разница

Чем отличается Nginx от Apache и что выбрать для сайта — иллюстрация

Один и тот же 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 из коробки.

Поделиться:
Марина
Редактор · FREEHOSTING
Главный редактор FREEHOSTING. С 2020 года тестирует VDS, VPS и хостинг-провайдеров — арендует серверы, нагружает их реальными проектами и пишет честные обзоры по итогам. Помогает читателям выбирать хостинг под свои задачи: от Telegram-бота до production-сайта.