HTTP vs SOCKS5 proxies: how each one works and which to use

The HTTP vs SOCKS5 proxy choice is about what the proxy understands. An HTTP proxy speaks HTTP: it forwards plain HTTP requests itself and opens a CONNECT tunnel for HTTPS. A SOCKS5 proxy works a layer lower and relays any TCP connection (and UDP, where the server supports it) without reading what is inside. For web scraping and API calls both work, and HTTP is the simpler default. Choose SOCKS5 for traffic that is not HTTP, for tools that only speak SOCKS, or when you want nothing between you and the target that could touch a header.

#How an HTTP proxy works

An HTTP proxy handles two different cases, and most confusion about "HTTPS proxies" comes from mixing them up.

#Plain HTTP: the proxy reads the request

For an http:// URL, the client sends the whole request to the proxy with the full URL in the request line, plus a Proxy-Authorization header:

GET http://example.com/page HTTP/1.1
Host: example.com
Proxy-Authorization: Basic VVNFUk5BTUU6UEFTU1dPUkQ=

The proxy opens its own connection to example.com, forwards the request and returns the response. It sees everything: URL, headers, body. It can also add or strip headers, which some proxies do.

#HTTPS through an HTTP proxy: CONNECT tunnelling

For an https:// URL, the client asks the proxy for a raw tunnel instead, using the CONNECT method defined in RFC 9110:

CONNECT api.ipify.org:443 HTTP/1.1
Host: api.ipify.org:443
Proxy-Authorization: Basic VVNFUk5BTUU6UEFTU1dPUkQ=

The proxy answers 200, and from then on it only copies bytes in both directions. The TLS handshake runs between your client and the target, so the proxy sees the hostname and port but not the path, the headers or the body. Almost all scraping today goes through this tunnel.

Two consequences worth knowing. First, the proxy resolves the target's hostname, so your DNS lookups never leave your machine. Second, Basic credentials are base64, not encryption: on a plain http:// proxy connection anyone on the network path to the proxy can read them. On an untrusted network, prefer an IP allowlist.

#What "HTTPS proxy" means

The phrase has two meanings:

1. An HTTP proxy that tunnels HTTPS with CONNECT. This is what most provider dashboards mean when they list an HTTPS port.
2. A proxy you reach over TLS, where even the hop to the proxy is encrypted. curl supports this with an https:// proxy URL; many libraries do not.

The scheme in a proxy URL describes the hop from you to the proxy, never the target. http://USERNAME:PASSWORD@HOST:PORT can carry https:// requests perfectly well. When a dashboard generates a code snippet for a port, follow the scheme it uses.

#How a SOCKS5 proxy works

SOCKS5, defined in RFC 1928, does not know what HTTP is. The client connects, the two sides agree on an authentication method (username and password is its own small spec, RFC 1929), and the client asks for a connection to a host and port. After that the proxy relays bytes. It cannot add headers, cache responses or rewrite anything, because it never parses the stream.

#UDP support

SOCKS5 defines a UDP ASSOCIATE command for relaying datagrams, which matters for DNS, VoIP, game clients and HTTP/3. It is also the most commonly unimplemented part of the spec, and HTTP libraries do not use it. ProxyHive does not advertise UDP relay, so ask support before you plan a UDP workload around it.

#DNS resolution: socks5 vs socks5h

With SOCKS5 the client decides who resolves the hostname:

The h stands for hostname. curl, Python requests and Node's socks-proxy-agent all honour the distinction. Use socks5h:// unless you have a reason not to.

#HTTP vs SOCKS5 proxy compared

#Client support

The browser rows are why the HTTP port is usually the easier choice for browser work: the browser prompts for HTTP proxy credentials, and has no place to type SOCKS5 ones.

#Code examples for HTTP and SOCKS5

Each ProxyHive ISP or datacenter IP has its own host, username, password, and a separate port per protocol. Copy them from the order in your dashboard at app.proxyhive.io into environment variables:

