Как исправить ошибку ERR_SPDY_PROTOCOL_ERROR в Chrome
ERR_SPDY_PROTOCOL_ERROR — это сетевая ошибка Chrome, которая возникает, когда браузер не может установить или поддерживать действительную сессию SPDY или HTTP/2 с веб-сервером. Она проявляется как неудачная загрузка страницы, обычно сопровождаемая стандартным экраном ошибки Chrome, и может быть вызвана устаревшими соединениями сокетов, повреждёнными данными кэша, несоответствиями TLS/SSL, мешающими расширениями или неправильно настроенным согласованием протокола на стороне сервера.
Название ошибки отсылает к SPDY — устаревшему мультиплексированному транспортному протоколу Google, предшественнику HTTP/2. Хотя Chrome прекратил нативную поддержку SPDY после версии 51, внутренний уровень управления сокетами и сессиями по-прежнему использует терминологию, унаследованную от SPDY, поэтому код ошибки сохраняется даже при современных соединениях HTTP/2 и HTTP/3. Понимание этого различия необходимо для точной диагностики первопричины.
Что на самом деле вызывает ERR_SPDY_PROTOCOL_ERROR
Прежде чем применять исправления вслепую, полезно знать точные режимы сбоя, стоящие за этой ошибкой:
- Устаревшие сессии сокетов SPDY/HTTP2, кэшированные в пуле соединений Chrome, которые больше не соответствуют текущему состоянию TLS сервера
- Истёкшие или перевыпущенные SSL/TLS-сертификаты на стороне сервера, которые аннулируют существующую сессию без чистого сброса рукопожатия
- Несоответствия ALPN (Application-Layer Protocol Negotiation), когда сервер объявляет поддержку HTTP/2, но TLS-рукопожатие прерывается в середине сессии
- Повреждённые данные профиля браузера, включая кэш, файлы cookie или файл состояния сети
- Прокси, VPN или программное обеспечение безопасности, выполняющее TLS-инспекцию, которая нарушает уровень фреймирования HTTP/2
- Устаревшие сборки Chrome с известными ошибками в реализации HTTP/2 или QUIC
- Неправильная конфигурация на стороне сервера — например, экземпляр Nginx или Apache с неисправным модулем
h2или истёкшим сертификатом на граничном узле CDN
Исправление 1: Прямая очистка сокетов SPDY
Это наиболее точное исправление, и оно должно быть вашим первым действием. Chrome поддерживает постоянный пул сессий сокетов SPDY/HTTP2. Если сессия становится повреждённой — например, после перезапуска сервера или перевыпуска сертификата — Chrome продолжит использовать неисправную сессию до тех пор, пока она не будет явно очищена.
- Откройте новую вкладку Chrome.
- Перейдите по адресу
chrome://net-internals/#sockets - Нажмите Flush socket pools.
- Затем перейдите по адресу
chrome://net-internals/#dns - Нажмите Clear host cache.
- Закройте вкладку и перезагрузите проблемную страницу.
Эта двухэтапная очистка одновременно удаляет пул сессий транспортного уровня и кэш DNS-разрешения, что устраняет две наиболее распространённые причины ошибки в браузере за один проход.
Почему старый URL больше не работает: Многие руководства по-прежнему ссылаются на chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active. Chrome удалил вкладку Events в новых сборках. Используйте #sockets и #dns напрямую.
Исправление 2: Очистка кэша браузера и файлов cookie
Кэшированные HTTP-ответы, сохранённые файлы cookie и устаревшее состояние HSTS (HTTP Strict Transport Security) могут конфликтовать с текущей конфигурацией TLS или протокола сервера.
- Откройте Chrome и нажмите
Ctrl+Shift+Delete(Windows/Linux) илиCmd+Shift+Delete(macOS). - Установите Временной диапазон на Всё время.
- Отметьте Файлы cookie и другие данные сайтов и Кэшированные изображения и файлы.
- Нажмите Удалить данные.
Для более точного подхода — если вы хотите очистить данные только для одного конкретного домена, не затрагивая всё состояние браузера — используйте следующее:
- Перейдите по адресу
chrome://settings/siteData - Найдите затронутый домен.
- Удалите только файлы cookie и хранилище этого сайта.
Кроме того, очистите состояние HSTS для домена по адресу chrome://net-internals/#hsts, введя имя хоста в поле Delete domain security policies. Устаревшая запись HSTS может принудить Chrome к пути обновления, который конфликтует с сервером, изменившим конфигурацию TLS.
Исправление 3: Обновление Google Chrome
Реализации HTTP/2 и QUIC в Chrome регулярно получают исправления. Использование устаревшей сборки может означать, что вы несёте известные ошибки обработки протокола, которые уже были исправлены в более новых версиях.
- Нажмите меню с тремя точками и перейдите в Справка > О браузере Google Chrome.
- Chrome автоматически проверит наличие обновлений и загрузит их.
- Нажмите Перезапустить, чтобы применить обновление.
Чтобы проверить текущую версию из адресной строки, перейдите по адресу chrome://version/. Сверьте номер сборки с блогом Chrome Releases, чтобы убедиться, что вы используете последний стабильный канал.
Исправление 4: Отключение VPN, прокси и инструментов TLS-инспекции
VPN, корпоративные прокси и антивирусные продукты, выполняющие глубокую инспекцию SSL/TLS (также называемую перехватом HTTPS), являются частой и недооценённой причиной ERR_SPDY_PROTOCOL_ERROR. Эти инструменты завершают TLS-соединение на клиенте, повторно шифруют его собственным сертификатом и пересылают на сервер. Если реализация HTTP/2 инструмента неполна или его цепочка сертификатов не является доверенной, Chrome отклонит сессию.
Отключение настроек прокси в Windows:
- Нажмите
Win+Iдля открытия Параметров. - Перейдите в Сеть и Интернет > Прокси-сервер.
- Установите Автоматическое определение параметров в положение Вкл., а Использовать прокси-сервер — в положение Выкл.
Отключение настроек прокси через командную строку:
netsh winhttp reset proxyПроверка активности прокси:
netsh winhttp show proxyЕсли вы находитесь в корпоративной сети, проконсультируйтесь с системным администратором перед отключением настроек прокси, так как это может нарушать сетевую политику. Вместо этого уточните, поддерживает ли инструмент SSL-инспекции режим сквозной передачи HTTP/2.
Исправление 5: Сброс стека TCP/IP и очистка кэша DNS
Повреждённые записи стека TCP/IP или отравленный кэш DNS могут вызывать сбои соединения, проявляющиеся как ошибки протокола. Это исправление работает на уровне сетевой ОС, ниже самого Chrome.
Откройте командную строку от имени администратора (нажмите Win+R, введите cmd, затем нажмите Ctrl+Shift+Enter) и последовательно выполните следующие команды:
netsh int ip reset
netsh winsock reset
ipconfig /flushdns
ipconfig /release
ipconfig /renewПерезагрузите компьютер после выполнения этих команд. Команда netsh winsock reset особенно важна — повреждённый каталог Winsock может вызывать периодические и внешне случайные ошибки протокола, которые трудно отследить до их источника.
На macOS эквивалентная команда очистки DNS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderИсправление 6: Отключение или изоляция расширений браузера
Расширения, перехватывающие сетевые запросы — блокировщики рекламы, инструменты конфиденциальности, антивирусные расширения, VPN-расширения и пользовательские переключатели прокси — могут повреждать фреймы HTTP/2 или внедрять заголовки, нарушающие спецификацию HTTP/2, что вызывает ошибку протокола.
Метод систематической изоляции:
- Откройте
chrome://extensions/ - Отключите все расширения одновременно.
- Перезагрузите проблемную страницу.
- Если ошибка исчезла, включайте расширения по одному, перезагружая страницу после каждого, пока не будет определён виновник.
Кроме того, откройте Chrome в режиме инкогнито (Ctrl+Shift+N), который по умолчанию отключает все расширения (если вы явно не разрешили их в режиме инкогнито). Если страница загружается нормально в режиме инкогнито, расширение определённо является причиной.
Исправление 7: Перезапуск роутера или модема
Таблицы NAT (Network Address Translation) и инспекция пакетов с отслеживанием состояния на потребительских роутерах могут хранить устаревшие записи TCP-сессий, которые препятствуют завершению рукопожатия новых HTTP/2-соединений. Полный цикл отключения питания — а не просто программная перезагрузка — очищает эти таблицы.
- Полностью выключите роутер и модем.
- Подождите 60 секунд (не 30 — конденсаторам нужно время для полного разряда и очистки энергозависимого состояния).
- Сначала включите модем, дождитесь его полной синхронизации, затем включите роутер.
- Дождитесь полного подключения перед тестированием.
Исправление 8: Временное отключение антивируса или брандмауэра
Программное обеспечение безопасности с функциями сканирования HTTPS или веб-щита работает аналогично корпоративному прокси TLS-инспекции. Оно перехватывает TLS-рукопожатие, что может нарушить согласование сессии HTTP/2, если движок программного обеспечения безопасности не полностью поддерживает расширение ALPN или фреймирование HTTP/2.
Известные продукты, вызывающие эту проблему, включают Avast, AVG, Kaspersky и ESET при активных модулях веб-защиты.
- Временно отключите именно функцию Веб-щит или Сканирование HTTPS (а не весь антивирус).
- Проверьте проблемный URL.
- Если ошибка устранена, найдите опцию для добавления затронутого сайта в список исключений сканирования HTTPS, а не отключайте защиту глобально.
Исправление 9: Создание нового профиля Chrome
Повреждённый профиль пользователя Chrome — в частности, подпапка Network в директории профиля — может вызывать постоянную ERR_SPDY_PROTOCOL_ERROR, которая сохраняется после очистки кэша и сброса сокетов. Файл состояния сети профиля хранит данные HSTS, журналы прозрачности сертификатов и кэшированные результаты согласования протокола.
Тестирование с новым профилем:
- Перейдите по адресу
chrome://settings/ - Прокрутите до раздела Пользователи и нажмите Добавить пользователя (или Добавить профиль).
- Создайте минимальный тестовый профиль.
- Откройте проблемный URL в новом профиле.
Если URL загружается корректно в новом профиле, проблема изолирована в сохранённом состоянии сети исходного профиля. Вы можете вручную удалить папку Network из директории профиля, не потеряв закладки или пароли:
- Windows:
%LOCALAPPDATA%GoogleChromeUser DataDefaultNetwork - macOS:
~/Library/Application Support/Google/Chrome/Default/Network - Linux:
~/.config/google-chrome/Default/Network
Удалите папку Network при закрытом Chrome, затем перезапустите браузер.
Исправление 10: Диагностика и эскалация проблем на стороне сервера
Если все исправления на стороне клиента не помогают, ошибка возникает на сервере. Распространённые причины на стороне сервера включают:
- Истёкший или недавно перевыпущенный SSL/TLS-сертификат без перезапуска сервера для применения нового сертификата
- Неправильная конфигурация HTTP/2 в Nginx (директива
http2настроена неверно) или Apache (mod_http2загружен, ноProtocols h2 http/1.1настроен неправильно) - Неправильная конфигурация CDN или обратного прокси, при которой граничный узел и исходный сервер имеют конфликтующие настройки протокола
- Несоответствие версий TLS — например, сервер настроен на использование только TLS 1.3, тогда как промежуточный прокси поддерживает только TLS 1.2
Пример правильной конфигурации Nginx HTTP/2:
server {
listen 443 ssl;
http2 on;
ssl_certificate /etc/ssl/certs/your_domain.crt;
ssl_certificate_key /etc/ssl/private/your_domain.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
}Примечание: в Nginx 1.25.1+ http2 on заменяет устаревший синтаксис listen 443 ssl http2. Использование устаревшего синтаксиса в новых сборках может вызывать сбои согласования ALPN.
Пример правильной конфигурации Apache HTTP/2:
Protocols h2 http/1.1
SSLEngine on
SSLCertificateFile /etc/ssl/certs/your_domain.crt
SSLCertificateKeyFile /etc/ssl/private/your_domain.keyЕсли вы управляете собственной серверной инфраструктурой, обеспечение действительности, правильной цепочки и своевременного обновления SSL-сертификатов устраняет наиболее распространённую серверную причину этой ошибки. Хостинговые среды, работающие на должным образом обслуживаемом VPS-хостинге, предоставляют прямой доступ к файлам конфигурации сервера, что позволяет легко применять эти исправления без ожидания ответа от провайдера общего хостинга.
Для команд, запускающих веб-приложения на выделенных серверах, проверка правильности компиляции и включения mod_http2 или модуля HTTP/2 Nginx должна быть частью любого контрольного списка после развёртывания.
Диагностические инструменты для более быстрого определения первопричины
Прежде чем последовательно перебирать все исправления, используйте эти инструменты для сужения круга источников:
| Инструмент | Что диагностирует | Как получить доступ |
|---|---|---|
chrome://net-internals/#sockets | Активные и пулированные сессии сокетов | Адресная строка Chrome |
chrome://net-internals/#dns | Записи кэша DNS | Адресная строка Chrome |
chrome://net-internals/#hsts | Сохранённые политики HSTS по доменам | Адресная строка Chrome |
chrome://net-export/ | Полный экспорт сетевого журнала для глубокого анализа | Адресная строка Chrome |
| SSL Labs Server Test | Конфигурация TLS/сертификата сервера | ssllabs.com/ssltest |
| Wireshark | Инспекция TLS-рукопожатия на уровне пакетов | wireshark.org |
curl -v --http2 https://example.com | Согласование HTTP/2 из командной строки | Терминал |
Команда curl особенно полезна для подтверждения того, является ли проблема специфичной для браузера или общесерверной:
curl -v --http2 https://your-domain.com 2>&1 | grep -E "ALPN|HTTP|SSL|error"Если curl также не может согласовать HTTP/2, проблема определённо на стороне сервера. Если curl успешно выполняется, но Chrome даёт сбой, проблема в состоянии сессии браузера или локальном инструменте перехвата.
ERR_SPDY_PROTOCOL_ERROR и связанные сетевые ошибки Chrome
| Код ошибки | Основная причина | Первое исправление для применения |
|---|---|---|
ERR_SPDY_PROTOCOL_ERROR | Устаревшая сессия HTTP/2 или несоответствие ALPN | Очистить пулы сокетов |
ERR_HTTP2_PROTOCOL_ERROR | Нарушение фреймирования HTTP/2 сервером или прокси | Проверить конфигурацию HTTP/2 сервера |
ERR_SSL_PROTOCOL_ERROR | Сбой TLS-рукопожатия | Проверить действительность сертификата |
ERR_CONNECTION_RESET | TCP-соединение прервано в середине сессии | Перезапустить роутер, сбросить TCP/IP |
ERR_CERT_AUTHORITY_INVALID | Ненадёжный или самоподписанный сертификат | Проверить цепочку сертификатов |
ERR_QUIC_PROTOCOL_ERROR | Сбой сессии QUIC/HTTP3 | Отключить QUIC в флагах Chrome |
Для сайтов, где QUIC вызывает нестабильность, вы можете отключить его по адресу chrome://flags/#enable-quic, установив флаг в значение Disabled. Это заставит Chrome вернуться к HTTP/2 на основе TCP или HTTP/1.1.
Техническая матрица решений: какое исправление применить первым
Используйте эту матрицу для приоритизации устранения неполадок в зависимости от контекста, в котором появляется ошибка:
| Сценарий | Наиболее вероятная причина | Рекомендуемое первое действие |
|---|---|---|
| Ошибка только на одном конкретном сайте | Устаревшая сессия сокета или проблема на стороне сервера | Очистить пулы сокетов, затем проверить с curl |
| Ошибка на нескольких сайтах одновременно | Локальная сеть или повреждение профиля браузера | Сбросить TCP/IP, очистить DNS, перезапустить роутер |
| Ошибка только в Chrome, но не в других браузерах | Конфликт профиля Chrome или расширения | Проверить в режиме инкогнито, затем в новом профиле |
| Ошибка началась после обновления антивируса | TLS-инспекция нарушает HTTP/2 | Отключить сканирование HTTPS в антивирусе |
| Ошибка в корпоративной/офисной сети | Прокси или устройство SSL-инспекции | Обратиться к IT; запросить сквозную передачу HTTP/2 |
| Ошибка после обновления сертификата сервера | Сервер не перезагружен после смены сертификата | Перезагрузить процесс сервера (nginx -s reload) |
| Ошибка на самостоятельно управляемом VPS или сервере | Неправильная конфигурация модуля HTTP/2 | Проверить директивы HTTP/2 Nginx/Apache |
Если вы управляете собственным веб-сервером и вам нужна панель управления для упрощения управления SSL и протоколами, панели управления VPS предоставляют графические интерфейсы для установки сертификатов и настройки веб-сервера, снижающие риск ручных ошибок конфигурации. Для небольших проектов на общем веб-хостинге настройки протокола управляются на уровне инфраструктуры — обратитесь в службу поддержки, если вы подозреваете неправильную конфигурацию HTTP/2 на стороне сервера.
Контрольный список действий перед эскалацией
Выполняйте этот контрольный список по порядку. Остановитесь на шаге, который устраняет ошибку.
- [ ] Очистить пулы сокетов по адресу
chrome://net-internals/#sockets - [ ] Очистить кэш хостов DNS по адресу
chrome://net-internals/#dns - [ ] Удалить политику HSTS домена по адресу
chrome://net-internals/#hsts - [ ] Очистить весь кэш браузера и файлы cookie (Всё время)
- [ ] Проверить в режиме инкогнито для исключения расширений
- [ ] Проверить в другом браузере (Firefox, Edge) для исключения проблем, специфичных для Chrome
- [ ] Временно отключить сканирование HTTPS в антивирусе
- [ ] Отключить VPN или прокси
- [ ] Запустить
netsh winsock resetиipconfig /flushdnsот имени администратора - [ ] Выполнить полный цикл отключения питания роутера и модема (60-секундный полный разряд)
- [ ] Создать новый профиль Chrome и удалить папку
Networkиз старого профиля - [ ] Запустить
curl -v --http2 https://your-domain.comдля определения, является ли проблема серверной - [ ] Если проблема серверная: проверить действительность SSL-сертификата, конфигурацию модуля HTTP/2 и перезагрузить процесс сервера
- [ ] Обновить Chrome до последней стабильной сборки
Часто задаваемые вопросы
Что такое ERR_SPDY_PROTOCOL_ERROR и почему она всё ещё появляется, если SPDY устарел?
Внутренний сетевой стек Chrome унаследовал коды ошибок эпохи SPDY, которые так и не были переименованы. Теперь ошибка появляется при любом сбое в уровне сессии HTTP/2 или QUIC — включая сбои согласования ALPN, неудачные TLS-рукопожатия и устаревшие записи пула соединений — даже несмотря на то, что сам SPDY не использовался с Chrome 51.
Почему ошибка появляется только на одном сайте, но не на других?
Это почти всегда указывает либо на устаревшую сессию сокета Chrome, специфичную для этого домена, либо на проблему на стороне сервера на этом конкретном хосте — например, недавно перевыпущенный сертификат, аннулировавший существующие сессии, или неправильная конфигурация HTTP/2 на этом сервере. Очистка пулов сокетов и тестирование с curl --http2 подтвердят, что именно является причиной.
Может ли антивирусное программное обеспечение действительно вызывать ERR_SPDY_PROTOCOL_ERROR?
Да. Продукты безопасности, выполняющие HTTPS-инспекцию (Avast, AVG, Kaspersky, ESET и другие), действуют как TLS-прокси типа «человек посередине». Если их реализация HTTP/2 неполна или внедрённый ими сертификат не является доверенным в хранилище сертификатов Chrome, HTTP/2-сессия завершится сбоем именно с этой ошибкой. Отключение только компонента сканирования HTTPS — а не всего антивируса — является правильным точечным исправлением.
Как узнать, проблема на моей стороне или на стороне сервера?
Запустите curl -v --http2 https://your-domain.com из командной строки. Если curl также не может согласовать HTTP/2, сервер настроен неправильно. Если curl успешно выполняется, но Chrome даёт сбой, проблема локальная — либо устаревшая сессия Chrome, расширение, либо перехватывающий инструмент безопасности.
Влияет ли эта ошибка на SEO или производительность сайта?
Для конечных пользователей — да, ошибка полностью препятствует загрузке страницы. Для владельцев сайтов постоянная ERR_SPDY_PROTOCOL_ERROR, вызванная неправильной конфигурацией HTTP/2 на стороне сервера или истёкшим сертификатом, приведёт к неудачным попыткам сканирования Googlebot, что может негативно повлиять на охват сканирования и индексацию. Обеспечение действительности SSL-сертификата и правильности конфигурации HTTP/2 является базовым техническим требованием SEO.
