Если сайт использует HTTPS, владелец обычно смотрит на сертификат: действует ли он, совпадает ли домен, нет ли предупреждений в браузере. Но иногда проблема оказывается шире. В браузере появляется жесткая блокировка, перейти на HTTP не получается, а пользователи пишут, что сайт «совсем не открывается». Один из механизмов, который может усилить такую ситуацию, называется HSTS.
HSTS нужен для безопасности: он помогает браузеру всегда открывать сайт по HTTPS и не возвращаться к незащищенному соединению. Но если SSL настроен неправильно, сертификат истек, не покрывает поддомен или CDN отдает ошибочную конфигурацию, HSTS делает сбой заметнее для посетителя. Разберем, как это работает, что проверить владельцу сайта и почему такие ошибки лучше отслеживать заранее.
Что такое HSTS простыми словами
HSTS расшифровывается как HTTP Strict Transport Security. Это правило, которое сайт передает браузеру через HTTP-заголовок. После этого браузер запоминает: этот домен нужно открывать только по защищенному HTTPS-соединению.
Пример заголовка: Strict-Transport-Security: max-age=31536000; includeSubDomains.
В реальной конфигурации параметры могут отличаться. Для владельца сайта важен не сам набор символов в заголовке, а смысл: браузер получает указание доверять только HTTPS. Поэтому HSTS стоит включать осознанно, когда сертификаты, поддомены, редиректы и CDN уже проверены.
Почему HSTS усиливает проблему с SSL
Без HSTS часть сайтов в аварийной ситуации пытается «спастись» переходом на HTTP. Это плохая практика с точки зрения безопасности, но технически пользователь иногда хотя бы видит страницу. При включенном HSTS такой обходной путь закрывается: браузер требует корректный HTTPS.
Если SSL ломается, владелец получает жесткий сценарий:
- браузер не открывает сайт по HTTP;
- кнопка обхода предупреждения может быть недоступна;
- ошибка повторяется даже после перезагрузки страницы;
- часть пользователей не может попасть на сайт, хотя сервер может отвечать;
- проблема часто выглядит как полная недоступность, а не как «маленькая настройка сертификата».
Практический пример: магазин перевел checkout.example.ru на новый прокси, но сертификат на поддомене установлен с ошибкой. Главная открывается, а оформление заказа блокируется браузером.
Где чаще всего возникает ошибка
Сертификат не покрывает нужный домен
Самый понятный сценарий: сертификат выпущен для example.ru, но посетители открывают www.example.ru, shop.example.ru или другой поддомен. Если HSTS действует на поддомены, браузер будет требовать корректный HTTPS и там тоже.
Проверять нужно не только главную страницу. Для бизнеса важны страницы входа, оплаты, формы заявок, личный кабинет, API и служебные поддомены, которые видит клиент или партнерская система.
Включили includeSubDomains без инвентаризации
Параметр includeSubDomains распространяет правило HSTS на поддомены. Это удобно, если вся инфраструктура готова к HTTPS. Но если где-то остался старый поддомен, тестовая панель, временный лендинг или отдельный сервер без корректного SSL, пользователи могут столкнуться с блокировкой.
Пример: основной сайт давно работает по HTTPS, а старый поддомен promo.example.ru используется в рекламной кампании. После включения HSTS с поддоменами браузер перестает открывать этот адрес из-за неправильного сертификата. Ошибка проявляется только у тех, кто перешел по старой ссылке, поэтому ее легко пропустить при обычной проверке главной.
CDN или прокси отдает другую TLS-конфигурацию
Если сайт работает через CDN, WAF или обратный прокси, HTTPS может завершаться не там, где расположен основной сервер. Снаружи посетитель видит сертификат и настройки CDN, а между CDN и origin-сервером может быть отдельная схема.
После смены режима SSL, перевыпуска edge-сертификата или переноса DNS сайт может вести себя неодинаково: у владельца открывается, у части пользователей нет. В такой ситуации HSTS не является первопричиной, но делает ошибку более жесткой для клиента.
Как понять, что проблема связана с HSTS
HSTS редко появляется в тексте ошибки крупными буквами. Чаще пользователь видит сообщение о небезопасном соединении, недоверенном сертификате, несовпадении домена или невозможности установить защищенное соединение.
Проверьте несколько признаков:
- сайт автоматически открывается по HTTPS, даже если ввести http://;
- ошибка не дает перейти на обычную HTTP-версию;
- проблема появилась после настройки SSL, CDN, DNS или редиректов;
- сбой виден только на части поддоменов;
- в ответе сайта есть заголовок Strict-Transport-Security;
- старые ссылки, тестовые панели или служебные адреса начали блокироваться браузером.
Что проверить владельцу сайта
1. Сертификаты для всех важных хостов
Проверьте основной домен, вариант с www, поддомены для оплаты, API, личного кабинета, CRM, формы заявок и промо-страниц. Для каждого адреса важно понять:
- какой сертификат отдается наружу;
- совпадает ли имя в сертификате с адресом;
- не истек ли срок действия;
- корректна ли цепочка сертификатов;
- нет ли разных ответов через CDN и напрямую с origin-сервера.
Для быстрой ручной проверки можно использовать проверку SSL-сертификата и материалы блога о том, как проверить SSL-сертификат сайта.
2. Заголовок HSTS и его параметры
Посмотрите, отдается ли Strict-Transport-Security на нужных страницах. Важно понять, есть ли includeSubDomains, какой задан срок действия и не включен ли preload. Если заголовок добавляет не сам сайт, а CDN или панель хостинга, проверьте настройки именно там.
Не стоит удалять HSTS вслепую. Иногда проблема не в заголовке, а в сертификате, DNS или прокси. Правильнее сначала восстановить корректный HTTPS, а затем уже решать, нужно ли менять параметры HSTS.
3. Редиректы с HTTP на HTTPS
Даже при HSTS редиректы должны быть настроены аккуратно. Проверьте, нет ли цепочек, циклов и переходов на неправильный хост. Например, http://example.ru не должен вести на поддомен, где нет подходящего сертификата.
Если после редиректа появляется SSL-ошибка, пользователю все равно, на каком шаге она возникла. Для него сайт не открылся. Поэтому проверяйте полный путь до конечной страницы, а не только первый ответ сервера.
4. Старые и служебные поддомены
Отдельно пройдитесь по адресам, которые редко попадают в обычные проверки: old, dev, stage, panel, api, mail, static, промо-поддомены и старые лендинги.
Если поддомен не должен быть публичным, лучше явно закрыть его корректным способом. Если он нужен клиентам, для него должен быть нормальный HTTPS.
Что делать, если сайт уже не открывается
Начните с восстановления корректного HTTPS. Проверьте сертификат, цепочку, DNS, CDN и origin-сервер. Если ошибка затрагивает только один поддомен, не меняйте всю инфраструктуру сразу: сначала подтвердите, какой адрес ломается и какой сертификат видит пользователь.
Если проблема появилась после недавнего изменения, временно верните последнюю рабочую конфигурацию или отключите спорный маршрут, но только если понимаете последствия. При HSTS особенно важно не создавать новые промежуточные ошибки: браузер все равно будет требовать безопасное соединение.
Когда сайт работает через CDN, сравните, что видит пользователь снаружи и что CDN получает от origin-сервера. Иногда ошибка находится не на основном сервере, а на уровне edge-сертификата.
Почему мониторинг важнее ручной проверки
Проблемы с HSTS и SSL часто проявляются не как «все упало сразу», а как частичная недоступность: один поддомен, один маршрут, один регион, один тип пользователей. Ручная проверка главной страницы может показать, что сайт работает, хотя форма заявки, оплата или личный кабинет уже заблокированы.
Web-Puls помогает регулярно проверять доступность сайта и быстрее узнавать, если он перестал открываться корректно. Для SSL-сценариев полезно контролировать не только главную страницу, но и важные URL, где пользователь оставляет заявку, входит в аккаунт или завершает оплату.
Чтобы не проверять сайт вручную после каждого изменения, можно настроить автоматический мониторинг в Web-Puls. А для разовой диагностики пригодятся проверка доступности сайта и проверка SSL.
Когда стоит обратиться за поддержкой
Если ошибка связана с HSTS, SSL, CDN или поддоменами, проблема может оказаться не только в одном сертификате. Иногда нужно посмотреть DNS, конфигурацию веб-сервера, правила редиректов, настройки CDN и фактический ответ сайта из внешней сети.
При сложных сбоях с DNS, SSL, хостингом или сервером можно обратиться за профессиональной помощью: оставить заявку через форму поддержки Web-Puls или воспользоваться контактной информацией. В заявке лучше указать домен, проблемный адрес, текст ошибки в браузере и что менялось перед появлением сбоя.
Вывод
HSTS делает сайт безопаснее, но требует дисциплины в HTTPS-настройках. Если сертификат сломан, поддомен забыт или CDN отдает неправильную конфигурацию, браузер может полностью заблокировать доступ к странице.
Проверяйте не только дату окончания SSL, но и все важные хосты, редиректы, заголовок HSTS и поведение сайта снаружи. Так владелец быстрее отличит поломку сертификата от проблемы DNS или прокси и не будет узнавать о недоступности сайта только от клиентов.