OpenLiteSpeed на VDS: PHP LSAPI, virtual hosts и HTTPS

Инструкции
02 июл, 2026
Время на чтение: ~23 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

OpenLiteSpeed часто выбирают для PHP-сайтов на VDS, когда нужен быстрый веб-сервер с WebAdmin-панелью, LSAPI вместо классического FastCGI и понятной схемой virtual hosts. Он хорошо подходит для WordPress, Laravel, Bitrix-подобных проектов, небольших SaaS и обычных сайтов, где важны скорость отдачи, управляемый кэш и эксплуатация без тяжелой панели управления.

В этой инструкции пройдем полный базовый сценарий: подготовим Linux-сервер, установим OpenLiteSpeed, подключим PHP LSAPI, создадим отдельный virtual host, проверим DNS-предпосылки для домена и выпустим HTTPS через Let’s Encrypt. Команды будут для Debian/Ubuntu и RHEL-based дистрибутивов: AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux.

OpenLiteSpeed отличается от Nginx и Apache не только синтаксисом конфигов. В нем важны три сущности: listeners, virtual hosts и script handlers. Если понять эту связку, дальнейшая настройка становится предсказуемой.

Что получится в результате

После настройки у нас будет один сайт example.com на VDS, который обслуживается OpenLiteSpeed, использует PHP через lsphp и открывается по HTTPS. Структура будет такой:

OpenLiteSpeed установлен в /usr/local/lsws;
document root сайта: /var/www/example.com/public_html;
PHP запускается через LSAPI, например /usr/local/lsws/lsphp83/bin/lsphp;
сертификат Let’s Encrypt хранится в /etc/letsencrypt/live/example.com/;
WebAdmin доступен на порту 7080, но его нужно ограничить по IP.

В примерах заменяйте example.com, www.example.com и пути под свою инфраструктуру. Если сервер уже используется в продакшене, сначала сделайте снимок VDS или резервную копию конфигов: OpenLiteSpeed хранит настройки централизованно, и случайная ошибка в listener или vhost может быстро положить сайт.

Подготовка VDS и DNS

Для OpenLiteSpeed достаточно небольшого VDS: один-два vCPU, 1–2 ГБ RAM и SSD/NVMe-диск для стартового PHP-сайта. Но если планируется WordPress с WooCommerce, тяжелый фреймворк или много одновременных PHP-запросов, лучше сразу закладывать запас по памяти: LSAPI-процессы, база данных и объектный кэш легко съедают больше, чем кажется на пустом стенде.

До выпуска HTTPS проверьте DNS. У домена должны быть A-записи на IPv4-адрес сервера, а если используете IPv6 — AAAA-записи. Если домен еще не куплен или вы переносите проект на новое имя, заранее проверьте доступность через регистрацию доменов и настройте корректные NS-записи.

dig +short example.com A
dig +short www.example.com A
dig +short example.com AAAA

Для Let’s Encrypt критично, чтобы домен уже резолвился на ваш VDS и порт 80 был доступен извне. HTTP-01 challenge не пройдет, если перед сервером стоит прокси, который не пропускает путь проверки, или если firewall закрывает входящие соединения.

Проверка DNS-записей домена перед выпуском HTTPS-сертификата

Установка OpenLiteSpeed

OpenLiteSpeed обычно ставят из репозитория проекта. Перед установкой обновите систему и убедитесь, что на сервере не запущены другие веб-серверы на портах 80 и 443. Если Nginx или Apache уже слушают эти порты, OpenLiteSpeed не сможет стартовать с нужными listener-ами.

Debian и Ubuntu

Сначала скачайте скрипт подключения репозитория OpenLiteSpeed с сайта проекта в файл /root/litespeed-repo.sh, проверьте его содержимое, затем выполните установку.

sudo apt update
sudo apt install -y wget gnupg ca-certificates curl
sudo bash /root/litespeed-repo.sh
sudo apt update
sudo apt install -y openlitespeed lsphp83 lsphp83-common lsphp83-mysql lsphp83-opcache lsphp83-curl lsphp83-mbstring lsphp83-xml lsphp83-zip

Если нужна другая версия PHP, замените lsphp83 на доступную в репозитории версию, например lsphp82 или lsphp84. Для CMS и фреймворков почти всегда понадобятся расширения mysql, curl, mbstring, xml, zip, а для изображений — gd или imagick, если они доступны в вашем наборе пакетов.

AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux

Для RHEL-based систем загрузите RPM-пакет репозитория OpenLiteSpeed в /root/litespeed-repo.rpm, после чего установите его локально.

sudo dnf install -y epel-release curl wget
sudo rpm -Uvh /root/litespeed-repo.rpm
sudo dnf install -y openlitespeed lsphp83 lsphp83-common lsphp83-mysqlnd lsphp83-opcache lsphp83-curl lsphp83-mbstring lsphp83-xml lsphp83-zip

На RHEL-based системах обращайте внимание на совместимость репозитория с версией ОС. Для AlmaLinux и Rocky Linux 8/9 названия пакетов могут немного отличаться, особенно у PHP-расширений. Если пакет не найден, сначала посмотрите доступные варианты:

dnf search lsphp83

Проверка службы

sudo systemctl enable lsws
sudo systemctl start lsws
sudo systemctl status lsws --no-pager

Основные управляющие команды находятся в /usr/local/lsws/bin/lswsctrl. Для первичной диагностики полезны статус systemd, список слушающих портов и журналы самого OpenLiteSpeed.

sudo /usr/local/lsws/bin/lswsctrl status
sudo ss -lntp | grep -E ':80|:443|:7080|:8088'
sudo tail -n 80 /usr/local/lsws/logs/error.log

После установки демо-сайт часто доступен на порту 8088, а WebAdmin — на 7080. В продакшене порт 8088 обычно не нужен, а доступ к 7080 стоит ограничить firewall-ом или временно открывать только на период настройки.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия

Нидерланды

Смотреть тарифы

Первичная защита WebAdmin

Сразу задайте пароль администратора. Скрипт попросит имя пользователя и пароль. Не используйте стандартные логины вроде admin с простым паролем: WebAdmin дает полный контроль над конфигурацией веб-сервера.

sudo /usr/local/lsws/admin/misc/admpass.sh

Дальше настройте firewall. Минимально для сайта нужны порты 80/tcp и 443/tcp. Порт 7080/tcp лучше разрешить только с вашего статического IP. Если статического IP нет, используйте временное правило на время настройки и закрывайте порт после изменений.

UFW на Debian/Ubuntu

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow from 203.0.113.10 to any port 7080 proto tcp
sudo ufw enable
sudo ufw status verbose

firewalld на RHEL-based системах

sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10" port port="7080" protocol="tcp" accept'
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Замените 203.0.113.10 на свой административный IP. Если SSH работает не на 22-м порту, добавьте актуальное правило до включения firewall. Иначе можно самому себе закрыть доступ к VDS.

Как устроены listeners, virtual hosts и PHP LSAPI

В OpenLiteSpeed listener отвечает за IP, порт и протокол. Например, listener на *:80 принимает HTTP-запросы, а listener на *:443 — HTTPS. Но listener сам по себе не знает, какой сайт отдавать. Для этого к нему подключаются virtual hosts через domain mapping.

Virtual host описывает конкретный сайт: document root, логи, индексы, rewrite rules, SSL-параметры, контексты и ограничения. Один OpenLiteSpeed может обслуживать десятки virtual hosts на одном VDS, а listener будет выбирать нужный vhost по имени домена в Host-заголовке и SNI при HTTPS.

PHP LSAPI — это способ общения OpenLiteSpeed с PHP-процессами. В отличие от типичной связки Nginx плюс PHP-FPM, здесь PHP запускается как LSAPI-приложение, а OpenLiteSpeed управляет соединениями и обработчиками через External App и Script Handler. Для администратора это означает: нужно указать путь к бинарнику lsphp, сокет, лимиты процессов и сопоставить расширение php с нужным handler-ом.

Схема связи listener, virtual host и PHP LSAPI в OpenLiteSpeed

Создаем структуру сайта

Сначала подготовим каталог сайта и простой тестовый файл. Пользователь веб-сервера в OpenLiteSpeed обычно nobody или lsadm в зависимости от сборки и настроек. Не раздавайте права 777: это частая причина взломов и странных ошибок.

sudo mkdir -p /var/www/example.com/public_html
sudo mkdir -p /var/www/example.com/logs
sudo chown -R nobody:nogroup /var/www/example.com

На RHEL-based системах группы могут отличаться. Если nogroup нет, проверьте доступные системные группы:

