HTTP/2 в Nginx, Apache и Caddy
nginx HTTP/2 config · Apache HTTP/2 config · Caddy HTTP/2 проверка
На что смотреть в конфигурации Nginx, Apache и Caddy при включении HTTP/2.
Автор: DN01 Network Team
Nginx, Apache и Caddy включают HTTP/2 через разные настройки, но production-чеклист одинаков: TLS listener, ALPN, hostname, proxy path и внешняя проверка после reload. Надежнее всего проверять тот же публичный hostname, scheme и redirect path, по которому идут пользователи, поисковые роботы или API-клиенты. Значок protocol в одной вкладке браузера полезен, но он не доказывает, что все hostname, CDN edge и backend route согласуют тот же протокол.
Практичная проверка подтверждает публичный протокол после deploy, затем сверяет headers, certificate chain, redirects и cache behavior снаружи. В DN01 начинайте с HTTP/2 Tester на /ru/http2-tester и держите рядом HTTP Header Checker и SSL Certificate Checker. HTTP/2 согласуется через TLS и часто скрывается за редиректами или proxy, поэтому один сигнал редко объясняет весь сбой.
Эта статья входит в набор руководств по HTTP/2 Tester. Для соседних сценариев откройте /ru/articles/http2-seo-i-proizvoditelnost и /ru/articles/ustranenie-sboev-http2, особенно если результат меняется во время deploy или миграции CDN.
Что проверить первым
После изменения конфига запустите /ru/http2-tester и рядом проверьте тот же hostname через /ru/ssl-certificate-checker и /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. Важно, совпадает ли результат с вашей архитектурой и ожиданиями пользователей.
Конфиг может выглядеть правильным локально, пока managed load balancer, container ingress или старый virtual host отдает публичный hostname по HTTP/1.1. Поэтому проверка протокола должна жить рядом с 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, чтобы команда проверяла одну и ту же публичную поверхность до и после релиза.
Операционный чеклист
Ведите отдельные заметки по virtual host, особенно если apex, www, admin и API завершают TLS в разных местах. Не полагайтесь на один зеленый результат с локального ноутбука, если 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, который меняет финальный протокол.