Around two years ago, rumors and anxieties started echoing around the proxy industry suggesting that the time of proxies was about to be at an end. At the time news about HTTP/3 and QUIC had started making the rounds. Many were nervous that, with the introduction of QUIC, proxies — which overwhelmingly use TCP connections — would be rendered useless.
As HTTP/3 has been adopted by more and more browsers and increasing numbers of websites support it, the worry has died down. Let’s talk about why it won’t be a Y2K moment for the proxy industry.
In this article we’re going to take a look at UDP over SOCKS, HTTP/3 and QUIC, and why this is an out-of-proportion concern today. Additionally, we’ll take a look at the future, consider the implications of wider HTTP/3 adoption and why — even then — it won’t end proxies.
Evolution of HTTP
Before we begin in earnest, it’s probably a good idea to start with a brief history of the evolution of HTTP. Instead of covering HTTP from the very beginning, we’ll look at HTTP/2 and go from there.
HTTP/2
HTTP/2, standardized in 2015, was a way to overcome the limitations of HTTP/1.1. It introduced several improvements, namely the ability to multiplex over a single TCP connection, header compression, and server pushes.
Instead of establishing a connection between client and server for every request and response, multiplexing allows several requests and responses to be sent over one connection, as illustrated. Each stream represents a different request, each of which elicits a response over the same stream.
This solved HTTP’s head-of-line blocking problem — where a lost packet has to be retransmitted and received before any of the subsequent packets can be processed — at the application layer but the problem is still present at the transport layer, due to limitations inherent to TCP. Another example of such a limitation is a relatively high latency due to the need to establish TCP’s three-way handshake.
Version 2 was a massive improvement over its 1.1 predecessor.
HTTP/3 & QUIC
QUIC (Quick UDP Internet Connections) is a transport protocol developed by Google that works over UDP, as the name might suggest. It integrates features of TCP and TLS to provide reliable and secure connections. HTTP/3 was built on top of QUIC to reduce latency and improve performance of web applications by, among other things, handling network congestion better than previous versions of HTTP.
The shift from HTTP/2 to HTTP/3 moves away from TCP at the transportation layer. QUIC also allows for multiplexing but manages each stream separately, which means that a lost packet in one stream doesn’t affect the others. This solves HTTP/2’s head-of-line blocking problem.
QUIC is also always encrypted, incorporating TLS 1.3 into the protocol, which combines the otherwise separate handshakes needed to establish a secure connection.
Why does any of this matter? Let’s take a look at what a transition from TCP to UDP might mean for TCP-based proxying.
What is UDP over SOCKS?
UDP over SOCKS refers to the ability of a SOCKS proxy to handle User Datagram Protocol traffic.
SOCKS, or Socket Secure, is an internet protocol that allows network packets to be sent from client to server via a proxy server. In general, UDP is used in situations where low latency is valued, namely streaming media, online gaming, VoIP, and DNS queries.
Today, most internet traffic occurs over TCP. However, with the introduction of HTTP/3, more services will start using QUIC.
Unfounded Anxieties About HTTP/3 and Proxies
Let’s go over some of the reasons people might be concerned about what a shift to HTTP/3 might mean for the proxy industry. Many of these stem from a September 2022 YouTube video by VectorT13 in which he claimed that 99% of proxy services would be “dead in the next few months”. Two years later, proxies are still kicking.
Let’s go over some of the reasons why some might be concerned about the rise of HTTP/3.
Shift from TCP to UDP
The crux of the flawed argument says that because most proxies are on a TCP basis, they won’t be able to support UDP traffic. VectorT13 goes one step further to say that while UDP proxies exist, there’s no software that allows you to use them — certainly not on Windows.
Later in this article we’ll go over why this is an exaggeration and how to set up a SOCKS proxy that supports UDP, even on Windows.
The second half of the argument is that even if you could find a way to use UDP over SOCKS, there would still be real IP leaks happening as a result of QUIC. Even if websites do not rely on HTTP/3, he argues, many of the services they rely on do. One example he cites is reCAPTCHA, a free Google service to identify bots.
From this framing, you, through your proxy, would be interacting with the website via TCP, but the services the website is using would be talking directly to your device via UDP. Most — if not all — of this context is from the assumption that QUIC over HTTP/3 is an insurmountable problem.
This isn’t an unsolvable problem; solutions already exist and we’ll discuss them at length.
Predatory Marketing Opportunity
Many proxy services have taken advantage of the uncertainty regarding QUIC to roll out many an advertisement of UDP over SOCKS. A quick Google search reveals request after request for SOCKS5 with UDP support, overwhelmingly dated after September 2022.
We’ll leave that for what it is.
It’s true that many proxy services don’t support UDP, and there’s a good reason for that. They don’t need to, as we’ll get into in the next section. By exploiting this worry in the market, providers who have proxies that do (or claim to) support UDP can differentiate themselves from the rest of the pack regardless of the market’s actual need. Clients want it, and that’s that.
These worries are exacerbated by two things: The first is a technological deficiency on the part of proxy providers who are unable to provide UDP proxies that are sufficiently anonymizing and the second is their competition’s exploitation of that fact to shill their own products.
Why HTTP/3 Doesn’t Threaten Proxies Today
HTTP/3 Adoption is Still Low
In a report by Cloudflare, they detail the adoption of HTTP/3 a year into its rollout. By the end of November 2023, only 28% of global web traffic going through Cloudflare used HTTP/3. According to W3 Techs, as of October 18, 2024, “HTTP/3 is used by 25.3% of all the websites”, referring to the top 1,000 sites it uses as a baseline.
Given that this refers to HTTP/3 being used at all, this means that not only do the majority of sites not use HTTP/3, but most of their processes are not UDP-based. The overwhelming majority of all traffic on the internet still uses TCP.
Browsers Yet to Fully Embrace QUIC
If we take a look at CanIUse, 94.53% of people have browsers that support HTTP/3 — higher even than HTTP/2 at first glance. However, this percentage drops drastically when we take Safari users into consideration. Roughly 17% of users worldwide use some version of Safari, according to the site, which does not come with HTTP/3 enabled by default. This means that HTTP/3 is nowhere close to achieving the ubiquity of its predecessor and, as a consequence, no anti-bot technology that definitely rules out non-HTTP/3 connections can be implemented any time soon without excluding almost a fifth of users worldwide.
This leads us to the next important point.
Most Things Are Still TCP
Proxies as an anonymizing technology is used largely for web scraping and web automation, two activities that are still overwhelmingly done via TCP. Browsers that don’t support QUIC also still operate over TCP. Websites do this too: Amazon defaults to HTTP/2 when you use Safari or disable HTTP/3 on Chrome.
Until this changes, which as we’ve explained is unlikely anytime soon, proxies as we know them today will continue to work the way they always have.
Solutions Already Exist
As of the date of publication of this article, proxying QUIC over SOCKS is already possible. Let’s discuss a few solutions that have shown potential for wider application.
At EuroPython2022, Miloslav Pojman gave a lecture discussing how he wrote a Python client that could proxy HTTP/3. While he doesn’t go into too much technical detail, he details how his client uses the MASQUE protocol to tunnel traffic through HTTP/3 or HTTP/2.
In November 2023, Google software engineer Jeongseok Son gave a lecture on how the Internet Engineering Task Force’s MASQUE working group developed the CONNECT-UDP HTTP method. He also covers how they implemented a way to tunnel QUIC or UDP over HTTP.
At a less formal level, in response to VectorT13’s video, another user uploaded a video dismantling his arguments one by one. He also showed how he used his product, called Double SSH Tunnel Manager, in combination with a 3proxy server and Yddrasil, to create a QUIC-aware SOCKS proxy.
While these are far from being industry standards yet, they indicate a concerted effort across multiple avenues to achieve that standardization.
The Future
Let’s talk a little bit about what the future might hold. Much of this article hinges on the idea that HTTP/3 ubiquity isn’t imminent, but it could happen sooner rather than later. It’s safe to say that QUIC is here to stay, and that more and more websites and applications will start relying on it. The benefits are obvious: it’s faster, more reliable, more secure, and easier to implement. The only immediate limitations are adoption rates and interoperability, which has never slowed the industry down for very long.
Where does this leave us?
Proxies have solved such problems before. Web automation and anti-bot technologies have always had a cyclical, competitive relationship, albeit not always directly caused by one another. CAPTCHA is an explicitly anti-bot technology used to disrupt web automation. A mini–arms race in its own right, automators continue to find new ways to bypass them and developers find new technology to include in CAPTCHA to trip up the bots.
By comparison, in the wake of GDPR, websites found new and creative ways to track visitors across sites and sessions — enter browser fingerprinting, which those wanting to stay anonymous online needed to overcome. Although fingerprinting wasn’t intentionally developed for anti-bot purposes, anti-fraud and security communities realized its potential and started applying it to track bots. In turn, anti-detect browsers were developed to complement proxies in ensuring anonymity by suppressing or spoofing identifiable characteristics of a user’s browser and device.
These are just two examples that illustrate that as technology advances, new innovations will have ripple effects. These repercussions, both in general and as it relates to web automation and anonymity specifically, are something the proxy sector, among others, will always have to adapt to and overcome.
The effects of a development as disruptive as a transition from TCP to UDP at the transport layer will attract investment and resources from every corner of the world, from the tech industry to academia. Solutions to proxying QUIC over SOCKS already exist; efforts to scale them up and standardize them are already underway, not just the proxy sector itself.
Conclusion
In short, HTTP/3 will not render proxies obsolete and the urgency for proxying UDP over SOCKS is largely exaggerated. This is, as it stands today, for the following reasons:
- Low adoption rate of HTTP/3 by websites
- Browsers haven’t fully embraced QUIC
- Continued reliance on TCP
- QUIC-aware proxying over SOCKS is already possible
The proxy and automation industries have already overcome obstacles that were initially seen as significant, from passive OS fingerprinting to CAPTCHAs. As QUIC becomes more widely adopted — which will be a gradual process — proxies will continue to adapt and industry standards will be implemented. The need for proxies, both as an anonymizing technology and the many other purposes proxies serve, is not going away.
