SOCKS5, defined in RFC 1928 with username and password authentication in RFC 1929, works a layer below HTTP. The client tells the proxy which host and port to connect to, the proxy opens the connection, and from then on it relays bytes without interpreting them. It adds no headers and does not care whether the traffic is HTTP, SMTP, a database protocol or a game.
SOCKS5 vs HTTP proxies
| SOCKS5 | HTTP proxy | |
|---|---|---|
| Carries | Any TCP, and UDP where supported | Web traffic |
| Adds headers | Never | Can, on plain HTTP |
| Hostname resolution | Client or proxy, your choice | Proxy |
| Library support | Often needs an extra package | Built in almost everywhere |
For scraping websites, both work. SOCKS5 earns its place with non-HTTP protocols and apps that only offer a SOCKS setting.
Using it
In curl and Python requests, the URL scheme selects it:
curl -x socks5h://USERNAME:PASSWORD@HOST:PORT "https://api.ipify.org?format=json"
Python needs the extra: pip install "requests[socks]". Use socks5h rather than socks5 so the proxy, not your machine, looks up hostnames and you avoid a DNS leak.
On ProxyHive
HTTP, HTTPS and SOCKS5 are supported, and the dashboard lists a SOCKS5 port for each ISP or datacenter IP next to its HTTP port. Copy the one for the protocol you use.
Common confusion
SOCKS5 does not encrypt anything; it relays whatever you send. And Chromium-based browsers cannot send a username and password to a SOCKS5 proxy, so in Chrome, Puppeteer or Playwright use the HTTP port or an IP allowlist. HTTP vs SOCKS5 proxies covers the rest.