Ошибка 525: Cloudflare не договорился с сервером о шифровании

Ошибка 525 SSL handshake failed означает, что Cloudflare не смог договориться с сервером сайта о защищённом соединении. Соединение открылось, но рукопожатие TLS — обмен приветствиями, выбор версии протокола и шифра, проверка сертификата — оборвалось. Страница Cloudflare в таком случае отмечает браузер и Cloudflare как работающие, а сервер сайта — как ошибку.

Мы собрали стенд: nginx в роли Cloudflare с его набором шифров и nginx-источник, которому по очереди ломали TLS в девяти вариантах. Посмотрели, что видит посредник, что пишет сервер и как это проверить самому.

Что такое рукопожатие SSL

Рукопожатие — первые миллисекунды защищённого соединения, до того как передан хоть один байт страницы. Клиент (здесь — Cloudflare) отправляет серверу приветствие: какие версии протокола TLS и наборы шифров он поддерживает и к какому сайту обращается. Сервер выбирает версию и шифр из предложенных, отправляет свой сертификат, и стороны договариваются о ключах. Если на любом из этих действий сервер не находит общего языка с клиентом, он обрывает соединение — рукопожатие не удалось.

При обычном заходе на сайт без посредника такое рукопожатие делает браузер. За Cloudflare их два: браузер договаривается с Cloudflare, а Cloudflare — с вашим сервером. Ошибка 525 возникает на втором.

Что означает ошибка 525

Справка Cloudflare (обновлена 16.06.2026) ставит два условия: рукопожатие между Cloudflare и сервером не удалось, и в настройках SSL/TLS выбран режим Full или Full (strict).

Режим важен. В Flexible Cloudflare ходит к серверу по обычному HTTP, без шифрования, — там нечему ломаться, и 525 не бывает. В Full и Full (strict) Cloudflare открывает к серверу HTTPS на порт 443 и ждёт, что тот поддерживает TLS.

Cloudflare называет четыре причины:

• на сервере нет действующего SSL-сертификата;
• порт 443 закрыт;
• сервер не поддерживает SNI — указание имени сайта в начале рукопожатия;
• у сервера и Cloudflare нет общих шифров.

Стенд: девять способов сломать рукопожатие

Посредник — nginx 1.31.6 с теми же параметрами, что у Cloudflare: версии TLS от 1.0 до 1.3, список шифров TLS 1.2 из справки Cloudflare, имя сайта в SNI. Режим Full мы повторили без проверки сертификата, Full (strict) — с проверкой по своему корневому сертификату. У nginx неудачное рукопожатие с источником даёт ответ 502; у Cloudflare на его месте появляется 525.

Все отказы рукопожатия посредник получил примерно за 2 миллисекунды: в отличие от 522, здесь нет таймаута и долгого ожидания. Ошибки посредника различались: «wrong version number» для HTTP на TLS-порту, «tlsv1 unrecognized name» (alert 112) при отказе по имени, «sslv3 alert handshake failure» (alert 40) при несовпадении шифров.

Три вывода, которых нет в справке Cloudflare.

Просроченный и чужой сертификат дают не 525. В режиме Full они проходят — Cloudflare в этом режиме сертификат не проверяет. В Full (strict) рукопожатие ломается уже на проверке, и Cloudflare называет это отдельной ошибкой — 526.

Требование сертификата клиента дало 400, а не ошибку рукопожатия. nginx с ssl_verify_client on пропустил рукопожатие и ответил страницей «No required SSL certificate was sent». Cloudflare передаст такую 400 посетителю как есть.

Только TLS 1.3 — не проблема. Cloudflare поддерживает 1.3 при соединении с сервером, отключать новые версии ради него не нужно.

Журнал сервера молчит

Самая неприятная находка стенда. После десяти запросов, из которых пять окончились отказом рукопожатия, файл error.log на источнике имел размер 0 байт. Записи появились только после строки:

error_log /var/log/nginx/error.log info;

nginx пишет ошибки рукопожатия уровнем info, а журнал по умолчанию начинается с уровня error. Справка Cloudflare об этом предупреждает осторожно: для nginx «may possibly require an increased log level». На практике без этой строки владелец сайта увидит 525 у посетителей и чистый журнал у себя. Включите info на время поиска причины — потом верните, журнал на этом уровне быстро растёт.

