Nginx или Apache в 2026: что выбрать для нового проекта

Коротко: для нового проекта в 2026 году по умолчанию берите Nginx. Он держит тысячи соединений малой памятью, быстрее отдаёт статику, умеет HTTP/3 и сразу работает как reverse proxy перед приложением на PHP, Python, Node.js или Go. Apache оправдан, когда без .htaccess не обойтись: shared-хостинг, старый PHP-проект, CMS с правилами в .htaccess. Связка «Nginx спереди, Apache сзади» нужна в основном при переезде legacy-кода.

Вопрос «Nginx или Apache» звучит как спор вкусов, но на деле его решают три вещи: какое приложение будет работать за веб-сервером, кто будет править конфигурацию и сколько одновременных соединений придётся держать. Если вы собираетесь заказывать создание сайта у студии, этот вопрос стоит задать подрядчику до старта: на каком веб-сервере и с какой схемой PHP или прокси он будет разворачивать проект. От ответа зависят скорость сайта под нагрузкой, требования к серверу и то, сможете ли вы потом сами поправить редирект, не открывая тикет.

Ниже разберём, чем серверы отличаются по устройству, где разница в скорости реальна, а где это миф из старых бенчмарков, и соберём рабочие конфиги для обоих. Примеры проверены на Debian 12 и Ubuntu 24.04 с пакетами из репозиториев дистрибутива.

Чем Nginx отличается от Apache по архитектуре?

Главное различие в том, как сервер обслуживает соединения. Всё остальное — скорость, расход памяти, поведение под нагрузкой — вытекает отсюда.

Apache: процессы и потоки через MPM

Apache HTTP Server (httpd) появился в 1995 году и много лет был стандартом веба. Модель обработки в нём подключается модулем MPM (Multi-Processing Module), и их три:

• prefork — один процесс на одно соединение, без потоков. Самый старый и самый прожорливый режим. Нужен только для mod_php и других модулей, которые не дружат с потоками.
• worker — несколько процессов, в каждом пул потоков, один поток на соединение. Экономнее prefork, но поток всё равно занят, пока клиент держит keep-alive.
• event — развитие worker: простаивающие keep-alive соединения отдаются отдельному слушающему потоку, а рабочие потоки освобождаются. Это текущий стандарт для Apache 2.4.

Даже в режиме event Apache остаётся сервером «поток на активный запрос». Пока запрос обрабатывается, он занимает поток со своим стеком памяти. Когда медленных клиентов становится тысячи, растёт и число потоков.

Nginx: событийный цикл

Nginx написал Игорь Сысоев в начале 2000-х как ответ на проблему C10k — как держать десять тысяч одновременных соединений на одной машине. Архитектура другая: мастер-процесс и несколько рабочих процессов, обычно по числу ядер. Каждый рабочий процесс крутит событийный цикл (epoll в Linux) и обслуживает тысячи соединений сразу, не блокируясь на медленных клиентах.

Отсюда главные свойства Nginx: память почти не растёт с числом соединений, медленный клиент на мобильном интернете не держит целый поток, а отдача файлов с диска идёт через sendfile без лишних копирований. Обратная сторона — Nginx не исполняет код приложения внутри себя. PHP, Python или Node.js работают отдельными процессами, и Nginx передаёт им запросы по FastCGI, uwsgi или HTTP.

Кто быстрее: Nginx или Apache?

Короткий ответ: на статике и при большом числе соединений быстрее Nginx, на динамике разница почти исчезает, потому что упирается не в веб-сервер, а в приложение и базу данных.

Статика

Картинки, CSS, JS, шрифты, видео — сильная сторона Nginx. Он отдаёт их прямо из событийного цикла, кэширует дескрипторы открытых файлов и не тратит поток на каждого клиента. Apache с MPM event справляется с умеренной нагрузкой нормально, но при тысячах соединений расходует заметно больше памяти. Поэтому даже на проектах с Apache статику часто отдают через Nginx или CDN.

Динамика

Когда страница собирается PHP-кодом и тремя десятками SQL-запросов, ответ занимает 100–300 мс в приложении и единицы миллисекунд в веб-сервере. Здесь выбор сервера почти не влияет на время ответа. Влияет другое: как подключён PHP. Схема Apache + mod_php + prefork проигрывает любой схеме с PHP-FPM, причём из-за модели процессов, а не «медленного Apache». Apache с MPM event и PHP-FPM по скорости динамики близок к Nginx с тем же PHP-FPM.

Под нагрузкой

Разница становится критичной, когда приходит пик: распродажа, рассылка, вирусный пост, бот-трафик. Apache в prefork при исчерпании MaxRequestWorkers начинает ставить соединения в очередь, память уходит в своп, и сервер «ложится» целиком. Nginx в той же ситуации продолжает принимать соединения и отдавать статику, а очередь копится на стороне PHP-FPM, где её проще ограничить и увидеть. Именно поэтому старые бенчмарки с разницей «в разы» правдивы для prefork и почти неактуальны для event.

Сравнение Nginx и Apache: сводная таблица

