HTTP/3 на Nginx: включаем QUIC на VDS, тестируем и откатываем без простоя

HTTP/3 на базе QUIC избавляется от голодания из‑за Head‑of‑Line блокировок TCP и заметно ускоряет первую отрисовку страниц, особенно на мобильных и нестабильных сетях. Но в продакшне важнее не цифры из бенчмарков, а план: как включить, как проверить и как безопасно откатить без простоя. Ниже — практический чек‑лист для админов: сборка Nginx с поддержкой HTTP/3, конфигурация TLS 1.3 и alt-svc, staged‑включение через отдельный порт, мониторинг и мгновенный rollback. Если нужен отдельный стенд — удобно поднять его на VDS.

Что даёт HTTP/3 и почему внедрять аккуратно

HTTP/3 работает поверх QUIC (UDP) и решает головную боль HTTP/2 на TCP: при потере пакета страдает только поток, а не всё соединение. Плюс быстрее соединяется за счёт сокращённого рукопожатия и встроенного шифрования (TLS 1.3). В реальном мире это означает меньше латентности, стабильнее загрузку на 4G/5G/Wi‑Fi и меньше «подвисаний» при перемещении клиента между сотами.

Главный риск — совместимость и инфраструктура: не все сети и межсетевые экраны одинаково любят UDP/443, а готовые пакеты Nginx часто не включают HTTP/3. Поэтому — staged rollout с возможностью мгновенного отката.

Предпосылки: окружение, ядро, фаервол

Минимальный набор для комфортного старта:

• Современная ОС (Debian 12/Ubuntu 22.04+), ядро 5.x с включённым UDP GRO/GSO (полезно для производительности).
• Открыт UDP/443 (или тестовый порт, например 8443) в системном файрволе и внешнем периметре. Важно: зачастую UDP по умолчанию закрыт.
• Актуальный сертификат и цепочка; HTTP/3 требует TLS 1.3. В конфиге Nginx будет ssl_protocols TLSv1.3;. Если сертификата нет — оформите SSL-сертификаты.
• Доступ к сборочным инструментам: поддержка HTTP/3 в «готовых» пакетах может отсутствовать, поэтому обычно компилируем Nginx со --with-http_v3_module и QUIC‑TLS.

Проверьте, поддерживает ли ваш curl HTTP/3 (нужны сборки с ngtcp2/nghttp3 или quiche). Это пригодится для тестов.

Два пути установки Nginx с HTTP/3

1) Компиляция Nginx с QUIC‑TLS (надёжный и предсказуемый)

Большинство дистрибутивных пакетов Nginx пока не включает HTTP/3 из‑за зависимости от реализаций TLS с QUIC. Практичный путь — собрать Nginx вручную, связав его с quictls (форк OpenSSL) или BoringSSL. Далее — общий план (подставьте актуальные версии):

apt update && apt install -y build-essential git cmake automake libtool \
  zlib1g-dev libpcre3-dev pkg-config curl ca-certificates

# Сборка quictls (OpenSSL с QUIC)
cd /usr/local/src
git clone --depth=1 https://github.com/quictls/openssl.git quictls
cd quictls
./config enable-tls1_3 enable-ktls no-shared
make -j$(nproc)
make install_sw

# Сборка Nginx с HTTP/3
cd /usr/local/src
curl -LO https://nginx.org/download/nginx-1.25.5.tar.gz
tar xf nginx-1.25.5.tar.gz
cd nginx-1.25.5
./configure \
  --prefix=/etc/nginx \
  --sbin-path=/usr/sbin/nginx \
  --conf-path=/etc/nginx/nginx.conf \
  --pid-path=/var/run/nginx.pid \
  --with-threads \
  --with-file-aio \
  --with-http_ssl_module \
  --with-http_v2_module \
  --with-http_v3_module \
  --with-stream_quic_module \
  --with-pcre-jit \
  --with-zlib=/usr \
  --with-openssl=/usr/local/src/quictls
make -j$(nproc)
make install

nginx -V | tr ' ' '\n' | grep -E 'http_v3|quic'

Обратите внимание на связку --with-openssl=/usr/local/src/quictls: так Nginx собирается против QUIC‑совместимого TLS. После инсталляции добавьте systemd‑юнит, если он вам нужен, или используйте свой способ управления сервисом.

2) Готовые сборки из сторонних репозиториев

Если вы находите репозиторий с Nginx, уже собранным с --with-http_v3_module и QUIC‑TLS — это ускоряет процесс. Однако внимательно проверяйте происхождение пакетов и доверяйте только проверенным источникам. Ключевой тест — nginx -V должен показывать флаги v3/quic.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Базовая конфигурация Nginx под HTTP/3

