Apache против NGINX: какой веб-сервер лучше для WordPress?

Если вы держите WordPress на собственном VPS, и Apache, и NGINX справятся с обслуживанием сайта, но идут на разные компромиссы. NGINX обычно лучший вариант по умолчанию при высокой конкурентности, отдаче статики и опциональном HTTP/3. Apache проще, когда ваш стек WordPress завязан на .htaccess или на модули, специфичные для Apache.

Это сравнение Apache и NGINX сосредоточено на различиях, которые важны для WordPress: архитектура, обработка PHP, конфигурация, HTTP/3 и вопрос, стоит ли запускать оба сервера ради дополнительной сложности. LiteSpeed и Caddy остаются за рамками.

Короткий ответ: для самостоятельно управляемого VPS с WordPress по умолчанию выбирайте NGINX. Выбирайте Apache, если сайт или плагины сильно завязаны на .htaccess. Запускайте оба только тогда, когда вам действительно нужен NGINX впереди без отказа от совместимости с Apache.

Что такое Apache?

Apache — популярное веб-серверное программное обеспечение с открытым исходным кодом, которое разрабатывает и поддерживает американская некоммерческая организация Apache Software Foundation (ASF). Он также известен как Apache HTTP Server и HTTPD.

Страница загрузки Apache указывает версию 2.4.68, выпущенную в июне 2026 года, как текущий стабильный релиз.

Apache HTTP Server — модульный сервер с открытым исходным кодом и зрелой поддержкой покаталожных правил .htaccess, нескольких мультипроцессных модулей (MPM), обратного проксирования, переписывания URL, TLS и динамически загружаемых модулей. Для WordPress его главное практическое преимущество — совместимость конфигураций, а не чистая скорость.

Возможности Apache, которые важнее всего в этом сравнении: MPM prefork, worker и event; .htaccess; HTTP/2; обратное проксирование и балансировка нагрузки; поддержка FastCGI; динамические модули; переписывание URL; и TLS.

Что такое NGINX?

NGINX («engine x») — это веб-сервер с открытым исходным кодом, обратный прокси, кэш контента, балансировщик нагрузки, TCP/UDP-прокси и почтовый прокси, изначально написанный Игорем Сысоевым. Его рабочие процессы используют событийную модель, рассчитанную на обслуживание множества одновременных соединений с небольшими накладными расходами на каждое.

Страница загрузки NGINX lists the 1.30.x stable branch and the 1.31.x mainline branch.

Apache против NGINX: ключевые различия для WordPress

Apache и NGINX сильнее всего расходятся в том, как они обрабатывают соединения, конфигурацию, PHP и поддержку протоколов. Поведение Apache во многом зависит от используемого MPM, а NGINX работает на событийных рабочих процессах.

Apache против NGINX: архитектура

Модель обработки запросов в Apache зависит от того, какой MPM вы используете. Prefork построен на процессах, а worker и event используют потоки. NGINX работает на рабочих процессах, устроенных вокруг циклов событий. Поэтому привычное сравнение «процессный Apache против событийного NGINX» слишком упрощает картину для современной установки Apache 2.4.

MPM event в Apache может передавать простаивающие keep-alive соединения своему потоку-слушателю вместо того, чтобы занимать под каждое отдельный рабочий поток. При очень большом числе одновременных соединений у NGINX по-прежнему обычно ниже накладные расходы на соединение, но архитектурный разрыв гораздо уже, чем следует из старых сравнений времён prefork.

Apache против NGINX: производительность

Преимущество NGINX по производительности проявляется прежде всего при высокой конкурентности и на статике. Его событийные рабочие процессы держат множество открытых соединений с относительно небольшими накладными расходами на каждое. MPM event в Apache заметно сокращает этот разрыв по сравнению со старыми конфигурациями prefork.

С динамическими запросами WordPress картина другая. NGINX обычно передаёт PHP в FastCGI, чаще всего в PHP-FPM. Apache тоже может работать с PHP-FPM через FastCGI или выполнять PHP через модуль Apache.

Как только PHP начинает выполнять WordPress, код плагинов, запросы к базе, объектный или страничный кэш и число PHP-воркеров могут значить больше, чем веб-сервер впереди. Если плагин выполняет десяток тяжёлых запросов к базе на каждый запрос, переход с Apache на NGINX не устранит саму причину.

Apache против NGINX: поддержка HTTP/3 и QUIC

HTTP/3 — текущая версия протокола, и она работает поверх QUIC вместо TCP. Сможет ли ваш сайт вообще его предложить, зависит от веб-сервера впереди, и это единственный пункт сравнения, где два сервера не близки.

NGINX поставляет модуль HTTP/3 начиная с версии 1.25.0. По умолчанию он не собирается, и сборке нужен параметр --with-http_v3_module.

