Nginx vs Apache: что выбрать для сайта

Два способа решить одну и ту же задачу

Nginx и Apache HTTP Server — два самых распространённых веб-сервера в мире, оба решают одну и ту же базовую задачу: принимают HTTP-запросы от браузеров и отдают в ответ файлы или передают запрос дальше приложению вроде PHP. При этом внутреннее устройство у них принципиально разное, и это различие определяет сильные и слабые стороны каждого в конкретных сценариях.

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

Я хотел решить проблему C10k — как обслужить десять тысяч одновременных соединений на одном сервере, не тратя на каждое соединение отдельный поток операционной системы.

Игорь Сысоев, создатель Nginx, о причинах разработки сервера

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

По данным регулярных опросов использования веб-серверов в интернете, Nginx и Apache на протяжении последнего десятилетия попеременно делят первое и второе места по популярности среди самых посещаемых сайтов мира, а на менее нагруженных проектах массовых хостинг-провайдеров Apache по-прежнему сохраняет значительную долю благодаря глубокой интеграции с панелями управления вроде cPanel и ISPmanager.

Архитектура: событийная модель против процессов и потоков

Apache в классической конфигурации prefork MPM (Multi-Processing Module) создаёт отдельный процесс операционной системы на каждое входящее соединение — это простая и надёжная модель, где сбой в обработке одного запроса не затрагивает остальные, но каждый процесс потребляет заметный объём памяти независимо от того, насколько активно используется соединение.

Более современные MPM-модули Apache — worker и event — используют потоки вместо полноценных процессов, что снижает накладные расходы, но принципиальная модель «выделенный обработчик на соединение» сохраняется. Nginx с самого начала спроектирован иначе: он использует событийную модель, где ограниченное число рабочих процессов обрабатывает тысячи соединений одновременно, переключаясь между ними по мере готовности данных, а не блокируясь в ожидании каждого отдельного запроса.

Практическое следствие этой разницы: на сервере с ограниченным объёмом RAM Nginx способен обслуживать заметно больше одновременных соединений, чем Apache в классической конфигурации, — особенно это заметно на длинных keep-alive соединениях или при большом числе клиентов с медленным интернет-каналом, которые держат соединение открытым дольше среднего.

Конфигурация: .htaccess против централизованного файла

Одна из самых заметных для пользователя разниц — механизм .htaccess, доступный в Apache и отсутствующий в Nginx. Файл .htaccess позволяет задавать правила переписывания URL, редиректы, ограничения доступа и другие настройки прямо в директории сайта, без доступа к основной конфигурации сервера — это исторически сделало Apache стандартом для виртуального хостинга, где сотни клиентов делят один сервер и не имеют административного доступа к его настройкам.

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php [QSA,L]

Nginx требует, чтобы аналогичные правила были заданы в основном конфигурационном файле сервера, доступном только администратору — это менее гибко для многопользовательского хостинга, но заметно быстрее в работе: Nginx не тратит время на поиск и разбор .htaccess файлов в каждой директории на пути к запрошенному файлу, что Apache вынужден делать при каждом запросе, если AllowOverride включён.

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

Обработка PHP: mod_php против PHP-FPM

Классическая связка Apache использует модуль mod_php, встроенный прямо в процесс веб-сервера — PHP выполняется в том же процессе, который принял HTTP-соединение, что просто в настройке, но означает, что каждый Apache-процесс, обрабатывающий PHP-запрос, весит заметно больше, чем процесс, отдающий статический файл.

Nginx не умеет исполнять PHP самостоятельно и всегда передаёт такие запросы отдельному процессу PHP-FPM (FastCGI Process Manager) через сокет или сетевой порт. Это разделение — сам веб-сервер отдельно, обработчик PHP отдельно — на первый взгляд усложняет конфигурацию, но даёт заметное преимущество: статические файлы (изображения, CSS, JS) отдаются напрямую Nginx без обращения к PHP вообще, что значительно снижает нагрузку на самый дорогой ресурс — PHP-процессы.

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

Общий принцип архитектуры современных PHP-стеков

Apache тоже может использовать PHP-FPM вместо mod_php через модуль mod_proxy_fcgi, получая похожую архитектуру разделения — но по умолчанию и по историческим причинам большинство инструкций и готовых сборок Apache используют именно mod_php, тогда как для Nginx связка с PHP-FPM — единственный практический вариант с самого начала. Подробная пошаговая настройка связки Nginx с PHP-FPM разобрана в отдельной статье базы знаний.

Производительность под нагрузкой: когда разница становится заметна

Для сайта с посещаемостью в пределах нескольких сотен визитов в день разница в производительности между правильно настроенными Nginx и Apache практически незаметна — оба справляются с такой нагрузкой без каких-либо проблем на любой типичной конфигурации VPS.