В access.log отказы рукопожатия тоже не попадают: запроса не было. Видно только случай с обычным HTTP на порту 443 — бинарная строка \x16\x03\x01… (начало приветствия TLS) с кодом 400.

Замок есть, а сайт не грузится: почему так

Посетитель видит страницу ошибки по HTTPS с замком в адресной строке, и это не противоречие. Замок относится к соединению браузера с Cloudflare: его сертификат действителен, и эта часть работает. Сбой — на участке от Cloudflare до сервера, а его браузер не видит.

По той же причине бесполезны онлайн-сервисы проверки SSL, которые принимают только имя домена. Имя ведёт на адреса Cloudflare, и сервис проверит сертификат Cloudflare, а не сертификат на вашем сервере. Такой инструмент покажет, что всё в порядке, когда 525 продолжается. Проверять нужно сервер напрямую по его адресу — как, описано ниже.

Сайт открывается, а через Cloudflare — 525

Вариант с шифром CHACHA20 показателен. curl напрямую получил от сервера 200: браузеры и curl этот шифр предлагают. Посредник с набором Cloudflare получил отказ, потому что в списке шифров TLS 1.2, которые Cloudflare предлагает серверу, CHACHA20 нет. Для TLS 1.3 он есть, для TLS 1.2 — нет.

Отсюда частая ловушка. Владелец открывает сайт по адресу сервера, видит замок и рабочую страницу и решает, что TLS в порядке. Проверять надо набором Cloudflare. Для TLS 1.2 он такой (справка Cloudflare, обновлена 17.04.2026): ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-SHA, AES128-GCM-SHA256, AES128-SHA, ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-SHA384, AES256-SHA. Хватит одного общего.

Как определить, что ошибку отдаёт Cloudflare

Существует простой способ убедиться, что 525 пришла от Cloudflare, а не от внутренних систем сайта. Откройте инструменты разработчика (F12), перейдите на вкладку «Сеть» (Network) и обновите страницу. У первого запроса будет статус 525, а среди заголовков ответа — Server: cloudflare и CF-Ray с тем же номером, что и на странице ошибки. Так же это показывает curl:

curl -sI https://example.ru/ | grep -i -E '^(HTTP|server|cf-ray)'

Если статус 525 и заголовок Server: cloudflare на месте, сбой произошёл при обработке запроса на участке от Cloudflare до вашего сервера. Контент сайта при этом не удалён и не повреждён: ресурс просто недоступен, пока не восстановлено успешное рукопожатие.

Частые причины ошибки 525

1. На сервере не настроен HTTPS. Сайт работал в режиме Flexible, потом режим переключили на Full, а сертификат на сервер так и не поставили. Порт 443 закрыт или на нём отвечает обычный HTTP.
2. Нет сертификата для этого имени. На сервере несколько сайтов, и для нужного домена блока server с сертификатом нет — сервер отклоняет рукопожатие или отдаёт чужой сертификат.
3. Нет общих шифров. Слишком строгий список ssl_ciphers или несовпадение типа ключа: ECDSA-сертификат и только RSA-шифры, или наоборот.
4. Устаревший протокол. Сервер поддерживает только версии TLS или SSL, которых Cloudflare не предлагает, например SSLv3.
5. Файрвол или защита от атак режут соединение посреди рукопожатия. Весь трафик идёт с адресов Cloudflare, и правила защиты могут принять его за атаку. Иногда хостинг ограничивает число подключений после всплеска трафика.
6. Недавние изменения на сервере. Переезд на новый сервер, где остался старый сертификат или нет блока для домена, обновление панели хостинга, новый шаблон настроек TLS. Если 525 появилась внезапно, первым делом вспомните, что меняли.

Часто в списки причин 525 включают недействительный сертификат: срок истёк, не установлен промежуточный сертификат, сертификат выпущен на другой домен. По справке Cloudflare это другая ошибка. В режиме Full сертификат не проверяется вовсе, и такой сервер работает — на нашем стенде просроченный и чужой сертификаты в Full дали 200. В Full (strict) невалидный сертификат даёт 526: Cloudflare требует, чтобы он был не просрочен, выдан публичным центром или Cloudflare Origin CA и совпадал по имени с доменом.

