TCP and UDP are the two ways most internet traffic travels. TCP opens a connection first and then delivers every byte in order, resending whatever gets lost. UDP sends each datagram on its own, with no connection and no promise that it arrives. Through a proxy, that difference decides what can pass at all. HTTP proxies and SOCKS4 carry TCP only. SOCKS5 can carry UDP, but few SOCKS5 proxies actually do. For web pages, APIs and scraping, use TCP. UDP matters for DNS, voice, video, games and HTTP/3, and only when both the proxy and the app support it.
We measured the difference on 10 October 2026 instead of describing it. Our server sent the same DNS lookup both ways, 140 times each, and we captured the packets. We also counted which protocols the proxies on our free list speak.
What is the actual difference between TCP and UDP?
TCP talks before it sends. RFC 9293 (IETF, August 2022) calls the setup a "three-way handshake", and once it is done TCP "provides a reliable, in-order, byte-stream service to applications". Lost data is sent again, and nothing reaches the application out of order.
UDP simply sends. RFC 768 (IETF, August 1980) says "delivery and duplicate protection are not guaranteed", and it tells applications that need ordered, reliable delivery to use TCP. Whatever reliability a UDP application needs, it builds itself.
The order guarantee has a cost of its own. RFC 9114 (June 2022) explains it for HTTP/2 over TCP: "a lost or reordered packet causes all active transactions to experience a stall". This is head-of-line blocking. QUIC, which carries HTTP/3, avoids it across streams, and RFC 9000 (May 2021) says "QUIC packets are carried in UDP datagrams".
| TCP | UDP | Source | |
|---|---|---|---|
| Before the first byte | Three-way handshake | Nothing | RFC 9293, RFC 768 |
| Delivery | Reliable, in order, resent when lost | Not guaranteed | RFC 9293, RFC 768 |
| Header | 20 bytes without options | 8 bytes | RFC 9293, RFC 768 |
| One lost packet | Holds up what comes after it | Only that datagram is gone | RFC 9114, RFC 9000 |
| One DNS lookup, as we captured it | 10 packets | 2 packets | Our capture, 10 October 2026 |
What did the same lookup cost over each?
We sent one DNS question, the A record of example.com, from our server to public resolvers. It went over UDP and over TCP in turn, and tcpdump recorded every packet:
UDP needed two packets: the question and the answer. TCP needed ten. Three set up the connection, four carried the question and the answer with an acknowledgement for each, and three closed it. The query also grew by two bytes, because DNS over TCP puts the message length in front.
Then we timed 50 rounds each way to 1.1.1.1 and to 8.8.8.8:
- UDP
- TCP
The fastest values show the protocols most clearly. TCP took 2.8 ms against 1.0 ms to 1.1.1.1, and 15.8 against 7.1 ms to 8.8.8.8. The medians are higher for both, because our server was busy, with a load average of 10 to 12 during the test.
UDP paid for its speed in the other column. Across both runs, 4 of 140 UDP lookups got no answer within three seconds, and nothing told the program why. All 140 TCP lookups were answered. A program using UDP has to notice the silence and ask again.
What is each one best at?
TCP is best when every byte matters and must arrive in order. Web pages and APIs run on it. RFC 9112 gives the http scheme "a default connection of TCP over IP", and RFC 9114 notes that HTTP/2 has run "primarily with TLS over TCP". It is also the traffic an HTTP proxy's CONNECT carries.
UDP is best when late data is worse than lost data, or when one question and one answer are all there is:
- DNS. RFC 1035 (November 1987) offers name servers over both, with UDP messages "restricted to 512 bytes" and longer answers truncated. Since RFC 7766 (March 2016), TCP support is "a REQUIRED part of a full DNS protocol implementation".
- Voice and video. Calls and live media use RTP, which applications run "on top of UDP to make use of its multiplexing and checksum services", in the words of RFC 3550 (July 2003).
- HTTP/3. It runs on QUIC over UDP. But RFC 9114 adds that when UDP is blocked, "clients SHOULD attempt to use TCP-based versions of HTTP".
Which proxies carry TCP and which carry UDP?
| Proxy type | Carries | Where it says so |
|---|---|---|
HTTP proxy, CONNECT | TCP | RFC 9114: a CONNECT proxy "establishes a TCP connection" |
| HTTP proxy with RFC 9298 | UDP | RFC 9298 (August 2022), a newer standard few proxies offer |
| SOCKS4 | TCP | RFC 1928 extends "the SOCKS Version 4 model to include UDP" |
| SOCKS5 | TCP, and UDP through UDP ASSOCIATE | RFC 1928 |
The table is the protocol. Real proxies are narrower. At 20:18 UTC on 10 October 2026, our free proxy list held 4,933 live proxies. 1,846 answered HTTP, 1,111 HTTPS, 726 SOCKS4 and 2,004 SOCKS5, and many answered more than one. Only the SOCKS5 group can carry UDP at all. In a sample of 575 of them tested that evening, 17 relayed a real DNS query. Our page on SOCKS5 UDP shows why the others failed.
The client has a say too. Chromium's documentation states that "In Chrome SOCKSv5 is only used to proxy TCP-based URL requests". So even with a UDP-capable SOCKS5 proxy, Chrome sends it TCP only.
Which should you use with a proxy?
For web pages, APIs, scraping and account work, use TCP, through an HTTP or a SOCKS5 proxy. UDP loses this comparison. It gains nothing for HTTP traffic, because HTTP/3 falls back to TCP when it has to. Few proxies relay it, common clients such as Chrome never send it through SOCKS5, and lost datagrams fail in silence. For HTTP or SOCKS5, the choice between those two matters more than TCP against UDP.
DNS does not need UDP through the proxy either. It can go over TCP, or the proxy can resolve names itself, which is what socks5h asks for, as SOCKS4 vs SOCKS5 shows.
Use UDP only when the application needs it: voice, video, games or a target that speaks only QUIC. Then you need a SOCKS5 proxy that really relays UDP and a client that asks for it, and you should test both. Our UDP proxy checker sends a real DNS query through the relay. On our network, Residential Premium SOCKS5 lines generated with udp: true open a UDP relay, billed from the same balance as TCP traffic, from $1.00 per GB; see UDP residential proxies.
What this page could not check
Our timings come from one busy server, so the medians include our own delay; the fastest values compare the protocols more fairly. We measured DNS only, not downloads, voice, games or HTTP/3. We sent no traffic through a proxy for this page: proxy support comes from the standards, our free list counts and the UDP test on our companion page. Four lost UDP answers out of 140 show that loss happens without warning; they are not a loss rate to plan with. Support for RFC 9298 among real proxies was not measured. Our free list changes by the minute, so the counts here will be redone by 10 January 2027.
Sources
- RFC 9293, Transmission Control Protocol, IETF, August 2022.
- RFC 768, User Datagram Protocol, IETF, August 1980.
- RFC 9114, HTTP/3, IETF, June 2022.
- RFC 9112, HTTP/1.1, IETF, June 2022.
- RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport, IETF, May 2021.
- RFC 1035, Domain Names: Implementation and Specification, IETF, November 1987.
- RFC 7766, DNS Transport over TCP: Implementation Requirements, IETF, March 2016.
- RFC 3550, RTP: A Transport Protocol for Real-Time Applications, IETF, July 2003.
- RFC 9298, Proxying UDP in HTTP, IETF, August 2022.
- RFC 1928, SOCKS Protocol Version 5, IETF, March 1996.
- Chromium, Proxy support in Chrome, read 10 October 2026.
- HProxy: the UDP residential proxies product page and the free proxy list API, read 10 October 2026.
- Our own measurements, 10 October 2026: 140 DNS lookups each way to 1.1.1.1 and 8.8.8.8 from our server, three packet captures to 9.9.9.9, and the protocol counts of our free list. The script and every run's output are filed with this page's research.