HTTP/3 работает через UDP, поэтому в server потребуется второй listen с параметром quic, плюс Alt-Svc для постепенной активации в браузерах. Также включаем TLS 1.3 и настраиваем шифры.

http {
    # Лог с индикатором negotiated протокола: $http3 покажет h3 при успехе
    log_format quic '$remote_addr - $host "$request" $status $body_bytes_sent '
                    '"$http_user_agent" proto=$server_protocol h3=$http3 tls=$ssl_protocol';
    access_log /var/log/nginx/access_quic.log quic;

    # Рекомендуется ограничить только TLS 1.3 для h3-виртуалов
    ssl_protocols TLSv1.3;
    ssl_ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

    server {
        server_name example.com;
        root /var/www/example;

        # Классика: HTTPS на TCP (HTTP/1.1 + HTTP/2)
        listen 443 ssl http2;
        # QUIC/HTTP/3 на UDP
        listen 443 quic reuseport;

        ssl_certificate     /etc/ssl/example/fullchain.pem;
        ssl_certificate_key /etc/ssl/example/privkey.pem;

        # Сообщаем клиентам, что доступен h3 на 443
        add_header Alt-Svc 'h3=":443"; ma=86400' always;
        add_header Strict-Transport-Security "max-age=31536000" always;

        # Опционально: минимальные хедеры для кеширования/безопасности
        add_header X-Content-Type-Options nosniff always;

        location / {
            try_files $uri $uri/ =404;
        }
    }
}

Ключевые моменты:

• listen 443 quic reuseport; — включает UDP‑листенер. reuseport улучшает масштабируемость на многоядерных системах.
• Alt-Svc — мягкий путь: клиент откроет сайт по привычному HTTPS, увидит alt-svc и попробует HTTP/3 при следующей загрузке или в параллельном соединении.
• $http3 в логе — простой индикатор: пусто при HTTP/1.1/2, «h3» при успешном QUIC.

Про HSTS и цепочку TLS — разбор здесь: 301, HSTS и SSL: нюансы внедрения.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Staged‑включение на отдельном порту (канареечный подход)

Чтобы не затрагивать продуктивный UDP/443, можно поднять HTTP/3 на 8443 и рекламировать его через Alt-Svc. Так клиенты начнут пробовать QUIC на 8443, а обычный трафик не пострадает.

server {
    server_name example.com;
    root /var/www/example;

    listen 443 ssl http2;              # стабильный HTTPS на TCP
    listen 8443 quic reuseport;        # тестовый QUIC на UDP

    ssl_certificate     /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;

    add_header Alt-Svc 'h3=":8443"; ma=300' always;  # короткий TTL для быстрой смены

    location / { try_files $uri $uri/ =404; }
}

Плюсы подхода: можно безопасно замерять долю успешных h3, отклик, ошибки рукопожатия, не трогая 443/UDP. Когда всё стабильно — переносим QUIC на 443 и увеличиваем ma. Про бесшовные релизы см. также: миграция без простоя.

Открываем UDP и проверяем сокеты

Не забудьте фаервол и периметр:

• Откройте UDP/443 (и/или тестовый UDP/8443) в ufw/iptables/ACL облака.
• Проверьте, что Nginx слушает порт:

ss -u -lpn | grep -E ':443|:8443'
# или
sudo tcpdump -i any udp port 443 -n

Локальные тесты: curl и заголовки

Проверяем HTTP/3 прямо с сервера или удалённой машины, где curl собран с поддержкой h3:

curl -I --http3 https://example.com/
# Строже: требовать только h3
curl -I --http3-only https://example.com/

# С портом канареечного стенда
curl -I --http3 https://example.com:8443/

В ответе ищите alt-svc, а в логах Nginx — поле h3=. Ещё удобнее добавить локацию‑индикатор:

location = /proto {
    add_header Content-Type text/plain;
    return 200 "proto=$server_protocol h3=$http3 tls=$ssl_protocol\n";
}

Запрос /proto сразу покажет, какой протокол согласован.

Наблюдаем и сравниваем производительность

Два простых приёма:

• Соберите выборку по логам: доля h3, коды ошибок, время ответа. Можно парсить access_quic.log по полю h3=.
• Сравните TTFB и загрузку «тяжёлых» страниц из сетей с высокой задержкой (мобильные, внешние регионы). На практике HTTP/3 часто выигрывает именно там.

Дополнительно можно померить падающие пакеты и ретрансмит в tcpdump и общее CPU‑потребление. Если ядро и NIC поддерживают GSO/GRO, включение QUIC GSO в Nginx (quic_gso, если доступна в вашей сборке) уменьшает нагрузку на CPU.

