Почему не работает редирект на HTTPS в WordOps и как это исправить

На серверах с 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 и фрагмент конфига на сервере.

force-ssl конфиг WordOps в /etc/nginx/conf.d
Проверка force-ssl в conf.d
Фрагмент конфигурации Nginx для HTTPS-редиректа
Фрагмент Nginx-конфига

Шаг 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://.

Короткий чеклист

  1. DNS на этот сервер, wo site update ... --le=on без ошибок.
  2. Нет force-ssl-*.conf.disabled для нужного домена.
  3. Порт 80 отвечает 301 на https, а не 200 с контентом.
  4. nginx -t успешен, сервис перезагружен.
  5. URL в CMS на https, mixed content убран.

Итог

В WordOps редирект на HTTPS почти всегда чинится связкой: валидный Let’s Encrypt, включённый force-ssl, корректный server-блок на 80 и https-URL в приложении. Ручные правки Nginx допустимы, но после них обязательны nginx -t и проверка через curl -I, а не только «открылось в браузере».

Источники и ссылки


Комментарии загружаются…