An HTTP/3 Request Needs a UDP-Capable Proxy Path
Distinguish HTTP/3's QUIC transport from ordinary HTTP CONNECT TCP tunnels and from a SOCKS5 service's optional UDP support.
A client that successfully reaches HTTPS through a TCP proxy has not established a route for HTTP/3. HTTP/3 uses QUIC, and QUIC uses UDP.
An ordinary HTTP CONNECT tunnel provides a TCP stream to its destination. It does not turn into a UDP relay when the URL begins with HTTPS or the destination listens on port 443.
SOCKS5 needs the UDP path too
SOCKS5 defines UDP association, but both the client and server must implement it, and the relay endpoint must be reachable. A library exposing only a SOCKS TCP dialer cannot supply a datagram transport merely because its type name says SOCKS5.
Likewise, a tool's component named proxy might be a development packet-loss simulator rather than a general upstream-proxy client. Inspect its actual interface and supported transport.
Standards such as CONNECT-UDP define another way to carry UDP through an HTTP proxy system. They require support on both ends and should not be confused with traditional CONNECT.
If the HTTP client falls back to HTTP/2 or HTTP/1.1 over TCP, a request can succeed through the ordinary proxy while no HTTP/3 connection was used. Record the negotiated protocol when that distinction matters.
The useful compatibility question is therefore specific: can this client carry its QUIC datagrams through this proxy using this supported mechanism? A working browser page or a TCP port check answers a smaller question.