Перенос на 443 и увеличение доли трафика

Когда канареечный стенд стабилен, переносим HTTP/3 на 443 и увеличиваем TTL объявления:

1. Измените listen 8443 quic на listen 443 quic, Alt-Svc на 'h3=":443"; ma=86400'.
2. nginx -t, затем nginx -s reload. Релоад бесшовный.
3. Проконтролируйте долю h3 в логах и метриках.

Важно: даже если UDP где‑то блокируется, клиенты автоматически откатятся на HTTP/2/1.1 по TCP, так что доступность не пострадает.

Откат без простоя: что делать, если что‑то пошло не так

Иногда встречаются промежуточные устройства, которые «косо» обрабатывают UDP/443, либо рост ошибок рукопожатия на конкретном сегменте сети. Откатываемся по шагам:

1. Временно выключаем QUIC‑листенер: закомментируйте listen 443 quic (или 8443) и сделайте nginx -s reload. TCP‑HTTPS продолжит работать без паузы.
2. Сообщаем клиентам «забыть» про альтернативный сервис: выставьте add_header Alt-Svc 'clear' always; на 10–30 минут, затем верните стандартные заголовки. Альтернатива — ma=0 в Alt-Svc, но clear надёжнее очищает кэш альтернатив.
3. Оставьте UDP‑порт открытым ещё на короткое время — на случай, если у клиента закешировалось объявление — затем закрывайте его в файрволе.

Такой откат не требует перезапуска и не рвёт активные TCP‑соединения.

Тюнинг и безопасность

• quic_retry: включает валидацию адреса клиента до выделения состояния. Полезно против спуфинга, но добавляет 1 RTT на первое соединение. Включайте осознанно для публичных API.
• MTU: по умолчанию Nginx подбирает безопасный размер (в районе 1350). Если наблюдаете систематические потери в «капризных» сетях, можно снизить quic_mtu до ~1200 для диагностики.
• 0‑RTT: QUIC поддерживает ранние данные, но это зона повышенного внимания к повторному воспроизведению. Включайте только для идемпотентных методов и после анализа рисков.
• H3‑только? Не стоит. Держите HTTP/2/1.1 параллельно: это ваш safety net для сетей с фильтрацией UDP.

Типовые проблемы и как их ловить

• UDP закрыт: ss -u -lpn пуст, но TCP слушает. Проверьте UFW/iptables/ACL на стороне провайдера и маршрутизаторы.
• Клиент не переходит на h3: нет Alt-Svc или ma слишком мал. Проверьте, не кешируется ли заголовок прослойками.
• Старый curl/браузер: убедитесь, что инструменты поддерживают HTTP/3. Для curl это обычно сборки с ngtcp2+nghttp3.
• Потери и высокая латентность: включите BBR на хосте (net.ipv4.tcp_congestion_control=bbr не влияет напрямую на UDP, но система в целом выигрывает), проверьте перегрузки CPU и IRQ balancing.
• Сертификаты/цепочки: HTTP/3 требователен к корректной цепочке. Всегда указывайте fullchain.pem, а не только листовой сертификат.

Процедура «включить — проверить — расширить — откатить» в одном месте

1. Соберите Nginx с --with-http_v3_module и QUIC‑совместимым TLS. Проверьте nginx -V.
2. Откройте UDP/8443, настройте сервер с listen 8443 quic и Alt-Svc: h3=":8443" с малым ma. Релоад.
3. Тестируйте curl --http3, мониторьте $http3 в логах, собирайте ошибки.
4. Перенесите QUIC на 443, увеличьте ma до суток и шире. Релоад.
5. При проблемах мгновенно удалите listen ... quic, верните Alt-Svc: clear на короткое время, затем закройте UDP.

Такой подход даёт измеряемый эффект производительности, не рискуя доступностью. На практике постепенное включение через Alt-Svc и отдельный порт позволяет поймать «краевые случаи» в конкретных сетях и провайдерах до того, как вы прокатите HTTP/3 на весь трафик.

Итог

HTTP/3/QUIC для Nginx на VDS — уже рабочая история, если соблюдать дисциплину: собрать правильную связку TLS, включить UDP‑листенер, объявить alt-svc, замерить и только потом расширять охват. Ключ к безболезненному внедрению — staged раскат и простой rollback через удаление quic‑листенера и временный Alt-Svc: clear. В результате вы получаете ощутимое ускорение на сложных сетях без риска простоя и с полным контролем над обратной стороной — безопасным откатом.