Разница становится заметна при росте числа одновременных соединений: событийная модель Nginx масштабируется линейнее по потреблению памяти, тогда как классический Apache на prefork MPM начинает упираться в лимит MaxRequestWorkers и объём доступной RAM заметно раньше. Для интернет-магазина в пиковые часы распродажи или сайта, попавшего в топ обсуждений соцсетей, эта разница может определить, останется ли сайт доступным или начнёт отдавать ошибки перегрузки.

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

Модульность и гибкость: где сильнее Apache

У Apache — самая обширная экосистема модулей, накопленная за почти три десятилетия существования: от специфичных инструментов аутентификации и авторизации до модулей, редко встречающихся в стандартных сборках Nginx. Для нишевых требований, специфичных для legacy-проекта или узкой корпоративной задачи, вероятность найти готовый модуль под Apache исторически выше.

Динамическая загрузка модулей без пересборки сервера — ещё одна сильная сторона Apache: модуль можно включить или отключить командой a2enmod/a2dismod и перезапуском сервиса, тогда как многие модули Nginx (особенно сторонние) требуют пересборки бинарного файла сервера из исходников с нужным набором флагов, если они не были включены в дистрибутив изначально.

Для проектов с нестандартными требованиями — например, специфичной аутентификацией через LDAP с редко используемыми параметрами или интеграцией с legacy-системами, под которые существуют только Apache-модули, — этот аргумент может перевесить архитектурные преимущества Nginx в производительности.

Практический конфиг Nginx для типичного сайта на PHP

Минимальный работоспособный конфиг виртуального хоста Nginx для сайта на CMS с PHP-FPM выглядит компактно — большая часть логики сосредоточена в нескольких директивах location, определяющих, что делать с разными типами запросов.

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

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

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location ~* \.(jpg|jpeg|png|gif|css|js)$ {
        expires 30d;
    }
}

Обратите внимание на директиву expires в блоке для статических файлов — она указывает браузеру кэшировать изображения, CSS и JS на 30 дней, снижая число повторных запросов к серверу при повторных визитах того же посетителя.

Практический конфиг Apache для того же сайта

Эквивалентный VirtualHost для Apache с mod_php выглядит иначе по структуре, но решает ту же задачу — часть логики (например, конкретные правила ЧПУ) в реальном проекте обычно выносится в отдельный файл .htaccess внутри директории сайта, а не остаётся целиком в основном конфиге.

<VirtualHost *:80>
    ServerName example.ru
    ServerAlias www.example.ru
    DocumentRoot /var/www/example.ru/public

    <Directory /var/www/example.ru/public>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/example.ru-error.log
    CustomLog ${APACHE_LOG_DIR}/example.ru-access.log combined
</VirtualHost>

Директива AllowOverride All — ключевая для того, чтобы .htaccess файлы в директории сайта вообще обрабатывались; без неё Apache будет игнорировать эти файлы, даже если они физически присутствуют на диске, что становится частой причиной «правила в .htaccess не работают» у новичков.

Гибридная схема: Nginx перед Apache

Распространённое решение, сочетающее сильные стороны обоих серверов, — поставить Nginx на внешние порты 80 и 443 в роли reverse proxy, который отдаёт статические файлы напрямую и передаёт все динамические запросы на Apache, слушающий внутренний порт (например, 8080), доступный только с localhost.

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

Такая схема особенно оправдана при миграции legacy-проекта, который годами полагался на специфичные .htaccess-правила и Apache-модули, но требует лучшей производительности отдачи статики и защиты от избыточной нагрузки на уровне первого рубежа. Издержка — дополнительная сложность конфигурации и ещё один слой в цепочке обработки запроса, которую нужно учитывать при отладке проблем с сайтом.

HTTPS, HTTP/2 и сжатие: что из коробки

Оба веб-сервера поддерживают TLS-терминацию, HTTP/2 и современные протоколы сжатия, но различаются деталями настройки. В Nginx поддержка HTTP/2 включается одним параметром директивы listen и не требует дополнительных модулей в современных сборках, тогда как в Apache для этого нужен явно подключённый модуль mod_http2, доступный не во всех готовых сборках хостинг-панелей по умолчанию.

listen 443 ssl http2;

Обработка TLS-рукопожатий — заметная нагрузка на CPU при большом числе HTTPS-соединений, и здесь разница между серверами не так принципиальна, как в случае с обычным HTTP-трафиком: оба используют одну и ту же библиотеку OpenSSL под капотом, поэтому реальная производительность шифрования зависит больше от версии OpenSSL и настроек шифров, чем от выбора самого веб-сервера.

Сжатие ответов через gzip или более современный Brotli настраивается в обоих серверах декларативно через несколько директив — разница скорее в удобстве синтаксиса, чем в итоговом результате. Более подробно про настройку HTTPS с бесплатным сертификатом рассказано в статье «SSL: бесплатный сертификат Let's Encrypt».

