Артём Савельев 
ERR_SSL_PROTOCOL_ERROR: что означает ошибка и как её исправить
Эта ошибка — про сорвавшееся рукопожатие: браузер и сервер начали договариваться о защищённом соединении и не договорились. Важно: до проверки сертификата дело даже не дошло — сломался сам протокол переговоров. Поэтому и чинится она иначе, чем «Ваше подключение не защищено». Разбираем причины по обе стороны — от неправильного времени на компьютере до сервера, отдающего HTTP на 443-м порту.
Где именно ломается
Защищённое соединение начинается с TLS-рукопожатия: браузер предлагает версии протокола и наборы шифров, сервер выбирает, стороны обмениваются ключами — и только потом сервер предъявляет сертификат. ERR_SSL_PROTOCOL_ERROR означает провал на первом этапе: ответ сервера не похож на TLS вообще или стороны не сошлись в версиях и шифрах. Этим она отличается от ошибок семейства NET::ERR_CERT_* («подключение не защищено») — там рукопожатие состоялось, но браузеру не понравился сертификат. Две разные болезни — два разных лечения.
Если вы посетитель
| Шаг | Почему помогает |
|---|---|
| 1. Проверить дату и время на устройстве | Сбитые часы ломают криптографию: включите автоматическую синхронизацию времени |
| 2. Отключить в антивирусе «проверку HTTPS/SSL» | Антивирусы встраиваются в TLS-соединения как посредник — и регулярно делают это криво |
| 3. Выключить VPN/прокси | Ещё один посредник в соединении — ещё один кандидат в виновники |
| 4. Попробовать другой браузер и инкогнито | Отсекает профиль браузера, расширения и залипший кэш соединений |
| 5. Проверить с другого устройства/сети | Ошибка у всех — проблема на сервере, дальше зона ответственности владельца |
Если вы владелец: четыре серверных причины
1. На 443-м порту нет TLS. Классика конфигурационных ошибок: в nginx прописан listen 443, но без параметра ssl — и сервер отдаёт на «защищённый» порт обычный HTTP. Браузер ждёт TLS-ответ, получает открытый текст — и падает ровно с этой ошибкой. Проверка: curl -v https://домен расскажет, что именно пришло в ответ.
2. Устаревшие версии протокола. Браузеры отключили поддержку TLS 1.0 и 1.1 ещё в 2020 году. Если сервер собран так, что умеет только их (старые панели, древние Java-приложения, оборудование с веб-интерфейсом десятилетней давности), современный браузер с ним не договорится. Лечение — включить TLS 1.2/1.3 на сервере; заодно и по соображениям безопасности.
3. Несогласованные шифры. Перестарались с «hardening»: набор шифров в конфиге сужен до экзотики, которой нет у части клиентов. Симптом — работает в одних браузерах/ОС и падает в других. Разумный путь — использовать актуальные рекомендованные наборы, а не составлять свои.
4. Посредник портит соединение. Если сайт за CDN/прокси, рукопожатие с посетителем выполняет посредник — и ошибки его конфигурации становятся вашими. У Cloudflare, например, свои режимы SSL, и неправильный выбор ломает часть соединений — подробности в статье про Cloudflare.
# Диагностика рукопожатия с сервера или любой машины с openssl: openssl s_client -connect домен:443 -servername домен # Что смотреть в выводе: # - "Protocol: TLSv1.3/1.2" — версии согласованы, рукопожатие ок # - "no protocols available" / "handshake failure" — несовместимость версий или шифров # - HTML вместо TLS-ответа — на порту нет ssl (причина №1)
Эта ошибка любит появляться после «успешных» работ: обновили сертификат, перенастроили nginx, перевесили сайт на новый прокси — и не проверили результат из внешнего мира. Внутренние проверки с самого сервера рукопожатие не тестируют так, как его видит браузер посетителя. Правило: закончили работы с TLS — откройте сайт из чужой сети или дождитесь зелёной внешней проверки.
Чек-лист владельца после любых работ с TLS
Пять пунктов, закрывающих девять из десяти инцидентов с рукопожатием: конфиг слушает 443 именно с ssl (nginx -t перед перезагрузкой — обязателен); включены TLS 1.2 и 1.3, отключены 1.0/1.1; набор шифров — рекомендованный, не самодельный; после reload сайт открыт из чужой сети или инкогнито с телефона через мобильный интернет; и внешняя проверка HTTPS зелёная. Шестой пункт — для сайтов за CDN: SSL-режим прокси согласован с настройками origin (для Cloudflare — Full strict), иначе рукопожатие будет ломаться не у вас, а у посредника, где вы его не увидите.
Ошибка-хамелеон: разные имена в разных браузерах
В Chrome это ERR_SSL_PROTOCOL_ERROR, в Firefox — SSL_ERROR_RX_RECORD_TOO_LONG (чаще всего при HTTP на 443-м порту) или PR_CONNECT_RESET_ERROR, в curl — «error in the SSL handshake». Все они об одном: соединение сорвалось на этапе переговоров, до сертификата. Если пользователи присылают разные скриншоты с этими названиями — это одна и та же проблема, а не несколько.
Пруфен выполняет проверку SSL и HTTPS-проверки снаружи, как их видит браузер посетителя: сорванное рукопожатие фиксируется как инцидент с первого же цикла проверки — из 13 точек, с интервалом от 2 минут для HTTP и от 1 часа для сертификата. Сломали TLS вечерними работами — узнаете от мониторинга, а не из утренних жалоб.
Частые вопросы
Чем это отличается от «Ваше подключение не защищено»? Этапом: здесь браузер и сервер не смогли начать разговор (протокол), там — поговорили, но браузер не поверил документам (сертификат). Про второй случай у нас отдельная статья со всеми кодами NET::ERR_CERT_*.
Сайт работает у всех, кроме пользователей старых Android/Windows. Почему? Обратная ситуация: у сервера современный TLS, а у старых систем нет его поддержки (или нет нужных корневых сертификатов). Решение — компромиссный набор протоколов/шифров с поддержкой TLS 1.2, без экзотики.
Ошибка появилась у всех после переезда на новый сервер. С чего начать? С curl -v https://домен: чаще всего на новом сервере на 443-м порту просто не включён ssl или не подхватился конфиг. Это чинится одной строкой — если знать, куда смотреть.
Может ли эта ошибка быть у части посетителей из-за провайдера? Да: вмешательство в TLS-трафик по пути (корпоративные прокси, некоторые фильтры) ломает рукопожатие для конкретных сетей. Диагноз тот же, что всегда: сравнить доступность из нескольких сетей и городов.