← Speed / speed / optimization / protocol / troubleshooting

Устранение проблем с протоколом

В этом руководстве рассматриваются распространенные проблемы HTTP/2 и HTTP/3, включая несовместимость origin-сервера, ошибки мультиплексирования и ошибки браузера, а также приводятся шаги по их диагностике и устранению.

H2 до источника: несовместимость источника

Источника max_concurrent_streams согласовывается в процессе установления соединения.
Если GOAWAY(0) получен, это, вероятно, вызвано перезапуском сервера или другой причиной, из-за которой сервер отказывается принимать новые потоки.
Подробнее см. в RFC 9113 - SETTINGS_MAX_CONCURRENT_STREAMS ↗.

Мультиплексирование H2: несовместимость или проблемы на стороне источника

Проблемы с мультиплексированием могут возникать из-за неправильной настройки сервера.
Используйте netlogs ↗ , чтобы определить SETTINGS_MAX_CONCURRENT_STREAMS нарушения или неожиданные GOAWAY кадров.
Подробнее см. в Проблемы конкурентности потоков (stream concurrency) ↗.

Типичные ошибки браузера

Распространённые ошибки браузера включают:

ERR_HTTP2_PROTOCOL_ERROR
ERR_HTTP3_PROTOCOL_ERROR
ERR_QUIC_PROTOCOL_ERROR

Эти ошибки не всегда указывают на проблему на уровне протокола. Выполните следующие действия:

Попробуйте воспроизвести проблему с использованием HTTP/1.1.
Если проблема сохраняется в HTTP/1.1, устраните основную ошибку, прежде чем тестировать HTTP/2 или HTTP/3.
Если проблема не повторяется, проанализируйте netlogs на наличие проблем, характерных для HTTP/2 или HTTP/3.

Подробнее см. в Заголовок URL-запроса Chromium ↗.

Chrome зависает или завершается ошибкой только при использовании HTTP/3

Если проблема воспроизводится только в Chrome через HTTP/3 и исчезает при отключении HTTP/3, причина может быть в обработке QUIC на стороне браузера, а не в исходном сервере. Это известная проблема Chrome (crbug.com/41161335 ↗) : реализация QUIC в Cloudflare здесь ни при чём.

Возможные симптомы:

Крупные загрузки неожиданно останавливаются.
Страницы с большим количеством одновременных запросов зависают на одну-три минуты, а затем выдают ошибку.
Chrome сообщает ERR_QUIC_PROTOCOL_ERROR или ERR_HTTP3_PROTOCOL_ERROR после того как соединение перестает продвигаться.
Проблема не воспроизводится в Firefox или Safari.
Проблема устраняется после отключения QUIC в chrome://flags.

Как локализовать проблему

Временно отключите HTTP/3 для зоны.
Повторите тот же запрос через HTTP/2.
Если проблема исчезает при использовании HTTP/2, запишите NetLog для Chrome и сравните поведение.

Проверьте немедленно: В Chrome перейдите в chrome://flags, найдите "QUIC" и установите значение Отключено, затем перезапустите Chrome.

Решение

Если проблема ограничена конкретными именами хостов, можно применить более точечное решение: создайте Response Header Modification Transform Rule, чтобы удалить Alt-Svc заголовок для затронутого имени хоста.

В панели управления Cloudflare перейдите в раздел Rules Обзор страницу.
Выберите Создать правило > Response Header Transform Rule.
Задайте выражение соответствия по вашему имени хоста: (http.host eq "example.com").
В разделе Изменение заголовка ответа, выберите Удалить и введите Alt-Svc в качестве имени заголовка.

Это заставляет Chrome использовать HTTP/2 для данного хоста без глобального отключения HTTP/3. Однако проксируемые хосты могут также анонсировать HTTP/3 через сгенерированные HTTPS-записи, поэтому для надежного перехода на HTTP/2 во время диагностики лучше отключить HTTP/3 для всей зоны.

После изменения Alt-Svc, учитывайте, что браузеры могут кэшировать анонсированный альтернативный сервис на срок до 24 часов.