@its3am Я полностью понимаю твою озабоченность, и ты прав: в данный момент нет прямых метрик, которые бы показывали, что USG исчерпывает пространство NAT-сессий, и у меня нет логов, которые бы явно указывали на насыщение или падение. Моё наблюдение основано в основном на исключении и воспроизводимости:

Соединение работает отлично с сотовой сети или через "прозрачный" роутер ISP.

Проблема возникает только за USG 3P (firmware 4.4.57) и только с Safari. Отключение Alt-Svc или принудительное использование HTTP/2 сразу же делает сайт доступным снова, не меняя ничего на стороне клиента или сети.

Другие пользователи с аналогичными устройствами сообщали о том же поведении (например, в GitHub/Reddit тредах).

Я не утверждаю со всей уверенностью, что USG точно исчерпывает пространство NAT-сессий, но его обработка трафика через UDP/443 не кажется достаточно толерантной (или современной) для HTTP/3. Это, в свою очередь, плохо сочетается с поведением fallback в Safari, которое известно как хрупкое в этих случаях, особенно если добавить агрессивное кэширование Alt-Svc заголовков.

Конечно, ничто не мешает человеку, поднявшему проблему, протестировать это самому: просто подавить Alt-Svc на стороне сервера (или отключить HTTP/3) и посмотреть, работает ли Safari нормально снова. Это будет простой, но полезный тест, чтобы подтвердить или опровергнуть гипотезу.

@its3am Ты абсолютно прав, что USG не обязательно напрямую поддерживать QUIC: это протокол сетевого уровня приложений, и все, что нужно устройству вроде USG 3P – это корректно пересылать UDP-трафик на порту 443, что теоретически он вполне способен делать. Однако, на практике, устройства вроде USG 3P используют stateful NAT-фаервол, предназначенный в основном для TCP-трафика и, возможно, не всегда надежно обрабатывает постоянные или передовые UDP-соединения, такие как те, что основаны на QUIC (на котором основан HTTP/3). В таких случаях, даже если UDP/443-трафик пересылается, NAT/фаервол может вмешиваться нестандартными способами – например, преждевременно завершать сессии, некорректно обрабатывать таймауты или «выбрасывать» пакеты в неидеальных условиях сети. Это поведение не является проблемой для всех браузеров: Chrome, например, более устойчив и откатывается к HTTP/2, если соединение QUIC не удается. Safari, с другой стороны, как сообщил @JonathanMB, не всегда корректно откатывается, и в сочетании с агрессивным кэшированием Alt-Svc заголовков, может приводить к ситуациям, когда сайт просто не загружается, пока ты вручную не очистишь кэш. USG 3P не должен «поддерживать QUIC», но если его NAT/фаервол вмешивается в UDP/443 нестандартными или несовершенными способами, это может сломать HTTP/3. Поэтому, на данный момент, самым стабильным и надежным решением, если у тебя нет возможности обновиться до устройства с современной обработкой NAT/UDP (такого как UDM или UXG-Lite), является отключение HTTP/3 или подавление серверного Alt-Svc заголовка.

@Alex7021 А зачем вообще правительству США поддержка QUIC? Им нужно только пересылать 443/udp, а это они и так прекрасно умеют.