QUIC connections are always encrypted and authenticated, so they should work just fine with a CONNECT-style proxy that supports UDP. (I don't know for sure; I'm just reasoning from first principles.)

EDIT: after thinking a few minutes, I'm not sure a "UDP proxy" is a meaningful concept except in very limited circumstances such as forwarding only to a single destination, because there's no connection to establish that a proxy server could know anything about. Maybe proxy servers don't have a place in a QUIC world.

Do you mean forward proxies? The HTTP/3 draft currently specifies how the CONNECT method is used. At present, it only allows you to create an onward TCP connection. So you have a QUIC connection between client and proxy, and a TCP connection between proxy and server. Like so

        QUIC         TCP

client <----> proxy <----> server

Unfortuantely, this means that a HTTP/3 client has to tunnel HTTP/1.1 or HTTP/2 to the target server. I realised this was a shortcoming last year and prepared an I-D called HiNT that explores the problem space and some candidate solutions:

https://datatracker.ietf.org/doc/draft-pardue-httpbis-http-n...

This was presented, along with some nicer tunnel diagrams, at the IETF 102 meeting. Slides in pdf: https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102...

Could be client HTTP/3 --> proxy HTTP/1 --> backend

gcloud load balancer docs: https://cloud.google.com/load-balancing/docs/https/#QUIC