SOCKS5 vs HTTP Proxy: The Protocol Differences That Matter
HTTP proxies speak HTTP and tunnel HTTPS with CONNECT; SOCKS5 relays any TCP or UDP traffic. What that means for DNS, authentication, tooling and error handling.
By the Proxonym team
An HTTP proxy understands the HTTP protocol: it forwards web requests and tunnels HTTPS through the CONNECT method. A SOCKS5 proxy works one layer lower and relays any TCP connection, plus UDP when the server supports it, without parsing the traffic. For scraping websites, both reach the same pages at practically the same speed. The differences that decide which one to use are DNS resolution, UDP support, authentication support in your tools, and how errors are reported.
How an HTTP proxy works#
For a plain http:// URL, the client sends the full URL to the proxy, and the proxy makes the request on its behalf. The proxy sees, and could modify, the whole request and response.
For an https:// URL, the client asks the proxy to open a tunnel:
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic VVNFUk5BTUU6UEFTU1dPUkQ=
HTTP/1.1 200 Connection establishedAfter the 200, the proxy copies bytes in both directions. The client runs its TLS handshake with example.com through the tunnel, so the proxy sees the hostname and port but none of the encrypted content. Credentials travel in the Proxy-Authorization header as Base64, which is an encoding, not encryption. Missing or wrong credentials get a 407 Proxy Authentication Required.
Because the proxy speaks HTTP, it can explain failures with status codes. Our gateway returns 402 when your traffic balance runs out, 403 for a target blocked by the acceptable use policy, 429 when the request rate guard kicks in, 502 when an upstream peer fails and 504 when a target takes longer than 60 seconds.
HTTP proxy or HTTPS proxy: a naming trap#
"HTTPS proxy" can mean two different things. Usually it means an HTTP proxy that tunnels HTTPS sites through CONNECT, which is what port 8000 on our gateway does. Strictly, it means a proxy you reach over TLS, so the hop to the proxy, credentials included, is encrypted. Clients treat the two differently: a proxy URL that starts with https:// tells most libraries to open TLS to the proxy itself. Point that at a plain HTTP proxy port and you get TLS errors such as WRONG_VERSION_NUMBER. Keep the proxy URL on http:// even when every target is HTTPS.
How a SOCKS5 proxy works#
SOCKS5, defined in RFC 1928, is a small binary protocol. The client greets the proxy with the authentication methods it supports, authenticates (username and password authentication is defined in RFC 1929), then sends a command with a destination. The destination can be an IPv4 address, an IPv6 address or a domain name. The proxy's reply carries a one-byte status code, and from then on the proxy relays raw bytes. It never parses HTTP.
The protocol has three commands:
- CONNECT opens a TCP connection to the destination. Web traffic uses this.
- BIND accepts an inbound connection, used by a few legacy protocols.
- UDP ASSOCIATE relays UDP datagrams, for example DNS lookups, QUIC (HTTP/3), voice or game traffic.
UDP needs support on the server side. In our lineup it is available on shared datacenter proxies, ISP proxies, and unlimited residential plans with the UDP add-on.
DNS resolution: socks5 vs socks5h#
Because SOCKS5 accepts either an IP or a hostname, the client decides who resolves DNS. With local resolution (socks5:// in most tools, --socks5 in curl), your machine looks up the hostname and sends the proxy an IP. With remote resolution (socks5h://, --socks5-hostname), the proxy does the lookup.
Remote resolution is almost always what you want. Local lookups reveal every site you visit to your own DNS resolver. Worse, geo-aware DNS answers with servers near you rather than near the exit IP, so a request meant to look German may land on a US edge server and get US content.
What about SOCKS4 and SOCKS4a?#
SOCKS4 is the older version: TCP only, IPv4 only, no password authentication (just a user ID field), and the client must resolve DNS itself. SOCKS4a added hostname support so the proxy can do the lookup. Neither supports UDP or IPv6. Unless a legacy tool leaves you no choice, use SOCKS5.
SOCKS5 vs HTTP proxy side by side#
| Aspect | HTTP proxy | SOCKS5 proxy |
|---|---|---|
| Layer | Application: speaks HTTP | Session: protocol-agnostic |
| Traffic | HTTP; HTTPS and other TCP through CONNECT | Any TCP; UDP through UDP ASSOCIATE |
| What the proxy sees | Full requests for plain HTTP; host and port for HTTPS | Destination address and port only |
| DNS resolution | By the proxy, from the hostname in the request | Client or proxy (socks5 vs socks5h) |
| Authentication | Basic, in the Proxy-Authorization header | Username and password subnegotiation |
| Error reporting | HTTP status codes such as 407, 502 or 504 | One-byte reply codes such as "connection refused" |
| Authenticated use in Chromium | Supported | Not supported |
| Proxonym ports | Gateway 8000, shared datacenter 3129 | Gateway 1080, shared datacenter 1081 |
ISP and dedicated datacenter proxies accept both protocols on the same port, so switching is only a change of scheme. Neither protocol encrypts the hop between you and the proxy, and HTTPS content stays encrypted end to end with either one.
Which tools support what#
| Tool | HTTP proxy with auth | SOCKS5 |
|---|---|---|
| curl | Yes: -x http://host:port -U user:pass | Yes: --socks5-hostname or socks5h:// |
| Python requests | Yes, built in | Yes, after pip install "requests[socks]" |
| Scrapy | Yes, through request.meta["proxy"] | Not built in |
| Node.js | undici ProxyAgent or https-proxy-agent | socks-proxy-agent |
| Puppeteer and Playwright (Chromium) | Yes: page.authenticate() or the proxy option | Only without authentication, for example with a whitelisted IP |
The practical consequence: authenticated browser automation runs over HTTP. Setup for each language is in the documentation, and the Python requests guide and Puppeteer and Playwright guide go deeper.
curl examples for both protocols#
# HTTP proxy on port 8000: HTTPS goes through a CONNECT tunnel
curl -x http://gw.proxonym.com:8000 -U "USERNAME-country-de:PASSWORD" https://api.ipify.org
# SOCKS5 on port 1080, hostname resolved by the proxy
curl --socks5-hostname gw.proxonym.com:1080 -U "USERNAME-country-de:PASSWORD" https://api.ipify.org
# The same SOCKS5 request in URL form
curl -x "socks5h://USERNAME-country-de:[email protected]:1080" https://api.ipify.org
# SOCKS5 with local DNS: works, but leaks lookups and can pick the wrong edge server
curl --socks5 gw.proxonym.com:1080 -U "USERNAME-country-de:PASSWORD" https://api.ipify.orgAdd -v to watch the handshake. Over the HTTP proxy you see the CONNECT request and the gateway's status line, so a 407 or 402 is obvious. Over SOCKS5, curl can only report the generic reply code, so diagnose credential and balance problems on port 8000 first.
Which one should you use?#
Default to HTTP for web scraping, API calls and browser automation. Every HTTP library supports it, authentication works in headless browsers, and status codes tell you exactly why a request failed. Every product supports HTTP proxies; on the residential gateway, use port 8000.
Choose SOCKS5 when:
- the client speaks a protocol other than HTTP;
- you need UDP, for example for QUIC, DNS or real-time media testing;
- an application only offers a SOCKS setting, as many desktop clients do;
- you want one generic tunnel for everything an application sends, with DNS resolved at the proxy.
See SOCKS5 proxies for the products and ports that support it.
Speed is rarely the deciding factor. For HTTPS, both protocols set up a tunnel once and then copy bytes, and the handshake overhead is tiny next to network latency. Security is not a deciding factor either: neither protocol encrypts the hop to the proxy. Limit the damage of a leaked credential instead by giving each application its own sub-user with its own traffic limit.
Key takeaways#
- HTTP proxies parse HTTP and tunnel HTTPS with CONNECT; SOCKS5 relays any TCP, plus UDP where the server supports it.
- With SOCKS5, resolve DNS at the proxy:
socks5h://or--socks5-hostname. - HTTP proxies report clear status codes; SOCKS5 errors are terse.
- Chromium cannot authenticate to SOCKS5 proxies, so authenticated browser automation uses HTTP.
- Pick SOCKS5 for non-HTTP traffic, UDP or SOCKS-only applications, and HTTP for everything else.