Документация модуля HTTP/3 в NGINX по-прежнему называет модуль «experimental, caveat emptor applies».

Apache 2.4 не поставляет собственного модуля HTTP/3 или QUIC; встроенная поддержка протоколов заканчивается на mod_http2.

Практическое следствие для владельца сайта: обычная установка Apache 2.4 не отдаёт HTTP/3. В продакшене рабочий вариант по-прежнему такой: терминировать HTTP/3 на обратном прокси или CDN с поддержкой HTTP/3 перед Apache. Если протокол нужен, один из вариантов — поставить NGINX перед Apache и дать NGINX терминировать клиентские соединения, ровно та схема, которая разбирается ниже.

Apache против NGINX: безопасность

Ни Apache, ни NGINX не является безоговорочно «более безопасным». Оба проекта зрелые, с активным сопровождением по безопасности, и защищённость продакшена зависит скорее от обновлений, включённых модулей, настройки TLS, контроля доступа, ограничения запросов и самого приложения за сервером.

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

Apache против NGINX: конфигурация

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

У этого удобства есть цена. Собственная документация Apache рекомендует держать правила в основной конфигурации сервера, если у вас есть root-доступ: файлы .htaccess проверяются во время запросов, а их включение добавляет как вопросы производительности, так и вопросы безопасности.

У NGINX нет аналога .htaccess. Его конфигурация централизована, поэтому WordPress не может сам записать правила переписывания на уровне сервера. Правила постоянных ссылок и серверные директивы, которые требуют плагины, администратор добавляет в конфигурацию NGINX и затем перезагружает её.

Apache против NGINX: модули и расширяемость

У Apache зрелая поддержка динамических разделяемых объектов (DSO): модули можно собрать отдельно и подключить через LoadModule. NGINX тоже поддерживает динамически загружаемые модули через load_module, но двоичная совместимость с установленной версией NGINX и её конфигурацией сборки значит больше, как только вы берёте нестандартные сторонние модули.

Значит, Apache впереди, если вы завязаны на нестандартные сторонние модули. Для обычного хостинга WordPress эта разница обычно значит меньше, чем .htaccess, работа с PHP и уже привычные вам инструменты.

Apache против NGINX: поддержка платформ

Apache работает на Linux, Windows, macOS и многих Unix-подобных системах. NGINX тоже доступен на основных платформах, но его нативная сборка под Windows имеет серьёзные ограничения. NGINX по-прежнему называет версию для Windows бетой, предупреждает, что не стоит ждать высокой производительности и масштабирования, отмечает, что реально работает только один воркер, и не поддерживает ни UDP, ни QUIC. Для продакшена с NGINX практичным выбором остаётся Unix-подобная операционная система.

Apache против NGINX: обработка запросов

Apache обычно отображает URL запроса на файловую систему под DocumentRoot, а его система конфигурации умеет применять ещё и локации по URI, перезаписи и правила проксирования. NGINX сначала выбирает блок server, затем блок location, в основном по URI запроса, и только потом решает, отдать файл или передать запрос дальше.

Эта разница влияет на то, как вы пишете конфигурацию, но сама по себе не доказывает, что NGINX передаёт данные быстрее.

Краткое сравнение NGINX и Apache

Вот как два сервера соотносятся по перечисленным выше пунктам, плюс поддержка протоколов и текущая версия каждого.

Использование Apache и NGINX вместе

Да, можно запустить оба. Распространённая гибридная схема ставит NGINX впереди как обращённый к клиентам обратный прокси, а Apache позади. NGINX умеет терминировать TLS и HTTP/2, а также HTTP/3, когда его экспериментальный модуль HTTP/3 собран и включён. Ещё он может сам отдавать часть статики, передавая запросы приложения в Apache.

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

Цена в том, что теперь у вас работают два веб-сервера. Две конфигурации, которые должны согласовываться, два цикла обновлений и ещё одно место, куда придётся заглянуть, когда запрос вернёт что-то неожиданное. На одном небольшом сайте эти хлопоты обычно перевешивают выгоду; они начинают окупаться, когда вам нужен HTTP/3 или более быстрая отдача статики без отказа от поведения .htaccess, на которое рассчитывают ваши плагины.

NGINX проще, чем Apache?

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

На сервере, который вы контролируете, «проще» сводится в основном к тому, какую модель конфигурации ваш стек уже подразумевает.

Когда выбирать Apache вместо NGINX?

Выбирайте Apache, когда ваш стек WordPress завязан на .htaccess, когда плагины или инструменты панели управления рассчитывают на директивы переписывания Apache, или когда вам нужен конкретный модуль Apache. Разумно и оставить Apache на существующем сайте, который и так работает хорошо: менять веб-сервер ради теоретического выигрыша в бенчмарке редко стоит связанных с этим хлопот.

