Когда у команды встает вопрос, на чем поднимать следующий PHP‑проект или как ускорить текущий, выбор часто сводится к двум веб‑серверам: OpenLiteSpeed (OLS) и Nginx. Оба зрелые, производительные, событийно‑ориентированные. Но различия в архитектуре, кэшировании, совместимости с конфигами и экосистеме могут существенно повлиять на итоговую скорость, стабильность и стоимость сопровождения. Ниже — практический взгляд администратора: где что выигрывает, какие подводные камни на проде и как принимать решение без религиозных споров.
Краткий итог в двух словах
Если нужна максимальная производительность WordPress/типовых CMS «из коробки» при минимуме настройки — OpenLiteSpeed с его тесной интеграцией LSAPI и приложным кэшем часто покажет лучший TTFB и p95. Если стек смешанный (reverse‑proxy, gRPC, TCP/UDP‑балансировка, продвинутые карты и роутинг), больше гибкости и привычной IaC‑парадигмы даст Nginx.
Архитектура и модель обработки PHP
Оба сервера построены вокруг неблокирующего ввода‑вывода и масштабируются на ядрах CPU за счет многопроцессной/многопоточной модели. Разница — в связке с PHP и ряде деталей:
- Nginx традиционно работает с PHP через FastCGI и
php-fpm. Это стабильный и предсказуемый слой, легко настраивается под разные пулы, пользователей и лимиты. - OpenLiteSpeed применяет LSAPI (LiteSpeed SAPI) и «lsphp». В высоких нагрузках LSAPI обычно снижает накладные расходы на форки/контексты по сравнению с классическим FastCGI, что даёт меньшую латентность при большом числе одновременных запросов.
Практически это означает: при равной аппаратуре на динамических страницах (особенно под CMS) OLS часто демонстрирует более короткий TTFB и лучшее p95/p99. Nginx же выигрывает архитектурной универсальностью: от статического файлового сервиса до сложного реверс‑прокси для разных бэкендов. Если вы также сравниваете с Apache, посмотрите разбор «Nginx против Apache» с обновлениями 2025 года — он помогает понять границы каждого стека: сравнение Nginx и Apache.
Производительность: от статики до динамики
На статике оба сервера быстры, упираясь скорее в дисковую подсистему и сеть. На динамике разрыв чаще возникает из‑за различий в кэшировании и PHP‑стеке:
- OpenLiteSpeed: встроенная интеграция с LSAPI и приложным кэшем (через плагины для популярных CMS) даёт агрессивное, но безопасное кэширование всего HTML. При корректной настройке это снимает 80–95% нагрузки с PHP и базы.
- Nginx: fastcgi‑microcache позволяет получить похожий эффект, но требует аккуратной сегментации ключей, исключений по кукам/авторизации, политик инвалидирования. Результат сопоставим, но ценой большего числа нюансов в конфиге и интеграции с приложением.
На реальных проектах прирост от OLS заметен на «чистой» CMS (лендинги, блоги, каталоги без сложной персонализации). Чем больше персонализированных блоков, тем меньше выигрыша и тем аккуратнее нужно проектировать кэш‑стратегию — на Nginx и OLS одинаково. Для работы с политиками кэширования статических ресурсов пригодится материал о заголовках Cache-Control и ETag: настройка Cache-Control и ETag.
HTTP/2 и HTTP/3
Оба сервера поддерживают HTTP/2, и оба умеют HTTP/3/QUIC. На сетях с высокой задержкой (мобильные пользователи, геораспределение) HTTP/3 способен уменьшить p95. Разница между OLS и Nginx не фундаментальна — важнее качество TLS/сжатия/кэширования и грамотные таймауты.
Сжатие и TLS
Сжатие gzip есть везде; Brotli и современные шифросuites зависят от сборки и конфигурации. На практике выигрыши даёт:
- включение Brotli на статике и кэшируемой динамике;
- ECDSA‑сертификат при поддержке клиентами (ускоряет TLS‑рукопожатие и снижает нагрузку на CPU);
- адекватные таймауты keepalive и буферы под профиль трафика.
Следите за актуальностью сертификатов и цепочек доверия. Если нужен быстрый выпуск и автоматизация — обратите внимание на SSL-сертификаты.
Совместимость: .htaccess, rewrite и CMS
Главное отличие — отношение к Apache‑совместимым правилам:
- Nginx не понимает
.htaccessв принципе. Правила нужно переписывать на язык Nginx (rewrite,try_files, карты и пр.). Это даёт контроль и скорость, но усложняет миграцию из мира Apache. - OpenLiteSpeed поддерживает Apache‑совместимые rewrite‑правила и может подхватывать их из
.htaccess. В реальности не все директивы и модули Apache доступны или совпадают по семантике, но для типовых CMS (WordPress, Joomla, Drupal, Magento, OpenCart) миграция проходит значительно мягче.
Плагины прикладного кэширования — ещё один слой совместимости. Для популярных CMS доступны готовые плагины, которые «знают» о кэше и умеют точечно инвалидировать страницы при публикациях, комментариях и т. п. Это снижает риск «несвежего» контента и делает кэш по‑настоящему безопасным. Для небольших проектов и типовых CMS быстрый старт чаще всего удобнее на виртуальный хостинг.
Администрирование и эксплуатация
Подходы различаются по философии:
- Nginx — конфигурация в файлах, декларативность, удобство для IaC (Ansible, Terraform, шаблоны). Легко вести версии, код‑ревью, быстро деплоить изменения и откатывать.
- OpenLiteSpeed — конфигурирование через WebAdmin плюс конфиги на диске. Для некоторых команд GUI ускоряет старт и снижает порог входа. Тем не менее, для полностью кодового управления потребуется стандартизировать файлы конфигурации OLS и привыкнуть к их синтаксису.
Мониторинг у обоих привычный: метрики по соединениям, очередям, кэш‑хитам, логи доступа и ошибок. Для PHP: php-fpm status (в случае Nginx) или статистика LSAPI (в случае OLS). Сбор метрик и алертинг — через стандартные агенты, парсеры логов и экспортеры.
Безопасность и WAF
Оба сервера поддерживают ограничения скорости, базовые фильтры по запросам, ограничения размеров тела/заголовков. Для полноценных правил приложного уровня можно использовать ModSecurity (поддерживается и в OLS, и в Nginx через модуль). На практике важнее корректно:
- задать лимиты:
client_max_body_sizeили аналог у OLS, буферы, таймауты; - фильтровать и логировать подозрительные паттерны;
- держать минимальный набор включенных модулей и периодически обновлять движок и правила.
Для повышения базовой защищенности дополнительно проверьте заголовки безопасности: CSP, HSTS, X‑Frame‑Options и др. Поможет наш практический чек‑лист: безопасные HTTP‑заголовки в Nginx и Apache.
Если требуется выпуск и установка сертификатов под SNI/HTTP‑2/3, используйте управляемые SSL-сертификаты — так проще автоматизировать продление.
Функциональная экосистема
Где сильнее Nginx:
- универсальный реверс‑прокси/балансировщик с богатой картографией (
map), подстановками и условиями; - gRPC‑прокси, WebSocket, стриминг TCP/UDP (
stream), продвинутые кейсы с апстримами и ретраями; - широкая инфраструктура рецептов, best‑practice и модулей.
Где удобнее OpenLiteSpeed:
- быстрый старт PHP‑сайтов с
.htaccess-правилами и CMS; - производительная связка LSAPI + приложный кэш с минимальным числом движущихся частей;
- настроечный GUI для админов, кто ценит визуальный контроль.
Реальные сценарии выбора
- «Чистая» CMS, основная цель — TTFB и стабильный p95 без танцев: чаще выигрывает OLS.
- Сборная витрина: статика, API‑шлюзы, gRPC, websockets, внешний поиск/медиасервисы: Nginx как универсальный фронт.
- Строгий IaC и единый стандарт конфигов в компании: Nginx проще встроить в существующий pipeline.
- Наследие Apache и много редиректов/переписей в
.htaccess: OLS облегчит миграцию.
Для бенчмарков и staging‑окружений удобно поднимать стенд на изолированном VDS, чтобы повторить продакшен‑лимиты и сетевую топологию.
Минимальные конфиги: взгляд на различия
Nginx + PHP‑FPM
server {
listen 80;
server_name example.com;
root /var/www/html;
index index.php index.html;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
fastcgi_read_timeout 60s;
fastcgi_buffers 16 16k;
}
client_max_body_size 64m;
}
OpenLiteSpeed (фрагменты)
extprocessor lsphp {
type lsapi
address UDS://tmp/lshttpd/lsphp.sock
maxConns 50
env LSAPI_AVOID_FORK=1
}
scriptHandler {
add lsapi:lsphp php
}
vh mysite {
docRoot /var/www/html
enableGzip 1
enableQuic 1
rewrite {
enable 1
autoLoadHtaccess 1
}
phpIniOverride {
upload_max_filesize 64M
post_max_size 64M
}
}
Важно понимать, что под капотом — разные механики. У Nginx много явных директив для буферов и таймаутов FastCGI; у OLS часть оптимизаций спрятана в LSAPI и профиле «lsphp».
Кэш: особенности и подводные камни
В кэше решается 80% производительности PHP‑сайтов. Практические моменты:
- Ключ кэша должен учитывать куки авторизации, язык, валюту, фильтры каталога. Ошибка в ключе даст «протекание» персональных страниц.
- Инвалидация на событиях (публикация, комментарий, изменение цены) — критична. Плагины кэша под OLS значительно упрощают её.
- На Nginx с fastcgi‑cache полезен короткий «грязный» TTL (несколько секунд) и стратегии stale при сбоях бэкенда, чтобы выдерживать пики.
План честного тестирования
Чтобы сравнение было корректным, держите паритет окружения:
- Одна и та же версия PHP, одинаковый
opcache, совпадающие лимиты памяти и воркеров. - Отключить плагинные кэши в первом заходе; затем включить и измерить прирост.
- Прогреть кэш перед замерами, фиксировать холодный и тёплый старт.
- Тестировать и статику, и несколько типовых страниц динамики (главная, категория, карточка, поиск).
- Инструменты:
wrk,abилиheyс профилем, близким к реальному: конкаренси, длительность, keepalive.
# Примеры команд
wrk -t8 -c200 -d60s http://127.0.0.1/
wrk -t8 -c200 -d60s http://127.0.0.1/product/123
Снимайте p50/p95/p99, ошибки, RPS, загрузку CPU/IO. Интерпретируйте в контексте: упрётесь ли в PHP, базу, сеть, кэш или TLS?
Миграция: нюансы и соответствия директив
При переезде будьте внимательны к «парами» настроек:
- Размер тела запроса: Nginx —
client_max_body_size, OLS — лимит запроса в настройках сервера/виртуального хоста. - Таймауты бэкенда: Nginx —
fastcgi_read_timeoutи др.; OLS — параметры LSAPI и обработчиков. - Перезапись URL: Nginx —
try_files/rewrite; OLS — Apache‑совместимые правила в.htaccessили блокrewrite. - Заголовки и буферы: у Nginx множество явных
proxy_/fastcgi_*директив; в OLS часть предустановлена адекватно, но под высокую конкуренцию полезно увеличить лимиты соединений/воркеров LSAPI.
Отдельная проверка — загрузки файлов, лимиты PHP (upload_max_filesize, post_max_size, max_execution_time). На OLS их удобно переопределять в phpIniOverride виртуального хоста. На Nginx за пределы PHP они не выведены — правим php.ini или .user.ini плюс лимиты самого Nginx.
Надежность и отладка
Под высокой нагрузкой у Nginx чаще встречаются узкие места в очередях FastCGI, буферах и таймаутах. Лечатся профилированием php-fpm (число воркеров, процесс‑менеджер dynamic/ondemand, медленные логи) и разгрузкой через кэш. В OLS мониторьте очереди LSAPI, латентность бэкенда, следите за «узким горлышком» в LSAPI‑сокете.
Отладка полезных заголовков ускоряет диагностику: отдавайте идентификатор запроса, признак кэша (hit/miss/bypass), версию сборки. Это одинаково применимо к обоим серверам.
Стоимость владения
При правильно включённом кэше оба решения экономят CPU и память. Разница упирается в затраты на внедрение и сопровождение:
- OLS ускоряет старт и снижает время на тонкую настройку микрокэша и переписывание правил.
- Nginx требует больше инженерного времени на сложные кейсы, но взамен даёт универсальность и единообразие инфраструктуры.
Выводы и практические рекомендации
- Если основной трафик — анонимные пользователи на типовой CMS, начните с OpenLiteSpeed. Вы получите быстрый результат и простую схему кэширования.
- Если проект — «швейцарский нож» с проксированием разных протоколов и сервисов, Nginx будет более гибкой базой.
- В обоих случаях измеряйте, а не гадайте. Делайте A/B‑замеры на идентичном окружении, сначала без кэша, затем с кэшем, фиксируйте p95/p99.
- Не забывайте про релевантные лимиты: размер тела, буферы, таймауты, keepalive — они влияют на стабильность не меньше, чем «сырой» RPS.
Итого: OpenLiteSpeed — быстрый старт и высокий КПД на PHP‑динамике; Nginx — инженерная свобода, мощный реверс‑прокси и богатая экосистема. Выбор имеет смысл делать не «вообще», а под конкретный профиль нагрузки и процессы вашей команды.
