ERR_HTTP2_PROTOCOL_ERROR: где ломается HTTP/2 и как найти причину

Ошибка ERR_HTTP2_PROTOCOL_ERROR означает, что браузер не смог корректно завершить обмен данными по HTTP/2. Это не готовый диагноз и не указание на единственную неисправность: одинаковое сообщение может появиться из-за ответа веб-сервера, reverse proxy, CDN, слишком больших заголовков или обрыва отдельного потока. Ниже — последовательность проверки, которая помогает локализовать сбой, не сводя его автоматически к SSL или блокировке.

Что означает ERR_HTTP2_PROTOCOL_ERROR

При открытии HTTPS-страницы клиент и сервер согласуют прикладной протокол. Если выбран HTTP/2, браузер получает заголовки и тело ответа внутри потоков одного соединения. Когда структура обмена нарушается, поток неожиданно сбрасывается или ответ заканчивается не так, как ожидает клиент, браузер может показать ERR_HTTP2_PROTOCOL_ERROR.

Важно разделять три факта:

• домен мог успешно разрешиться в IP-адрес;
• TLS-соединение и сертификат могли пройти проверку;
• ошибка могла возникнуть позже, уже при передаче HTTP/2-ответа.

Поэтому замена сертификата наугад обычно не помогает. Сначала нужно выяснить, воспроизводится ли проблема именно на HTTP/2, на каком URL и на каком участке между браузером и приложением.

Сначала определите масштаб сбоя

Начните с точного адреса, на котором появилась ошибка. Главная страница и, например, /catalog/item/ могут проходить через разные правила кеша, обработчики и upstream-сервисы.

Что проверить в браузере

Перезагрузите страницу, запишите время ошибки и откройте тот же URL в другом актуальном браузере, приватном окне и через другую сеть. В панели Network посмотрите, падает ли основной документ или отдельный API, JavaScript-файл либо изображение. Очистка кеша и отключение расширений полезны только как диагностический тест: они не исправляют сервер.

Владельцу сайта нужны URL целиком, время с часовым поясом, браузер и последовательность действий. Разовую внешнюю диагностику можно начать через проверку сайта Web-Puls: отчет показывает HTTP-код, редиректы, DNS, TLS и сведения об HTTP/2. Один успешный результат не исключает плавающий сбой, поэтому сравните его с моментом ошибки.

Сравните HTTP/1.1 и HTTP/2

Один из самых полезных тестов — запросить одинаковый URL по двум версиям протокола. Для этого подходит curl, если его сборка поддерживает HTTP/2. Возможности клиента видны в выводе curl --version.

curl -v --http2 https://example.com/problem-page -o /dev/null
curl -v --http1.1 https://example.com/problem-page -o /dev/null

Замените пример своим точным URL. Ключ -v выводит служебные сведения, поэтому перед передачей результата другому человеку проверьте, нет ли в нем cookie, токенов или других секретных заголовков.

Результаты нужно трактовать осторожно:

• HTTP/1.1 работает, а HTTP/2 стабильно завершается ошибкой — круг поиска сужается до обработки HTTP/2 на CDN, proxy или веб-сервере;
• обе версии не работают — вероятна более общая проблема приложения, сети или конфигурации;
• командная проверка проходит, а браузер падает — сравните заголовки, cookie, редиректы и конкретный ресурс, который запрашивает браузер;
• ошибка возникает не каждый раз — ищите различия между узлами балансировки и сопоставляйте запросы по времени.

Само различие между HTTP/1.1 и HTTP/2 еще не называет виновника. Например, браузер может общаться по HTTP/2 с CDN, а CDN — по HTTP/1.1 с origin-сервером. Нужно отдельно проверить каждый доступный слой.

Где чаще всего ломается HTTP/2

Слишком большие или некорректные заголовки

Размер заголовков растет из-за cookie, длинных политик безопасности, множества служебных полей или цепочки proxy. Особенно показателен сценарий, когда страница открывается для нового посетителя, но перестает работать после авторизации: к запросу добавляются cookie, и он может выйти за лимит одного из компонентов.

Сравните запрос в приватном окне и в обычной сессии. На сервере проверьте лимиты заголовков последовательно у CDN, reverse proxy, веб-сервера и приложения. Не увеличивайте их вслепую: сначала выясните, какие поля занимают место и действительно ли они нужны.

HTTP/2 предъявляет правила к представлению заголовков, а промежуточные серверы преобразуют их при переходе между версиями протокола. Ошибки преобразования, дублирование несовместимых полей или нестандартный модуль могут привести к сбросу потока. Фактическую причину в этом случае обычно видно в error log компонента, который закрыл соединение.

Обрыв ответа или сброс потока

Браузер может получить начало страницы, а затем потерять поток. Такое происходит, если upstream-процесс аварийно завершился, proxy превысил таймаут, один узел балансировщика разорвал соединение или CDN не смог дочитать ответ origin-сервера.

