ERR_SSL_PROTOCOL_ERROR: как исправить в Chrome и на телефоне

Что такое ERR_SSL_PROTOCOL_ERROR?

ERR_SSL_PROTOCOL_ERROR означает, что защищённое соединение оборвалось при рукопожатии TLS, прежде чем браузер успел что-либо загрузить. Chrome и Edge показывают его как «Этот сайт не может обеспечить безопасное подключение. Сайт example.com отправил недействительный ответ.» Если адрес — localhost, ваш сервер разработки почти наверняка отвечает по обычному HTTP: откройте вместо этого http://localhost (см. раздел для разработчиков ниже).

Каждое HTTPS-соединение начинается с рукопожатия TLS, в котором браузер и сервер договариваются о версии протокола (TLS 1.2 или 1.3) и шифрах и обмениваются сертификатами. ERR_SSL_PROTOCOL_ERROR означает, что эти переговоры сорвались: другая сторона ответила чем-то, что не является корректным TLS, или отклонила рукопожатие так, что браузер не смог определить причину.

Он возникает до отправки любого HTTP-запроса, поэтому не является кодом состояния HTTP. В списке ошибок Chromium он определён как ошибка -107 с одной строкой, «An SSL protocol error occurred»: общая ошибка сорванного рукопожатия, в отличие от конкретной ошибки -113 («нет общей версии протокола или шифра»).

Как выглядит ERR_SSL_PROTOCOL_ERROR

Chrome и другие браузеры на основе Chromium показывают эту ошибку как предупреждение на весь экран с сообщением «Этот сайт не может обеспечить безопасное подключение». Под ним указан конкретный код ошибки. Вот самые частые варианты.

• Сайт localhost отправил недействительный ответ (по-английски «localhost sent an invalid response») — вариант, который видят разработчики: https:// открыт на локальном сервере, отвечающем по обычному HTTP
• ERR_SSL_PROTOCOL_ERROR — код ошибки, который Chrome печатает мелким шрифтом под сообщением
• net::ERR_SSL_PROTOCOL_ERROR — полный внутренний код ошибки в консоли Chrome DevTools
• Этот сайт не может обеспечить безопасное подключение — заголовок, который Chrome показывает пользователю
• Сайт [домен] отправил недействительный ответ — подробный текст ошибки, который Chrome показывает под заголовком
• ERR_SSL_PROTOCOL_ERROR во всех браузерах — когда ошибка появляется сразу в Chrome, Edge, Brave и Opera (указывает на проблему на стороне сервера или всей системы, а не на ошибку конкретного браузера)

Что вызывает ERR_SSL_PROTOCOL_ERROR?

У этой ошибки есть причины на стороне клиента (ваше устройство) и на стороне сервера (сайт). Первый шаг — выяснить, с какой стороны проблема. Если ошибка появляется на любом сайте, проблема у вас. Если только на одном конкретном сайте, причина, скорее всего, на сервере.

• HTTPS отправлен на сервер, который отвечает по HTTP — самый частый поисковый случай: https://localhost на сервере разработки или сайт, у которого порт 443 не настроен под TLS. Браузер начинает рукопожатие и получает обычный текст, а Chrome сообщает об этом как «отправил недействительный ответ».
• Сканирование SSL/HTTPS в антивирусе — защитное ПО, перехватывающее HTTPS (Avast, Kaspersky, Bitdefender, ESET), встраивается в рукопожатие и может ломать его сразу на всех сайтах.
• VPN или прокси — VPN и корпоративные прокси, проверяющие HTTPS-трафик, могут нарушить рукопожатие, особенно сразу после смены сети.
• Сеть, которая фильтрует сайт — фильтры провайдеров, школ, работодателей и государств, а также блокировщики на основе DNS намеренно ломают рукопожатие для блокируемых сайтов. Признак: сайт открывается через мобильный интернет или другую сеть Wi-Fi.
• Сломанная настройка TLS на сервере — порт 443 отвечает по обычному HTTP (серверный блок на 443 без включённого TLS) или порт 443 слушает другая программа.
• Расширения браузера — дополнения для приватности, блокировки рекламы и безопасности, которые переписывают HTTPS-запросы, могут мешать рукопожатию.
• Устаревшее состояние браузера — сохранённые данные сессии, которые больше не соответствуют серверу.
• Часто путают с ним — сервер, застрявший на TLS 1.0 или 1.1, показывает ERR_SSL_VERSION_OR_CIPHER_MISMATCH («используется неподдерживаемый протокол»), просроченный, с неверным именем или самоподписанный сертификат либо неверные часы показывают ошибку сертификата (NET::ERR_CERT_…), а проблема с QUIC (HTTP/3) показывает ERR_QUIC_PROTOCOL_ERROR. См. ERR_SSL_VERSION_OR_CIPHER_MISMATCH и «Ваше подключение не является приватным».

