UDP through proxies: what carries it, and what to do instead

Why an HTTP proxy cannot carry UDP at all

This is not a licensing decision or a missing feature. The HTTP proxy protocol is defined on top of TCP. A client either sends an ordinary HTTP request with an absolute URL over a TCP connection to the proxy, or it sends CONNECT host:443 and the proxy opens a second TCP connection and splices the two together so TLS can flow end to end.

There is no message anywhere in that protocol that means "send this datagram to that address and give me back whatever comes in reply". UDP has no connection to splice — it is individual packets with no handshake, no ordering and no session for a proxy to hold on to. So no configuration, header or flag makes an HTTP proxy pass UDP. If your tool says "proxy set" and then sends UDP, it is not sending it through the proxy; it is sending it directly.

SOCKS5, UDP ASSOCIATE, and why it is so rarely available

SOCKS5 is the one proxy protocol with a real answer for UDP. Alongside CONNECT and BIND, RFC 1928 defines UDP ASSOCIATE: the client opens a TCP control connection to the proxy, asks for a UDP association, and the proxy replies with an address and port to which the client may send datagrams. Each datagram is wrapped in a small SOCKS header naming the real destination. The proxy unwraps it, forwards the payload, and wraps replies on the way back. The TCP control connection stays open for the lifetime of the association — drop it and the association dies.

That mechanism is optional, and in practice most of the industry skips it. Three reasons recur. It needs per-client UDP state on the proxy with no connection semantics to drive cleanup, which is unpleasant to operate. It is a natural amplification and abuse vector, so anyone with a public endpoint has a reason not to expose it. And on residential networks the exit is a consumer device behind carrier NAT, where inbound datagrams to a negotiated port are unreliable even when everything is implemented correctly.

So the practical rule: assume UDP ASSOCIATE is unavailable unless a provider states in writing that it is supported on the specific product you are buying. "SOCKS5 supported" on a pricing page almost always means TCP through SOCKS5 and nothing more. Test rather than assume, and if it matters commercially, ask support before you pay — for PyProxy that is @PyProxyBack on Telegram.

What people actually need UDP for

Before engineering around this, check which of these you are really facing, because two of the four have clean answers that do not involve UDP.

DNS is the case that surprises people. When you hand a hostname to an HTTP proxy — the whole hostname, not a pre-resolved address — the proxy does the lookup at its end. Your machine never sends a DNS query for that name, so there is nothing to route. With curl, -x http://... plus a URL already behaves this way. What breaks it is resolving locally first and then connecting to a literal IP: now the lookup leaks from your real address and the proxy only sees an address.

Forcing a client onto TCP, and the HTTP/3 leak

Modern browsers and many HTTP libraries prefer HTTP/3 when the server advertises it, and HTTP/3 rides QUIC over UDP. This produces the single most common "my proxy is not working" report: the page loads, the proxy log is empty, and a check page shows your real address. Nothing is broken. The client saw Alt-Svc: h3, opened a UDP socket to port 443, and your HTTP proxy setting was simply not applicable to that socket.

Chromium-based browsers usually disable QUIC when a proxy is configured, but "usually" is not a guarantee across builds, extensions, PAC files and system-wide settings — so turn it off explicitly:

chrome --disable-quic --proxy-server="http://127.0.0.1:8080"

# or, in the UI:
#   chrome://flags/#enable-quic  ->  Disabled

In Firefox, open about:config and set network.http.http3.enable to false. Command-line tools generally either need HTTP/3 requested explicitly, or expose a --no-quic style switch; with curl, HTTP/3 is opt-in via --http3, and you can pin a version if a library is choosing for you:

curl --http1.1 -x http://USERNAME-country-us:PASSWORD@gw.pyproxy.com:1111 https://httpbin.org/ip

If you want certainty rather than a setting somebody can flip, block the datagrams at the operating system. Anything that wanted QUIC then falls back to TCP, which is exactly what you want:

# Linux
sudo iptables -A OUTPUT -p udp --dport 443 -j REJECT
sudo iptables -A OUTPUT -p udp --dport 80  -j REJECT

# Windows, elevated
netsh advfirewall firewall add rule name="Block QUIC out" ^
  dir=out action=block protocol=UDP remoteport=443

Then verify with the proxy in place. The address in the response should be the exit address, and it should still be that address on the next call within the same session — a session token in the username holds one PyProxy exit address for about thirty minutes, which is what keeps a multi-step job coherent. If the reported address ever flips back to your own, something is still escaping over UDP.

When the right answer is a VPN or a dedicated server

A proxy is an application-level relay for application traffic. A VPN is a virtual network interface: WireGuard and OpenVPN move IP packets, so TCP, UDP, ICMP and DNS all traverse it without the application knowing. That difference, not marketing, is why game traffic and voice belong on a VPN.

Reach for one of these instead of a proxy when:

• The protocol is UDP by design — game netcode, RTP media, WireGuard inside WireGuard, QUIC you cannot disable because you do not control the client.
• Latency and jitter are the product. An extra relay hop and a re-established handshake cost more than they buy. Put a server near the destination region instead.
• You need inbound connections — hosting anything, or peer-to-peer where the far side must reach you. A rotating residential exit cannot offer that; a rented server with a static address can, and you configure whatever daemon you like on it.

And keep using proxies for what they are unbeatable at: HTTPS requests that need to appear to come from a particular place, at a particular scale, with the address swappable per request. That is a TCP problem, which is why the tooling is TCP-shaped. A working line looks like this, and the username carries the options:

curl -x http://USERNAME-country-us:PASSWORD@gw.pyproxy.com:1111 https://httpbin.org/ip

If you are not sure which side of the line your project falls on, the cheap move is to try the HTTP path first with QUIC disabled. In most cases the UDP requirement turns out to be an optimisation the client chose on its own, not something your target needs.

Questions people ask