В 2025 году спор «nginx vs apache» по‑прежнему актуален для админов, девопсов и вебмастеров, которым нужно сочетать производительность, совместимость и простоту эксплуатации. Оба сервера зрелые, поддерживают http2, интегрируются с php-fpm и умеют работать в высоконагруженных сценариях. Но различия в архитектуре, модели конфигурирования и стоимости владения по‑прежнему приводят к разным оптимальным схемам. Ниже — практичный разбор без фанатизма, с фокусом на performance, compatibility и типовые конфигурации, пригодные для продакшена.
Ключевые отличия архитектуры
Главная разница — модель обработки соединений. Nginx изначально событийный и неблокирующий, с фокусом на эффективную работу с большим числом одновременных соединений, проксирование и балансировку. Apache исторически процессно/потоковый, но с mpm event сильно приблизился к событийной модели, разгрузив потоки от ожидания I/O и позволив держать тысячи keep-alive соединений без взрывного роста потребления ресурсов.
Apache: MPM и эволюция к event
Apache поддерживает несколько MPM: prefork, worker и современный mpm event. В 2025 году prefork — опция для редких легаси‑кейсов (в частности, старого mod_php), а worker и особенно event являются базовой рекомендацией. Пара mpm event + mod_http2 + proxy_fcgi для php-fpm — стандарт де‑факто. Это уменьшает накладные расходы и близко подводит Apache к модели Nginx по обработке очередей событий, сохраняя при этом традиционную гибкость и совместимость с .htaccess.
Nginx: событийная модель по умолчанию
Nginx изначально проектировался как обратный прокси и HTTP‑сервер с неблокирующей I/O моделью. Это позволяет эффективно использовать CPU и память при высоком числе одновременных соединений (особенно TLS + keep‑alive + HTTP/2), выдаче статики и терминальном проксировании до бэкендов (PHP, Node.js, Python, gRPC). Строгая централизованная конфигурация без .htaccess даёт предсказуемую производительность: сервер не «гуляет» по дереву каталогов на каждый запрос и не перечитывает правила динамически.
Коротко: Apache в связке
mpm event+php-fpmрадикально сократил исторический разрыв, но Nginx по‑прежнему выигрывает у простых прокси‑и статик‑нагрузок и лучше масштабируется в сценариях высокой конкуренции соединений.
Performance и как его правильно мерить
Термин performance в контексте «nginx vs apache» — это не только RPS на синтетике. Важно учитывать реальный профиль нагрузки: долю TLS‑рукопожатий, использование http2 (мультиплексирование, хедер‑компрессия), процент кэш-хитов, размер статики (от мелких иконок до крупных ассетов), поведение бэкенда (PHP/DB), стойкость к медленным клиентам и пр. Ошибка многих «benchmarks» — мерить только раздачу маленьких файлов на локалхосте без TLS и без keep-alive.
Надёжная методика минимально включает:
- Отдельные сеты для статики (размеры 1–10 КБ, 100–300 КБ, 1–5 МБ) и динамики (PHP через
php-fpm). - Сценарии: plaintext HTTP/1.1, TLS +
http2с ALPN, с/безkeep-aliveи с/без сжатия. - Холодное/тёплое состояние кэшей ОС (page cache) и самого веб‑сервера (например,
open_file_cacheв Nginx). - Параллельность: лестничная (ramp‑up) и длительные плато на высокой конкуренции (1k–20k соединений, если релевантно).
- Учёт лимитов: сокеты, файловые дескрипторы, ulimit, net.core somaxconn и пр., чтобы не мерить узкое место не на уровне веб‑сервера.
Типичные результаты на современных ядрах и OpenSSL показывают: Nginx сохраняет преимущество на статике, HTTPS‑терминации и «сыром» проксировании, особенно при большом числе одновременных клиентов. Apache с mpm event демонстрирует сравнимые показатели на смешанных профилях и динамике через proxy_fcgi, а также даёт выигрыш там, где решает гибкость .htaccess и богатая экосистема модулей.
Совместимость и экосистема: где выигрывает каждый
Ключевой вопрос compatibility: приложения, документация и команды многих CMS исторически затачивались под Apache и .htaccess. В 2025 году подавляющее большинство популярных CMS и фреймворков имеют готовые рецепты для Nginx, но в легаси‑ландшафте всё ещё встречаются плагины и инструкции строго под .htaccess. Если вам критичны динамические директивы «на местах», Apache проще: включили AllowOverride и отдали право проектам менять поведение (перенаправления, доступы, кэши) без перезагрузки сервера.
Nginx, напротив, требует централизованной конфигурации. Это дисциплинирует, упрощает контроль и часто ускоряет запросы (нет дискового обхода директорий на каждый запрос), но потребует явного портирования правил переписывания. Для типовых CMS такие маппинги давно известны, однако редкие хитрые конструкции из mod_rewrite и директивы доступа иногда требуют ручного рефакторинга.
Модули: у Apache очень богатая экосистема модулей, включая mod_security, mod_evasive, mod_status, и многие встроены «из коробки» в дистрибутивы. У Nginx функциональные расширения часто собираются отдельно (динамические модули, сторонние патчи) или решаются внешними сервисами/прокси. При этом Nginx традиционно лидирует в роли фронтового прокси: TLS‑терминация, кэширование, rate‑limit, балансировка, статик, в то время как Apache остаётся сильным как универсальный веб‑сервер с тонкой настройкой доступа и гибкостью конфигов.
HTTP/2 в 2025: что важно знать
http2 сегодня — стандарт по умолчанию в браузерах (через TLS с ALPN). Важно корректно включить ALPN, оптимизировать параметры TLS (сессионные тикеты, кривая, OCSP‑stapling) и следить за приоритетами потоков. Для реальной выдачи ассетов сегодня важнее балансировать количество доменов/поддоменов и контролировать кеширование, чем полагаться на push, который де‑факто признан вредным. И Nginx, и Apache отлично работают с http2; в Apache за это отвечает mod_http2, а в Nginx — опция http2 в listen. Если сертификаты невалидны или просрочены — клиенты откатятся на HTTP/1.1: следите за актуальностью SSL-сертификаты.
PHP: только php-fpm
В 2025 году использовать mod_php под prefork — почти всегда антипаттерн. Индикативная связка для Apache — mpm event + proxy_fcgi + php-fpm; для Nginx — php-fpm через fastcgi_pass. Это повышает изоляцию, упрощает масштабирование и даёт предсказуемые метрики. Тюнинг пула php-fpm (pm, max_children, process_idle_timeout, slowlog) критичнее, чем выбор веб‑сервера, для динамики на PHP.
Типовые схемы конфигурации в 2025
Nginx + PHP‑FPM (один сервер)
Базовая схема для PHP‑приложения с симпатичным профилем статики и переписыванием URL. Удобно добавлять кэш слоёв: от open_file_cache до fastcgi_cache для микрокеша.
server {
listen 443 ssl http2;
server_name example.com;
root /var/www/app/public;
index index.php index.html;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
include fastcgi_params;
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}
Ключевые параметры, о которых часто забывают: client_max_body_size для аплоадов, корректные fastcgi_buffers для крупных заголовков, грамотные таймауты (client_body_timeout, fastcgi_read_timeout), и X‑Forwarded‑* заголовки при работе за балансировщиком.
Apache mpm_event + php-fpm
Современная сборка Apache, где http2 и proxy_fcgi включены, а обработка PHP идёт через php-fpm. Сохраняем гибкость .htaccess и получаем адекватную производительность.
# mods-enabled: mpm_event, http2, proxy_fcgi, setenvif, ssl, headers, rewrite
<IfModule http2_module>
Protocols h2 http/1.1
</IfModule>
<VirtualHost *:443>
ServerName example.com
DocumentRoot /var/www/app/public
<Directory "/var/www/app/public">
AllowOverride All
Require all granted
</Directory>
<FilesMatch "\.php$">
SetHandler "proxy:unix:/run/php/php8.2-fpm.sock|fcgi://localhost/"
</FilesMatch>
</VirtualHost>
Если .htaccess не нужен, лучше отключить его обход и повысить performance: AllowOverride None и все правила вынести в виртуальный хост. Это уменьшит файловую нагрузку и ускорит обработку запросов.
Nginx как фронт перед Apache
Компромиссный вариант для сильной зависимости от .htaccess: Nginx выполняет роль TLS‑терминатора, кэширует и раздаёт статику и отдаёт динамику на Apache. Это снижает нагрузку на Apache и даёт современный фронт, при этом сохраняется совместимость.
server {
listen 443 ssl http2;
server_name example.com;
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:8080;
}
location ~* \.(?:css|js|png|jpe?g|gif|svg|ico)$ {
expires 7d;
access_log off;
}
}
Важно корректно прокидывать исходные заголовки и схему, чтобы приложения за Apache понимали, что клиент пришёл по HTTPS, и формировали абсолютные URL без лишних редиректов.
Миграция правил: htaccess → Nginx
Частый вопрос — перенос .htaccess в конфиг Nginx. Базовые паттерны переписывания и каноникализации домена переносятся прямолинейно.
# .htaccess
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [L]
# nginx
server {
listen 443 ssl http2;
server_name example.com;
# Каноникализация и принудительный HTTPS обычно делаются на 80-порте редиректом
# здесь приведена уже HTTPS-секция
location / {
try_files $uri $uri/ /index.php?$query_string;
}
}
Осторожность нужна с тонкими условиями RewriteCond и флагами типа [QSA,NC,NE], обработкой кодировок и спецсимволов. Если у вас много доменных сценариев (301, HSTS, переезд), посмотрите разбор в материале Миграция домена: 301, HSTS и SSL.
Безопасность и харднинг
Оба сервера позволяют выставить строгие security‑заголовки (CSP, HSTS, X‑Frame‑Options, X‑Content‑Type‑Options), лимитировать размер запросов и тела (LimitRequestBody vs client_max_body_size), настраивать таймауты чтения/записи и защищаться от медленных клиентов. Apache традиционно силён благодаря mod_security (с OWASP CRS), Nginx часто используют с внешними WAF или в связке с модулем‑коннектором. Подробную шпаргалку по заголовкам смотрите в статье HTTP security headers для Nginx и Apache.
Типичные ошибки харднинга в бою: забытые директивы для больших загрузок, отсутствие лимитов на количество соединений с одного IP, неочевидные редирект‑петли при проксировании HTTPS‑за‑HTTPS, и смешение доверенных и недоверенных сетей на одном слушателе без фильтрации.
Эксплуатация: обновления, перезагрузки и наблюдаемость
Nginx славится предсказуемым graceful‑reload: конфиг проверяется, старые воркеры плавно завершаются, новые поднимаются без разрыва подключений. Apache тоже поддерживает аккуратные перезапуски, но в сложных инсталляциях с множеством виртуальных хостов и динамических правил важно внимательно отслеживать влияние .htaccess на кэш инструкций и файловые операции. В наблюдаемости Apache удобен своим mod_status, Nginx — метриками через статус‑эндпоинт или экспортерами. В обоих случаях добавляйте логирование таймингов (например, upstream_response_time), чтобы видеть вклад бэкенда.
Benchmarks: на что смотреть в отчётах
Слово benchmarks в контексте «nginx vs apache» часто перегружено маркетингом. Проверяйте: есть ли TLS и http2; учитываются ли реальная RTT и пропускная способность канала; есть ли разделение тестов на «чистую статику», «прокси без бэкенда», «динамика через php-fpm»; используются ли разные размеры объектов; продемонстрированы ли устойчивость к долгим соединениям и распределение латентности (p95/p99). Без этого сравнение цифр RPS мало что говорит о вашей продакшен‑нагрузке.
Ресурсная стоимость и предсказуемость
У Nginx обычно меньше накладной расход на соединение, он предсказуемо ведёт себя при взрывном росте конкурентных клиентов, что полезно при DDoS‑смежных всплесках, длинных загрузках или долгих http2‑сессиях. Apache с mpm event на современном Linux также ведёт себя достойно, но остаётся чувствительнее к включённым модулям и .htaccess, которые могут тянуть дополнительные проверки на каждый запрос. Если у вас дюжина команд, регулярно меняющих правила на местах, этот оверхед может окупаться гибкостью; если всё централизовано и инфраструктура дисциплинирована — Nginx будет проще и быстрее.
Короткие рецепты выбора
- Нужны динамические правила на проекте через
.htaccessбез перезагрузки сервера — выбирайте Apache (mpm event+php-fpm), оптимизируйтеAllowOverrideточечно. - Фронт‑прокси, TLS‑терминация, статика, простые редиректы, балансировка — Nginx будет эффективнее и проще.
- Легаси‑проект на Apache, но хочется современный фронт и кэш — ставьте Nginx перед Apache, затем поэтапно выносите тяжёлые правила вверх.
- Высокая конкуренция соединений, много
http2клиентов и тяжёлая статика — преимущество за Nginx; динамика на PHP упирается вphp-fpmи базу. - На старте проще использовать виртуальный хостинг; для тонкого тюнинга, собственного бэкенда и высоких нагрузок берите VDS.
Итоги
В 2025 году «nginx vs apache» — это вопрос профиля нагрузки, требований к compatibility с .htaccess, культуры конфигурирования и наблюдаемости. На чистой статике и фронтовом проксировании Nginx по‑прежнему фаворит в плане performance. Apache в конфигурации mpm event + http2 + php-fpm существенно сократил разрыв и остаётся лучшим выбором для проектов, где критична гибкость и модульность экосистемы, а также для команд, которым нужна динамическая настройка на уровне каталогов. Для большинства современных PHP‑проектов обе платформы дадут одинаково хорошие результаты при грамотном тюнинге пула php-fpm, кэшей и TLS. Выбор стоит делать не из догмы, а из измерений — в ваших конкретных benchmarks и с вашим реальным трафиком.