getent passwd nobody
getent group nobody
getent group nogroup

Создадим тестовый PHP-файл. В продакшене файл с phpinfo() оставлять нельзя: он показывает версии, модули, пути и часть окружения. Используйте его только для проверки и сразу удалите.

sudo tee /var/www/example.com/public_html/index.php > /dev/null
<?php
phpinfo();
?>

Если вы вставляете этот пример через терминал, завершите ввод сочетанием Ctrl+D. Альтернативно создайте файл редактором nano или загрузите код через Git/rsync.

Настраиваем PHP LSAPI

Самый безопасный путь для первой настройки — через WebAdmin. Откройте панель на порту 7080, войдите под созданным пользователем и проверьте глобальную конфигурацию PHP. В разделе External App должен быть обработчик типа LiteSpeed SAPI App. Для PHP 8.3 типовые параметры выглядят так:

Name: lsphp83;
Address: uds://tmp/lshttpd/lsphp83.sock;
Command: /usr/local/lsws/lsphp83/bin/lsphp;
Max Connections: от 10 до 35 для небольшого VDS;
Instances: обычно 1;
Environment: PHP_LSAPI_CHILDREN=20.

Не ставьте Max Connections и PHP_LSAPI_CHILDREN «с запасом в сотни» на маленьком VDS. Каждый PHP-процесс потребляет память. Если один процесс WordPress занимает 80–150 МБ RSS под нагрузкой, то 30 одновременных процессов уже могут привести к OOM, свопу и резким задержкам.

Затем в Script Handler укажите, что суффикс php должен обрабатываться этим LSAPI-приложением. На уровне сервера это удобно, если все сайты используют одну версию PHP. Если нужны разные версии PHP для разных virtual hosts, создавайте отдельные External App: lsphp82, lsphp83, lsphp84, а handler задавайте на уровне конкретного vhost.

Хорошая отправная точка для небольшого PHP-сайта: Max Connections 10–15, PHP_LSAPI_CHILDREN 10–15, включенный OPcache и аккуратные лимиты памяти в php.ini.

Проверьте версию LSAPI-PHP:

/usr/local/lsws/lsphp83/bin/php -v
/usr/local/lsws/lsphp83/bin/php -m | sort

Файл php.ini для LSAPI обычно находится внутри каталога конкретной версии PHP, например /usr/local/lsws/lsphp83/etc/php/8.3/litespeed/php.ini или похожем пути. Точный путь можно увидеть в выводе phpinfo() в поле Loaded Configuration File.

Создаем virtual host для домена

В WebAdmin перейдите в раздел Virtual Hosts и создайте новый vhost, например example.com. В качестве Virtual Host Root укажите /var/www/example.com, а конфиг можно хранить в стандартном каталоге OpenLiteSpeed или рядом с сайтом. Для понятности часто используют отдельный файл:

/usr/local/lsws/conf/vhosts/example.com/vhconf.conf

Основные параметры vhost:

Document Root: /var/www/example.com/public_html;
Index Files: index.php, index.html;
Enable Rewrite: Yes;
Access Log: /var/www/example.com/logs/access.log;
Error Log: /var/www/example.com/logs/error.log.

После создания vhost нужно подключить его к listener. Для HTTP listener на порту 80 добавьте mapping: Virtual Host — example.com, Domains — example.com, www.example.com.

Именно этот шаг часто забывают. Vhost может быть идеально настроен, но если он не привязан к listener-у, запросы до него не дойдут. После изменения конфигурации нажмите Graceful Restart в WebAdmin или выполните перезапуск из консоли.

sudo /usr/local/lsws/bin/lswsctrl restart

Проверьте HTTP-ответ локально и снаружи:

curl -I http://example.com/
curl -I http://www.example.com/

Если видите не тот сайт, проверьте domain mapping и DNS. Если соединение не устанавливается, смотрите firewall, listener на порту 80 и занятость порта другим процессом.

Rewrite rules для популярных PHP-приложений

OpenLiteSpeed умеет читать совместимые rewrite rules, похожие на Apache .htaccess, но лучше не превращать каждый каталог в набор случайных правил. Для Laravel, Symfony, Yii и других front-controller-приложений обычно достаточно отправлять все несуществующие файлы в index.php.

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