Отдельный случай — сертификат клиента. Если сервер требует его у всех (ssl_verify_client on), а функция Cloudflare Authenticated Origin Pulls, при которой Cloudflare предъявляет серверу свой сертификат, не включена, посетитель получит не 525, а 400 — так было на стенде.

Как исправить ошибку 525

Шаг 1. Проверьте рукопожатие набором Cloudflare

Узнайте настоящий адрес сервера в панели хостинга и повторите рукопожатие так, как его делает Cloudflare — с именем сайта и его шифрами:

echo | openssl s_client -connect 203.0.113.10:443 -servername example.ru \
  -cipher 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:AES256-SHA'

Как читать ответ, по нашему стенду:

Шаг 2. Поставьте сертификат на сервер

Для режима Full подойдёт любой, даже самоподписанный. Для Full (strict) нужен действующий сертификат от публичного удостоверяющего центра или бесплатный сертификат Cloudflare Origin CA из панели Cloudflare. Он шифрует только участок от Cloudflare до сервера: если поставить Cloudflare на паузу, посетители увидят ошибку недоверенного сертификата. Напоминаний об окончании его срока Cloudflare не присылает (справка от 14.08.2026). Подробнее о выборе сертификата — в статье про SSL-сертификат сайта.

Шаг 3. Проверьте блок server для домена

У сайта должен быть блок server с listen 443 ssl, нужным server_name и путями к сертификату и ключу. Если на сервере включён ssl_reject_handshake on для блока по умолчанию, рукопожатие с незнакомым именем отклоняется — именно так на стенде получился alert 112.

Шаг 4. Расширьте список шифров

Справка Cloudflare приводит рекомендованные настройки nginx:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519:P-256:P-384;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE+AES128:RSA+AES128:ECDHE+AES256:RSA+AES256:ECDHE+3DES:RSA+3DES;
ssl_prefer_server_ciphers on;

Достаточно, чтобы в вашем ssl_ciphers был хотя бы один шифр из списка Cloudflare под тип вашего ключа: ECDSA-шифры для ECDSA-сертификата, RSA-шифры для RSA. Старые TLS 1.0 и 1.1 включать не обязательно.

Шаг 5. Включите подробный журнал

Если 525 появляется время от времени, а не всегда, Cloudflare советует просмотреть журналы сервера: в них видно, при какой попытке и почему произошёл сбой. Такие записи помогают найти и сложные причины, связанные с нагрузкой или защитой от атак. Для nginx — error_log … info, иначе неудачных рукопожатий там не будет. В Origin Analytics Cloudflare такие запросы видны с originResponseStatus 0.

Шаг 6. Временный выход — режим Flexible

Если сайт нужно поднять немедленно, а сертификата нет, режим Flexible уберёт 525. Это компромисс: участок до сервера пойдёт без шифрования. А если сервер сам перенаправляет HTTP на HTTPS, Flexible, по справке Cloudflare, даст бесконечный редирект — ошибку ERR_TOO_MANY_REDIRECTS.

Шаг 7. Что указать в обращении к хостингу

Если сервер у хостинг-провайдера и доступа к настройкам nginx нет, обратитесь в поддержку. Чтобы ответ был быстрым, укажите:

• домен и адрес сервера;
• время, когда появилась ошибка, и номер Ray ID со страницы ошибки;
• режим SSL в панели Cloudflare (Full или Full (strict));
• вывод openssl s_client из шага 1;
• что менялось перед сбоем: продление сертификата, переезд, обновление.

Если ошибка не ушла после базовой проверки и сервер свой, нужен специалист по настройке серверов: разбор журналов nginx на уровне info обычно сразу показывает причину.

Чек-лист: что проверить по порядку

Если необходимо быстро устранить сбой, пройдите список сверху вниз — так чаще всего удаётся понять причину за несколько минут:

