Сайт на WordPress тормозит при 50 посетителях, хотя сервер не загружен? Знакомая ситуация для тех, кто арендовал дешёвый хостинг на Apache и не вникал в стек. Причина почти всегда одна: веб-сервер не справляется с одновременными подключениями.

Замена хостинга решает проблему. Но важнее понять, какой веб-сервер стоит за тарифом. От этого зависит, выдержит ли сайт всплеск трафика или ляжет после репоста в Telegram.

Ниже, без воды: как устроены Apache и nginx, в чём разница на практике и почему nginx стал стандартом для WordPress-хостинга в 2026 году.

💡 Быстрый обзор:

• Веб-сервер принимает HTTP-запросы от браузера и возвращает ответ: статику отдаёт сам, динамику обрабатывает через связку с PHP.
• Apache создаёт процесс на каждое соединение, гибко, но под нагрузкой память кончается. Nginx использует событийную архитектуру и держит тысячи соединений в одном процессе.
• Для WordPress критичны одновременные соединения, работа с кешем и расход памяти. Nginx выигрывает по всем трём параметрам.
• Хостинг на nginx даёт более быстрый сайт при том же тарифе. Хотите проверить свой, спросите техподдержку о стеке веб-сервера.

Что такое веб-сервер и зачем он WordPress

Веб-сервер, программа, которая принимает HTTP-запросы и возвращает ответ. Когда посетитель открывает сайт, браузер стучится к серверу, а тот отдаёт HTML-страницу. Для WordPress схема чуть сложнее: PHP-процессор собирает страницу из шаблона и базы данных, а веб-сервер передаёт результат пользователю.

На рынке два доминирующих веб-сервера с открытым исходным кодом: Apache и nginx. По данным W3Techs на июнь 2026, nginx обслуживает 31,9% сайтов с известным веб-сервером, Apache, 23,9%. Вместе они покрывают больше половины интернета. IIS от Microsoft идёт третьим с заметным отставанием.

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

Apache: проверенный, но тяжёлый

Apache HTTP Server появился в 1995 году и десятилетиями был стандартом. Он лежит в основе cPanel, самой распространённой панели управления хостингом. Большинство shared-хостингов до сих пор крутят Apache просто потому, что «так исторически сложилось».

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

Но у этой гибкости есть цена. Apache создаёт отдельный поток или процесс на каждое соединение. При 100 одновременных посетителях, 100 процессов. При 500, память кончается, сервер отвечает с задержкой или роняет часть соединений. Это называется проблемой C10K, 10 000 одновременных подключений, которую Apache в стандартном режиме не тянет.

На практике сайт на Apache без дополнительного кеширования начинает заметно тормозить уже при нескольких десятках одновременных пользователей. WordPress с его динамической природой только усугубляет картину: каждый запрос гонит PHP, тот лезет в базу, и процесс висит до полной отработки.

Nginx: событийный подход и почему он быстрее

Nginx написал Игорь Сысоев в 2002 году именно для решения проблемы C10K. Первый публичный релиз вышел в 2004-м. В отличие от Apache, nginx построен на событийной архитектуре: один рабочий процесс обслуживает тысячи соединений, не создавая под каждое отдельный поток.

Как это работает. Nginx слушает события на сокетах и реагирует только тогда, когда есть данные для обработки. Новый запрос пришёл, обработали. Клиент медленно принимает ответ, не блокируемся, переключаемся на другого. Именно асинхронность позволяет nginx держать больше соединений при меньшем расходе памяти.

У nginx есть ограничение: он не умеет обрабатывать динамический контент самостоятельно. Ему нужен внешний обработчик, PHP-FPM, FastCGI или прокси на тот же Apache. Но на практике это не минус, а плюс: динамика изолирована, не мешает отдаче статики, и каждый компонент можно настраивать независимо.

Исторически главной проблемой nginx была документация. Сысоев писал её на русском, и ранние версии страдали от скудных описаний. Сейчас документация переведена, сообщество огромное, и для WordPress существуют готовые конфигурации под любые сценарии. Тот же DigitalOcean поддерживает детальные мануалы по связке nginx + WordPress.

Ещё одно отличие: nginx не умеет динамически загружать модули и не поддерживает .htaccess. Все настройки, в конфигурационных файлах сервера, и для их применения нужен reload. Это менее удобно при ежедневной правке мелочей, но даёт предсказуемость: сервер не сканирует директории на лету в поиске правил и не тратит на это процессорное время.

Шесть причин выбрать nginx для WordPress

Конкретные аргументы, почему nginx лучше Apache для сайта на WordPress.

Простая установка

Nginx ставится одной командой на любом Linux-дистрибутиве:

1
apt install nginx

Или для RHEL/CentOS:

1
yum install nginx

После установки nginx сразу работает как служба. Для WordPress понадобится добавить PHP-FPM и минимальную конфигурацию, типовой конфиг из 20 строк, который не меняется от проекта к проекту.

Прокси-режим для Apache

Если сайт уже живёт на Apache и переезжать страшно, nginx можно поставить перед ним как reverse proxy. Вся статика уходит через nginx, а PHP-запросы он проксирует на Apache. Прирост производительности виден сразу, а .htaccess и привычная модульная структура продолжают работать.