Почему у Nginx нет .htaccess и плохо ли это?

.htaccess — это файл с директивами Apache, который лежит прямо в каталоге сайта и применяется без перезапуска сервера. Удобно для shared-хостинга: клиент не имеет доступа к основному конфигу, но может настроить редиректы, ЧПУ и защиту каталога. Подробно механизм описан в официальном руководстве Apache по .htaccess.

У этого удобства есть цена. Если AllowOverride включён, Apache на каждый запрос проверяет наличие .htaccess во всех каталогах пути и перечитывает их. Для URL вида /a/b/c/file.jpg это четыре лишние операции с файловой системой на каждый запрос. Плюс правила размазаны по каталогам, и найти, откуда взялся странный редирект, бывает непросто.

Nginx от этой модели отказался сознательно: конфигурация читается один раз при старте или reload, проверяется командой nginx -t и живёт в одном месте. Для своего сервера это плюс. Минус — правила из .htaccess придётся переписать вручную, автоматические конвертеры справляются только с простыми случаями.

Практическое правило: если у вас свой VPS или выделенный сервер, .htaccess не нужен ни на одном из серверов. На Apache выключайте его через AllowOverride None и переносите правила в конфиг виртуального хоста — это ускоряет и Apache.

Как подключать PHP в 2026 году?

Для PHP-проектов это важнее выбора сервера. Рабочая схема одна — PHP-FPM, отдельный пул процессов PHP, к которому веб-сервер ходит по FastCGI через Unix-сокет.

Почему не mod_php: он встраивает интерпретатор в каждый процесс Apache и требует MPM prefork. В итоге процесс, который отдаёт картинку, весит столько же, сколько процесс, который выполняет PHP. Ещё один минус — все сайты на сервере работают от одного пользователя www-data, а в PHP-FPM у каждого сайта может быть свой пул со своим пользователем и лимитами.

Nginx + PHP-FPM

server {
    listen 80;
    server_name example.ru;
    root /var/www/example/public;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }

    location ~* \.(css|js|png|jpg|webp|svg|woff2)$ {
        expires 30d;
        access_log off;
    }

    location ~ /\.(?!well-known) {
        deny all;
    }
}

Последний блок закрывает доступ к скрытым файлам вроде .git и .env, оставляя открытым /.well-known/ для выпуска сертификатов. Это одна из самых частых дыр на новых серверах.

Apache + MPM event + PHP-FPM

На Debian и Ubuntu установка пакета libapache2-mod-php переключает Apache на prefork. Если он уже стоит, вернуть правильную схему можно так:

sudo apt install php8.2-fpm
sudo a2dismod php8.2 mpm_prefork
sudo a2enmod mpm_event proxy_fcgi setenvif http2
sudo a2enconf php8.2-fpm
sudo apachectl configtest && sudo systemctl restart apache2
apachectl -V | grep MPM

Последняя команда должна показать Server MPM: event. Версию PHP подставьте свою: на Ubuntu 24.04 это 8.3.

Когда ставить Nginx перед Apache?

Связка «Nginx на 80/443 порту, Apache на внутреннем порту» популярна с конца 2000-х. Nginx принимает соединения, терминирует TLS, отдаёт статику и буферизует медленных клиентов, а Apache получает только запросы к динамике и продолжает читать .htaccess.

Связка оправдана, если:

• у вас legacy-проект или CMS, в которой много логики завязано на .htaccess, и переписывать её сейчас некогда;
• сервер обслуживает клиентов хостинга, которые сами правят .htaccess;
• нужен модуль Apache, у которого нет аналога в Nginx.

Для нового проекта связка — лишний слой: два конфига, два набора логов, два сервиса для обновления. Если приложение можно сразу поднять на PHP-FPM, Apache в этой цепочке ничего не добавляет.

Минимальный проксирующий блок Nginx выглядит так:

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Со стороны Apache включите mod_remoteip (RemoteIPHeader X-Forwarded-For и RemoteIPInternalProxy 127.0.0.1), иначе в логах и в приложении все посетители будут с адреса 127.0.0.1, а fail2ban и лимиты по IP перестанут работать.

Что с HTTP/2, HTTP/3 и TLS?

HTTP/2 оба сервера поддерживают давно, и включать его стоит всегда. В Apache помните про ограничение: mod_http2 не работает с MPM prefork — ещё одна причина уйти с mod_php.

HTTP/3 поверх QUIC в Nginx есть с версии 1.25 (модуль ngx_http_v3_module, описание — в документации nginx.org). Он заметно ускоряет загрузку на мобильных сетях с потерями пакетов. В Apache встроенной поддержки HTTP/3 нет; если он нужен, перед Apache ставят Nginx, Caddy или CDN.

Для TLS в 2026 году базовый набор одинаков: только TLS 1.2 и 1.3, автоматический выпуск сертификатов через certbot или acme.sh, HSTS после проверки, что всё работает по HTTPS. Плагины certbot есть для обоих серверов.

Какой сервер безопаснее?