1. Какой режим SSL выбран в панели управления Cloudflare и не менялся ли он в последний раз перед сбоем.
2. Открыт ли порт 443 на сервере и отвечает ли он по TLS, а не по HTTP.
3. Есть ли на сервере сертификат для конкретного доменного имени и указывает ли блок server на правильные файлы.
4. Что показывает openssl s_client с шифрами Cloudflare: успешное рукопожатие или неверные параметры.
5. Что написано в журнале nginx на уровне info в момент ошибки.
6. Не блокирует ли файрвол адреса Cloudflare и не вызывает ли защита от атак обрывы при большом числе соединений.
7. Если ничего не помогло — перезапустить nginx после правок и затем повторить проверку: изменения конфигурации без перезагрузки не применяются.

Как предотвратить ошибку 525

• Меняйте режим SSL после сертификата, а не до. Сначала поставьте и проверьте сертификат на сервере, потом включайте Full.
• Проверяйте конфигурацию после обновлений. Новые шаблоны настроек хостинга и «рекомендации по безопасности» часто урезают список шифров.
• Следите за сроком сертификата, если работаете в Full (strict): после истечения срока Cloudflare перестанет считать его доверенным, и вместо 525 вы получите 526. Регулярно проверяйте дату и валидность сертификата, а продление по возможности автоматизируйте.
• Мониторинг в обход Cloudflare. Проверка сервера напрямую по адресу найдёт сбой раньше посетителя.

Что делать посетителю

Если вы пользователь, а не владелец, ошибка на стороне сайта: ваш браузер, интернет и Cloudflare работают. Чистить кэш, менять браузер или отключать антивирус бесполезно — рукопожатие ломается между Cloudflare и сервером, а не у вас. Подождите и попробуйте обновить страницу в течение часа. Если сайт нужен срочно, следует сообщить владельцу номер Ray ID со страницы ошибки: эта информация будет полезна для поиска записи о сбое в данных Cloudflare.

Чем 525 отличается от 520, 521, 522 и 526

Коды 5xx обозначают ошибки на стороне сервера. Стандартные коды вроде 500 или 502 описаны в спецификации HTTP, а коды 520–526 — собственные коды Cloudflare: так он сообщает, на каком этапе работы с сервером сайта произошёл сбой. Технически каждая из таких ошибок является ответом Cloudflare, а не вашего сервера, поэтому в журнале доступа сервера её может не быть.

Похожая ошибка без Cloudflare — у браузера, когда сервер и он сам не нашли общей версии или шифра: ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Что 525 значит для поиска

Для поискового робота 525 — ошибка сервера класса 5xx. Короткий сбой не вредит, но если сайт неделю отвечает 525 всем, включая роботов, страницы начнут выпадать из индекса. Переключение режима SSL без сертификата на сервере даёт ошибку сразу на всех страницах. Подробнее о поведении роботов при 5xx — в статье об ошибке 504.

Источники

• Cloudflare: Error 525 (обновлено 16.06.2026), Flexible (01.09.2026), Full и Full (strict), Origin CA certificates (14.08.2026), Cipher suites (17.04.2026) — developers.cloudflare.com
• Стенд: nginx 1.31.6, OpenSSL s_client, 20.10.2026

Похожие ошибки

• Ошибка 522 — Cloudflare не дождался соединения с сервером.
• Ошибка 520 — сервер вернул Cloudflare непонятный ответ.
• Ошибка 524 — соединение есть, ответа нет.
• ERR_SSL_PROTOCOL_ERROR — браузер не смог установить защищённое соединение с сайтом.
• ERR_SSL_UNRECOGNIZED_NAME_ALERT — сервер не знает имени, по которому к нему пришли.

Границы замера

Живой 525 мы не нашли: 20.10.2026 из 2056 сайтов Екатеринбурга за Cloudflare работали 79, и ни один не отвечал 525. Поэтому внешний вид страницы ошибки здесь не показан, а результаты стенда — это поведение nginx в роли посредника с набором Cloudflare, а не самого Cloudflare. Коды 502 стенда соответствуют 525 у Cloudflare по условиям из его справки.

Коротко

525 — Cloudflare и сервер не договорились о TLS. Проверьте рукопожатие через openssl s_client с именем сайта и шифрами Cloudflare, поставьте сертификат и расширьте ssl_ciphers. Если ищете причину по журналу nginx, сначала включите уровень info: по умолчанию неудачные рукопожатия туда не пишутся.