UDP
The connectionless transport protocol behind DNS, QUIC and real-time traffic, which most proxies cannot carry and SOCKS5 optionally can.
UDP is what you get when you delete everything from TCP that costs time. No handshake, no connection, no acknowledgements, no retransmission, no ordering. A sender addresses a datagram and releases it; it arrives, or it does not, and neither end is told which. That sounds like a defect and is actually a design: for traffic where a late answer is worthless, waiting to recover a lost packet is strictly worse than losing it.
That is why the protocols living on UDP are the time-sensitive ones. A DNS query fits in one datagram and would rather be re-asked than queued. Voice and video calls would rather drop a frame than pause. Game state is stale the moment a newer update exists. And since 2022 the web itself has joined the list: HTTP/3 runs on QUIC, a transport built on UDP that reimplements reliability and encryption in a way that avoids TCP's one-lost-packet-stalls-everything problem.
For proxy users the operative fact is blunt: the classic proxy protocols carry TCP, and UDP mostly does not fit through them. An HTTP proxy tunnels TCP connections; it has no mechanism for relaying datagrams at all. SOCKS5 is the exception on paper, with a dedicated UDP mode alongside its TCP relaying, but support for it is genuinely uncommon: many SOCKS5 servers, and most free list entries claiming the protocol, implement the TCP half only. A proxy advertised as SOCKS5 tells you UDP is possible in principle, not that it works.
The practical consequences are easy to recognise once named. Applications that depend on UDP, game clients, VoIP, some streaming, either fail through a proxy or silently bypass it, and traffic that bypasses the proxy is traffic wearing your real address. Browsers handle it more gracefully: configured with a proxy they simply skip HTTP/3 and fall back to the TCP protocols, so pages load normally over HTTP/2 without you noticing the negotiation.
DNS deserves its own caution here, because it is UDP and it is identity-relevant. Name lookups do not automatically follow the same path as the traffic they precede, and a lookup escaping around the proxy tells your resolver every hostname you visit. The remote-resolution options that exist in SOCKS5 and in well-behaved HTTP proxying are the fix, and they are worth verifying rather than assuming.
Frequently asked questions
Can I use UDP through a proxy?
Only through a SOCKS5 proxy whose operator actually implemented the UDP mode, which is rarer than the protocol label suggests. HTTP proxies cannot relay datagrams at all. If an application depends on UDP, test it explicitly, and watch for the quiet failure where the application bypasses the proxy and sends from your real address rather than erroring.
What happens to HTTP/3 when I use a proxy?
The browser falls back. HTTP/3 rides QUIC over UDP, which conventional proxies do not carry, so a proxied browser negotiates HTTP/2 or HTTP/1.1 over TCP instead. Every site that serves HTTP/3 also serves those, so nothing visibly breaks; the transport is simply older, and the fallback itself is one of the small ways proxied traffic differs in shape from direct traffic.
Why does DNS use UDP?
Because a lookup is one small question wanting one small answer as fast as possible. A datagram exchange costs no handshake, and if the answer is lost the client just asks again. Large answers and zone transfers fall back to TCP, and the newer encrypted variants run over TCP or QUIC, but the everyday lookup that precedes every connection you make is a UDP exchange.
Is UDP less secure than TCP?
Neither encrypts anything; security is a property of what runs on top. UDP is easier to abuse in one specific way: with no handshake, a source address can be forged, which is what makes reflection-style flooding possible. For your own traffic the practical security question is not the transport but whether the protocol above it, TLS or QUIC, is doing the encrypting.
Back to the full glossary.