У каждого, кто обслуживает серверы, рано или поздно наступает день выбора веб-сервера. Причины бывают разные: память кончается на старой связке, сертификат протух в выходные, конфиг под новый сайт разросся на две страницы, а руководство просит сделать "что-нибудь попроще". Рынок уже два десятилетия держат три имени: Nginx, Apache httpd и набирающий обороты Caddy. Осенью 2026 года все три проекта живы, регулярно выпускают версии и заметно разошлись в философии. Ниже разбор без рекламных лозунгов: что каждая программа делает лучше конкурентов, где спотыкается и под какие задачи её стоит ставить.
Актуальные ветки Nginx, Apache и Caddy на конец 2026 года
Сначала факты, чтобы разговор шёл о конкретных программах, а не о воспоминаниях. Nginx живёт в двух ветках: основная 1.31 с текущей сборкой 1.31.6 и стабильная 1.30, где последняя правка обозначена номером 1.30.5. Политика проекта проста: в основную ветку попадают новые возможности, в стабильную идут только исправления и заплатки безопасности, поэтому на нагруженных продакшенах чаще встречаются чётные ветки. Первая публичная версия Nginx вышла в 2004 году, и за два десятилетия базовая схема работы почти не менялась. Пакетные репозитории Debian и Ubuntu держат стабильную ветку, свежий мейнстрим ставят из репозитория самого проекта.
Apache httpd остаётся в линейке 2.4, которая развивается уже второе десятилетие: осенью 2026 актуальна сборка 2.4.69. Ветка 2.4 появилась в 2012 году и с тех пор регулярно получает исправления и небольшие улучшения. Сам проект старше многих читателей: первая версия вышла в 1995 году, и за это время под Apache накоплены тысячи инструкций, от хостинговых вики до корпоративных баз знаний.
Caddy движется по нумерации быстрее всех: релиз 2.11.7 датируется началом октября 2026 года. Вторая версия сервера вышла в 2020 году, написана на Go и с первого дня строилась вокруг автоматического HTTPS. Мелкие версии выходят часто, старые конфиги при этом продолжают работать.
Что из этого следует? Все три проекта зрелые, в продакшн можно ставить любой. Разница не в возрасте, а в том, на какую часть работы каждый делает упор.
Обработка соединений и поведение под пиковой нагрузкой
Начать логично с архитектуры, потому что именно она определяет поведение под нагрузкой. Nginx построен по схеме мастер и воркеры: управляющий процесс читает конфигурацию и поднимает рабочие процессы, а те крутят цикл событий поверх epoll в Linux или kqueue во FreeBSD. Один воркер держит десятки тысяч одновременных соединений, расходуя на каждое считанные килобайты памяти. Медленный клиент мобильной сети не занимает отдельный поток, он просто ждёт в очереди событий, и серверу всё равно, висит соединение секунду или час.
Apache httpd предлагает на выбор три модели обработки запросов, подключаемые модулями MPM: prefork с процессом на каждый запрос, worker с пулом потоков и event, где ожидание отложенных соединений вынесено в отдельные потоки. В современных сборках Debian и Ubuntu по умолчанию включён event, и это разумный выбор для большинства задач. prefork остаётся реликтом эпохи mod_php, когда код исполнялся прямо внутри процессов Apache, и на новых проектах почти не встречается.
Caddy написан на Go, каждая сетевая операция выполняется в лёгкой горутине, а планировщик языка сам распределяет их по ядрам, современная TLS-библиотека идёт в комплекте языка. HTTP/2 давно стал нормой для всех троих. HTTP/3 расставляет иначе: у Caddy он включён по умолчанию, у Nginx поддержка появилась в основной ветке в 2023 году начиная с версии 1.25 и к ветке 1.31 доведена до штатного состояния, а в стабильной ветке Apache 2.4 его нет, экспериментальный модуль живёт в ветке разработки. Забавная деталь: HTTP/3 живёт поверх UDP, поэтому в брандмауэре для Nginx и Caddy открывают и UDP 443, не только TCP.
Для включения HTTP/3 в Nginx нужен listen с пометкой quic и заголовок, сообщающий браузеру о поддержке UDP:
listen 443 ssl;
listen 443 quic reuseport;
add_header Alt-Svc 'h3=":443"; ma=86400';Честности ради: на отдаче статики с одного сервера все три покажут близкие результаты, разница утонет в погрешности измерений. Картина меняется там, где тысячи долгоживущих keep-alive соединений, десятки TLS-рукопожатий в секунду и очереди медленных клиентов. В таких режимах цикл событий Nginx и горутины Caddy обгоняют классические потоки. Синтетические тесты без реального профиля трафика почти всегда врут, и доверять стоит собственному мониторингу больше, чем чужим графикам.
Синтаксис конфигурации и порог входа для новичка
Удобство конфигурации субъективно ровно до первого вечера, потраченного на поиск лишней фигурной скобки. Сравнение честнее вести на одной задаче: отдать статику сайта по HTTPS. Вариант Nginx:
server {
listen 443 ssl;
http2 on;
server_name example.com;
root /var/www/example;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location / {
try_files $uri $uri/ =404;
}
}Тот же сайт на Apache httpd:
<VirtualHost *:443>
ServerName example.com
DocumentRoot /var/www/example
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
<Directory /var/www/example>
Require all granted
</Directory>
</VirtualHost>И вся та же задача на Caddy:
example.com {
root * /var/www/example
file_server
}Разница не только в количестве строк. В первых двух примерах пути к сертификатам администратор указывает руками, потому что сами серверы за сертификатами не ходят. Caddy выпускает и продлевает их сам, поэтому в конфиге просто нечего писать. Порог входа тоже разный: Nginx требует понять вложенность контекстов server и location и жёсткие правила о том, где какая директива разрешена, Apache живёт XML-подобными блоками и богатым синтаксисом, а Caddyfile читается почти как английское предложение. За простотой прячется глубина: когда возможностей короткого формата перестаёт хватать, открывается JSON-конфигурация с API для изменений на лету.
Проверка синтаксиса перед перезагрузкой у каждого своя:
nginx -t
apachectl configtest
caddy validate --config /etc/caddy/CaddyfileСертификаты HTTPS и жизнь без ручного продления
Для Nginx и Apache сертификаты чаще всего выпускает внешний помощник Certbot. Типовая последовательность для Nginx:
apt install certbot python3-certbot-nginx
certbot --nginx -d example.com -d www.example.com
systemctl status certbot.timerСертификаты живут три месяца, продление запускается таймером systemd или по cron, отдельный хук после обновления файлов перезагружает сервер. Схема работает годами, но у неё есть уязвимое место: таймер кто-нибудь однажды выключит, хук потеряется при переезде, и сертификат тихо истечёт в ночь с субботы на воскресенье. Пользователи увидят предупреждение браузера, а администратор узнает о проблеме из переписки раньше, чем из мониторинга.
Caddy держит ACME-клиент внутри себя. При старте сервер видит домены в конфигурации, получает для них сертификаты в публичных центрах вроде Let's Encrypt и ZeroSSL, включает перенаправление с HTTP на HTTPS и дальше сам следит за сроками. Продление запускается задолго до истечения и происходит фоном, без таймеров и перезагрузок. Если центр не отвечает, Caddy делает повтор, меняет способ проверки, переключается на другого эмитента и тянет попытки с растущими паузами до тридцати дней. Этап "настроить HTTPS" исчезает из инструкции вместе со своими ошибками.
Ручной работы меньше и в мелочах: современные шифры, HSTS и сшивание OCSP у Caddy настроены из коробки, а в конфиги Nginx и Apache эти строки обычно переносят из чужих готовых сниппетов, где опечатка спокойно живёт годами.
У классической связки остаётся одно преимущество: полный контроль над файлами и хранилищем. Когда сертификат выпускает корпоративный центр или требуется нестандартная цепочка, ручное управление иногда оказывается удобнее автоматики.
Модули, экосистема и совместимость со старыми проектами
Apache силён там, где от сервера нужна гибкость без правки основного конфига. Его знаменитый .htaccess позволяет клиенту виртуального хостинга управлять переадресациями, кэшем и доступом в собственном каталоге, не трогая главный файл. За удобство платится производительностью: файл перечитывается при каждом запросе. Зато тысячи унаследованных сайтов переезжают с хостинга на хостинг со своим .htaccess в кармане, и это до сих пор рабочий аргумент.
Nginx расширяется иначе: часть модулей собирается внутрь бинарника, часть подключается как динамические с жёсткой привязкой к версии. Когда нужен Lua или JavaScript прямо в конфигурации, берут сборку OpenResty или модуль njs. Caddy наращивает функции плагинами, которые собираются утилитой xcaddy из исходников: так добавляется, например, DNS-провайдер для wildcard-сертификатов.
Связка с PHP показательна. Современный стандарт это PHP-FPM, отдельный пул процессов, к которому веб-сервер обращается по FastCGI. У Nginx это блок с регулярным выражением:
location ~ \.php$ {
fastcgi_pass unix:/run/php/php-fpm.sock;
include fastcgi_params;
}У Apache обработчик переназначается на сокет:
<FilesMatch \.php$>
SetHandler "proxy:unix:/run/php/php-fpm.sock|fcgi://localhost"
</FilesMatch>У Caddy та же работа умещается в одну строку:
php_fastcgi unix//run/php/php-fpm.sockПо количеству готовых инструкций лидируют ветераны: под Nginx и Apache за десятилетия написаны десятки тысяч страниц, от настройки редиректов до защиты от медленных запросов. У Caddy база знаний компактнее, зато собственная документация проекта читается легко и редко отпускает читателя без ответа.
Память, перезагрузка конфигурации и наблюдение за службой
В простое все три сервера экономны и укладываются в десятки мегабайт. Под нагрузкой различия заметнее: воркер Nginx стабильно компактен, расход памяти Caddy держит ровным сборщик мусора Go, а Apache разрастается сильнее, особенно на prefork, где каждый процесс тянет копию окружения.
Перезагрузка конфигурации без разрыва соединений давно норма отрасли:
systemctl reload nginx
systemctl reload apache2
caddy reload --config /etc/caddy/CaddyfileЛоги у ветеранов текстовые и настраиваемые до последнего поля. Caddy по умолчанию пишет структурированный JSON, который удобно отправлять в системы анализа. Все три работают под systemd, поэтому журнал читается одной командой journalctl с одинаковым синтаксисом. Мелочь, которая экономит вечер на двухсотой перезагрузке за год.
Сценарии, в которых каждый сервер побеждает конкурентов
Типовые расклады к 2026 году устоялись. Nginx берёт высокие нагрузки: фронт перед микросервисами, терабайты статики, десятки тысяч долгих соединений, балансировка бэкендов. Apache держит массовый виртуальный хостинг и унаследованные проекты, где клиенты привыкли к .htaccess и mod_rewrite. Caddy выручает там, где время дороже всего: в команде из одного администратора и десятка проектов добавление нового домена сводится к трём строкам конфигурации.
Быстрый чек-лист перед решением выглядит так:
1. если проект переезжает с хостинга с горой правил в .htaccess, выручит Apache с настройками в каталогах;
2. если фронт держит тысячи долгих соединений и передаёт запросы десятку бэкендов, выбор падает на Nginx;
3. если сайтов много, а администратор один, время экономит Caddy с автоматическими сертификатами;
4. если стек уже описан в базе знаний и стабилен, переезд без явной причины обойдётся дороже возможной пользы;
5. если конфигурацией управляет код и нужен интерфейс для изменений на лету, присмотреться стоит к Caddy с JSON и API.
Встречаются и гибриды: Nginx спереди отдаёт статику и режет нагрузку, Apache сзади обслуживает приложение со своими правилами, Caddy ставят лёгким входом перед внутренними сервисами, где его автоматика раскрывается полностью.
Проигравших в сравнении нет, проигрывает только несоответствие сервера задаче. Nginx остаётся рабочей лошадкой больших фронтов, Apache хранителем совместимости, Caddy молодым инструментом, который забирает у админа рутину с сертификатами. И когда в пятницу вечером продление происходит само, без таймеров и хуков, даже ветераны признают: у новичков есть вкус.