It's designed with almost everything encrypted so that middleboxes can't inspect the contents of packets and filter or change them. This is essential, as it's

It's designed with almost everything encrypted so that middleboxes can't inspect the contents of packets and filter or change them. This is essential, as it's been found that middleboxes now break almost every kind of experimental protocol that's not shielded in this way. So it's designed very much to resist ossification and allow protocol evolution. Still, some vendors are adapting to QUIC by blocking QUIC: https://www.fastvue.co/fastvue/blog/googles-quic-protocols-security-and-reporting-implications/ https://www.fastvue.co/fastvue/blog/googles-quic-protocols-s... Resolving the QUIC issue The good news is that if QUIC communication does not work between a client and a server, the traffic will fall back to traditional HTTP/HTTPS over TCP, where it can be inspected, controlled, logged and reported on as usual. At the time of writing, the advice from most firewall vendors is to block QUIC until support is officially added to their products. This recommended method will vary from firewall to firewall. Some firewalls allow QUIC by default while others block it by default, but all firewalls are able to allow or block it. It's not really true that everything QUIC falls back to HTTP/HTTPS, as there are non-HTTP applications running over QUIC too. That kind of blocking is going to cause pain to the people I know who are implementing QUIC-only products. But it's not a new problem. WebSockets doesn't work everywhere either, even UDP does not work everywhere. HTTP is also a problem because some middleboxes modify responses (even if you don't care about privacy that breaks applications). The strongest fallback I know of in practice is HTTPS, but some places block HTTPS or modify the certificates, and some filter on the HTTPS domain which is visible in the TLS negotiation.