HTTP/2 не работает
устранение HTTP/2 · HTTP/2 не работает · сбой h2
Пошаговый порядок диагностики HTTP/2-сбоев из-за TLS, ALPN, редиректов, proxy или конфигурации сервера.
Автор: DN01 Network Team
Сбои HTTP/2 проще решать послойно, а не случайно переключать директивы веб-сервера. Надежнее всего проверять тот же публичный hostname, scheme и redirect path, по которому идут пользователи, поисковые роботы или API-клиенты. Значок protocol в одной вкладке браузера полезен, но он не доказывает, что все hostname, CDN edge и backend route согласуют тот же протокол.
Начните с публичного симптома, затем зафиксируйте DNS target, TLS certificate, ALPN negotiation, redirect chain, response headers и поведение proxy/CDN. В DN01 начинайте с HTTP/2 Tester на /ru/http2-tester и держите рядом HTTP Header Checker и SSL Certificate Checker. HTTP/2 согласуется через TLS и часто скрывается за редиректами или proxy, поэтому один сигнал редко объясняет весь сбой.
Эта статья входит в набор руководств по HTTP/2 Tester. Для соседних сценариев откройте /ru/articles/monitoring-http2-api и /ru/articles/proverka-http2-podderzhki, особенно если результат меняется во время deploy или миграции CDN.
Что проверить первым
Сначала запустите /ru/http2-tester, затем соберите TLS evidence в /ru/ssl-certificate-checker и redirects/cache evidence в /ru/http-header-checker. Используйте точный production hostname, а не удобный тестовый домен. Отдельно проверяйте apex, www, API, static assets и региональные hostnames, если TLS завершается в разных местах.
Проверьте финальный URL после редиректов. Сайт может перейти с HTTP/2-enabled hostname на legacy hostname или с современного CDN edge на origin path, который говорит только HTTP/1.1.
Фиксируйте время, target, финальный протокол и видимые TLS/header clues. Эти детали полезнее для incident review, чем скриншоты без контекста.
Как читать результат
Успешный h2 означает, что проверяемый клиент и публичный endpoint согласовали HTTP/2 для этого запроса. Это не доказывает автоматически, что каждый upstream hop, internal service или alternate hostname тоже использует HTTP/2.
HTTP/1.1 не всегда ошибка. Некоторые legacy clients, private origins, debugging endpoints и compatibility paths намеренно остаются на HTTP/1.1. Важно, совпадает ли результат с вашей архитектурой и ожиданиями пользователей.
Пропуск слоя тратит время: неверное имя в сертификате выглядит как h2-проблема, а CDN page rule может скрывать корректно настроенный origin. Поэтому проверка протокола должна жить рядом с TLS и header checks, а не в отдельной таблице без контекста.
Связанные проверки
Откройте /ru/ssl-certificate-checker, если результат указывает на TLS, certificate, SNI или ALPN. Покрытие hostname в сертификате и политика TLS listener часто объясняют неожиданный fallback.
Откройте /ru/http-header-checker, когда redirects, cache behavior, Via headers, Alt-Svc, HSTS или server headers могут объяснить различия между путями.
Для launch review держите /ru/http2-tester в runbook рядом с DNS, SSL и header checks, чтобы команда проверяла одну и ту же публичную поверхность до и после релиза.
Операционный чеклист
Меняйте по одной настройке, ждите deploy или cache propagation и повторяйте тот же target, чтобы before/after был честным. Не полагайтесь на один зеленый результат с локального ноутбука, если production traffic проходит через несколько регионов или провайдеров.
Проверяйте до изменения, сразу после rollout и еще раз после того, как CDN или DNS cache успели стабилизироваться. Если у провайдера региональные edges, сравните минимум две локации клиента или мониторинга.
Прикладывайте URL результата DN01 или скопированный вывод к тикету. Когда platform, security и frontend команды смотрят на одну evidence base, расследования HTTP/2 обычно становятся короче.
| Сигнал | Зачем он нужен |
|---|---|
| Negotiated protocol | Показывает, использовал ли запрос h2 или HTTP/1.1. |
| TLS и ALPN | Объясняет многие fallback до обмена HTTP-заголовками. |
| Redirect chain | Показывает смену протокола из-за canonical host или path rules. |
| Response headers | Дает clues по CDN, proxy, cache, HSTS и серверу. |
Частые вопросы
- HTTP/2 Tester заменяет browser devtools?
Нет. Он дает независимую внешнюю проверку, которой удобно делиться в тикетах. Для user-specific поведения используйте его вместе с devtools.
- Может ли сайт поддерживать HTTP/2 и все равно быть медленным?
Да. HTTP/2 снижает часть накладных расходов на соединения, но медленный origin, cache miss, тяжелые assets и blocking scripts могут оставаться главной причиной.
- Зачем дополнительно проверять SSL и headers?
Для большинства публичных сайтов HTTP/2 зависит от TLS negotiation, а headers и redirects часто показывают CDN или proxy behavior, который меняет финальный протокол.