TCP
The connection-oriented protocol that carries almost all proxy traffic, providing ordered, reliable delivery at the cost of a setup handshake.
Nearly everything a proxy carries rides on TCP, and most of what a proxy IS only makes sense once you know what TCP demands. It is the internet's reliable transport: before any data moves, the two ends perform a three-step handshake, the client sends a SYN, the server answers with a SYN-ACK, the client confirms with an ACK, and only then does a connection exist. Every byte after that is numbered, acknowledged, retransmitted if lost, and delivered in order.
The handshake is why proxies work at all, and the point deserves spelling out because it answers a question people keep asking. You cannot simply write somebody else's address on your packets and browse as them, because the server's SYN-ACK goes to the address you claimed, not to you, and the handshake never completes. Faking a source address on TCP gets you silence. The only way to make traffic genuinely originate from another address is for a real machine at that address to open the connection on your behalf, which is precisely the service a proxy sells.
The same handshake is also a tax, and it is priced in round trips. Opening a TCP connection costs one full round trip before the first byte of your request can leave, and TLS on top adds at least another. Through a proxy there are two legs, you to the proxy and the proxy to the destination, each paying its own setup. This is why connection reuse matters so much in practice: an HTTP client that keeps connections alive pays the setup once per server rather than once per request, and a scraper that opens a fresh connection per request is spending most of its time in handshakes.
TCP's guarantees have one structural cost worth knowing: everything arrives in order, so one lost packet holds up everything queued behind it until the retransmission lands. That head-of-line blocking is a genuine limit of the protocol, and it is the reason the newest version of the web, HTTP/3, abandoned TCP for a transport built on UDP. Proxies remain overwhelmingly TCP creatures, which is why a browser configured to use one quietly falls back from HTTP/3 to the TCP-based protocols the proxy can carry.
In proxy vocabulary, TCP is the shared floor. An HTTP proxy parses what rides on the connection; a SOCKS5 proxy relays the connection without reading it; both are managing TCP streams. The port number you configure names which service to reach; the handshake is what actually opens the door.
Frequently asked questions
Why can't I just spoof my IP address instead of using a proxy?
Because TCP requires a completed handshake before any data flows, and the handshake replies go to the address you claimed. Spoof a source address and the SYN-ACK is delivered somewhere you cannot see, the connection never establishes, and no page is ever served. Changing your visible address for real web traffic requires a machine that genuinely holds that address to relay for you, which is what a proxy is.
Does a proxy add TCP overhead?
Yes, structurally: the path becomes two connections, you to the proxy and the proxy to the destination, and each pays its own handshake and TLS setup. Good clients blunt this by reusing connections, so the cost lands once per server rather than once per request. If your workload opens a fresh connection every request, setup time will dominate and the proxy will look slower than it is.
Is TCP faster than UDP?
It is not a speed contest so much as a different contract. TCP spends time guaranteeing order and delivery: handshake first, acknowledgements throughout, retransmission on loss, and one lost packet delaying everything behind it. UDP skips all of that and simply sends. For bulk correctness TCP wins; for latency-sensitive traffic that would rather lose data than wait, UDP does; HTTP/3 gets both by rebuilding reliability on top of UDP.
Why does my proxy not support HTTP/3?
Because HTTP/3 runs over QUIC on UDP, and conventional proxy protocols relay TCP. A browser configured with a proxy detects this and falls back to HTTP/2 or HTTP/1.1 over TCP, which every site still serves. Nothing breaks; the connection simply uses the older transport, which is one of several reasons traffic through a proxy has a slightly different shape than traffic without one.
Back to the full glossary.