An HTTP proxy and a SOCKS5 proxy both change the address a site sees. They differ in what they understand, in how they open a connection, and in who looks up the site's name. Most comparisons stop at "SOCKS5 is faster" or "SOCKS5 is more secure", and neither claim survives a look at the wire.
So we looked. On October 23, 2026, we ran curl 8.5.0 through two stub proxies on our own machine, an HTTP proxy and a SOCKS5 proxy, both asking for a login. Each one counted every byte and every round trip before the site's first byte arrived. Below: what each protocol does, what we measured, and which one to pick for which job.
What each one does
An HTTP proxy understands HTTP. For a plain http address it reads your request and fetches the page. For an https address, which is nearly every site today, your client sends it one line, CONNECT with the host and port. The proxy opens a connection to the site and from then on passes bytes both ways. RFC 9110 calls that tunnel "a blind relay between two connections without changing the messages".
A SOCKS5 proxy understands no application protocol at all. Your client tells it which host and port to reach, and it relays the bytes, whatever they are: web pages, mail, a database protocol or game traffic. RFC 1928 also gives it a command for UDP, UDP ASSOCIATE, which an HTTP tunnel lacks.
For an https page, the end result is the same through both: an encrypted stream that neither proxy can read.
What happens before the first byte
The difference is in the setup. Curl and our two stubs exchanged this much before the tunnel opened:
The HTTP proxy took one round trip. curl sent the CONNECT line with the login already in it, 174 bytes, and the proxy answered "200 Connection established" in 39.
The SOCKS5 proxy took three. First a greeting, in which curl offered three login methods: none, GSSAPI and username with password. Then the login itself. Then the request to connect. Each step waited for the proxy's answer before the next one left.
Bytes this small cost nothing. Round trips cost time: each one is a full trip to the proxy and back. So with a login, a new SOCKS5 connection pays two more network delays than an HTTP one before the site sees anything. A scraper that keeps connections open pays that once. One that opens a fresh connection per request pays it every time.
Who looks up the site's address
For the HTTP proxy, curl sent "CONNECT target.test:443": the name itself. The proxy side always does the lookup.
SOCKS5 gives you the choice, and the choice is one letter. With socks5:// curl resolved the name on our machine and sent the proxy an IP address. With socks5h:// it sent the name, and the proxy would resolve it. The requests library works the same way: "If you want to resolve the domains on the proxy server, use socks5h as the scheme," its docs say.
That letter matters on a residential line. Some DNS servers tailor answers to where the query comes from: RFC 7871 describes nameservers that "tailor responses based upon location of the querier". Resolve at home and you may get servers near you, then reach them through an exit in another country. Resolve at the exit with socks5h, and the address matches the location the site sees.
What the login looks like on the wire
Neither protocol hides your proxy login. RFC 1929, which defines the SOCKS5 login, says "the request carries the password in cleartext". RFC 7617 says the same of the Basic login HTTP proxies use: it "is not a secure method of user authentication". In our run, both stubs read the login straight off the connection.
So "SOCKS5 is more secure" has no basis in either standard. The protection you have is https between you and the site, and it works the same through both proxies.
When UDP decides it
An HTTP tunnel carries one TCP stream. SOCKS5 can also relay UDP, through UDP ASSOCIATE. Most scraping and browsing runs over TCP, so this rarely matters there. It matters for voice, some games, and QUIC, the protocol under HTTP/3.
Not every SOCKS5 server relays UDP, and not every client asks for it. Check both. On our side, Residential Premium relays UDP over SOCKS5, switched on per generated line. Residential Lite speaks SOCKS5 without UDP.
Browsers and apps
The client often makes the choice for you. Chrome 155, in our run for another guide, rejected a login written into its proxy switch, for HTTP and SOCKS5 alike. Its SOCKS5 greeting offered only "no authentication". So in Chrome, a SOCKS5 proxy works only without a password, for example from an address your provider lets in without a login. Our Chrome setup guide covers the options.
Command-line tools and libraries are more flexible. curl takes both, chosen by the scheme. Python's requests needs one extra install for SOCKS, pip install 'requests[socks]', and then takes socks5h:// like curl.
Side by side
| HTTP proxy | SOCKS5 proxy | |
|---|---|---|
| Round trips to open, with a login | 1 in our run | 3 in our run |
| Bytes before the tunnel opened | 213 | 55 to 63 |
| Who resolves the site's name | Always the proxy side | You, with socks5; the proxy, with socks5h |
| What it carries | HTTP, and https through CONNECT | Any TCP stream, and UDP through UDP ASSOCIATE |
| The login on the wire | Basic, readable (RFC 7617) | Username and password, readable (RFC 1929) |
| A login in Chrome's proxy switch | Rejected in our run | Rejected; no SOCKS5 login offered |
How to see which one you got
curl tells you in its verbose output. Add -v and look for these lines, copied from our run:
* Establish HTTP proxy tunnel to target.test:443
* CONNECT tunnel established, response 200
* SOCKS5 connect to 127.0.0.1:443 (locally resolved)
* SOCKS5 request granted.
* SOCKS5 connect to target.test:443 (remotely resolved)
* SOCKS5 request granted.
The first pair is an HTTP proxy. The second is socks5://, where your machine looked up the name; the third is socks5h://, where the proxy did. If a SOCKS5 setup should resolve at the exit and you see "locally resolved", change the scheme.
Which one to pick
- A web scraper or a browser, over https: an HTTP proxy. One round trip per new connection, the login works in more clients, and the proxy resolves names at the exit.
- Anything that is not HTTP: SOCKS5. Mail, SSH, databases and custom protocols need a relay that does not care what the bytes are.
- UDP traffic: SOCKS5, from a provider that relays UDP.
- SOCKS5 for any reason: use socks5h, so names resolve at the exit.
- Many short connections: prefer HTTP, or keep SOCKS5 connections open and reuse them.
Our gateways for both
Both of our residential products answer on both protocols. Use the login from your dashboard in place of YOUR-LOGIN and YOUR-PASSWORD:
# Residential Lite, HTTP (port 6969) and SOCKS5 (port 9696)
curl -x http://YOUR-LOGIN:YOUR-PASSWORD@gw.hproxy.com:6969 https://example.com/
curl -x socks5h://YOUR-LOGIN:YOUR-PASSWORD@gw.hproxy.com:9696 https://example.com/
# Residential Premium: HTTP 9000 rotating, 10000 and up sticky; SOCKS5 11000 rotating, 12000 and up sticky
curl -x http://YOUR-LOGIN:YOUR-PASSWORD@premium.hproxy.com:9000 https://example.com/
curl -x socks5h://YOUR-LOGIN:YOUR-PASSWORD@premium.hproxy.com:11000 https://example.com/
Residential Lite costs $0.50/GB for one GB, falling to $0.44/GB at 2,000 GB+. Residential Premium costs $1.49/GB for one GB, falling to $1.00/GB at 1,000 GB+. The protocol you choose does not change the price. For the SOCKS5 handshake step by step, see what a SOCKS5 proxy is.
Sources
- RFC 9110, HTTP Semantics, the CONNECT tunnel, June 2022.
- RFC 1928, SOCKS Protocol Version 5, March 1996.
- RFC 1929, Username/Password Authentication for SOCKS V5, March 1996.
- RFC 7617, The 'Basic' HTTP Authentication Scheme, September 2015.
- RFC 7871, Client Subnet in DNS Queries, May 2016.
- Requests: SOCKS proxies, read October 23, 2026.
- curl man page, proxy schemes, read October 23, 2026.
- Our own runs on October 23, 2026: curl 8.5.0 against an HTTP and a SOCKS5 stub proxy on 127.0.0.1, and headless Chrome 155 against stub proxies for our Discord guide. Nothing outside the machine was contacted.