export PROXY_HOST=HOST
export PROXY_HTTP_PORT=PORT
export PROXY_SOCKS_PORT=PORT
export PROXY_USER=USERNAME
export PROXY_PASS=PASSWORD

We ran each snippet below against a local authenticating proxy with curl 8.5, requests 2.34, and Node 22 with undici 8 and socks-proxy-agent 10.

#curl

curl -x "http://$PROXY_USER:$PROXY_PASS@$PROXY_HOST:$PROXY_HTTP_PORT" \
  "https://api.ipify.org?format=json"

curl -x "socks5h://$PROXY_USER:$PROXY_PASS@$PROXY_HOST:$PROXY_SOCKS_PORT" \
  "https://api.ipify.org?format=json"

If a password contains @, : or /, pass it with -U "$PROXY_USER:$PROXY_PASS" instead of inside the URL. The curl integration guide covers the rest of the flags.

#Python requests

import os

import requests

user = os.environ["PROXY_USER"]
password = os.environ["PROXY_PASS"]
host = os.environ["PROXY_HOST"]

http_proxy = f"http://{user}:{password}@{host}:{os.environ['PROXY_HTTP_PORT']}"
socks_proxy = f"socks5h://{user}:{password}@{host}:{os.environ['PROXY_SOCKS_PORT']}"

for proxy in (http_proxy, socks_proxy):
    r = requests.get(
        "https://api.ipify.org?format=json",
        proxies={"http": proxy, "https": proxy},
        timeout=15,
    )
    print(proxy.split("://")[0], r.json())

SOCKS support needs the extra: pip install "requests[socks]", as the requests documentation notes. More patterns, including sessions and retries, are in the Python requests guide.

#Node.js

HTTP proxy with undici (npm install undici):

import { fetch, ProxyAgent } from 'undici';

const { PROXY_USER, PROXY_PASS, PROXY_HOST, PROXY_HTTP_PORT } = process.env;
const dispatcher = new ProxyAgent(`http://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:${PROXY_HTTP_PORT}`);

const res = await fetch('https://api.ipify.org?format=json', { dispatcher });
console.log(await res.json());

SOCKS5 with socks-proxy-agent (npm install socks-proxy-agent):

import https from 'node:https';
import { SocksProxyAgent } from 'socks-proxy-agent';

const { PROXY_USER, PROXY_PASS, PROXY_HOST, PROXY_SOCKS_PORT } = process.env;
const agent = new SocksProxyAgent(`socks5h://${PROXY_USER}:${PROXY_PASS}@${PROXY_HOST}:${PROXY_SOCKS_PORT}`);

https.get('https://api.ipify.org?format=json', { agent }, (res) => {
  res.setEncoding('utf8');
  res.on('data', (chunk) => process.stdout.write(chunk));
});

The Node.js guide covers more clients and error handling.

#Which should you use?

Use the HTTP port when:

• you are scraping websites or calling HTTP APIs, which is most proxy work,
• you configure a browser and want username and password authentication,
• you want DNS resolved at the exit without having to think about it.

Use the SOCKS5 port when:

• the traffic is not HTTP: a database client, SSH, or a custom TCP protocol,
• a tool only speaks SOCKS,
• you want a proxy that cannot modify requests, even on plain HTTP.

Use neither for encryption. Neither protocol encrypts anything on its own. If what you want is a protected connection for your own device on public Wi-Fi, that is a VPN's job; proxy vs VPN explains the difference.

#Protocols on a ProxyHive order

On ISP and datacenter orders, the dashboard lists an HTTP, an HTTPS and a SOCKS5 port for every IP. Each protocol's port is listed on its own, so copy the one that matches the protocol in your client. You can authenticate with username and password, or switch the order to an IP allowlist, which is the practical way to use SOCKS5 in a browser. For residential, check which protocols your order lists in the dashboard.

Datacenter proxies start at $3.20/IP a month for one IP, and ISP proxies at $3.20/IP. The docs cover authentication and your first request.