SOCKS5 vs HTTP proxies: which one your tool actually needs

Your tool has a dropdown that says HTTP, HTTPS, SOCKS4 and SOCKS5, and nobody told you which one to pick. This is the SOCKS5 vs HTTP proxy question answered for people who want to get on with their day: what each protocol does, where your DNS lookups go, which libraries need an extra package, and the one-line change that moves a script from one to the other.

SOCKS5 vs HTTP proxy: the short answer

For web scraping and browsing, use HTTP. It works in every tool without extra packages, it handles https:// sites through a tunnel the proxy cannot read, and browsers accept it with a password. Pick SOCKS5 when the traffic is not HTTP at all, or when the tool only speaks SOCKS.

That covers most people. The rest of this page is for the cases where the difference shows up.

HTTP vs HTTPS proxy: what an HTTP proxy does

An HTTP proxy understands web requests. For a plain http:// URL your client hands it the whole request and the proxy makes it for you, so it can see everything: the URL, the headers, the page.

For an https:// URL, which is nearly every site now, your client sends one line first:

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

The proxy opens a TCP connection to example.com, answers 200 Connection established, and from then on it only shovels encrypted bytes. It knows the hostname and the port you asked for. It never sees the path, the cookies or the page. TLS runs end to end between you and the site.

Notice the Proxy-Authorization line. That is your username and password, base64-encoded, which is an encoding and not encryption. The hop from you to the proxy is plain TCP, so on a network you do not trust, the password is readable to anyone watching it. SOCKS5 sends its password in the clear too. Neither is a reason to panic, but both are a reason not to reuse that password anywhere else. If you want that hop encrypted, that is a VPN’s job, and the proxy vs VPN guide covers when it is worth having one.

So what is an HTTPS proxy? Usually it is marketing shorthand for “an HTTP proxy that supports CONNECT”, which is all of them. Occasionally it means a proxy you talk to over TLS. That is why the proxy URL in your code starts with http:// even when every site you visit is https://: the scheme describes the hop to the proxy, not the site. The HTTP proxy glossary entry has a diagram of both hops.

What a SOCKS5 proxy does

A SOCKS5 proxy sits a layer lower. Your client says “connect me to this host on this port”, the proxy does, and after that the bytes pass through untouched. It does not know or care whether they are HTTP, a database protocol or an SSH session. That generality is its whole selling point.

Where it matters in practice: a database client, a mail client talking IMAP, a game or chat client, anything that opens a raw TCP connection and has never heard of HTTP. An HTTP proxy can technically tunnel those through CONNECT too, but far fewer non-web tools know how to ask, while “SOCKS5 proxy” is a setting many of them ship with.

Authentication is a username and password, sent in its own small exchange before the connect request. The protocol also defines a UDP ASSOCIATE command for relaying UDP, which sounds useful until you find how unevenly it is supported: plenty of clients never implement it and plenty of proxy services never offer it. We do not advertise UDP relaying, so treat our SOCKS5 as TCP only.

socks5 vs socks5h: where DNS gets resolved

This is the part that actually bites. Before connecting anywhere, a hostname has to become an IP address, and with SOCKS5 your client decides who does that lookup.

• socks5:// in curl, Python requests and Node’s socks-proxy-agent: your machine resolves the hostname, then asks the proxy to connect to the IP.
• socks5h://: the hostname goes to the proxy, and the proxy resolves it. The h is for hostname.

Resolving locally has two costs. Your own DNS resolver, usually your ISP’s, sees every hostname you visit through the proxy, which is the “DNS leak” people worry about. And big sites answer DNS by location: a CDN hands you the edge nearest to you, not to the exit IP, so a request leaving from another country can land on a far-away server or get content meant for your region. With socks5h the answer matches the place your request actually leaves from.

An HTTP proxy never has this problem, because the hostname is in the request line. The proxy always resolves it. If you remember one thing from this page: when you use SOCKS5, write socks5h.

curl has flag versions of the same choice: --socks5 resolves locally and --socks5-hostname hands the name to the proxy. Browsers decide for you in different ways. Chrome always lets a SOCKS5 proxy resolve hostnames, with no option to change it. Firefox has a Proxy DNS when using SOCKS v5 checkbox, ticked by default in current versions.

Is SOCKS5 faster than HTTP?

No, not in any way you will measure. Once the connection is set up, both protocols pass the same bytes over the same TCP connection, and speed comes down to the exit’s network and the distance to the site.

