Если на сайте появляется сообщение 525 SSL Handshake Failed, это значит, что посетитель дошел до CDN или обратного прокси, но дальше соединение с вашим сервером не установилось по HTTPS. Для владельца сайта это неприятный сценарий: главная может перестать открываться полностью, часть рекламного трафика упрется в ошибку, а команда начнет спорить, проблема в Cloudflare, сертификате или хостинге.
Ошибка 525 почти всегда связана не с браузером клиента, а с участком между прокси и origin-сервером. Ниже разберем, как быстро понять причину, что проверить на стороне сертификата и TLS, и как не пропустить повторение такой аварии.
Что означает ошибка 525 SSL Handshake Failed
Простыми словами, прокси-сервис пытается подключиться к вашему серверу по HTTPS, но TLS-рукопожатие не завершается успешно. Это не обязательно означает, что сайт «лежит» целиком. Иногда origin отвечает по HTTP, иногда открывается напрямую без прокси, а ошибка возникает только на боевом домене, который проходит через защиту или CDN.
Для владельца сайта важно помнить две вещи:
- ошибка 525 возникает на пути прокси -> origin-сервер;
- проблема обычно связана с сертификатом, цепочкой, TLS-настройками, SNI или блокировкой соединения на стороне сервера.
Почему появляется ошибка 525
Сертификат установлен не полностью
На сервере может стоять сам сертификат домена, но отсутствовать промежуточная цепочка. Внешне кажется, что SSL «есть», однако часть клиентов и прокси не может корректно завершить проверку соединения.
На origin-сервере слушается не тот виртуальный хост
Если на одном IP размещено несколько сайтов, сервер должен понимать, для какого домена устанавливается HTTPS-соединение. Когда SNI настроен неправильно, origin может отдавать чужой сертификат или вообще обрывать рукопожатие.
TLS-версии или наборы шифров не совпадают
Иногда сайт продолжает работать для части клиентов, но прокси не может договориться с сервером по поддерживаемым протоколам или cipher suites. Такое бывает после жесткого обновления настроек безопасности, смены панели хостинга или ручной правки конфигурации веб-сервера.
Сервер или firewall режет соединения от прокси
Если после ужесточения firewall, WAF или fail2ban были заблокированы внешние адреса, прокси может просто не достучаться до origin по 443 порту. С точки зрения владельца это выглядит как «у нас сертификат в порядке, но сайт всё равно не открывается».
Сертификат выпущен, но привязан не к тому домену
Частая ситуация после переноса: сертификат обновили для `www`, а трафик идет на домен без `www`, либо наоборот. В панели все выглядит зеленым, но реальный боевой hostname получает другой ответ.
Чем ошибка 525 отличается от 526
Эти ошибки часто путают. 525 говорит о том, что TLS-рукопожатие с origin не завершилось. 526 обычно указывает на невалидный сертификат на origin-сервере при строгой проверке. На практике граница между ними для владельца сайта не так важна: обе ошибки требуют проверить сертификат, доменное имя, цепочку и настройки HTTPS именно на стороне origin.
Как быстро понять, где именно сбой
1. Проверьте, открывается ли origin без прокси
Если у вас есть технический домен, тестовый поддомен или прямой доступ через панель хостинга, посмотрите, отвечает ли сам сервер по HTTPS. Важно проверять не только код ответа, но и какой сертификат реально выдается.
2. Сверьте домен, сертификат и цепочку
Проверьте, что сертификат выпущен именно для нужного hostname, не истек и установлен вместе с промежуточными сертификатами. Для быстрой внешней проверки можно использовать инструмент Web-Puls: проверить SSL-сертификат.
3. Посмотрите, не было ли недавних изменений
Ошибка 525 часто появляется сразу после переноса сайта, перевыпуска сертификата, включения нового reverse proxy, замены Nginx-конфига или переключения DNS. Если проблема началась после конкретного изменения, это сильная подсказка, где искать причину.
4. Убедитесь, что 443 порт доступен снаружи
Если origin недоступен извне, прокси не сможет завершить HTTPS-соединение даже при корректном сертификате. Здесь стоит проверить firewall, ACL, security groups и правила у хостинг-провайдера.
Практические примеры
После продления забыли промежуточный сертификат
Сайт открывался у администратора, потому что браузер подтягивал недостающую цепочку из кеша. Но прокси-сервис обращался к origin как новый клиент и не мог завершить handshake. В результате на боевом домене появилась ошибка 525.
После миграции на новый сервер остался старый сертификат
DNS уже указывал на новый origin, а на нем был установлен сертификат для другого проекта. Пользователь видел ошибку не всегда сразу, потому что часть трафика шла по старому пути, но после обновления DNS проблема стала массовой.
Хостинг ограничил подключения после всплеска трафика
Команда включила жесткие защитные правила, и сервер начал отклонять часть входящих HTTPS-соединений. Для владельца это выглядело как случайное падение сайта, хотя причина была не в приложении, а в сетевой политике.
Что проверить вручную по шагам
- Уточните, на каком домене и через какой прокси возникает ошибка.
- Проверьте срок действия и состав сертификата на origin-сервере.
- Сверьте, что сертификат покрывает нужный hostname: с `www` и без `www`, если используются оба варианта.
- Проверьте, что веб-сервер на 443 порту отдает правильный виртуальный хост.
- Посмотрите последние изменения в DNS, SSL, панели хостинга и конфигурации Nginx или Apache.
- Проверьте firewall и ограничения по IP, чтобы origin принимал соединения от внешнего прокси.
- После исправления повторно протестируйте сайт снаружи, а не только из админской сети.
Как снизить риск повторения
Ручная проверка помогает только когда кто-то уже заметил аварию. Надежнее держать под контролем и доступность сайта, и срок действия SSL, и внешние симптомы после релизов или переносов. Web-Puls помогает регулярно проверять сайт снаружи и быстрее узнавать, если HTTPS перестал открываться как у обычного посетителя.
Если тема с сертификатами и origin-сервером для команды неочевидна, полезно заранее завести короткий чеклист: какой домен является основным, где лежит приватный ключ, кто отвечает за перевыпуск, какие хосты участвуют в проксировании, и как проверять цепочку после изменений.
Когда стоит подключить профессиональную поддержку
Если ошибка 525 повторяется, затрагивает продажи, рекламу или формы заявок, лучше не ограничиваться только просмотром панели CDN. При сложных сбоях с DNS, SSL, хостингом или сервером можно обратиться за профессиональной помощью: оставить заявку на support или использовать контакты.
Вывод
Ошибка 525 SSL Handshake Failed почти всегда указывает на проблему между прокси и origin-сервером. Чем быстрее вы проверите сертификат, цепочку, hostname, доступность 443 порта и недавние изменения в инфраструктуре, тем меньше будет простой. А чтобы не узнавать о таких сбоях от клиентов, стоит держать внешний мониторинг и проверки SSL включенными постоянно.