В WebAdmin эти правила можно добавить в раздел Rewrite конкретного virtual host. Для WordPress стандартные правила тоже работают, но если включаете LiteSpeed Cache, внимательно проверяйте исключения для админки, корзины, страниц авторизации и персонализированного контента. Кэш — полезный инструмент, но он не должен отдавать приватные страницы другим пользователям.

Выпускаем HTTPS через Let’s Encrypt

Для OpenLiteSpeed удобнее всего использовать Certbot в режиме webroot. Нам не нужен nginx- или apache-плагин: Certbot положит challenge-файл в каталог сайта, Let’s Encrypt проверит его по HTTP, а затем выдаст сертификат. Если нужна отдельная инструкция по TLS-политикам, посмотрите материал про Certbot, HTTPS и HSTS.

Установка Certbot на Debian/Ubuntu

sudo apt update
sudo apt install -y certbot

Установка Certbot на RHEL-based системах

sudo dnf install -y epel-release
sudo dnf install -y certbot

Теперь выпускаем сертификат:

sudo certbot certonly --webroot -w /var/www/example.com/public_html -d example.com -d www.example.com

После успешного выпуска появятся файлы:

/etc/letsencrypt/live/example.com/fullchain.pem — сертификат вместе с цепочкой;
/etc/letsencrypt/live/example.com/privkey.pem — приватный ключ;
/etc/letsencrypt/live/example.com/cert.pem — только сертификат сайта;
/etc/letsencrypt/live/example.com/chain.pem — цепочка промежуточных сертификатов.

В OpenLiteSpeed обычно указывают именно fullchain.pem и privkey.pem. Не копируйте эти файлы вручную в другой каталог без необходимости: Certbot обновляет симлинки при продлении, и OpenLiteSpeed должен читать актуальные пути.

Подключаем сертификат к HTTPS listener

Создайте или отредактируйте listener на порту 443. У него должен быть включен SSL. Для одного домена можно указать сертификат прямо в listener. Для нескольких доменов лучше использовать SNI и SSL-настройки на уровне virtual host, а listener оставить с сертификатом по умолчанию.

Минимальные параметры HTTPS listener:

IP Address: ANY или конкретный IP;
Port: 443;
Secure: Yes;
Private Key File: /etc/letsencrypt/live/example.com/privkey.pem;
Certificate File: /etc/letsencrypt/live/example.com/fullchain.pem;
Domains в mapping: example.com, www.example.com.

Для коммерческих проектов, где важны расширенная проверка организации, поддержка и узнаваемый центр сертификации, вместо бесплатного DV-сертификата можно рассмотреть SSL-сертификаты. Но техническая схема подключения в OpenLiteSpeed останется той же: приватный ключ плюс цепочка сертификатов.

sudo /usr/local/lsws/bin/lswsctrl restart
curl -I https://example.com/
openssl s_client -connect example.com:443 -servername example.com -brief

Если сертификат не тот, чаще всего проблема в SNI mapping: запрос приходит на listener, но OpenLiteSpeed выбирает дефолтный сертификат. Проверьте домены в mapping, наличие SSL-параметров у нужного vhost и совпадение имени в команде openssl s_client с реальным доменом.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Автопродление Let’s Encrypt

Certbot обычно создает systemd timer или cron-задачу автоматически. Но после продления сертификата OpenLiteSpeed должен перечитать файлы. Для этого добавьте deploy hook. Самый простой вариант — команда restart после успешного обновления сертификата.

sudo certbot renew --dry-run
sudo certbot renew --deploy-hook "/usr/local/lsws/bin/lswsctrl restart"

Чтобы hook был постоянным, создайте исполняемый файл в каталоге deploy-hook:

sudo mkdir -p /etc/letsencrypt/renewal-hooks/deploy
sudo tee /etc/letsencrypt/renewal-hooks/deploy/openlitespeed-restart.sh > /dev/null
#!/bin/sh
/usr/local/lsws/bin/lswsctrl restart

sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/openlitespeed-restart.sh
sudo certbot renew --dry-run

После этого проверяйте не только сам факт продления, но и дату сертификата, который реально отдает сервер. Иногда сертификат обновился на диске, но веб-сервер продолжает держать старую версию до перезапуска.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject

HTTP to HTTPS и canonical host

Когда HTTPS работает, стоит настроить редирект с HTTP на HTTPS и выбрать канонический хост: с www или без. Не делайте хаотичные цепочки из нескольких редиректов. Хороший результат — один переход с http://www.example.com сразу на нужный конечный URL.