Когда выбирать NGINX вместо Apache?

Выбирайте NGINX, когда ждёте много одновременных соединений, хотите сильный слой отдачи статики или обратного проксирования, предпочитаете централизованную конфигурацию или хотите иметь возможность включить HTTP/3. Для WordPress плата в том, что правила переписывания и серверные директивы плагинов становятся задачей администратора, а не тем, что WordPress может записать в .htaccess.

NGINX против Apache: какой веб-сервер лучше для WordPress?

Берите NGINX. Для сайта на WordPress на сервере, который вы контролируете, это лучший вариант по умолчанию: небольшие накладные расходы на соединение при высокой конкурентности, эффективная отдача статики и доступный HTTP/3, если он вам нужен.

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

Под всем этим лежит одно допущение: сервер должен быть вашим и изменяемым. На управляемом хостинге WordPress веб-сервер выбирает хостер, и ответ на этот вопрос — просто то, что у него уже работает. Это сравнение для того, у кого есть root-доступ к собственной машине.

Как проверить, что у вас работает: Apache или NGINX?

Если это ваш собственный VPS, проверьте запущенные службы напрямую:

systemctl status nginx
systemctl status apache2   # Debian/Ubuntu
systemctl status httpd     # RHEL/Fedora-family systems

Для чужого сайта, который вы не контролируете, заголовок ответа HTTP Server может быть подсказкой, но не доказательством. Обратный прокси или CDN может показывать своё серверное ПО вместо того, что стоит на origin, а сам заголовок можно скрыть или изменить.

Размещение Apache или NGINX на VPS

Если VPS ваш, оба сервера запускаются без сложностей. Подбирайте размер машины под весь стек WordPress, а не только под Apache или NGINX: PHP-воркеры, база данных, кэширование, трафик и фоновые задачи обычно съедают больше ресурсов, чем сам веб-сервер.

Какой бы сервер вы ни выбрали, конфигурация, обновления, TLS, резервные копии и мониторинг остаются на вас. Запуск обоих добавляет ещё одну конфигурацию и ещё один путь обновлений, так что беритесь за гибридную схему только при конкретной причине.

NGINX VPS от Cloudzy — это самостоятельно управляемый Linux VPS с полным root-доступом, так что конфигурация сервера остаётся вашей.

Образ Apache HTTP Server в нашем маркетплейсе устанавливается так же, в один клик, поэтому поднять любой из серверов или сразу оба не начинается со сборки из исходников.

ЧИТАТЬ

Caddy против Nginx на VPS: сравнение файлов конфигурации

Часто задаваемые вопросы

Apache лучше, чем NGINX?

Ни один не лучше во всех случаях. NGINX обычно более сильный вариант по умолчанию, когда вам важны высокая конкурентность, отдача статики, обратное проксирование или HTTP/3. Apache обычно проще, когда ваш стек WordPress завязан на .htaccess или на модули, специфичные для Apache.

Почему NGINX быстрее Apache?

NGINX умеет обрабатывать множество соединений внутри цикла событий каждого воркера, что удерживает низкие накладные расходы на соединение при высокой конкурентности. MPM event в Apache тоже обрабатывает соединения асинхронно, поэтому разрыв меньше, чем следует из старых сравнений с prefork. В WordPress PHP, запросы к базе и кэширование могут значить больше, чем разница между веб-серверами.

Что использовать для WordPress: Apache или NGINX?

Для самостоятельно управляемого VPS с WordPress NGINX — сильный вариант по умолчанию, если вы готовы сами вести правила в блоках server. Выбирайте Apache, если опираетесь на .htaccess или на плагины, ожидающие правил переписывания Apache, и хотите, чтобы они работали с меньшим объёмом ручной настройки сервера.

Почему NGINX так популярен?

NGINX сочетает эффективную обработку запросов при высокой конкурентности с обратным проксированием, балансировкой нагрузки, кэшированием, поддержкой FastCGI и терминацией TLS. Благодаря этому он полезен и как основной веб-сервер, и как фронтальный прокси.

Почему Apache всё ещё используют?

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

В чём разница между Apache и apache2?

В Debian и Ubuntu apache2 — это имя пакета и службы для Apache HTTP Server. В системах семейства RHEL и Fedora эту службу обычно называют httpd. Это не разные веб-серверы: оба названия означают Apache HTTP Server. Текущая стабильная ветка Apache — 2.4, последний выпуск в ней 2.4.68.

Поддерживает ли Apache HTTP/3?

Изначально нет. Apache HTTP Server 2.4 не поставляется с модулем HTTP/3 или QUIC; встроенная поддержка протоколов заканчивается на HTTP/2. Если HTTP/3 нужен в продакшене, вы можете терминировать его на обратном прокси или CDN с поддержкой HTTP/3 перед Apache.