When you connect to a target resource through an anti-detect browser using a proxy, security systems inspect and evaluate your IP address and geolocation. At a basic level, it may seem that this is the maximum an anti-fraud system can do. However, it can also analyze how exactly the browser transmits network packets.
In the latest Aurorium Browser update, we have not only added native UDP support but also introduced technology that automatically wraps any proxy in a UDP tunnel. How does it work, why is it useful, and what does Google’s QUIC technology have to do with it? We explain everything below.
TCP Proxy, UDP Proxy, or UDP Proxy with Standard HTTP/3 — Does It Really Matter?
Every time a browser opens a web page, data is exchanged using one of the following transport protocols:
- TCP
- UDP
TCP Protocol
TCP is a protocol that guarantees data delivery and preserves the order of packets. Today, it is the foundation of web traffic and is used by most proxy servers (HTTP/HTTPS and SOCKS5).
The primary purpose of TCP is to deliver data and ensure that it arrives in the same order in which it was sent.
Basically, data transmission follows this sequence:
- Connection establishment: the client and server negotiate a connection and perform a three-way handshake.
- Data transmission with delivery control: data is divided into packets and transmitted in the established order.
- Retransmission: for each transmitted block, the sender must receive confirmation that it was delivered. If a packet is lost due to a connection interruption or network congestion, it is sent again.
This approach prevents data loss but can introduce additional latency.
Classic protocols such as HTTP/1.1, HTTP/2, SSH, FTP, and database protocols operate over TCP.
UDP Protocol
UDP is a fast datagram-based transmission protocol that does not require prior connection establishment or delivery acknowledgments.
This is where the key difference between TCP and UDP lies. The primary goal of UDP is to deliver data as quickly as possible, even if some packets are lost.
Data transmission over UDP follows this sequence:
- Data transmission: no connection is established; data is sent to the recipient immediately.
- No acknowledgments: the recipient does not notify the sender that the data has been received.
- Loss tolerance: the protocol does not track lost data, and retransmission is not built into the protocol itself.
This approach minimizes latency and provides low ping, but it does not guarantee that all transmitted data will arrive.
UDP has traditionally been used wherever response speed is critical. Real-time protocols and services such as DNS, DHCP, VoIP, video streaming, multiplayer online games, WebRTC, and the QUIC protocol (HTTP/3) operate over UDP.
What Is QUIC?
QUIC is a next-generation protocol built on top of UDP, sometimes referred to as the “Google protocol.” QUIC combines the speed of UDP with end-to-end TLS 1.3 encryption.
The HTTP/3 standard operates on top of QUIC.
Why do we call it the “Google protocol”? Because Google engineers originally developed QUIC and later submitted it to the Internet Engineering Task Force (IETF).
Today, HTTP/3 accounts for just under half of global internet traffic. It is deployed by default on the servers of Google, Meta, YouTube, Instagram, Cloudflare, and Amazon. If both the network and your browser support HTTP/3, the connection will be established over UDP.
The primary goal of QUIC is to increase the speed of encrypted data transmission.
Data transmission over QUIC follows this sequence:
- Connection establishment and TLS encryption: the connection and TLS encryption are established in a single exchange with the server (1 RTT instead of 2–3 RTT with TCP + TLS).
- Data transmission over independent streams: data is transmitted in parallel, and if a packet is lost, it can be retransmitted without blocking other data streams or page loading.
An interesting detail is that a QUIC connection is not tied to the IP address + port combination. Instead, it is associated with a connection ID. This means that when a device switches from one internet connection to another, the connection can remain active.
Why Does the Lack of UDP Attract Anti-Fraud Systems?
Advanced security systems can analyze network anomalies in much the same way they analyze a device fingerprint. Lack of UDP support can lead to several consequences, including:
- forced fallback to HTTP/2 (TCP);
- potential leakage of the device’s real IP address.
Forced Fallback to TCP
This is not the most critical issue, but it can still be problematic. As mentioned above, if a website supports HTTP/3, a real Chrome browser will choose it in most cases, especially when connecting to Google or Meta servers.
If a proxy does not support UDP, the browser is forced to fall back to HTTP/2 over TCP. From an anti-fraud perspective, this can be a signal that there is an anomaly in the connection, potentially increasing your Fraud Score.
Real IP Address Leakage
You have probably already heard of WebRTC, a technology responsible for real-time media transmission. It is used for video calls, P2P connections, online streaming, and more. During operation, WebRTC queries STUN/TURN servers over UDP.
Normally, when a proxy operates exclusively over TCP and does not support UDP, the browser cannot send STUN requests through the proxy tunnel and sends them directly instead. This can result in the classic leakage of the user’s real IP address.
The anti-fraud system may see one IP address in the TCP request headers and another through WebRTC. At that point, the consequences can be serious, as such a discrepancy significantly increases the likelihood of an account being flagged.
By the way, WebRTC did not leak the real IP address in the Aurorium anti-detect browser even before this update. However, this type of leak remains one of the most common issues in the multi-accounting space.
How Is UDP Implemented in Aurorium Browser?
The main problem in the proxy market is the shortage and high cost of solutions with genuine UDP support. Most providers either do not support UDP at all or offer UDP-enabled proxies at significantly higher prices.
But even if you find a provider with genuine UDP support, there is a second problem: support for this type of proxy in an anti-detect browser. As of today, only a limited number of anti-detect browsers provide such support.
Technically, implementing UDP support is more challenging because Chrome does not natively support UDP proxying. Without extensive additional development, an anti-detect browser will send TCP traffic through SOCKS5 instead.
We solved this problem by adding genuine UDP support. Moreover, Aurorium Browser not only supports UDP proxies but can also wrap standard proxies in UDP tunnels with QUIC support.
Native UDP Support
If your proxy natively supports UDP packet transmission, Aurorium Browser automatically detects the protocol and routes QUIC and WebRTC traffic directly through the proxy.
Automatic UDP Wrapping
When this option is enabled, an intermediate server with UDP support is added to the traffic routing path. The browser takes any standard proxy (HTTP/SOCKS5) and automatically wraps outgoing connections in a full UDP tunnel.
As a result, the target website sees behavior that is closer to that of a regular browser: sessions are established over HTTP/3 (QUIC).
The feature is already available on all Aurorium plans. Update the application to the latest version to ensure maximum profile consistency when working with traffic sources that are sensitive to network characteristics.