HTTP vs SOCKS5 Proxy: Handshake & Wire Specs

Almost every comparison of these two protocols scores them on speed and security, and almost every one of those scores is invented. Both protocols spend a handful of bytes agreeing how to open a connection and then get out of the way entirely. What actually differs is what happens during those bytes — and there are exactly three consequences worth knowing.

An HTTP Proxy Is Really Two Different Things

The phrase “HTTP proxy” names two behaviours that a comparison article usually blurs together. In the first, the client sends an ordinary request whose request line carries an absolute URI rather than a path, and the proxy is a full participant: it parses your headers, may cache the response, may filter it, and may add its own — a Via header naming itself, an X-Forwarded-For carrying your address. This is a forwarding proxy, and it reads everything.

In the second, the client sends CONNECT with a host and port instead of a URL, and asks the proxy to stop being an HTTP participant. RFC 9110 defines what happens next in unusually plain language: after a 2xx response the proxy becomes a tunnel that acts as a blind relay between two connections without changing the messages, and once active a tunnel is not considered a party to the HTTP communication at all. The specification even names carrying TLS through a shared firewall proxy as the point of the mechanism.

> CONNECT example.com:443 HTTP/1.1
> Host: example.com:443
>
< HTTP/1.1 200 Connection established
<
  ... every byte after this line is relayed untouched ...

That distinction decides how much of the standard comparison survives. Because essentially all traffic is HTTPS now, the HTTP proxy you are actually using is the tunnel, not the forwarding proxy — which means the caching, the header rewriting and the content filtering that most HTTP-versus-SOCKS5 articles credit to the HTTP side simply do not apply to the connection you will really open. Those are real capabilities of a forwarding proxy carrying cleartext, and they are unreachable on a tunnel by construction.

The SOCKS5 Handshake, Byte by Byte

SOCKS5, defined in RFC 1928, never learns what protocol it is carrying. The exchange opens with a greeting: the client sends a version byte, a count of authentication methods it supports, and the method codes themselves. The server answers with two bytes — the version, and the one method it has chosen. If it answers 0xFF, no method was acceptable and the client must close the connection.

The client then sends a request naming a command: 0x01 CONNECT for an outbound TCP connection, 0x02 BIND for an inbound one, or 0x03 UDP ASSOCIATE. The same request carries an address-type byte — ATYP — which may be 0x01 for a four-octet IPv4 address, 0x03 for a domain name whose first octet is its length, or 0x04 for a sixteen-octet IPv6 address. The server replies, and from that reply onward the connection is raw bytes in both directions.

> 05 02 00 02              VER=5, 2 methods offered: none, user/pass
< 05 02                    server chose 02 (username/password)

> 05 01 00 03 0b 65 78 61  VER=5, CMD=01 CONNECT, RSV=00,
  6d 70 6c 65 2e 63 6f 6d  ATYP=03 domain, LEN=11 "example.com"
  01 bb                    port 443
< 05 00 00 01 ...          REP=00 succeeded, then raw bytes

That protocol-agnosticism is the whole of the SOCKS5 advantage, and it is a real one. Nothing in the exchange above mentions HTTP, so the same endpoint carries an SSH session, an SMTP conversation, a game client or an in-house binary protocol that an HTTP proxy would have no vocabulary for. Where an HTTP proxy needs a request it can parse or a CONNECT it can honour, SOCKS5 needs an address and a port.

The third command, UDP ASSOCIATE, is the one exception to “raw TCP bytes”, and RFC 1928 leaves parts of it optional — an implementation that does not support fragmentation must simply drop the datagrams it cannot handle. Whether a given server implements the command at all is not something a specification can tell you, so the proxy checker is the place to settle it against a specific endpoint. It stays out of this page beyond this sentence.

The Same Two Exchanges in Words

HTTP CONNECT

1. Client to proxy: CONNECT example.com:443

   The request-target is an authority — a host and a port — rather than a URL with a path. The name is handed to the proxy by construction, so the proxy is the side that resolves it.

2. Optionally, proxy to client: 407, then client to proxy: Proxy-Authorization

   A proxy that demands credentials answers with a challenge and the client retries carrying them. This costs one extra round trip unless the client sends them pre-emptively.

3. Proxy to client: HTTP/1.1 200 Connection established

   The tunnel exists from this line onward. The proxy stops being a party to the conversation.

4. Client to origin, through the proxy: TLS, then payload

   Bytes are relayed unchanged in both directions. The proxy has your hostname and port and nothing else.

SOCKS5

1. Client to proxy: version 5 and a list of methods

   A greeting naming every authentication method the client is willing to use, most commonly 0x00 none and 0x02 username/password.

2. Proxy to client: the method it selected

   Two bytes. A reply of 0xFF means nothing offered was acceptable and the client must close the connection.

3. Optionally, the RFC 1929 subnegotiation

   If username/password was selected, the client sends its credentials and the server answers with a status byte. One more round trip.

4. Client to proxy: the request, with its ATYP byte

   The command, then an address type: 0x01 carries four already-resolved octets, 0x03 carries the domain name itself. This single byte is the socks5 and socks5h fork.

5. Proxy to client: the reply, then raw bytes

   A reply code of 0x00 means succeeded. Everything after it is your protocol, unexamined.

Who Turns the Hostname Into an IP Address

The socks5-versus-socks5h question has no HTTP equivalent at all, and that asymmetry is the sharpest genuine difference between the two protocols. An HTTP proxy is handed a hostname by construction: CONNECT's request-target is an authority, and a forwarding request line is an absolute URI. Either way the proxy receives a name and has to resolve it before it can open anything. There is no version of an HTTP proxy exchange in which the client has already done the lookup and passes an address instead.