ERR_SSL_PROTOCOL_ERROR на localhost (для разработчиков)

Сайт localhost отправил недействительный ответ. ERR_SSL_PROTOCOL_ERROR почти всегда означает, что вы открыли https://localhost на сервере разработки, который отвечает только по обычному HTTP. Браузер начинает рукопожатие TLS, сервер отвечает обычным HTTP-текстом, а Chrome сообщает, что этот ответ недействителен. Firefox сообщает об этой же ошибке как SSL_ERROR_RX_RECORD_TOO_LONG.

• Используйте адрес, который выводит сервер — замените https://localhost:3000 на http://localhost:3000. Серверы разработки Next.js, Vite, React, Django, Rails и Flask отдают HTTP, пока вы не включите HTTPS
• Проверьте порт — https://localhost без порта означает порт 443. Если ваше приложение работает на 3000 или 5173, запрос попадает в другую программу или в никуда
• Chrome постоянно переключается на https:// — причиной может быть сохранённое перенаправление от прежнего приложения на том же порту: очистите кешированные файлы и изображения или проверьте в окне инкогнито. (В версиях Chrome до 132 мог также сохраняться HSTS-запись для localhost, которую удаляют в chrome://net-internals/#hsts в поле Delete domain security policies)
• Вам нужен HTTPS локально (обратные вызовы OAuth, защищённые cookie) — next dev --experimental-https создаёт локально доверенный сертификат с помощью mkcert; Vite принимает параметры сертификата в server.https, а @vitejs/plugin-basic-ssl даёт быстрый самоподписанный; в остальных случаях mkcert -install && mkcert localhost 127.0.0.1 создаёт файлы, которые может загрузить ваш сервер
• Самоподписанный сертификат даёт другую ошибку — NET::ERR_CERT_AUTHORITY_INVALID, а не эту. Нажмите Дополнительные настройки → Перейти на сайт localhost (небезопасно) или, лучше, используйте сертификат mkcert (старый флаг allow-insecure-localhost перестал действовать)

Как исправить ERR_SSL_PROTOCOL_ERROR (для пользователей)

Начните со способа 1: за две минуты он покажет, где проблема — в браузере, на вашем устройстве или в сети, либо на самом сайте. Затем идите по списку вниз.

Способ 1: попробуйте режим инкогнито и другую сеть

Окно инкогнито запускается без cookie, без кеша и без расширений (если вы не разрешили их там). Откройте сайт в окне инкогнито (Ctrl+Shift+N в Chrome и Edge, Ctrl+Shift+P в Firefox), а затем в другой сети, например через мобильный интернет на телефоне.

Если в режиме инкогнито сайт загружается, причина в браузере: расширение или устаревшие данные (способы 4 и 5). Если он загружается только в другой сети, его фильтрует или перехватывает ваша сеть либо VPN или прокси (способ 3). Если не открывается нигде, проверьте сайт через инструмент Проверка SSL сертификата: если и он показывает сбой, исправить может только владелец сайта.