Для редиректа на HTTPS можно использовать rewrite rules на уровне HTTP virtual host:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

Если нужно одновременно убрать www, добавьте правило для host. Важно протестировать все четыре варианта: HTTP/HTTPS и www/non-www. Ошибки в canonical redirect быстро приводят к redirect loop, особенно если перед сервером стоит CDN или внешний балансировщик, который терминирует TLS.

curl -I http://example.com/
curl -I http://www.example.com/
curl -I https://example.com/
curl -I https://www.example.com/

HSTS включайте только после того, как убедились, что HTTPS стабилен, сертификаты продлеваются, а все поддомены, которые попадут под политику, действительно готовы к TLS. Для первого дня миграции достаточно обычного 301-редиректа без агрессивного HSTS.

OPcache и базовая настройка PHP

Для PHP-сайта на VDS OPcache почти всегда обязателен. Без него PHP будет постоянно перечитывать и компилировать файлы, а это лишняя нагрузка на CPU и диск. Проверьте, что модуль загружен:

/usr/local/lsws/lsphp83/bin/php -m | grep -i opcache

Типовые параметры для небольшого сайта можно начать с таких значений в соответствующем php.ini:

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2
memory_limit=256M
upload_max_filesize=64M
post_max_size=64M
max_execution_time=60

Для продакшена с атомарными деплоями можно рассмотреть более редкую проверку timestamps или отключение opcache.validate_timestamps, но только если у вас есть надежный reload или reset OPcache после релиза. Иначе пользователи будут получать старый код, а вы потратите время на «мистическую» диагностику.

Логи и диагностика типичных ошибок

У OpenLiteSpeed есть глобальные логи и логи virtual host. Начинайте диагностику с них, а не с догадок. Глобальный error log показывает проблемы запуска, синтаксис конфигов, ошибки listener-ов и LSAPI. Лог сайта помогает понять, что происходит с конкретным доменом.

sudo tail -f /usr/local/lsws/logs/error.log
sudo tail -f /var/www/example.com/logs/error.log
sudo tail -f /var/www/example.com/logs/access.log

Если PHP-файл скачивается вместо выполнения, значит не настроен Script Handler для суффикса php или vhost не использует нужный handler. Если получаете 503, проверьте External App: путь к lsphp, права на сокет, лимиты процессов и ошибки в PHP. Если HTTPS отдает чужой сертификат, смотрите listener, SNI и domain mapping.

Для проверки занятых портов используйте:

sudo ss -lntp
sudo lsof -iTCP -sTCP:LISTEN -P -n

Перед крупными изменениями полезно копировать каталог конфигурации:

sudo tar -C /usr/local/lsws -czf /root/ols-conf-backup.tar.gz conf

Мини-чеклист перед продакшеном

DNS A/AAAA указывают на правильный VDS, старые записи не мешают.
Порты 80 и 443 открыты, 7080 ограничен административным IP.
Virtual host подключен к HTTP и HTTPS listener-ам.
PHP LSAPI handler назначен для php, нужные расширения установлены.
Let’s Encrypt сертификат выпущен, OpenLiteSpeed читает fullchain.pem и privkey.pem.
Автопродление проверено через certbot renew --dry-run.
Редиректы HTTP to HTTPS и www/non-www не создают цепочек и циклов.
phpinfo() удален после проверки.
Логи сайта пишутся в отдельный каталог и не растут бесконтрольно.

Итоги

OpenLiteSpeed на VDS — хороший вариант для PHP-проектов, если вам нужна производительная связка с LSAPI, удобным управлением virtual hosts и нормальной поддержкой HTTPS. Главная особенность — не пытаться настраивать его как Nginx или Apache. В OpenLiteSpeed своя модель: listener принимает соединение, mapping выбирает virtual host, а Script Handler отправляет PHP-запросы в LSAPI.

Для стабильной эксплуатации держите конфигурацию простой: отдельный vhost на домен, понятные каталоги, ограниченный WebAdmin, аккуратные лимиты PHP-процессов и проверенное продление Let’s Encrypt. Когда базовая схема заработает, уже можно добавлять кэш, несколько версий PHP, staging-домены, отдельные логи для аналитики и более строгие security headers.

Поделиться статьей