SOCKS5 is the only one of the two that offers the choice, and it offers it as a single byte rather than as a setting. ATYP 0x01 says the four octets that follow are an address the client has already resolved. ATYP 0x03 says the bytes that follow are a name and the proxy should resolve it. Most client libraries default to resolving locally, which is why the choice usually has to be made deliberately.

What that actually changes is whose resolver answers, and resolvers do not all answer the same. A CDN steers you toward an edge near whoever asked; a split-horizon setup can return an entirely different record depending on where the query came from. Resolve locally and you get the answer for your own location while your traffic exits somewhere else, which is how a request ends up at an edge node that does not match its exit IP. Resolve at the proxy and the answer lines up with the exit. It also changes what your own network can observe, since a locally resolved name is a lookup your network sees regardless of where the traffic goes afterwards.

One more consequence hides in the same byte. ATYP 0x04 carries a sixteen-octet IPv6 address, so a SOCKS5 client that has resolved locally to an IPv6 record can hand it straight over — a detail that matters if you are working with IPv6 mobile proxies and want to know which side of the connection chose the address family.

Authentication, and the Hop Neither Protocol Encrypts

The two protocols authenticate on completely different mechanics. An HTTP proxy that wants credentials answers an unauthenticated attempt with 407 Proxy Authentication Required and a Proxy-Authenticate header describing the challenge; the client retries with a Proxy-Authorization header. It is a rejection followed by a retry, which is why it costs a round trip unless the client volunteers credentials up front.

SOCKS5 never rejects and retries. The method is negotiated before anything else happens: the client lists what it supports, the server names one, and if that method is 0x02 the two sides run the RFC 1929 subnegotiation — a version byte of 0x01, then a username length and username, then a password length and password, each between one and 255 octets, answered with a two-byte status in which 0x00 means success. RFC 1928 also defines 0x01 for GSSAPI, specified separately in RFC 1961, though it is rarely what a commercial proxy offers.

Different mechanics, identical security position: neither protocol encrypts the hop between you and the proxy. RFC 1929 says so about its own method in as many words, warning that because the request carries the password in cleartext, the subnegotiation is not recommended for environments where sniffing is possible and practical. HTTP is no better — Proxy-Authorization with the Basic scheme is base64, which is an encoding chosen for transport safety, not a cipher, and is trivially reversible by anything on the path.

This is also the cleanest way to see why the protocol question and the privacy question are not the same question. If what you actually want to know is what a proxy hides and from whom, and how that differs from a tunnel that encrypts the first hop by design, that comparison lives on proxy versus VPN rather than here.

Speed: What Is Measurable and What Is Folklore

The usual claim is that SOCKS5 is faster because it does not parse your traffic. It does not survive contact with the handshake. Both protocols stop parsing at exactly the same moment — the instant setup completes — and after that both are blind relays moving identical bytes over the same TCP connection to the same origin. There is no per-byte processing difference to measure, because there is no per-byte processing on either side.

On setup latency the ranking is the opposite of the folklore. HTTP CONNECT costs one round trip before your first payload byte: send CONNECT, receive 200. SOCKS5 costs two: greet, receive the method, send the request, receive the reply. Add username/password authentication and SOCKS5 costs three, while HTTP costs two only if the client waits to be challenged rather than sending credentials pre-emptively. That arithmetic is ours rather than the RFCs', but it follows directly from the message counts each specification requires.

Which means the variables that actually decide your throughput are the ones neither protocol controls: the route between the proxy and the origin, the exit network's conditions — radio quality and peering on a mobile exit, congestion on any exit — and how well your client reuses connections. On a long-lived session the setup cost is paid once and is statistical noise. On a scraping workload that opens a fresh connection per request, per-connection cost dominates everything, and the fix is connection reuse rather than a different protocol.

For what genuinely moves the number on a collection workload — concurrency per host, retry behaviour, and the shape of the requests themselves — the Python 数据抓取指南 is the more useful page than any protocol comparison.

Which One Your Client Actually Wants

Protocol choice is decided by two things: what your traffic actually is, and what your client configures without help. It is not decided by a general verdict, because for the most common case there is no meaningful difference to decide on.

Read down the last two columns and the honest conclusion is that for HTTPS traffic they are the same product. If your traffic is HTTPS from a browser, a scraping framework or an HTTP library, both tunnel it identically, and the right choice is whichever one your tool configures natively.

When SOCKS5 Is the Answer

• The traffic is not HTTP at all — SSH, SMTP, a database client, a game client, or an in-house binary protocol. A CONNECT tunnel can technically carry any of these, but only if the client knows how to ask for one, and most non-HTTP clients do not.
• You want a single system-wide entry point that everything on the machine can be pointed at, rather than per-application HTTP proxy settings that many applications quietly ignore.
• You need proxy-side name resolution from a client that only offers it on the SOCKS path, which is a common shape — the setting exists on the SOCKS side and has no HTTP counterpart to toggle.
• You need UDP relay, which no HTTP proxy offers. Whether a specific SOCKS5 server implements it is a separate question, and one only a live test answers.

Outside those cases, the cheaper or simpler option is genuinely fine, and picking the one your client already supports costs you nothing measurable. PXM2 ships both, on separate ports, so the choice stays a client-side one rather than a purchase decision. If you are still deciding between proxy categories rather than protocols — which is a different question with real cost consequences — start from the types of proxies explained or the proxy types hub.

Deploy HTTP and SOCKS5 Mobile Proxies

Every PXM2 mobile proxy provides both HTTP and SOCKS5 endpoints on dedicated ports:

常见问题解答

Related Guides

Proxy fundamentals

核心移动代理指南