Способ 2: отключите сканирование SSL/HTTPS в антивирусе

Во многих антивирусах (Avast, Kaspersky, Bitdefender, ESET, Norton) есть функция «сканирование HTTPS» или «проверка SSL», которая перехватывает зашифрованные соединения, выступая прокси-посредником (man-in-the-middle). Если она неверно обрабатывает рукопожатие сайта, этот сайт не открывается во всех браузерах на компьютере.

Найдите в антивирусе настройки с названиями вроде Web Shield, Сканирование HTTPS, Сканирование SSL или Проверка зашифрованных соединений и временно отключите их. Если ошибка исчезла, можно добавить затронутый домен в список исключений антивируса.

Способ 3: отключите VPN или прокси

VPN и HTTP-прокси находятся между браузером и веб-сервером. Некоторые VPN проверяют HTTPS-трафик или направляют соединения через серверы с неисправным TLS. Корпоративные прокси часто используют перехват SSL (как сканирование HTTPS в антивирусе), который может ломать рукопожатие TLS.

Временно отключите VPN и попробуйте загрузить сайт. Если без VPN всё работает, проблема в том, как ваш VPN обрабатывает SSL-соединения. Попробуйте другой сервер VPN или обратитесь к поставщику VPN.

Способ 4: отключите расширения браузера

Расширения, которые фильтруют или перенаправляют трафик, такие как расширения VPN и прокси и защитные дополнения, могут ломать защищённые соединения.

Откройте chrome://extensions/, выключите все расширения и перезагрузите страницу. Если ошибка исчезла, включайте их обратно по одному, чтобы найти виновника.

Способ 5: очистите кеш и файлы cookie браузера

Устаревшие cookie или кешированные данные иногда мешают, а их очистка занимает минуту.

• Шаг 1: Нажмите Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete), чтобы открыть Удалить данные о работе в браузере
• Шаг 2: Выберите Ещё → Все время в качестве периода
• Шаг 3: Отметьте Файлы cookie и другие данные сайтов и Кешированные файлы и изображения
• Шаг 4: Нажмите Удалить данные (Удалить с устройства, если вы не вошли в аккаунт) и перезапустите Chrome

Для одного сайта откройте chrome://settings/content/all, найдите домен и удалите его данные.

Способ 6: исключите QUIC (HTTP/3)

Chrome пробует QUIC (HTTP/3 поверх UDP) параллельно с обычным TCP-соединением и возвращается к TCP, если QUIC не работает, поэтому QUIC редко вызывает ERR_SSL_PROTOCOL_ERROR. Если страница или DevTools показывают вместо этого ERR_QUIC_PROTOCOL_ERROR, решение — отключить QUIC (см. ERR_QUIC_PROTOCOL_ERROR):

• Шаг 1: Введите chrome://flags/#enable-quic в адресной строке
• Шаг 2: Найдите Experimental QUIC protocol
• Шаг 3: Измените значение с Default на Disabled
• Шаг 4: Нажмите Relaunch, чтобы перезапустить Chrome

Страницы по-прежнему загружаются без QUIC, по HTTP/2 поверх TCP; включите QUIC обратно, когда сеть или сайт будут исправлены.

Способ 7: обновите браузер

В старых версиях браузеров может не хватать функций TLS и шифров, которых ждут современные сайты, а обновления исправляют ошибки TLS.

Обновите Chrome: откройте chrome://settings/help или Меню → Справка → О браузере Google Chrome. Chrome скачивает обновления автоматически, но для их применения нужен перезапуск. Для Edge: edge://settings/help. Для Firefox: Меню → Справка → О Firefox.

Способ 8: очистите DNS-кеш

Устаревший DNS может направить браузер на старый сервер, который больше не отдаёт сайт по TLS. Очистка DNS-кеша вынуждает выполнить новый запрос.

# Windows (Command Prompt as Admin)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Linux
sudo resolvectl flush-caches

# Chrome internal DNS cache
# Visit chrome://net-internals/#dns → Click "Clear host cache"

