В 2026 году выбор стека для PHP стал заметно интереснее, чем несколько лет назад. Раньше типовой ответ звучал почти автоматически: Nginx плюс PHP-FPM, иногда Apache, если нужен .htaccess или проект уже давно живет на старой экосистеме. Но для небольших сайтов, админок, pet-проектов и внутренних сервисов все чаще рассматривают три сценария: Caddy, Nginx Unit и Apache с mod_php.
Сразу зафиксирую важную мысль: это не соревнование на тему «кто быстрее в вакууме». Для маленького PHP-сайта выбор чаще упирается не в синтетические бенчмарки, а в предсказуемость, простоту сопровождения, понятность конфигов, удобство TLS, работу после обновлений и то, насколько легко потом передать проект другому администратору.
Поэтому ниже не будет попытки назначить одного абсолютного победителя. Вместо этого разберем, где каждый стек действительно хорош: для простого сайта, для внутренней панели, для API за reverse proxy, для self-hosted проекта на Debian или Ubuntu и для маленького сервиса, который должен просто жить без постоянного внимания.
Такое сравнение особенно полезно, если у вас обычная рабочая среда: 1–4 vCPU, умеренный объем RAM, одно-два PHP-приложения, база на той же машине или рядом, иногда Redis, а иногда вообще SQLite, cron и ничего лишнего.
Короткий вывод без долгих чтений
Если нужен быстрый старт, автоматический HTTPS, минимум возни с конфигами и современный админский UX, Caddy выглядит самым дружелюбным вариантом. Он особенно хорош там, где сайт один или их немного, а команда не хочет держать в голове лишние детали вокруг TLS, редиректов и фронтовой обвязки.
Если важна модель управления приложением как рантаймом, нужен API-подход к конфигурации, несколько приложений с разными требованиями и аккуратная маршрутизация без привычной россыпи файловых конфигов, стоит смотреть на Nginx Unit. Но он требует принять его логику работы, а не ждать от него «еще одного Nginx».
Если проект старый, завязан на .htaccess, требует совместимости с набором модулей Apache или вы просто хотите максимально прямой путь без отдельного PHP-FPM, Apache с mod_php все еще имеет смысл. Он не модный и не самый экономный по памяти, но для части задач остается практичным.
Главный критерий здесь не абсолютная скорость, а стоимость эксплуатации: сколько времени вы тратите на настройку, обновления, отладку и типовые ошибки вокруг PHP runtime.
Что именно мы сравниваем
Caddy: современный фронтенд с очень коротким путем до результата
Caddy давно интересен не только тем, что умеет сам получать сертификаты. В контексте PHP это удобный фронтенд для типового сайта: описали хост, корневую директорию, обработчик PHP — и получили рабочую схему без длинного набора ручных директив.
Для небольших проектов это дает реальную экономию времени. Меньше шансов забыть HTTPS-редирект, меньше ручной рутины с ACME, проще запуск на новой машине. В 2026 году это уже не «упрощение для новичков», а нормальный операционный плюс.
Слабая сторона Caddy не столько в производительности, сколько в инерции экосистемы. Если команда годами жила в Apache или классическом Nginx-стеке, некоторые привычные паттерны придется переосмыслить.
Nginx Unit: веб-сервер как управляемый runtime приложений
Nginx Unit часто неверно воспринимают как еще один вариант обычного Nginx для PHP. На практике он интересен тем, что смотрит на задачу через модель приложений, listeners, routes и runtime-сред, а не через привычную длинную конфигурацию фронтенда.
Для self-hosted PHP-сценариев Unit хорош там, где хочется отдельно описывать процессы, версии интерпретатора, правила маршрутизации и обновлять приложение без тяжелого перезапуска всей связки. Это особенно удобно, когда на одной машине живет несколько приложений с разными требованиями.
Но у такого подхода есть цена. Unit требует, чтобы администратор принял его модель. Если ждать от него тот же опыт, что от привычного Nginx, будет раздражение. Если же нужен именно управляемый PHP runtime с API-подходом, это сильный кандидат.
Apache mod_php: не списывайте раньше времени
Про mod_php любят говорить как о чем-то окончательно устаревшем, но для небольших PHP-сайтов он никуда не исчез. Особенно там, где проект давно работает, разработчики знают Apache, а миграция на другой стек не дает внятной выгоды.
Его главное преимущество — прямолинейность. Нет отдельного слоя PHP-FPM, меньше компонентов для дебага, меньше межпроцессной коммуникации. Подняли Apache, включили модуль, отдали сайт. Для маленького legacy-проекта это может быть не устаревший, а просто самый дешевый по времени администратора путь.
Минусы тоже известны давно: более заметное потребление памяти, менее выгодная масштабируемость под высокую конкуренцию, зависимость от особенностей MPM и в целом меньшая гибкость по сравнению с разнесенной схемой «веб-сервер плюс FPM». Но маленький сайт с умеренным трафиком — не всегда тот случай, где это становится критично.
Архитектурные отличия, которые реально влияют на выбор
На практике именно архитектура определяет, насколько спокойно стек ведет себя под нагрузкой, при выкладке и во время диагностики проблем.
- Caddy для PHP обычно выступает как веб-сервер и reverse proxy к PHP-обработчику, чаще всего к PHP-FPM.
- Nginx Unit ближе к application server с собственной моделью запуска PHP-приложения.
- Apache
mod_phpвстраивает PHP прямо в рабочие процессы веб-сервера.
Из этого вытекают вполне практические последствия. В Caddy и схеме с FPM проще мыслить слоями: фронтенд, сокет FPM, пул воркеров, таймауты, ограничения. Такая диагностика привычна, особенно если вы уже работали с PHP-FPM. В Unit логика более централизована, но и менее знакома. В Apache меньше внешних точек отказа, зато ниже модульность.
Еще один важный момент — выкладка и перезагрузка конфигурации. Caddy приятен в сценариях, где надо быстро менять фронтовую часть и не тратить много времени на проверку типовых вещей. Unit хорош там, где вы хотите обновлять приложение и его параметры через API. Apache обычно понятен, но старые проекты нередко тащат за собой хвост из include-файлов, старых rewrite-правил и исторических исключений.
Если вы поднимаете такой стек не локально, а на отдельном сервере, удобнее всего тестировать его на VDS: там проще сравнить память, поведение воркеров и настройки PHP без ограничений типового shared-окружения.
Производительность PHP: где интернет-споры расходятся с реальностью
Когда обсуждают производительность PHP, разговор почти всегда пытаются свести к одному числу запросов в секунду. Но для маленького сайта важнее другое: стабильный TTFB, отсутствие резких провалов, понятное поведение при медленной базе, приемлемый расход памяти и быстрая диагностика, когда что-то идет не так.
На чистой динамике без тяжелой бизнес-логики разница между Caddy с PHP-FPM, Unit и Apache mod_php часто оказывается меньше, чем разница между удачной и неудачной настройкой OPcache, между быстрым и медленным диском или между нормальным SQL и N+1 в коде.
В реальной эксплуатации обычно видно следующее:
- Caddy показывает хорошую фронтовую эффективность и почти не мешает PHP-FPM раскрыться. Для небольшого сайта этого более чем достаточно.
- Nginx Unit может вести себя очень достойно по задержкам и управляемости рантайма, особенно если приложение хорошо вписано в его модель.
- Apache
mod_phpчаще проигрывает по памяти на конкурентной нагрузке, но на малом трафике может быть вполне адекватен и даже проще в обслуживании.
Если сайт упирается в CPU на уровне PHP-кода или ждет базу данных, смена одного из этих трех веб-слоев редко даст драматический выигрыш. Сильнее сработают OPcache, профилирование запросов, уменьшение автозагрузки, кэширование шаблонов и нормальная работа с БД.
Для маленького сайта проигрывает не тот стек, который медленнее на несколько процентов, а тот, который администратор боится обновлять и не умеет быстро чинить ночью.
Кстати, если после выбора стека вы хотите дополнительно выжать поведение статики и условных запросов, полезно отдельно посмотреть на настройку Cache-Control и ETag для статики: это часто дает более заметный эффект, чем спор о веб-сервере.
Память, процессы и поведение на маленьком сервере
Если стек выбирается для небольшого VPS, домашнего сервера или внутренней машины, память часто важнее синтетической скорости. Именно здесь Apache mod_php обычно проигрывает первым. Встроенный PHP в процессах Apache удобен, но расплачиваетесь вы большим memory footprint, особенно при тяжелых расширениях и неаккуратной настройке MPM.
Caddy плюс PHP-FPM обычно выглядит более предсказуемо по памяти: фронтенд сам по себе легкий, а FPM можно дозировать через пулы, pm.max_children, разделение пользователей и отдельные настройки под разные сайты.
Nginx Unit занимает интересную середину. Он не выглядит исторически прожорливым, как старые сценарии с Apache, но и не всегда столь же прозрачен в тюнинге для администратора, который много лет жил в мире PHP-FPM. Если опыта с Unit мало, часть ресурса уйдет не в железо, а в привыкание.
Минимальные ориентиры по памяти
Для одного небольшого проекта разумно оценивать стек не только по среднему потреблению, но и по худшему сценарию во время пиков, бэкапов, cron-задач и обновлений. На маленьких машинах именно это чаще всего убивает стабильность.
- Смотрите не только на RAM веб-сервера, но и на суммарную память PHP-воркеров.
- Проверяйте поведение при пике одновременных запросов, а не только в idle.
- Оставляйте запас под БД, системный кэш, логи и фоновые задачи.
- Не завышайте
pm.max_childrenтолько ради красивых цифр в теории.
Reverse proxy, TLS и внешний трафик
Если сервер смотрит в интернет, вопрос reverse proxy и TLS становится обязательным. И здесь у Caddy одно из самых заметных практических преимуществ. Он очень хорошо закрывает типовые потребности: HTTPS по умолчанию, редиректы, базовое проксирование, понятные настройки виртуальных хостов.
Для одиночного проекта это буквально уменьшение количества возможных ошибок. Если серверу нужен только нормальный внешний вход, а не сложная историческая экосистема правил, Caddy обычно оказывается самым комфортным вариантом.
Unit как фронтенд тоже может работать, но на практике его часто удобнее рассматривать как часть application stack, а не как самый универсальный внешний edge. Если нужен привычный внешний reverse proxy с акцентом на простое и понятное TLS-поведение, Caddy воспринимается легче.
Apache во внешней роли тоже остается рабочим вариантом, особенно если команда хорошо знает его модули и правила. Но если вы стартуете с нуля и не привязаны к Apache-экосистеме, в 2026 году он редко выглядит самым приятным выбором именно для новой PHP-установки.
Если стек будет принимать внешний трафик, не забывайте и про заголовки безопасности. Это уже не про выбор между Caddy, Unit и Apache, а про базовую гигиену. По теме полезно держать под рукой материал про HTTP security headers.
Когда проект выходит в интернет и нужен отдельный сертификат под домен или несколько поддоменов, пригодятся и нормальные SSL-сертификаты — особенно в сценариях, где вы хотите контролировать выпуск и совместимость не только встроенной автоматикой.
Удобство сопровождения: где стек экономит часы, а где съедает их
Для большинства админов главный вопрос звучит не как «что лучше на бумаге», а как «с чем я проведу меньше времени в логах, shell и diff-конфигах». И тут картина довольно понятна.
Caddy выигрывает простотой входа и коротким временем до рабочего результата. Новый сайт, TLS, прокси и базовые правила поднимаются быстро. Минус в том, что некоторые нестандартные сценарии приходится формулировать иначе, чем в привычных Nginx- или Apache-конфигах.
Nginx Unit выигрывает управляемостью модели приложения. Если вы строите несколько self-hosted PHP-сервисов, любите API-driven настройку и хотите более современный подход к runtime, Unit может ощущаться чище классического стека. Но для одной CMS или маленького сайта он иногда оказывается сложнее, чем нужно.
Apache mod_php выигрывает знакомостью. Если у вас legacy, старые rewrite-правила, зависимость от .htaccess и команда, которая знает Apache наизусть, стоимость изменений может быть минимальной. Проигрыш в том, что современная эксплуатация вокруг него чаще требует оговорок и аккуратного тюнинга, чтобы не уехать в лишний расход ресурсов.
Какой стек выбрать под конкретные сценарии
Небольшой сайт компании, лендинг, админка, пара форм
Базовый выбор в большинстве случаев — Caddy плюс PHP-FPM. Причина простая: быстро поднимается, легко обновляется, удобно обслуживается и дает хороший баланс между современностью и понятностью. Если вы не хотите собирать все вручную, а нужен просто рабочий сайт, это очень сильный вариант.
Несколько PHP-приложений на одной машине, разные версии и управляемый runtime
Здесь уже стоит серьезно смотреть на Nginx Unit. Особенно если это не одна CMS, а набор внутренних сервисов, API, панелей и утилит. Его модель может оказаться аккуратнее, чем разрастающаяся ручная обвязка вокруг нескольких FPM-пулов и фронтенда.
Старый проект на Apache, завязанный на .htaccess и привычную экосистему
Не ломайте стек только ради моды. Если Apache mod_php уже работает стабильно, а нагрузка невелика, миграция может не окупиться. В таком случае выгоднее вложиться в OPcache, актуальную версию PHP, аудит модулей, кэш и мониторинг.
Домашний или self-hosted PHP-проект на Debian или Ubuntu
Если хочется простоты и быстрого результата — Caddy. Если интересно поработать с более современным application runtime и есть желание понять его архитектуру — Unit. Apache здесь обычно имеет смысл только если вы точно знаете, зачем он вам нужен.
Если проекту не нужен отдельный сервер и задача сводится к одному-двум сайтам без сложной инфраструктуры, иногда практичнее начать с виртуального хостинга, а уже потом переезжать на более гибкую схему по мере роста требований.
Практические замечания перед финальным выбором
Перед окончательным решением полезно проверить не только документацию, но и свои привычки эксплуатации.
- Сколько у вас сайтов и насколько они похожи друг на друга.
- Нужны ли разные версии PHP и изоляция по приложениям.
- Есть ли legacy-зависимость от
.htaccessи модулей Apache. - Насколько важны автоматический TLS и минимальное число ручных действий.
- Кто будет сопровождать сервер через полгода: вы, разработчик или другой администратор.
- Что для вас критичнее: максимальная гибкость, минимальная память или самая простая эксплуатация.
И еще одна мысль, которую стоит проговорить вслух. Для маленького PHP-проекта в 2026 году почти всегда лучше «достаточно хороший и понятный стек», чем самый изощренный. Большинство проблем небольших сайтов происходят не из-за выбора между Caddy, Unit и Apache, а из-за отсутствия обновлений, резервных копий, OPcache, контроля логов и нормального деплоя.
Итог: мой честный вердикт
Если бы меня попросили выбрать один универсальный вариант для нового маленького PHP-сайта сегодня, я бы в большинстве случаев начал с Caddy. Он лучше всего попадает в реальность небольших проектов: быстрый старт, удобный HTTPS, понятное сопровождение и низкий порог входа.
Nginx Unit я бы рекомендовал не всем подряд, а тем, кому действительно нужен управляемый PHP runtime и кто готов принять его модель. Это хороший инструмент, но сильнее раскрывается в более осмысленных сценариях, чем просто «поднять один сайт за вечер».
Apache mod_php я бы не объявлял проигравшим. Для legacy и консервативных инфраструктур он все еще оправдан. Но для нового проекта без исторического багажа это уже скорее специальный выбор, а не дефолт.
Если свести все к одной строке, получится так: Caddy — лучший выбор по удобству для нового небольшого PHP-сайта, Nginx Unit — самый интересный по модели runtime, Apache mod_php — самый жизнеспособный для наследуемых систем и команд, которые уже умеют с ним жить.