If anything, setup goes the other way. A SOCKS5 connection with a password usually takes three round trips to the proxy before your request goes out: pick an auth method, send the password, ask for the connection. An HTTP CONNECT with the credentials sent up front, which curl and requests both do, takes one. On a proxy far from you that is a few hundred milliseconds per new connection, and it disappears once connections are reused.

The myth probably comes from SOCKS5 being described as “lightweight” because it does not parse HTTP. True, and irrelevant: parsing a request line is not where your time goes.

What does make a difference is reusing connections. Every new connection repeats the handshake, whichever protocol you chose, so a requests.Session in Python or one shared agent in Node saves more time than switching protocols ever will.

Which tools support SOCKS5 proxies

HTTP proxy support is everywhere. SOCKS5 support is common but often needs an extra package, and browsers have one specific hole.

The browser row is the one that sends people to support. The guide to using a proxy in Chrome and Firefox covers the workarounds, and the SwitchyOmega setup guide explains why the extension shows a warning when you pick SOCKS5 and click the lock button.

API and automation tools have holes of their own. Postman lists SOCKS5 in its proxy settings but sends only HTTP and HTTPS requests through it, as the Postman proxy guide explains. n8n’s HTTP Request node silently drops a socks5:// proxy URL and falls back to the instance’s proxy settings, or to none; the n8n proxy guide has the format that works.

Switching from HTTP to SOCKS5 in curl, Python and Node

Every example below uses placeholders. Use the host, port and credentials your dashboard lists for the order, and write the scheme as socks5h://.

curl. Change the scheme. Nothing else.

curl -x http://USER:PASS@IP:PORT https://httpbin.org/ip
curl -x socks5h://USER:PASS@IP:PORT https://httpbin.org/ip

Python requests. Install the extra once, then swap the URL. Both dictionary keys point at the same proxy.

pip install "requests[socks]"

import requests

PROXY = "socks5h://USER:PASS@IP:PORT"

r = requests.get(
    "https://httpbin.org/ip",
    proxies={"http": PROXY, "https": PROXY},
    timeout=30,
)
print(r.json())

Forget the extra and requests raises InvalidSchema: Missing dependencies for SOCKS support. With httpx it is the same story, with a different extra:

pip install "httpx[socks]"

import httpx

r = httpx.get("https://httpbin.org/ip", proxy="socks5h://USER:PASS@IP:PORT", timeout=30)
print(r.json())

Node.js. Two agent packages with the same shape, so the switch is which one you construct. The example uses import, so save it as proxy.mjs, or set "type": "module" in package.json.

npm i https-proxy-agent socks-proxy-agent

// proxy.mjs, run with: node proxy.mjs
import https from "node:https";
import { HttpsProxyAgent } from "https-proxy-agent";
import { SocksProxyAgent } from "socks-proxy-agent";

const agent = process.env.USE_SOCKS
  ? new SocksProxyAgent("socks5h://USER:PASS@IP:PORT")
  : new HttpsProxyAgent("http://USER:PASS@IP:PORT");

https.get("https://httpbin.org/ip", { agent }, (res) => res.pipe(process.stdout));

socks-proxy-agent follows curl’s convention: socks5:// looks the hostname up locally, socks5h:// leaves it to the proxy. The same agent works with axios through its httpsAgent option. For more on each tool, the curl proxy setup page, the Python requests proxy setup page and the Node.js proxy setup page go further, including what to do with a password full of special characters.

Which one to use with ProxyMonkey

All three of our lines, residential, ISP and datacenter, speak HTTP, HTTPS and SOCKS5. Which protocol you use changes nothing about the IP you get or the rate you pay. The handshakes differ by a few bytes and those are metered like any other traffic, but not enough to notice, so choose by your tool:

• Scripts and scrapers: HTTP. No extra packages, and DNS is always resolved at the proxy.
• Browsers with a password: HTTP, because no browser sends a SOCKS5 password on its own. If you need SOCKS5 in a browser, every line supports an IP allowlist as well as a username and password, and an allowlisted IP needs no password.
• Non-HTTP traffic, or a tool that only speaks SOCKS: SOCKS5, written as socks5h://.

What matters far more than the protocol is the type of IP behind it. If you have not settled that yet, the four-question guide to picking a proxy type will, and the SOCKS5 glossary entry is the short version of this page for sending to a teammate.