Проверьте, совпадает ли ошибка с определенной динамической страницей или большим ответом. Сравните маленький статический файл, главную страницу и проблемный URL. Если статика отдается стабильно, а один обработчик обрывается, логи приложения и upstream важнее общих настроек HTTP/2.

CDN, reverse proxy и балансировщик

Каждый промежуточный слой может завершать одно соединение и создавать другое. Поэтому надпись HTTP/2 в браузере подтверждает протокол только на участке до ближайшего узла, но не между CDN и сервером приложения.

Если ошибка появилась после подключения CDN, смены proxy или обновления конфигурации, сравните рабочую и текущую версии настроек. Проверяйте origin только в контролируемой среде, с правильными Host и SNI, не публикуя служебный IP.

Сжатие и длина ответа

Не смешивайте сжатие заголовков HTTP/2 и сжатие тела страницы через gzip или Brotli. Проблема может возникнуть при повторном сжатии на нескольких слоях, неверной длине ответа или обрыве уже сжатого тела. При этом браузер иногда показывает более узкую ошибку декодирования, а иногда сбой выглядит как нарушение протокола.

Сравните заголовки content-encoding и content-length на CDN и origin, затем временно изменяйте по одному параметру на тестовом контуре. Не отключайте оптимизации на production без контрольного сравнения: иначе будет трудно понять, какое изменение повлияло на результат.

Несовместимая конфигурация веб-сервера

После обновления веб-сервера, TLS-библиотеки, HTTP-модуля или proxy старые параметры могут оказаться несовместимыми. Проверьте конфигурацию штатным инструментом и изучите error log. Для Nginx, Apache и CDN настройки различаются, поэтому сверяйте решение с версией своего ПО и официальной документацией.

Практические сценарии диагностики

Ошибка только после входа в личный кабинет

В приватном окне страница работает, а в авторизованной сессии падает. Сначала сравните размер и состав cookie, затем лимиты заголовков на всей цепочке. Удаление cookie у пользователя временно скрывает симптом, но владельцу сайта нужно уменьшить лишние данные или согласовать лимиты компонентов.

Главная работает, а API-запрос обрывается

HTML загрузился, но в Network красным отмечен запрос /api/.... Скопируйте URL, время и идентификатор запроса, если он есть. Проверьте этот endpoint отдельно по HTTP/1.1 и HTTP/2, после чего сопоставьте событие с логами proxy и приложения. Общая проверка главной страницы такой сбой не воспроизведет.

Какие логи собрать

Ищите событие одновременно на нескольких уровнях:

• журнал CDN или WAF;
• access log и error log reverse proxy;
• журнал веб-сервера;
• логи приложения и upstream-сервиса;
• сведения браузера о проблемном запросе.

Полезны точное время, URL, метод, полученный статус, длительность, размер ответа и request ID. В журналах обращайте внимание на сообщения о сбросе потока, преждевременном закрытии соединения, ошибке upstream и превышении лимита заголовков. Названия сообщений зависят от продукта, поэтому не подменяйте реальный лог догадкой по тексту браузера.

Перед отправкой логов в поддержку удалите пароли, cookie, токены, персональные данные и секретные параметры URL. Если request ID уже связывает события, полный набор пользовательских заголовков обычно не нужен.

Порядок исправления без хаотичных изменений

1. Зафиксируйте точный URL, время и ресурс, на котором произошла ошибка.
2. Повторите запрос из другого браузера и сети.
3. Сравните один URL по HTTP/1.1 и HTTP/2.
4. Определите, где завершается HTTP/2: на CDN, proxy или самом веб-сервере.
5. Сопоставьте запрос с логами всех доступных слоев.
6. Проверьте заголовки, cookie, сжатие, таймауты и стабильность upstream.
7. Воспроизведите предполагаемое исправление на тестовом контуре.
8. После изменения повторите исходный сценарий несколько раз и оставьте наблюдение включенным.

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

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

ERR_HTTP2_PROTOCOL_ERROR может исчезнуть после перезагрузки и вернуться на другом узле. Регулярный мониторинг не заменяет логи, зато помогает установить, когда URL перестал отвечать и насколько стабилен результат. В Web-Puls можно проверять критичные публичные URL автоматически. Для страниц после авторизации нужен отдельный функциональный тест: обычная проверка URL не воспроизводит пользовательский сценарий.

Вывод

При ERR_HTTP2_PROTOCOL_ERROR не стоит сразу менять SSL-сертификат, отключать HTTP/2 или обвинять CDN. Сначала найдите точный запрос, сравните HTTP/1.1 и HTTP/2, определите границу протокола и сопоставьте сбой с логами. Такой порядок превращает общее сообщение браузера в проверяемую гипотезу и помогает исправить причину, а не временно скрыть симптом.