UDP & QUIC Through Proxies

A proxy can pass a web check and still be unable to carry the traffic your program needs. For example, a game might sign in through the proxy but fail to exchange gameplay updates. A website might open normally while the browser uses HTTP/2 instead of HTTP/3. These operations use different network capabilities.

For the broader choice of protocol, see SOCKS vs HTTP Proxies. This article explains how UDP reaches a destination through a proxy, what QUIC needs from that path, and how to check that your application is using the intended transport and exit IP.

What UDP, QUIC and HTTP/3 do

TCP delivers an ordered stream of bytes. If some data is lost, it arranges retransmission and withholds later bytes from the application until the gap is filled. UDP sends separate messages, called datagrams. UDP itself does not guarantee delivery, order or protection against duplicates; the software using it decides how to handle these situations.

This gives applications room to choose different behavior. A voice application may discard an audio packet that has arrived too late to play. A game may prefer a recent position update to an old one. A DNS exchange can consist of a short question and answer. The actual transport depends on the program: these examples do not mean that every call, game or DNS request uses UDP.

QUIC is a transport protocol built on UDP. It adds connection establishment, recovery of lost data, congestion control and reliable streams. A file transferred over a reliable QUIC stream can arrive complete and in order. The fact that its packets travel inside UDP datagrams does not remove the reliability supplied by QUIC.

QUIC also lets several streams share a connection. When data from one stream is lost, other streams whose data has arrived can continue. This can reduce waiting compared with carrying all streams through one ordered TCP connection. The result still depends on the route, packet loss, server and client; choosing QUIC alone does not guarantee a faster application.

HTTP/3 carries HTTP over QUIC. HTTP/1.1 and HTTP/2 normally use TCP. All three can serve an HTTPS website, so https:// in the address does not identify the HTTP version or confirm that UDP was used.

Encryption is a separate property. UDP does not encrypt data. QUIC uses TLS 1.3 to establish protection for application traffic. An ordinary UDP application may use another security mechanism or transmit its payload without encryption; forwarding it through a proxy does not automatically add that protection.

How SOCKS5 carries UDP

SOCKS5 defines a UDP relay: a service that accepts datagrams from the client, sends their payloads to the destination and returns the replies. The client first arranges this forwarding over TCP. The control connection and the datagram path then exist side by side.

1. The client connects to the SOCKS5 server over TCP and completes the agreed authentication procedure.
2. It requests UDP ASSOCIATE. If the proxy accepts, the reply supplies the address and UDP port of the relay.
3. The client sends datagrams to the relay with a SOCKS header identifying the destination. The relay removes that header before forwarding the payload. For replies, it adds a SOCKS header before sending the datagram back to the client.
4. The client keeps the TCP control connection open while using the relay. Closing it ends the UDP forwarding arranged by that connection. This association between the control connection and UDP forwarding is called a UDP association.

The relay can use a different address or port from the TCP endpoint entered in the proxy settings. Sending raw UDP to that familiar endpoint does not perform the SOCKS5 exchange. A client that implements only CONNECT can use SOCKS5 for TCP, but lacks the procedure needed here. SOCKS4 does not define this UDP relay facility.

This explains a common partial success: a firewall permits the TCP connection and authentication, but blocks datagrams to the negotiated relay. The password works; the application still receives no UDP replies. Both parts of the route need to be available.

Can an HTTP proxy forward UDP?

An ordinary HTTP CONNECT request asks the proxy to open a TCP connection to the destination and carry a byte stream. It does not establish UDP forwarding. Using TLS for the connection to an HTTPS proxy protects that connection without changing the type of tunnel being requested.

HTTP has an additional UDP tunneling mechanism, commonly called CONNECT-UDP and developed as part of MASQUE. With a compatible client and server, the client requests a tunnel to a UDP destination. The proxy forwards the datagrams to that destination and carries the replies back. This requires explicit support on both sides.

On the client-to-proxy connection, HTTP Datagrams can be carried in QUIC DATAGRAM frames when HTTP/3 and the required extensions are supported. They can also be carried in capsules: framed messages inside a reliable HTTP stream, including HTTP/2 over TCP. In that case, the proxy still sends UDP to the destination even though the first part of the route uses TCP.

That choice affects timing. If the TCP connection loses data, later bytes can wait for its recovery, delaying the datagrams carried inside them. The tunnel may be functional yet unsuitable for a particular real-time workload. Merely entering an http:// proxy address in a program does not enable any of these additional UDP mechanisms.

Which connection uses QUIC?

The phrase “QUIC proxy” needs context. It can describe the transport used to reach the proxy, or the application's connection to the destination. Those are separate parts of the exchange.

In ordinary UDP relaying, the proxy does not need to terminate the application's QUIC connection. It forwards packets while the application and destination remain the endpoints of that encrypted exchange. The proxy still knows where it is forwarding traffic and can observe its volume and timing.

Why support in the application matters

A program needs to implement the forwarding method that the service offers. A SOCKS5 checkbox does not tell you whether it supports UDP ASSOCIATE. Likewise, a program may support HTTP/3 for direct connections while offering only TCP proxy connections.

Chrome provides a concrete example: its built-in SOCKS5 support proxies TCP-based URL requests and does not relay UDP through SOCKS5. Loading a page with that setting cannot test the service's UDP relay. This limitation concerns that specific client mode; other clients or external routing software can have different capabilities.