После очистки проверьте, что домен разрешается в правильный IP, с помощью инструмента Проверка DNS от DNS Robot. Если IP-адрес выглядит неверно, возможно, сайт сменил хостинг-провайдера, а DNS ещё не полностью распространился.

Способ 9: проверьте дату и время системы

Неверные часы обычно проявляются как другая ошибка, NET::ERR_CERT_DATE_INVALID («Часы спешат» или «Часы отстают»), потому что сертификат действителен только между двумя датами. Исключить это можно за десять секунд:

• Windows: «Параметры» → «Время и язык» → «Дата и время» → включите «Установить время автоматически» и «Автоматическая установка часового пояса»
• Mac: «Системные настройки» → «Основные» → «Дата и время» → включите автоматическую установку даты и времени («Set time and date automatically» в английском интерфейсе)
• Linux: Выполните sudo timedatectl set-ntp true, чтобы включить синхронизацию NTP

Способ 10: очистите состояние SSL (Windows)

Во многих руководствах советуют Очистить SSL в «Свойствах браузера» Windows (inetcpl.cpl → вкладка Содержание → Очистить SSL). Это очищает кеш сеансов собственной библиотеки TLS в Windows, которой пользуются приложения на сетевом стеке Windows. Chrome и Edge используют собственную библиотеку TLS, поэтому для них это редко что-то меняет.

Аналог для браузера проще: закройте все окна браузера (проверьте в области уведомлений, нет ли Chrome в фоне) и откройте его снова. Это сбрасывает все кешированные сеансы TLS. Если ошибка пережила полный перезапуск, переходите к следующим способам.

Способ 11: сброс сетевых настроек (крайняя мера)

Если ничего не помогает, сбросьте сетевой стек. В Windows эти команды сбрасывают Winsock и TCP/IP, включая статические IP-адреса и DNS-серверы, заданные вручную; в macOS и Linux они только очищают DNS-кеш или перезапускают сетевую службу.

# Windows (Command Prompt as Admin)
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

# Then restart your computer

# macOS — flush the DNS cache
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux — restart NetworkManager
sudo systemctl restart NetworkManager

Как исправить ERR_SSL_PROTOCOL_ERROR (для владельцев сайтов)

Если об ERR_SSL_PROTOCOL_ERROR сообщают многие посетители, проблема на сервере: обычно порт 443 отвечает по обычному HTTP или этот порт занят другой программой. Проблемы с сертификатом показывают собственные ошибки, но проверьте их заодно. (Если сертификат и ключ не совпадают, сервер вообще не загрузит новую конфигурацию: после изменений проверяйте её командой nginx -t или apachectl configtest.)

Проверьте свой SSL-сертификат

Первый шаг — убедиться, что SSL-сертификат действителен, правильно установлен и не просрочен. Воспользуйтесь инструментом Проверка SSL сертификата от DNS Robot, чтобы сразу увидеть статус сертификата, дату окончания, издателя и цепочку сертификатов.

Эти проблемы с сертификатом показывают собственные ошибки, а не ERR_SSL_PROTOCOL_ERROR, но исправьте их заодно:

• Просроченный сертификат (NET::ERR_CERT_DATE_INVALID) — сертификаты Let's Encrypt действуют 90 дней (с февраля 2027 года 64 дня), поэтому продление должно выполняться автоматически; если оно не сработало (не работает таймер certbot, сломана проверка DNS), сертификат истекает незаметно.
• Неверный домен (NET::ERR_CERT_COMMON_NAME_INVALID) — сертификат выпущен для example.com, а сайт открывается по адресу www.example.com (или наоборот). Сертификат должен точно соответствовать домену или включать wildcard (*.example.com).
• Самоподписанный сертификат (NET::ERR_CERT_AUTHORITY_INVALID) — подходит для разработки, но браузеры никогда не доверяют ему в продакшене.
• Отозванный сертификат (NET::ERR_CERT_REVOKED) — центр сертификации отозвал его после компрометации ключа или ошибочного выпуска.
• Не тот сертификат для этого имени (NET::ERR_CERT_COMMON_NAME_INVALID) — несколько сайтов делят один IP-адрес, а сервер не использует SNI (Server Name Indication), чтобы выбрать сертификат каждого сайта.

