Support for UDP over SOCKS5 (QUIC / HTTP/3)
Modern web services are actively transitioning to HTTP/3, which operates over QUIC, and QUIC operates over UDP.
For browser platforms, this means the need for full routing not only of TCP traffic but also UDP connections through proxies.
If UDP does not pass through the proxy tunnel, network mismatches occur, and in certain cases, there is a risk of leaking the real IP address.
Why UDP support is critically important
A browser can:
- declare support for HTTP/3
- use a modern TLS stack
- correctly generate a fingerprint
But if QUIC is not routed through the proxy, one of the following occurs:
- HTTP/3 is not established
- the connection is forcibly downgraded to HTTP/2
- UDP traffic goes directly
For modern anti-fraud systems, this is an indicator of network anomaly.
Architectural approach
A comprehensive implementation includes:
- support for the SOCKS5 UDP ASSOCIATE mechanism
- transmission of QUIC datagrams through proxy IP
- correct establishment of HTTP/3 without fallback
- coordinated operation with the Chromium network stack
As a result, the server sees the proxy IP for all traffic - both TCP and UDP.
Technical routing scheme (Packet Flow)
Below is a simplified diagram of QUIC traffic passing through SOCKS5:
Process Details
- The browser establishes a TCP connection with the SOCKS5 proxy
- The
UDP ASSOCIATEcommand is executed - The proxy allocates a UDP port for datagram transmission
- QUIC packets are transmitted through this UDP channel
- The target server receives traffic from the proxy IP
This architecture eliminates:
- direct UDP traffic bypassing the proxy
- forced downgrade of HTTP/3
- network behavior mismatches
Practical Benefits
- Consistency of network profile
- Realistic behavior of a modern browser
- Correct HTTP/3 handshake
- Absence of IP leaks through UDP
- Increased resilience to network checks
Technological Complexity
Historically, SOCKS5 has been oriented towards TCP connections. Support for UDP requires:
- separate handling of datagram packets
- correct routing without NAT conflicts
- synchronization with the QUIC stack
- integration at the browser's network architecture level
This is a system-level task that requires deep work with the network stack.
Conclusion
Support for UDP over SOCKS5 is a mandatory element of a modern browser platform working with HTTP/3.
Full routing of QUIC traffic through a proxy ensures network integrity, realistic network behavior, and protection against IP leaks.
Afina Browser implements this at the engine level.
No workarounds. No traffic bypass. No protocol degradation.
QUIC traffic is routed correctly through the proxy stack, preserving HTTP/3 functionality while maintaining strict network isolation.
Modern protocol support should not be optional - it should be native.
Afina delivers exactly that.
DownloadFAQ — Frequently Asked Questions
Why does UDP support in a proxy suddenly matter?
Because the web is shifting to HTTP/3, and HTTP/3 runs on QUIC, which is a UDP-based protocol. If your proxy only routes TCP, then QUIC traffic either goes directly (bypassing the proxy) or fails entirely, forcing the browser to fall back to HTTP/2. Both outcomes create a detectable network anomaly.
What exactly leaks if UDP doesn't go through the proxy?
Two things, depending on browser configuration:
- Direct IP exposure — QUIC datagrams travel from your real IP to the target server, while TCP goes through the proxy. The server sees two different IPs for the same session.
- Protocol fingerprint mismatch — the browser advertises HTTP/3 support, but the connection silently downgrades. Anti-fraud systems flag this inconsistency.
Is HTTP/3 really that widespread yet?
Yes. Cloudflare, Google, Meta, YouTube, Cloudfront, Akamai, and most major CDNs already serve HTTP/3 by default to compatible clients. If your browser claims HTTP/3 support but never actually uses it, that itself is a fingerprint.
Can't I just disable HTTP/3 in the browser to avoid the problem?
Technically yes, but it makes things worse. A modern Chrome build with HTTP/3 forcibly disabled is statistically rare and stands out. Anti-detect platforms aim for realism — disabling QUIC is the opposite of realism.
What is SOCKS5 UDP ASSOCIATE?
It's the part of the SOCKS5 protocol (RFC 1928) designed for UDP relay. The client sends a UDP ASSOCIATE command over TCP, the proxy allocates a UDP port, and from that moment datagrams are tunneled through the proxy. Most SOCKS5 implementations skip this part because TCP-only is simpler.
Do all SOCKS5 proxies support UDP ASSOCIATE?
No, and this is the catch. Many commercial proxy providers advertise "SOCKS5" but only implement the TCP portion. Before relying on a provider for HTTP/3 routing, you need to actually test UDP ASSOCIATE — advertising it isn't the same as supporting it.
Does HTTP proxy support UDP?
No. HTTP and HTTPS proxies are TCP-only by design. For QUIC routing you need SOCKS5 with full UDP ASSOCIATE, or a higher-level tunnel (WireGuard, OpenVPN UDP mode, etc.).
How does Afina Browser handle this differently from regular Chromium?
Stock Chromium has no native concept of routing QUIC through SOCKS5 — it either uses the system proxy (TCP only) or sends QUIC directly. Afina integrates UDP relay at the network stack level, so QUIC datagrams are wrapped into SOCKS5 UDP ASSOCIATE packets before leaving the machine.
Will this slow down my connection?
There's a small overhead from the SOCKS5 UDP encapsulation (about 10 bytes per packet), but QUIC itself is faster than TCP+TLS, so the net effect is usually neutral or positive compared to HTTP/2 over a proxy.
What about IPv6 and QUIC?
QUIC works over both IPv4 and IPv6. If your proxy only provides IPv4 but the target server prefers IPv6, the browser may attempt direct IPv6 QUIC connections. Proper implementation forces all QUIC traffic through the proxy regardless of address family.
How can I verify QUIC is actually routed through the proxy?
Three quick checks:
- Open
chrome://net-export/, capture a session, and inspect QUIC connection IPs - Visit
https://cloudflare-quic.com/— it shows whether HTTP/3 is established - Check the target server's perspective via a site like
https://browserleaks.com/ipwhile loading an HTTP/3 site in parallel
What happens with WebRTC if UDP goes through the proxy?
WebRTC uses UDP too, but it's a separate concern with its own STUN/TURN leak vectors. Routing QUIC through SOCKS5 doesn't automatically fix WebRTC leaks — those require separate handling at the browser level (which Afina also addresses).
Is this an issue only for anti-detect browsers, or for regular users too?
For privacy-conscious regular users it matters too. A VPN that doesn't route UDP, or split-tunnel configurations, can leak the real IP via QUIC. Anti-detect users just face higher consequences because anti-fraud systems actively check for this.
What about HTTP/3 connection migration — does it break through a proxy?
QUIC supports connection migration (switching networks without dropping the connection). When routed through SOCKS5 UDP ASSOCIATE, migration still works as long as the proxy maintains the UDP association. The connection ID stays stable; only the underlying transport changes.
Can detection systems tell the difference between native HTTP/3 and HTTP/3 over SOCKS5?
If implemented correctly — no. The target server only sees QUIC packets arriving from the proxy IP, identical in shape to packets sent natively. Detection relies on inconsistencies (IP mismatch, missing HTTP/3 when advertised, latency anomalies), not on packet structure itself.
Where can I read the protocol specs?
- SOCKS5: RFC 1928
- SOCKS5 UDP ASSOCIATE: Section 7 of RFC 1928
- QUIC: RFC 9000
- HTTP/3: RFC 9114