Check the scope of the setting as well. Login, file downloads, voice and gameplay may use different network components within one application. A proxy configured for web requests may cover only some of them. A system proxy setting also depends on whether each program follows it.

A program that redirects another application's traffic can send its UDP through a proxy, provided it supports UDP and the service's forwarding method. Redirecting TCP alone is insufficient. If the program uses a virtual network interface, its routing rules decide which traffic enters it. Test the complete combination: the application, the routing program and the proxy endpoint.

Fallback, failure and a direct connection

When the required path is unavailable, the outcome depends on the application's capabilities and policy. Three results can look similar if the only question is whether something opened:

Switching to a TCP-based HTTP version is called fallback. It can preserve normal browsing when QUIC is unavailable. The client opens a different connection; QUIC itself does not turn into TCP. Disabling QUIC can therefore help a web application use an available TCP path, but cannot supply UDP to a feature that requires it.

Going directly to the destination is a routing decision. Unsupported UDP is not universally sent directly: software may stop, try another transport or follow a configured bypass rule. If all traffic for the task must pass through the proxy, use a mode that stops when that route fails and check its behavior with the proxy unavailable.

Why UDP can stop working after setup

Port rules and the return path

TCP port 443 and UDP port 443 belong to different transports. Allowing one does not open the other. For SOCKS5, the client must reach the returned UDP relay endpoint; the relay must also be allowed to reach the destination's UDP port. HTTP/3 can use ports other than 443, so check the endpoint the application actually uses.

Replies must return through the relay, firewall and any NAT, which translates addresses and often ports between networks. A sent datagram alone does not show that this return path works. A network change can alter the client's public IP or port mapping. SOCKS5 relays are required to reject datagrams from a source IP other than the one recorded for that UDP association, so a changed address can require a new association.

Pauses and expired state

Relays and NAT devices keep temporary records for UDP exchanges. Those records may expire during a pause. A call or session can work at first, then lose its UDP path until the client sets it up again. Keeping the same exit IP does not prevent this: the state needed to forward UDP and the service's IP assignment are separate things.

Datagram size and MTU

MTU is the largest IP packet a network link can carry without fragmentation. The usable size along a route is limited by its smallest such limit, known as the path MTU. IP, UDP and additional tunnel headers all take space in the packet. A small test message can pass while larger datagrams are dropped, so the application must account for the complete path and its added headers.

A QUIC path must carry at least 1,200 bytes of UDP payload, without counting the IP and UDP headers. The client pads UDP datagrams carrying its QUIC Initial packets to at least that payload size. Proxy headers on the client-to-proxy part need additional space. This is not a recommendation to set an interface MTU to 1,200: it explains why a small DNS request and reply can work while the larger QUIC handshake cannot pass.

Delay, loss and load

For a call or a game, delivery time can matter as much as delivery itself. Variable delay, packet loss and limits on packet rate can impair an otherwise working UDP relay. Bandwidth alone does not describe these conditions. A proxy adds another part to the route; it can change performance in either direction, depending on the networks and workload.

How to verify UDP and HTTP/3 through a proxy

Test the application you intend to use, or a client that implements the same forwarding method. A useful test checks the reply, the transport and the exit address for the same exchange.

1. Choose a destination that answers the required traffic. Use the actual application server or a controlled UDP responder. For HTTP/3, choose a destination known to support it. Silence from an arbitrary UDP port does not tell you which part failed.
2. Confirm that the relay or tunnel was accepted. With SOCKS5, inspect the UDP ASSOCIATE result and the returned relay address and port. With an HTTP UDP tunnel, confirm acceptance of that tunnel. Authentication alone does not cover this step.
3. Complete a request and reply. A controlled responder can return a request identifier and record the source IP it saw. This checks the exit used for that UDP exchange. A separate web IP check covers only its own request.
4. For HTTP/3, confirm the protocol at the destination exchange. Look for HTTP/3 or h3 in the client or server's connection log, together with evidence of the proxy route. If the test client has an HTTP/3-only mode, it can expose a failure that automatic fallback would otherwise hide.
5. Repeat under relevant conditions: realistic datagram sizes, sustained traffic and a pause followed by activity. If direct traffic is forbidden for the task, also test what happens when the proxy is unavailable. Keep the client version and connection settings with the result.

A packet capture can help identify the route. Standard SOCKS5 UDP forwarding sends datagrams to the negotiated relay. An HTTP UDP tunnel may instead use an outer TCP connection, so the absence of UDP on that first part of the route is not sufficient evidence of failure.

Remote DNS and ping test different things. A proxy can look up a hostname for a TCP connection without relaying the application's UDP traffic. Ordinary ping uses ICMP. Neither test replaces a UDP request and reply observed on the intended proxy route.

When UDP support is worth choosing

Start with the traffic your task requires. Website and API work that runs over HTTP/1.1 or HTTP/2 may be fully served by a TCP-only proxy. HTTP/3 testing, UDP media and other UDP-dependent features require a suitable relay or tunnel, plus a client that can use it.

Ask the service which UDP forwarding method and client configuration are supported. Then check permitted destinations and ports, datagram-size limits, idle behavior and any traffic or packet-rate limits relevant to the workload. If TCP and UDP must use the same exit IP or location, verify that requirement in the actual application. A shared account or a successful web check does not establish identical exit behavior.