Оба проекта зрелые, уязвимости в них находят и закрывают регулярно. Реальный риск почти всегда в конфигурации и в том, как давно обновлялся пакет, а не в выборе сервера. Типичные ошибки, которые мы видим на чужих серверах:

1. Открытые .git и .env. Каталог сайта = корень репозитория, и всё содержимое доступно по HTTP. Закрывайте скрытые файлы правилом, как в конфиге выше.
2. Версия сервера в заголовках. server_tokens off; в Nginx и ServerTokens Prod + ServerSignature Off в Apache.
3. Листинг каталогов. В Apache по умолчанию включён Options Indexes — уберите его. В Nginx autoindex выключен, пока вы его не включили.
4. Нет лимитов. В Nginx есть встроенные limit_req и limit_conn, в Apache для этого нужны сторонние модули вроде mod_evasive. Хотя бы ограничьте частоту запросов к форме логина.
5. Слишком старый пакет. Обновления безопасности ставьте автоматически через unattended-upgrades — подробности в нашем чеклисте базовой защиты Linux-сервера.

Что выбрать для нового проекта: матрица решений

Если коротко: Apache в 2026 году — это выбор совместимости, а не производительности. Для новых проектов разумная точка отсчёта — Nginx, а Apache берут тогда, когда есть конкретная причина.

А что с форками и альтернативами?

После покупки Nginx компанией F5 у проекта появились форки. Angie развивают бывшие разработчики Nginx; он совместим по конфигурации и есть в виде пакетов для популярных дистрибутивов. Freenginx в 2024 году запустил Максим Дунин, один из ключевых разработчиков исходного проекта. Для типового сайта разница между ними и upstream-версией невелика — главное, чтобы пакет регулярно обновлялся. Из альтернатив стоит знать Caddy (автоматический HTTPS, простой Caddyfile) и Traefik (сам находит контейнеры в Docker и Kubernetes).

Как переехать с Apache на Nginx без простоя?

1. Инвентаризация. Соберите все виртуальные хосты, включённые модули (apachectl -M) и все файлы .htaccess: find /var/www -name .htaccess.
2. Перевод PHP на FPM. Сначала переключите Apache на MPM event + PHP-FPM. Это отдельный безопасный шаг, после него Nginx будет говорить с тем же пулом PHP.
3. Перенос правил. RewriteRule → location, return 301 и try_files. Редиректы с условиями по заголовкам — через map. Каждое правило проверьте curl-ом с -I.
4. Параллельный запуск. Поднимите Nginx на другом порту или на копии сервера, прогоните по нему список важных URL и сравните коды ответов и заголовки.
5. Переключение. Остановите Apache, переведите Nginx на 80/443, держите конфиг Apache и пакет на месте пару недель для быстрого отката.
6. Наблюдение. Первые дни смотрите error.log и долю 404/5xx в access.log. Как читать логи и юниты, мы разбирали в статье про systemd и журналы.

Если приложение уже живёт в контейнерах, переезд проще: веб-сервер становится ещё одним сервисом в docker compose — об этом подробнее в гиде по Docker. А выкатку конфигов удобно отдать конвейеру из статьи про GitLab CI, тогда каждое изменение проходит nginx -t до попадания на прод.

Полный справочник директив — в документации Nginx и документации Apache 2.4.

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

Можно ли использовать Nginx и Apache одновременно?

Да, это распространённая схема: Nginx принимает соединения, отдаёт статику и терминирует TLS, а Apache на внутреннем порту обрабатывает динамику и читает .htaccess. Для нового проекта она избыточна, а для переезда legacy-кода удобна.

Всегда ли Nginx быстрее Apache?

Нет. На статике и при тысячах соединений Nginx выигрывает заметно. На динамических страницах время ответа определяет приложение и база данных, и Apache с MPM event и PHP-FPM работает почти так же быстро.

Какой веб-сервер лучше для WordPress?

Nginx + PHP-FPM с кэшированием страниц. WordPress работает и без .htaccess: ЧПУ обеспечивает одна строка try_files $uri $uri/ /index.php?$args;. Правила плагинов безопасности и кэша из .htaccess придётся перенести в конфиг вручную.

Как перенести правила из .htaccess в Nginx?

Вручную: RewriteRule превращается в location с return или rewrite, условия RewriteCond — в map или if на уровне server. Конвертеры помогают с простыми редиректами, но результат всегда проверяйте curl-ом и командой nginx -t.

Нужен ли HTTP/3 обычному сайту?

Не обязателен, но полезен для мобильной аудитории: QUIC лучше переносит потери пакетов и смену сети. В Nginx он включается директивой listen 443 quic и открытым UDP-портом 443, при этом HTTP/2 продолжает работать для старых клиентов.

Сколько памяти нужно веб-серверу?

Самому Nginx хватает десятков мегабайт даже под заметной нагрузкой. Основной расход памяти даёт PHP-FPM или процессы приложения, поэтому планируйте ресурсы по ним: для небольшого сайта обычно достаточно VPS с 2 ГБ памяти.

Вернуться в блог