# Check certificate from command line
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

# Check certificate chain completeness
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>&1 | grep -E "depth|Verify"

# Renew Let's Encrypt certificate
sudo certbot renew --dry-run   # test first
sudo certbot renew

Включите TLS 1.2 и TLS 1.3

Все современные браузеры требуют как минимум TLS 1.2: TLS 1.0 и 1.1 официально объявлены устаревшими в 2021 году документом RFC 8996. Сторона, которая отвергает версию другой стороны, завершает рукопожатие оповещением TLS 70, protocol_version (RFC 8446 §6.2). Сервер, поддерживающий только TLS 1.0 или 1.1, показывает ERR_SSL_VERSION_OR_CIPHER_MISMATCH, а не эту ошибку, но в обоих случаях сбой. TLS 1.3 соединяется за один обмен вместо двух у TLS 1.2: включите оба.

# Nginx — ssl_protocols in nginx.conf or site config
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;

# Apache — in httpd.conf or ssl.conf
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder off

После изменения настроек TLS перезапустите веб-сервер (sudo systemctl restart nginx или sudo systemctl restart apache2) и проверьте через инструмент Проверка SSL сертификата от DNS Robot, что протоколы активны.

Установите полную цепочку сертификатов

Неполная цепочка проявляется как ошибка сертификата (NET::ERR_CERT_AUTHORITY_INVALID) в браузерах и приложениях, которые не могут сами подтянуть недостающий промежуточный сертификат, поэтому установите полную цепочку заодно с проверкой. Сервер должен отправлять ваш сертификат и промежуточные сертификаты, связывающие его с доверенным корневым.

Большинство центров сертификации предоставляют файл «CA bundle» или «full chain». Для Let's Encrypt используйте fullchain.pem (а не только cert.pem). У других центров скачайте промежуточный сертификат из их документации и объедините его со своим сертификатом.

# Nginx — use fullchain, not just cert
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

# Apache
SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem

Проверьте конфигурацию HSTS

HSTS (HTTP Strict Transport Security) велит браузерам всегда использовать HTTPS для вашего домена. Если у политики HSTS большой max-age, а настройка TLS потом ломается, браузеры не могут откатиться на HTTP: посетители видят страницу ошибки без возможности пройти дальше.

Проверьте заголовок HSTS с помощью инструмента Проверка HTTP-заголовков от DNS Robot. Если вы задали очень большой max-age (например, 2 года), а сертификат истёк, пользователи, уже посещавшие ваш сайт, заперты на HTTPS без запасного пути. Чтобы это исправить, сначала почините SSL-сертификат, и браузеры снова будут подключаться как обычно.

Проверьте конфигурацию сервера

Эта ошибка сервера ломает рукопожатие даже при действительном сертификате, а ещё одна показывает другую ошибку:

• Порт 443 отдаёт обычный HTTP — классическая причина на стороне владельца: в nginx listen 443; без ssl (должно быть listen 443 ssl;) или другая служба занимает порт 443.
• Несовпадение наборов шифров — сервер, предлагающий только шифры, которые браузеры отвергают, показывает ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Используйте современные шифры AEAD (AES-GCM, ChaCha20).

Проверьте снаружи командой openssl s_client -connect example.com:443 -servername example.com </dev/null: «wrong version number» (OpenSSL) или «tlsv1 alert protocol version» (встроенный openssl в macOS) означает, что порт 443 не отвечает по TLS, а вывод сертификата означает, что рукопожатие работает.

ERR_SSL_PROTOCOL_ERROR на Android

