HTTP vs SOCKS5 Proxies: Which Protocol Should You Use?

An HTTP proxy speaks HTTP. You hand it a request, it understands the method, the target URL and every header, and it can cache, rewrite or refuse what you sent. SOCKS5 speaks almost nothing. You tell it a host and a port, it opens the connection, and from then on it shovels bytes in both directions without knowing whether they are HTTP, SSH or a game protocol.

That difference sounds academic until it shows up as a DNS leak, a geo mismatch, or a QUIC connection that silently refuses to go through your proxy. Here is what each protocol does on the wire and how to pick between them.

Where each protocol sits in the stack

An HTTP proxy is an application-layer intermediary defined by the HTTP specification itself. SOCKS5, standardised in RFC 1928, sits below the application: it is a short binary negotiation followed by a transport-layer relay. Neither is encrypted on its own. Both carry TLS perfectly well, because in both cases the TLS session is established end-to-end between your client and the target.

What an HTTP proxy sees

For a plaintext http:// URL, your client sends the request to the proxy using the absolute form of the request target, so the request line reads GET http://example.com/products HTTP/1.1 instead of the origin form a server would receive. The proxy has the whole request in front of it. It can serve from cache, append a Via header, add X-Forwarded-For, strip headers, log the full URL, or return its own error page.

HTTPS turns the same proxy into a blind tunnel

Ask for an https:// URL and the client switches to the CONNECT method, sending the authority form of the target and nothing else useful:

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==

HTTP/1.1 200 Connection established

After that 200, the proxy is a pipe. Your TLS ClientHello goes through untouched, the certificate is validated against the real target by your client, and the proxy sees encrypted bytes plus one hostname in the CONNECT line and the TLS SNI field. Caching, header injection and content inspection all stop working. Since practically everything worth scraping is HTTPS, the supposed intelligence of an HTTP proxy rarely comes into play.

What SOCKS5 does instead

A SOCKS5 session opens with a greeting listing the authentication methods your client supports. The server picks one. If it chose username and password, a small sub-negotiation follows. Then the client sends a request containing a command and an address.

• CONNECT (0x01). Open an outbound TCP connection to the destination. This is what every proxy client uses.
• BIND (0x02). Ask the proxy to listen for an inbound connection, designed for protocols like active-mode FTP. Rarely implemented by commercial vendors.
• UDP ASSOCIATE (0x03). Set up a UDP relay so datagrams can be sent through the proxy. This is the capability HTTP proxies have no equivalent for.

The address in that request carries an address-type byte: IPv4, IPv6, or a domain name. That one byte is the source of the most expensive mistake in proxy configuration, because your client chooses which of the three to send.

DNS resolution is where the leaks happen

An HTTP proxy always receives a hostname, in the request line or in CONNECT, so name resolution happens at the proxy and there is nothing to configure. SOCKS5 lets the client resolve the name locally and send a bare IPv4 address instead. Many libraries do exactly that by default, and the consequences are easy to miss.

• Your resolver learns every hostname you visit, which defeats the point of routing the traffic elsewhere.
• Geo-aware DNS answers the wrong question. A CDN maps the querying resolver to a nearby edge node, so a request that exits in Madrid can be pinned to a US edge address and served US content. Anyone doing geotargeted collection will see inconsistent results without understanding why. The proxy geotargeting guide covers verification.
• Split-horizon and load-balanced hosts break. You connect to an address that was correct for your location and may be stale or unreachable from the exit.

curl encodes the distinction in the scheme. socks5:// resolves locally. socks5h:// sends the hostname for the proxy to resolve, and the h is the only difference between a clean setup and a leaking one.

# HTTP proxy: the hostname always travels to the proxy
curl -x http://USER:[email protected]:8080 https://api.ipify.org

# SOCKS5, local DNS: your resolver sees api.ipify.org  (usually wrong)
curl -x socks5://USER:[email protected]:1080 https://api.ipify.org

# SOCKS5, remote DNS: the exit resolves the name  (what you want)
curl -x socks5h://USER:[email protected]:1080 https://api.ipify.org

Other clients hide the same switch elsewhere. Firefox exposes it as a "Proxy DNS when using SOCKS v5" checkbox. Python's requests needs the socks5h scheme in the same way curl does. Chromium resolves remotely for SOCKS5 by default. Check yours rather than assuming.

Authentication and what it does not cover

HTTP proxies authenticate with a Proxy-Authorization header, almost always Basic, which is base64 of your credentials. A proxy that has not been told anything replies 407 with a challenge and the client retries. SOCKS5 authenticates during the greeting, most commonly with the username and password method from RFC 1929, which puts the credentials on the wire in clear text.

Neither scheme protects the credentials by itself, because in both cases the leg between you and the proxy is plaintext. TLS to the target protects your payload and leaves the proxy handshake exposed. Two things fix it: IP allowlisting instead of passwords, which most vendors support, or an HTTPS proxy endpoint where the client opens TLS to the proxy before speaking HTTP to it. Reused credentials on shared gateways are one of the many reasons free proxy lists are a bad idea.

UDP, QUIC and everything that is not a web page

HTTP proxies move TCP. That is the whole story. UDP ASSOCIATE gives SOCKS5 a path for datagrams, which is the only way to carry DNS queries, QUIC or media transport through a proxy at all.

Support in the commercial market is thin. Most residential and datacenter gateways that advertise SOCKS5 implement CONNECT and quietly reject UDP ASSOCIATE. The practical effect is that HTTP/3 does not survive the trip: browsers and clients fall back to HTTP/2 over TCP, which is fine for collection but worth knowing if you are fingerprinting protocol negotiation or measuring what a real user would experience.

Handshake cost and connection reuse

Throughput is identical. Both protocols relay the same bytes, and the exit node dominates everything you measure, as the spread in our latency rankings shows. Connection setup is where a real difference exists, and it runs against the intuition that the lighter binary protocol must be faster.

On a residential gateway with a hundred milliseconds of round-trip time, the difference between one and three trips is a few hundred milliseconds on every new connection. It disappears entirely if you keep connections alive and reuse them, which you should be doing anyway. Measure it on your own path with the method in how to test proxy speed.

Which one to use for which job

For the overwhelming majority of collection work, use the HTTP endpoint. It is the interface every vendor supports first, the one their session syntax is tested against, and it removes the DNS question entirely. Switch to SOCKS5 when your traffic is not HTTP, or when the tool you are stuck with only speaks SOCKS. The wider stack decisions sit in the web scraping proxy guide.

Confirming what your client actually did

Two checks catch nearly every misconfiguration. Run curl -v and read the handshake: an HTTP proxy shows the CONNECT exchange, a SOCKS5 connection shows the method negotiation and whether the hostname or an IP was sent. Then confirm the exit itself.

# Does the exit report the country and ASN you paid for?
curl -s -x socks5h://USER:[email protected]:1080 https://ipinfo.io/json

# Same request over the HTTP endpoint, for comparison
curl -s -x http://USER:[email protected]:8080 https://ipinfo.io/json

# Watch the proxy handshake itself
curl -v -x socks5h://USER:[email protected]:1080 https://example.com -o /dev/null

If the two endpoints report different countries for the same session identifier, the vendor is parsing your username differently per protocol and you have found a real bug worth raising. We run the same class of checks continuously across the vendors on the live benchmark table, and the procedure is documented in our methodology and in how to benchmark proxy providers.