HTTP/3 и QUIC на сервере: частые ошибки и решения

MAATRIX

Вы включили HTTP/3, добавили listen quic и заголовок Alt-Svc, а браузер упорно грузит сайт по HTTP/2, curl не видит h3, и непонятно, что не так. HTTP/3 и QUIC на сервере действительно требуют внимания к деталям: новый транспорт на UDP всплывает там, где раньше всё решал TCP. Разберём частые ошибки по схеме «симптом — причина — решение».

Как проверить, что именно не работает

Первым делом определите, на каком этапе обрыв: не собран QUIC, не слушается порт, не открыт фаервол или не отдаётся Alt-Svc. Начните с самой сборки Nginx — без модуля HTTP/3 всё остальное бессмысленно:

nginx -V 2>&1 | grep -o with-http_v3_module

Затем проверьте, слушает ли Nginx UDP-порт 443. Это ключевой признак того, что QUIC вообще поднялся:

ss -ulnp | grep :443

И, наконец, посмотрите, что реально отвечает сервер, свежим curl с поддержкой HTTP/3:

curl -I --http3 https://example.com

Эти три команды локализуют проблему за минуту. Нет модуля — вопрос к сборке. Модуль есть, но UDP-порт не слушается — вопрос к конфигу. Порт слушается локально, но снаружи h3 не виден — почти всегда закрытый UDP на фаерволе. Дальше разберём каждый случай.

Сборка Nginx без поддержки QUIC

Самая обидная ошибка, потому что конфиг выглядит правильным, а HTTP/3 не работает в принципе. Причина в том, что обычные пакеты Nginx из репозитория дистрибутива часто собраны без модуля http_v3. Директива listen 443 quic в таком Nginx либо игнорируется, либо роняет старт с ошибкой неизвестного параметра.

Проверка одна:

nginx -V 2>&1 | tr ' ' '\n' | grep http_v3

Пустой вывод означает, что QUIC в этой сборке нет. Решение — поставить пакет из официального mainline-репозитория Nginx, где поддержка QUIC включена:

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/mainline/ubuntu $(lsb_release -cs) nginx" > /etc/apt/sources.list.d/nginx.list
apt update && apt install nginx -y

После обновления снова проверьте наличие модуля. Если даже mainline-пакет для вашей платформы без QUIC, остаётся ручная сборка с TLS-библиотекой, поддерживающей QUIC, — но это редкий случай, обычно mainline закрывает вопрос.

Закрытый UDP-порт: главная причина «не работает снаружи»

Классика: локально curl --http3 с самого сервера отдаёт h3, а из интернета HTTP/3 недоступен, браузеры сидят на HTTP/2. В девяти случаях из десяти виноват закрытый UDP-порт. QUIC ходит по UDP 443, а привычное правило фаервола открывает TCP 443 — для UDP оно не действует.

Откройте именно UDP:

ufw allow 443/udp
ufw reload
ufw status | grep 443

Но системный фаервол — только половина дела. У многих провайдеров поверх него есть облачный фаервол или сетевой фильтр, и правило TCP 443 там тоже не покрывает UDP. Это самая частая скрытая причина: локально всё открыто, а внешний фильтр молча режет UDP. Проверьте настройки сетевой безопасности в панели провайдера и убедитесь, что UDP 443 разрешён. Если панель фаервола недоступна или режет UDP без объяснений, это повод выбрать площадку, где сеть под вашим контролем, — например VPS с чистым IP и открытым управлением фаерволом у MAATRIX, с оплатой из России картой или криптой.

Браузер не переключается на HTTP/3

Симптом мягче предыдущих: h3 доступен, curl его видит, но браузер грузит сайт по HTTP/2 и не спешит переходить. Здесь важно понимать механику QUIC. Браузер не знает заранее, что сервер умеет HTTP/3 — он узнаёт это из заголовка Alt-Svc, который приходит по первому TCP-соединению. Поэтому самая первая загрузка всегда идёт по HTTP/2, и только последующие браузер пробует по QUIC.

Важно не путать это с поломкой: пока браузер работает по HTTP/2, сайт полностью функционален, просто без ускорения QUIC. Поэтому переход на HTTP/3 никогда не ломает доступность — в худшем случае клиент остаётся на проверенном TCP. Это делает включение h3 безопасным экспериментом: вы ничем не рискуете, а поддерживающие клиенты получают выигрыш. Но если задача именно убедиться, что HTTP/3 реально задействован, нужно смотреть на второй и последующие запросы, а не на первый.

Первое, что проверить, — отдаётся ли заголовок:

curl -sI https://example.com | grep -i alt-svc

Должна быть строка вида alt-svc: h3=":443"; ma=86400. Если её нет, добавьте add_header Alt-Svc 'h3=":443"; ma=86400'; в серверный блок и перезагрузите Nginx. Если заголовок есть, но браузер всё равно на HTTP/2 — проверьте, что смотрите на повторную загрузку, а не на первый заход, и что HTTP/3 не отключён в настройках браузера. Ещё одна тонкая причина — несоответствие порта в Alt-Svc реальному порту QUIC: если QUIC слушает нестандартный порт, он должен быть указан в заголовке.

Alt-Svc, reuseport и конфликты конфига

Отдельная группа ошибок связана с самим конфигом. Частая — параметр reuseport в директиве listen ... quic указан в нескольких серверных блоках сразу. Он допустим только один раз на адрес и порт, иначе Nginx откажется стартовать с ошибкой о дублировании. Решение — оставить reuseport лишь в одном блоке, слушающем QUIC на этом порту.

Вторая частая проблема — рассинхрон сертификатов. HTTP/3 работает только по TLS 1.3, и если сертификат или его цепочка настроены неверно, QUIC-соединение не устанавливается, хотя TCP-версия по HTTP/2 продолжает работать. Проверяйте валидность и сборку конфига перед каждым перезапуском:

nginx -t && systemctl reload nginx

Третья — забытый http2 on рядом с QUIC. HTTP/3 не отменяет HTTP/2: старые клиенты и первое соединение идут по TCP, поэтому HTTP/2 должен оставаться включённым как основной путь. Отключив его вместе с переходом на h3, вы ухудшите совместимость. Правильная конфигурация держит оба: TCP с HTTP/2 как база и QUIC с HTTP/3 как ускорение для поддерживающих клиентов.

Нестабильный HTTP/3 и когда дело в сети

Иногда HTTP/3 работает, но нестабильно: то подключается, то откатывается на HTTP/2, скорость скачет. Часто это не ошибка конфигурации, а свойство сети между клиентом и сервером. Некоторые провайдеры и корпоративные сети агрессивно фильтруют или ограничивают UDP, считая его менее приоритетным, чем TCP. В такой сети QUIC будет то проходить, то нет, и браузер честно откатывается на TCP.

Проверить стабильность можно повторными запросами и замером времени соединения:

curl -w "%{http_version} %{time_connect}\n" -o /dev/null -s --http3 https://example.com

Если время подключения по QUIC скачет или соединение периодически падает на HTTP/2, а сам сервер в порядке, узкое место — в сетевом пути, и полностью его контролировать вы не можете. Что в ваших силах — обеспечить качественный канал и чистый IP на своей стороне: перегруженный сервер с плохой сетью усугубляет любые проблемы UDP. Убедитесь, что ресурсов достаточно, а сеть стабильна; на адекватной площадке HTTP/3 ведёт себя предсказуемо, а откат на HTTP/2 остаётся редким запасным сценарием, а не постоянным режимом.

Частые вопросы