На схеме это выглядит так: браузер → nginx (статика + кеш) → Apache (только PHP). По бенчмаркам, даже такая связка даёт двукратный выигрыш по числу обрабатываемых запросов в секунду.

Встроенный кеш

У nginx есть fastcgi_cache, он кеширует ответы PHP-FPM и отдаёт их как статику. Для WordPress это радикально: страница, собранная один раз, летит из кеша всем следующим посетителям без запуска PHP и запросов в базу.

На практике хорошо настроенный fastcgi_cache снижает время ответа сервера с 600-800 мс до 20-40 мс. Никакой внешний плагин кеширования для WordPress не даёт такого эффекта на уровне сервера.

Скорость отдачи статики

Картинки, CSS, JavaScript, шрифты, всё, что не требует PHP, nginx раздаёт напрямую, без дополнительных прослоек. Одна директива try_files перекрывает десяток правил Apache. Результат: статические файлы отдаются за миллисекунды, и PHP-воркеры не заняты мусорной работой.

Больше соединений при меньшем потреблении

Nginx держит примерно в четыре раза больше одновременных соединений, чем Apache, при сопоставимом расходе памяти. Это не абстрактная цифра, данные W3Techs показывают, что среди сайтов с высоким трафиком nginx занимает долю больше 60%.

Две практические выгоды для владельца WordPress-сайта:

• При росте посещаемости не нужно сразу переходить на более дорогой тариф.
• Сервер использует меньше CPU и RAM, хостинг-провайдер может держать цену ниже или давать больше ресурсов за те же деньги.

Легковесность

Nginx спроектирован так, чтобы потреблять минимум ресурсов. Рабочий процесс слушает события и активируется только по мере необходимости. Аргумент on demand в конфигурации позволяет вообще выгружать неиспользуемых воркеров из памяти.

Apache пытался внедрить событийный режим через mpm_event, но это надстройка над процессной архитектурой, а не перепроектирование. Производительность mpm_event не дотягивает до nginx именно потому, что Apache изначально построен иначе.

Балансировка нагрузки

Nginx умеет распределять запросы между несколькими бэкенд-серверами. Для высоконагруженного WordPress-проекта это означает: можно запустить два-три сервера приложений, поставить перед ними nginx как балансировщик, и сайт будет держать десятки тысяч одновременных посетителей. Крупные WordPress-хостинги, WP Engine, Kinsta, используют именно такую архитектуру.

⁉️🤔 Частые вопросы

Обязательно ли переходить на nginx, если сайт на Apache работает нормально?

Если сайт стабилен при текущем трафике, срочной замены не требуется. Но при планах роста, запуске рекламы или сезонных всплесках, ставьте nginx как прокси перед Apache. Это даст запас по производительности без миграции.

Правда ли, что nginx сложнее настроить для WordPress?

Базовая настройка состоит из одного конфигурационного файла и типового набора правил для pretty permalinks. DigitalOcean и WordPress.org публикуют проверенные конфиги. Разница с Apache: вместо правки .htaccess вы правите nginx.conf и делаете nginx -s reload. На старте чуть непривычно, но конфиг читается проще.

Какой хостинг выбрать: сразу с nginx или любой с поддержкой nginx как прокси?

Если берёте managed WordPress, смотрите чтобы nginx был в стеке как основной веб-сервер. WP Engine, Kinsta, Rocket.net работают именно так. Если VPS, ставьте nginx + PHP-FPM, это стандарт для WordPress в 2026 году. Shared-хостинг с nginx как прокси перед Apache, компромиссный, но всё ещё выигрышный вариант.

Теряю ли я что-то важное при переходе с Apache на nginx?

Вы теряете .htaccess. Всё, что вы правили через него (редиректы, запреты доступа, кеширование), переносится в конфигурацию nginx, один раз и централизованно. Плагины WordPress, которые полагаются на .htaccess (например, некоторые плагины безопасности), могут требовать ручной адаптации правил. Но крупные плагины уже давно идут с конфигами для nginx.

Есть ли будущее у Apache для WordPress?

Apache никуда не денется, слишком много хостингов на нём построено. Но тренд однозначен: доля Apache снижается, доля nginx растёт. Новые WordPress-проекты и хостинги запускаются на nginx по умолчанию. Если вы начинаете с нуля, начинайте с nginx.

Nginx или Apache: что ставить в 2026 году

Если коротко: для WordPress выбирайте nginx. Не потому что Apache плох, а потому что nginx решает конкретную боль, держит много посетителей на скромном железе и раздаёт контент быстрее.

Схема действий для трёх типичных ситуаций:

• Запускаете новый сайт. Берите хостинг с nginx в стеке или настраивайте VPS на связке nginx + PHP-FPM. Шаблонных конфигов для WordPress, десятки, сложностей с настройкой нет.
• Сайт уже на Apache и тормозит. Поставьте nginx как reverse proxy. Это час работы системного администратора и мгновенный прирост производительности.
• Сайт на Apache, всё летает. Живите спокойно. Но держите в уме, что при росте трафика nginx даст больший запас, чем попытка выжать ещё из Apache.

Проверьте текущий стек: зайдите в консоль хостинга или спросите техподдержку. Если услышите «nginx», хорошо. Если «Apache», теперь вы знаете, что с этим делать.