Пользователи Android встречают ERR_SSL_PROTOCOL_ERROR и в Chrome для Android, и в приложениях на основе WebView. Исправления немного отличаются от десктопных, потому что Android по-своему управляет сертификатами и сетевыми настройками.

• Смените сеть — выключите Wi-Fi и попробуйте мобильный интернет (или наоборот). Если сайт загрузился, сеть его фильтрует или перехватывает
• Отключите частный DNS-сервер для проверки — Настройки → Сеть и интернет → Частный DNS-сервер → Отключен (а в Chrome: Настройки → Конфиденциальность и безопасность → Использовать безопасный DNS-сервер). Фильтрующий DNS-сервис (блокировка рекламы, родительский контроль) направляет блокируемые сайты на сервер, который не может завершить рукопожатие
• Очистите данные Chrome — Настройки → Приложения → Chrome → Хранилище и кеш → Очистить кеш (затем «Manage space», если это не помогло)
• Обновите Chrome — Google Play → значок вашего профиля → Управление приложениями и устройством → обновите Chrome
• Очистите учётные данные — Настройки → Безопасность (на новых телефонах: Дополнительные настройки безопасности → Шифрование и учетные данные) → Очистить учетные данные. Это удалит все сертификаты, установленные пользователем
• Проверьте дату и время — Настройки → Система → Дата и время → автоматически. Неверные часы показывают ошибку сертификата, но их легко исключить
• Сбросьте сетевые настройки — Настройки → Система → Сброс настроек, затем сброс Wi-Fi и мобильной сети (название зависит от версии Android)

ERR_SSL_PROTOCOL_ERROR на iPhone и iPad

На iPhone Chrome показывает ERR_SSL_PROTOCOL_ERROR, а Safari сообщает, что не может установить безопасное соединение с сервером. Причины те же, что и на компьютере, только переключатели находятся в других местах:

• Смените сеть — выключите Wi-Fi и попробуйте мобильный интернет. Если сайт загрузился, сеть Wi-Fi его фильтрует или перехватывает
• Удалите незнакомые VPN и профили — Настройки → Основные → VPN и управление устройством. Профиль, который устанавливает собственный сертификат или VPN, может перехватывать HTTPS
• Проверьте без «Частного узла iCloud» — Настройки → [ваше имя] → iCloud → Частный узел → выключите, затем повторите попытку
• Проверьте ограничения «Экранного времени» — Настройки → Экранное время → Контент и конфиденциальность, затем настройку веб-контента. Заблокированный сайт не открывается
• Включите автоматическую установку времени — Настройки → Основные → Дата и время → Автоматически

ERR_SSL_PROTOCOL_ERROR в других браузерах

ERR_SSL_PROTOCOL_ERROR — код ошибки, свойственный Chromium. Другие браузеры показывают другие сообщения об одном и том же сбое рукопожатия SSL.

Если ошибка появляется во всех браузерах сразу, проблема либо в вашей системе (сканирование HTTPS в антивирусе, VPN или прокси, ваша сеть), либо на сервере (порт 443 неправильно отвечает по TLS). Если не работает только один браузер, проверьте его расширения и сохранённые данные.

Связанные коды ошибок SSL/TLS

В Chrome есть несколько кодов ошибок, связанных с SSL. Все они указывают на разные проблемы с рукопожатием TLS или сертификатом.

Для любых ошибок SSL можно быстро найти причину с помощью инструмента Проверка SSL сертификата от DNS Robot: за одно сканирование он показывает статус сертификата, полноту цепочки, поддерживаемые версии TLS и дату окончания.

Если на вашей странице написано, что сайт «использует неподдерживаемый протокол», у вас ERR_SSL_VERSION_OR_CIPHER_MISMATCH, а не эта ошибка: см. как исправить ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Если на странице вместо этого написано «Сайт example.com неожиданно разорвал соединение» (ERR_CONNECTION_CLOSED), соединение было оборвано, а не сломано. Для этого случая см. ERR_CONNECTION_CLOSED.