На серверах с WordOps сайт часто «открывается по HTTP» или не уходит на HTTPS, хотя сертификат вроде выпущен. Обычно дело не в «магии SSL», а в цепочке: сертификат Let’s Encrypt, vhost Nginx, файл force-ssl и URL в приложении. Ниже типичные причины и рабочий порядок проверки.
Почему редирект HTTP на HTTPS ломается
1. Nginx без корректного return 301
WordOps собирает конфиги Nginx за вас. Редирект живёт в server-блоке на порту 80 (или в отдельном force-ssl include). Если блок перетёрт руками, сайт пересоздан неполностью или include отключён, HTTP продолжает отдавать контент без 301 на HTTPS.
2. Нет или сломан SSL-сертификат
Пока сертификат не выпущен или пути к fullchain/privkey неверны, HTTPS-блок не поднимется нормально. Браузер ругается, а редирект «в никуда» выглядит как «не работает HTTPS».
3. URL приложения остались на http://
Для WordPress: siteurl / home в БД или константы в wp-config.php. Nginx может редиректить, а CMS снова генерирует http-ссылки, mixed content и ощущение, что «редирект кривой».
4. force-ssl отключён (.disabled)
У WordOps часто лежит файл вида force-ssl-example.com.conf в /etc/nginx/conf.d/. Если он с суффиксом .disabled, принудительный редирект просто не подключается.
Как починить по шагам
Шаг 1. Включить / перевыпустить Let’s Encrypt
Сначала штатный путь WordOps (подставьте свой домен):
sudo wo site update yourdomain.com --le=on
Команда выпускает или обновляет сертификат и обычно поднимает нужные куски конфига под HTTPS. Если DNS ещё не указывает на сервер, LE не пройдёт – сначала A/AAAA записи.
Шаг 2. Проверить force-ssl и vhost
Посмотрите, не отключён ли force-ssl:
ls -la /etc/nginx/conf.d/ | grep -i force-ssl
# если видите .disabled - включите:
sudo mv /etc/nginx/conf.d/force-ssl-yourdomain.com.conf.disabled \
/etc/nginx/conf.d/force-ssl-yourdomain.com.conf
Базовый vhost сайта:
cd /etc/nginx/sites-available/ sudo nano yourdomain.com
Для HTTP-блока (порт 80) типичный принудительный редирект выглядит так:
server {
listen 80;
listen [::]:80;
server_name yourdomain.com www.yourdomain.com;
return 301 https://$host$request_uri;
}
Не дублируйте конфликтующие server-блоки на 80 с root и отдачей сайта «как есть», если цель – только редирект. Пути к сертификатам в SSL-части должны совпадать с тем, что выдал LE (обычно под /etc/letsencrypt/live/... или структура WordOps).
Скриншоты: пример force-ssl / conf.d и фрагмент конфига на сервере.
Шаг 3. nginx -t и перезапуск
После правок всегда проверка синтаксиса, потом reload/restart:
sudo nginx -t # ожидаемо: # nginx: the configuration file /etc/nginx/nginx.conf syntax is ok # nginx: configuration file /etc/nginx/nginx.conf test is successful sudo systemctl reload nginx # или, если reload недостаточно: sudo systemctl restart nginx
Шаг 4. Ещё раз зафиксировать LE в WordOps
Если правили руками и сомневаетесь в согласованности, повторно:
sudo wo site update yourdomain.com --le=on
Так WordOps снова выровняет сертификат и связанные фрагменты. Имеет смысл, если сайт создавали без --le или сертификат протух.
Шаг 5. Проверка снаружи и кэш
Не опирайтесь только на «обновить вкладку». HSTS и кэш браузера маскируют старое поведение. Удобно смотреть заголовки:
curl -sI http://yourdomain.com | head -n 20 # ждать Location: https://... и 301/302 curl -sI https://yourdomain.com | head -n 20
Для WordPress дополнительно проверьте URL сайта (админка → Настройки → Общие, или опции в БД): оба адреса должны быть с https://.
Короткий чеклист
- DNS на этот сервер,
wo site update ... --le=onбез ошибок. - Нет
force-ssl-*.conf.disabledдля нужного домена. - Порт 80 отвечает 301 на https, а не 200 с контентом.
nginx -tуспешен, сервис перезагружен.- URL в CMS на https, mixed content убран.
Итог
В WordOps редирект на HTTPS почти всегда чинится связкой: валидный Let’s Encrypt, включённый force-ssl, корректный server-блок на 80 и https-URL в приложении. Ручные правки Nginx допустимы, но после них обязательны nginx -t и проверка через curl -I, а не только «открылось в браузере».