Логи и мониторинг: что удобнее для диагностики

Оба веб-сервера по умолчанию ведут два типа логов — access-лог с записью о каждом запросе и error-лог с сообщениями о проблемах. Формат access-лога в обоих серверах настраивается под конкретные нужды: можно добавить время обработки запроса, размер ответа, заголовки — что полезно при диагностике медленных страниц или подозрительной активности.

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

Инструменты вроде GoAccess или Fail2ban одинаково хорошо работают с логами обоих серверов при условии, что формат лога стандартный и не был изменён нестандартным образом — при кастомизации формата логов стоит убедиться, что используемые инструменты анализа по-прежнему способны их разобрать.

Что выбирают популярные CMS по умолчанию

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

1С-Битрикс в готовых сборках вроде BitrixVM по умолчанию использует связку Nginx и Apache одновременно — именно ту гибридную схему, описанную выше, где Nginx обрабатывает статику и SSL, а Apache отвечает за исполнение PHP-кода модулей CMS с более специфичными требованиями к окружению. Подробнее об этом — в статье про преимущества BitrixVM.

Для новых проектов без legacy-требований к .htaccess современная практика чаще выбирает чистый Nginx с PHP-FPM напрямую, без промежуточного Apache, — как более простую в сопровождении и производительную схему для типичного сайта на современной CMS.

Типичные ошибки при выборе и настройке

Перенос сайта с Apache на Nginx без переноса правил из .htaccess в основную конфигурацию — Nginx просто игнорирует файл .htaccess, и специфичные редиректы или правила ЧПУ, годами работавшие на старом сервере, перестают работать без явного переноса в location-блоки нового конфига.

Использование mod_php на Apache для высоконагруженного проекта вместо PHP-FPM — на серьёзной нагрузке эта связка расходует заметно больше памяти на одинаковое число одновременных запросов по сравнению с любой конфигурацией, где статика отделена от обработки PHP.

Выбор Nginx для проекта, который сильно зависит от специфичных Apache-модулей или сложной логики в .htaccess, без оценки трудозатрат на перенос этой логики в новую конфигурацию — иногда выигрыш в производительности не окупает объём работы по миграции устоявшейся логики.

Игнорирование того, что оба веб-сервера требуют регулярных обновлений безопасности не меньше, чем PHP или сама CMS, — устаревшая версия любого из них так же может содержать известные уязвимости, актуальные для сканеров в интернете.

Чек-лист выбора веб-сервера для нового проекта

Шаг 1. Оцените ожидаемую нагрузку: для типичного сайта на CMS с умеренной посещаемостью выбор между Nginx и Apache почти не повлияет на реальную производительность — решающими становятся другие факторы.

Шаг 2. Проверьте зависимость проекта от .htaccess и специфичных Apache-модулей — если такая зависимость есть и объёмна, Apache или гибридная схема Nginx + Apache потребуют меньше трудозатрат на перенос.

Шаг 3. Для нового проекта без legacy-требований по умолчанию разумно выбирать Nginx с PHP-FPM — эта связка проще в сопровождении на современном стеке и лучше масштабируется при росте нагрузки.

Шаг 4. Если ожидается высокая нагрузка на статику (галереи изображений, файлы для скачивания) — Nginx предпочтителен независимо от остальных факторов благодаря заметно более эффективной раздаче статических файлов.

Шаг 5. При сомнениях начните с той связки, которая уже привычна команде — переход между веб-серверами всегда можно выполнить позже, когда появятся конкретные метрики нагрузки, обосновывающие такое решение.

Итог: нет универсально правильного выбора

Nginx выигрывает там, где важны производительность при большом числе одновременных соединений и эффективная раздача статических файлов — это делает его разумным выбором по умолчанию для большинства новых проектов на современном стеке. Apache сохраняет преимущество там, где критична гибкость .htaccess для многопользовательского хостинга или зависимость от специфичных модулей, накопленных за десятилетия существования сервера.

Для многих реальных проектов, особенно построенных на зрелых CMS вроде 1С-Битрикс, оптимальным решением оказывается не выбор одного веб-сервера вместо другого, а их совместное использование — Nginx на внешнем контуре и Apache там, где нужна его специфичная функциональность. Если не уверены, какая конфигурация веб-сервера подойдёт именно вашему проекту — опишите задачу в заявке внизу страницы, поможем настроить оптимальный стек под конкретные требования.

Практическая настройка связки Nginx с PHP-FPM с нуля, включая типичные ошибки конфигурации сокетов и таймаутов, разобрана в следующей статье базы знаний — она логично продолжает тему этой статьи для тех, кто уже определился с выбором в пользу Nginx.