Як виправити 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 продовжуватиме повторно використовувати зламану сесію, доки вона не буде явно очищена.

1. Відкрийте нову вкладку Chrome.
2. Перейдіть до chrome://net-internals/#sockets
3. Натисніть Flush socket pools.
4. Потім перейдіть до chrome://net-internals/#dns
5. Натисніть Clear host cache.
6. Закрийте вкладку та перезавантажте сторінку, що не працює.

Це двоетапне очищення одночасно очищає пул сесій транспортного рівня та кеш 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 або протоколу сервера.

1. Відкрийте Chrome і натисніть Ctrl+Shift+Delete (Windows/Linux) або Cmd+Shift+Delete (macOS).
2. Встановіть Часовий діапазон на Увесь час.
3. Позначте Файли cookie та інші дані сайтів і Кешовані зображення та файли.
4. Натисніть Видалити дані.

Для більш точного підходу — якщо ви хочете очистити дані лише для одного конкретного домену, не стираючи весь стан браузера — використовуйте наступне:

1. Перейдіть до chrome://settings/siteData
2. Знайдіть уражений домен.
3. Видаліть лише файли cookie та сховище цього сайту.

Крім того, очистіть стан HSTS для домену за адресою chrome://net-internals/#hsts, ввівши ім’я хоста в розділі Delete domain security policies. Застарілий запис HSTS може змусити Chrome використовувати шлях оновлення, що конфліктує з сервером, який змінив свою конфігурацію TLS.

Виправлення 3: Оновлення Google Chrome

Реалізації HTTP/2 та QUIC у Chrome отримують часті патчі. Використання застарілої збірки може означати, що ви маєте відомі помилки обробки протоколу, які вже були виправлені у вихідному коді.

1. Натисніть меню з трьома крапками та перейдіть до Довідка > Про Google Chrome.
2. Chrome автоматично перевірить наявність оновлень і завантажить їх.
3. Натисніть Перезапустити, щоб застосувати оновлення.

Щоб перевірити поточну версію з адресного рядка, перейдіть до chrome://version/. Звірте номер збірки з блогом Chrome Releases, щоб підтвердити, що ви використовуєте останній стабільний канал.

Виправлення 4: Вимкнення VPN, проксі та інструментів TLS-інспекції

VPN, корпоративні проксі та антивірусні продукти, що виконують глибоку інспекцію SSL/TLS (також відому як перехоплення HTTPS), є частою і недооціненою причиною ERR_SPDY_PROTOCOL_ERROR. Ці інструменти завершують TLS-з’єднання на клієнті, повторно шифрують його власним сертифікатом і пересилають на сервер. Якщо реалізація HTTP/2 інструменту є неповною або його ланцюжок сертифікатів не є довіреним, Chrome відхилить сесію.

Щоб вимкнути налаштування проксі у Windows:

1. Натисніть Win+I, щоб відкрити Параметри.
2. Перейдіть до Мережа та Інтернет > Проксі.
3. Встановіть Автоматично визначати параметри у положення Увімк., а Використовувати проксі-сервер — у положення Вимк.

Щоб вимкнути налаштування проксі через командний рядок:

netsh winhttp reset proxy

Щоб перевірити, чи активний зараз проксі:

netsh winhttp show proxy

Якщо ви перебуваєте в корпоративній мережі, проконсультуйтеся з вашим IT-адміністратором перед вимкненням налаштувань проксі, оскільки це може порушувати мережеву політику. Натомість запитайте, чи підтримує інструмент 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, викликаючи помилку протоколу.

Метод систематичної ізоляції:

1. Відкрийте chrome://extensions/
2. Вимкніть усі розширення одночасно.
3. Перезавантажте сторінку, що не працює.
4. Якщо помилка зникла, вмикайте розширення по одному, перезавантажуючи сторінку після кожного, доки не буде виявлено винуватця.

Крім того, відкрийте Chrome в режимі анонімного перегляду (Ctrl+Shift+N), який вимикає всі розширення за замовчуванням (якщо ви явно не дозволили їх в анонімному режимі). Якщо сторінка завантажується нормально в анонімному режимі, розширення є однозначною причиною.

Виправлення 7: Перезапуск маршрутизатора або модему

Таблиці NAT (Network Address Translation) та перевірка пакетів зі збереженням стану на споживчих маршрутизаторах можуть зберігати застарілі записи TCP-сесій, що перешкоджають завершенню рукостискання нових HTTP/2-з’єднань. Повне відключення живлення — а не просто програмне перезавантаження — очищає ці таблиці.

1. Повністю вимкніть маршрутизатор і модем.
2. Зачекайте 60 секунд (не 30 — конденсаторам потрібен час для повного розряду та очищення енергозалежного стану).
3. Спочатку увімкніть модем, дочекайтеся його повної синхронізації, потім увімкніть маршрутизатор.
4. Дочекайтеся повного з’єднання перед тестуванням.

Виправлення 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, журнали прозорості сертифікатів та кешовані результати узгодження протоколу.

Щоб перевірити з новим профілем:

1. Перейдіть до chrome://settings/
2. Прокрутіть до розділу Люди та натисніть Додати особу (або Додати профіль).
3. Створіть мінімальний тестовий профіль.
4. Відкрийте 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 має бути частиною будь-якого контрольного списку після розгортання.

Діагностичні інструменти для швидшого визначення першопричини

Перш ніж послідовно перебирати всі виправлення, використовуйте ці інструменти для звуження джерела:

Команда 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

Для сайтів, де QUIC спричиняє нестабільність, ви можете вимкнути його за адресою chrome://flags/#enable-quic, встановивши прапорець у положення Disabled. Це змушує Chrome повернутися до HTTP/2 на основі TCP або HTTP/1.1.

Технічна матриця рішень: яке виправлення застосувати першим

Використовуйте цю матрицю для пріоритизації усунення несправностей залежно від контексту, в якому з’являється помилка:

Якщо ви керуєте власним веб-сервером і потребуєте панелі керування для спрощення управління 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.