Текущая ситуация по QUIC примерно такая.
Опробовано порядка 12 провайдеров в RU из разных городов.
На большинстве из них QUIC блокируется путем анализа SNI из расшифрованного QUIC initial.
Если SNI плохой, то блокируется stateful все udp “соединение”.
Анализируется только udp port 443.
Поскольку поведение у всех примерно одинаковое, то можно сказать, что блокирует ТСПУ.
Но тут есть важная оговорка. Модуль парсера кривой.
тут есть статический curl для x86_64 и arm с поддержкой nghttp3 (curl) и quiche (curlq)
Если попробовать этими 2 курлами подергать инстаграм, то видно, что curl виснет, а curlq прокатывает.
Так же firefox после пробивки TCP (чтобы он начал переходить на QUIC) спокойно берет http3, а chrome - только http2.
Можно проверить, загнав через ncat на свой VPS : блобы из zapret:files/fake. quic_initial_facebook_com.bin не доходит, а quic_initial_facebook_com_quiche.bin доходит.
То есть вывод, что парсер сечет chrome и nghttp3, но не сечет quiche и firefox.
Без обхода блокировок по TCP броузеры все равно не пойдут на QUIC, так что разницы практической мало.
Разблокируется через nfqws --fake.
Есть и исключение у провайдеров. Tiera, как обычно. Аплинк глобалнет продолжает полностью блокировать QUIC. Больше нет никаких подвисаний сессии. Тупо режут long header в обе стороны.