A proxy test that only opens an HTTPS page cannot establish UDP support. The application may use TCP, fall back from HTTP/3, or apply its proxy setting to only part of its traffic. Diagnose the client, relay and destination as separate parts of the path.

SOCKS5 control connection and separate UDP relay path.

UDP, QUIC and HTTP/3 have different jobs

TCP supplies an ordered stream of bytes and handles retransmission when data is lost. UDP sends separate messages, called datagrams, without providing those delivery and ordering guarantees itself. Software using UDP decides how to deal with missing, late or duplicate messages.

That makes UDP useful for applications with different priorities. A live voice application may prefer the next audio packet to a delayed replacement of an old one. A game can send frequent state updates. DNS can use a short request and response. These examples do not mean that every call, game or DNS lookup always uses UDP; the actual application can have several transports and fallback modes.

QUIC runs over UDP and adds its own connection management, loss recovery, congestion control and secure communication. Its reliable streams can carry a complete webpage or file. Using UDP does not make QUIC an unreliable file-transfer protocol. Reliability is supplied at a different level.

HTTP/3 is HTTP carried over QUIC. HTTP/1.1 and HTTP/2 ordinarily use TCP. An HTTPS address can therefore be reached using different transports; the https:// prefix alone does not tell you which one was used. Supporting HTTPS websites and supporting HTTP/3 are separate claims.

UDP itself also provides no encryption. QUIC protects application data using TLS 1.3, while another protocol using UDP may have different protection or none. Forwarding a datagram and protecting its contents are separate functions.

How SOCKS5 forwards UDP

SOCKS5 uses a TCP connection to arrange UDP forwarding. That TCP connection stays open, but the UDP payload travels separately. The arrangement works as follows:

  1. Open the control connection. The client reaches the SOCKS5 endpoint over TCP and completes any required authentication.
  2. Request a UDP relay. It sends UDP ASSOCIATE. The proxy replies with the relay address and UDP port the client should use.
  3. Send datagrams to the relay. The client adds a SOCKS header containing the destination address and port. The relay forwards the payload and returns replies with the corresponding SOCKS framing.
  4. Keep the control connection open. Closing it ends the UDP association, even if the application still wants to send datagrams.

The returned relay endpoint is not necessarily the proxy's TCP listening endpoint. Sending raw UDP to the usual SOCKS port is not a substitute for this exchange. A client that only implements SOCKS CONNECT can establish TCP connections but cannot perform this UDP forwarding procedure.

Consider a company network that permits TCP to the proxy but blocks the separate UDP relay path. Authentication can succeed while no application datagrams get through. Replacing a correct password or selecting another website will not address that restriction; the missing part is access to the relay path.

Remote DNS for a SOCKS TCP connection is a different operation. Passing a hostname to the proxy for resolution does not exercise the application's UDP relay. A successful hostname lookup cannot replace a UDP test.

TCP setup can succeed even when the separate UDP path to the negotiated relay is blocked.

UDP forwarding through HTTP proxies

An ordinary HTTP CONNECT tunnel carries a byte stream to a TCP destination. It does not provide UDP forwarding. Encrypting the connection to the proxy does not change that, and specifying destination port 443 does not turn a TCP tunnel into a UDP tunnel.

HTTP can carry UDP when both sides implement a separate UDP tunneling facility, commonly called CONNECT-UDP, from the MASQUE family of mechanisms. The client identifies a UDP destination, establishes the tunnel and exchanges datagrams through it. The proxy sends those payloads onward over UDP and carries replies back. This is an additional capability, not something every HTTP or HTTPS proxy already provides.

The transport used between the client and the proxy matters too. HTTP/3 can carry HTTP Datagrams in QUIC DATAGRAM frames. The Capsule Protocol also allows datagrams to be carried in a reliable stream, including with HTTP/2 over TCP. A service and a compatible client must agree on the supported method.

The reliable-stream option preserves the messages, but it changes how delays behave. On a TCP segment of the route, later data can wait for a missing segment to be recovered. That can matter to time-sensitive applications even when UDP forwarding is functionally working. A tunnel that works on a restrictive network and a tunnel that gives the best timing for voice or a game are not necessarily the same choice.

Entering an ordinary http:// proxy address into a program does not enable these extensions. The program needs an actual UDP tunneling implementation and the service's corresponding configuration. A provider offering only standard CONNECT cannot meet that requirement by changing the endpoint's label.

Which connection uses QUIC?

A claim such as “QUIC proxy” needs a clear description of the connection it refers to. There are two distinct possibilities:

The connection to the proxy uses QUIC. This describes how the client reaches the proxy. For example, ordinary CONNECT over HTTP/3 still asks the proxy to open a TCP connection to the destination. QUIC on the first part of the route does not establish HTTP/3 with the website.

The application uses QUIC with the destination through a UDP relay. Here, the relay carries the application's QUIC packets onward. The application's HTTP/3 connection can reach the website through SOCKS5 UDP forwarding or an appropriate HTTP UDP tunnel, provided the client actually uses that mechanism and the path meets its requirements.

The distinction is especially relevant to testing. A browser or network log showing QUIC traffic to a proxy proves something about that connection. It does not, by itself, prove that the target website was reached using HTTP/3.

In ordinary UDP relaying, the proxy does not need to terminate the application's QUIC connection to forward its datagrams. The application and destination remain the endpoints of that exchange. The proxy still handles destination addresses and traffic, so encrypted content should not be confused with an invisible route.

Fallback, failure and traffic outside the proxy

When the requested transport is unavailable, software can behave in different ways. These outcomes should be distinguished when reading a test result:

Observed outcome What happened What it means for the test
The operation fails The required exchange did not complete Identify whether the failure occurred at the client, relay, network or destination.
The website works using HTTP/2 or HTTP/1.1 The client used a TCP-based HTTP connection instead of HTTP/3 Web access works, but this result does not demonstrate QUIC forwarding.
UDP goes directly to the destination The traffic bypassed the intended proxy The destination receives traffic from the direct route, not the proxy route you wanted to test.

HTTP clients can try a TCP-based version when an HTTP/3 connection cannot be established. This can be useful for ordinary browsing. It is misleading only when page loading is treated as proof that a required HTTP/3 path worked. QUIC did not turn into TCP; the client used a different connection and HTTP version.

Direct traffic is a different issue from a transport fallback. It depends on the application's routing and bypass policy, not on a rule that unsupported UDP must always be sent directly. If using the proxy is mandatory, configure the client or routing layer to stop when that path is unavailable. A successful operation after deliberately disabling the proxy is a reason to inspect the route.

Disabling QUIC can be a valid way to keep ordinary web traffic on a supported TCP path. It does not add UDP capability and does not solve an application that actually requires UDP. Decide whether the task needs the result, such as a webpage, or specifically needs that transport, such as an HTTP/3 test.

Verify the transport and the exit address

A useful test establishes both what was sent and which route carried it. Use the application you intend to run, or a test client that explicitly supports the same forwarding method. A generic proxy check in another tool may exercise a different feature.

  1. Choose a destination that answers the required traffic. For UDP, use a controlled test service or the actual application server. Include an identifier in a test request so its reply can be matched. For HTTP/3, use a target known to serve HTTP/3 on the intended port. Silence from an arbitrary UDP port does not diagnose the proxy.
  2. Confirm that forwarding was established. For SOCKS5, inspect the result of UDP ASSOCIATE and the returned relay endpoint. For an HTTP UDP tunnel, confirm that the requested tunnel was accepted. A login success or an open TCP socket is not this evidence.
  3. Observe a complete exchange. Confirm that the expected reply arrives through the configured client. A destination log or a controlled responder can record the source address it saw. This establishes the exit used for that UDP exchange; an IP-check page opened separately establishes only the route of its own request.
  4. For HTTP/3, verify the actual protocol. Inspect the application's protocol log or the destination's connection log. Look for HTTP/3 (h3) for the destination exchange, not merely QUIC on the connection to the proxy. Where the test client offers an HTTP/3-only mode, use it to prevent a TCP fallback from concealing failure. Combine protocol confirmation with evidence of the intended proxy route.
  5. Exercise the conditions that matter. Repeat with representative packet sizes, traffic duration and idle periods. If bypass must be prevented, test the client's behavior when the configured proxy is unavailable. Record the endpoint, client version and settings so the result can be reproduced.

A packet capture on your device can help locate a failure. In a standard SOCKS5 UDP exchange, it should show datagrams going to the negotiated relay rather than directly to the target. With an HTTP UDP tunnel, the outer connection may instead be HTTP/3 or a reliable HTTP stream. The absence of visible UDP packets on the first leg does not disprove UDP forwarding through that latter method.

Do not treat remote DNS or ping as replacements for these checks. A name can be resolved by the proxy without relaying the application's UDP, and ordinary ping uses ICMP. Neither demonstrates the complete UDP request-and-reply path your application needs.

Adapted from ProxyData: UDP and QUIC Support in Proxies. The selected technical sections reproduce the original guide; the introduction and selection were prepared with AI assistance.