SOCKS5 vs HTTP Proxies

How an HTTP proxy handles a request

An HTTP proxy understands the protocol it carries. There are two cases, and they behave differently.

For a plain http:// URL, the client sends the whole request to the proxy with the full address in the request line, and the proxy forwards it. The proxy can read and change everything, including headers and body.

For an https:// URL, the client first asks the proxy to open a tunnel. The HTTP standard defines the CONNECT method for this: the client names a host and port, the proxy opens a TCP connection there and then relays bytes in both directions (RFC 9110, CONNECT). The TLS handshake happens inside the tunnel, between your client and the website, so the proxy sees example.com:443 and nothing of the page.

Authentication uses HTTP headers. If the proxy needs credentials, it answers 407 Proxy Authentication Required with a Proxy-Authenticate header, and the client retries with Proxy-Authorization (RFC 9110, 407). With the common Basic scheme, the username and password are only base64-encoded, so they travel readable unless the connection to the proxy itself is encrypted.

A typical exchange for an HTTPS page looks like this:

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

HTTP/1.1 200 Connection established

After the 200, the client starts TLS with example.com through the tunnel.

How the SOCKS5 handshake works

SOCKS5 does not care what protocol you carry. It sets up a TCP relay with a short binary exchange defined in RFC 1928, and anything can run inside it: HTTP, TLS, mail, game clients or a database driver.

The exchange has three steps. The client sends a greeting listing the authentication methods it supports. The server picks one. If that method is username and password, the client sends both as length-prefixed fields, as specified in RFC 1929, and the server answers success or failure. Then the client sends a CONNECT request with the destination, which can be an IPv4 address or a domain name, plus the port.

To make that concrete, this short Python script builds each message the way RFC 1928 and RFC 1929 lay them out and prints the bytes. It does not open a network connection; it shows what goes on the wire.

import socket
import struct

def greeting():
    # VER=5, one method offered: 0x02 username/password (RFC 1928, section 3)
    return bytes([5, 1, 2])

def credentials(user, password):
    # RFC 1929: VER=1, ULEN, UNAME, PLEN, PASSWD (sent as plain bytes)
    u, p = user.encode(), password.encode()
    return bytes([1, len(u)]) + u + bytes([len(p)]) + p

def connect_by_name(host, port):
    # socks5h style: ATYP=3, the proxy resolves the name
    h = host.encode()
    return bytes([5, 1, 0, 3, len(h)]) + h + struct.pack(">H", port)

def connect_by_ip(ip, port):
    # socks5 style: ATYP=1, the client already resolved the name
    return bytes([5, 1, 0, 1]) + socket.inet_aton(ip) + struct.pack(">H", port)

for label, message in [
    ("greeting", greeting()),
    ("auth", credentials("user", "secret")),
    ("connect (name)", connect_by_name("example.com", 443)),
    ("connect (ip)", connect_by_ip("203.0.113.10", 443)),
]:
    print(f"{label:15} {message.hex(' ')}")

Output, run with Python 3.9:

greeting        05 01 02
auth            01 04 75 73 65 72 06 73 65 63 72 65 74
connect (name)  05 01 00 03 0b 65 78 61 6d 70 6c 65 2e 63 6f 6d 01 bb
connect (ip)    05 01 00 01 cb 00 71 0a 01 bb

Two things stand out. The auth message carries user and secret as readable bytes, so SOCKS5 credentials are no more protected than HTTP Basic. And the two CONNECT messages differ in who knows the hostname: the first sends example.com to the proxy, the second sends an address the client looked up itself.

DNS: socks5 versus socks5h

That last difference is the one most people trip over. Where the name lookup happens decides which resolver learns which sites you visit, and which location the answer is tuned for.

With socks5://, your client resolves the hostname with its own DNS, then sends the IP to the proxy. Your local resolver, often your ISP or office network, sees every lookup, and content networks that answer DNS by location may hand you an address suited to where you are rather than where the proxy is.

With socks5h://, the client sends the hostname and the proxy resolves it. curl documents socks5h:// as equivalent to its --socks5-hostname option (curl manual), and Python Requests documents that socks5 resolves on the client while socks5h resolves on the proxy (Requests advanced usage).

HTTP proxies avoid the question for HTTPS: the client puts the hostname in the CONNECT line, and the proxy resolves it. Chrome also resolves names at the proxy whenever a SOCKS5 proxy is set, with no option to change it (Chromium proxy documentation).

If your job is location-sensitive, use socks5h or an HTTP proxy, then confirm with a DNS leak test through the same client.

Encryption between you and the proxy

Both protocols discussed so far run over a plain TCP connection to the proxy. Whatever you send before the tunnel opens, including credentials and, for plain http:// pages, the whole request, crosses the network between you and the proxy unencrypted. On a home or office network that may be acceptable. On shared Wi-Fi it is worth thinking about.

There is a third option: an HTTPS proxy, where the client opens a TLS connection to the proxy itself and sends CONNECT inside it. The Chromium documentation notes that this protects communication with the proxy, supports client certificates as well as the usual HTTP authentication, and works in Chrome, Firefox and Opera, while many older HTTP stacks do not support it. It usually has to be configured through a PAC script or a browser setting rather than the operating system's proxy panel.

For most proxy work the practical rule is simpler. Load https:// sites, which keeps page content encrypted end to end whatever the proxy type, and treat proxy credentials as secrets that can be observed on untrusted networks. If a password leaks, change it rather than hoping nobody captured it.

Reading failures on each protocol

When a connection fails, the two protocols report it differently, and knowing the format saves time.

An HTTP proxy answers with ordinary status codes. A 407 means the proxy wants credentials or rejected the ones you sent. A 502 or 504 from the proxy usually means it could not reach the destination. Any status from the website itself, such as 403 or 429, arrives inside the tunnel and is not a proxy fault.

A SOCKS5 server answers the CONNECT request with a one-byte reply code defined in RFC 1928.

Most clients translate these into an error message rather than showing the byte. If your tool reports a SOCKS failure before any HTTP status appears, the problem is between you, the proxy and the destination network, not the website's rules. Our IP ban check and fix guide covers the cases where the website itself is refusing you.

UDP ASSOCIATE, briefly

RFC 1928 also defines a UDP ASSOCIATE command, which asks the SOCKS server to relay UDP datagrams for the client. It exists in the standard, but support is uneven. Many clients never implement it, and the Chromium documentation states that Chrome uses SOCKSv5 only for TCP-based requests and cannot relay UDP through it.

Do not assume a provider relays UDP because it offers SOCKS5. Coronium documents HTTP and SOCKS5 on every line; this article makes no claim about UDP relay on Coronium lines. If a workload depends on it, ask the provider for written confirmation and test it before buying for scale.

Tool support at a glance

Protocol choice often comes down to what your client can actually do. The table lists documented behavior for three common clients.

Antidetect browsers and automation tools usually expose both types with fields for credentials, but each vendor documents its own behavior. Our antidetect browser setup guide covers the common ones, and the Python Requests proxy authentication guide covers scripts in detail.

Which to pick

Start from the client and the job, then let the table decide.

Neither protocol encrypts your proxy credentials by itself. For both, keep credentials out of shared screenshots and logs, and rotate the password if one leaks. Every Coronium line offers both protocols, so you can switch per tool without buying anything new; copy the host, port and credentials the dashboard lists for the protocol you pick. Compare countries and carriers on the mobile proxies overview, and see our SOCKS5 proxy guide for setup examples.

Compare both on one line

The quickest way to settle the choice for your own setup is to send the same request through both protocols and compare what comes back. With curl, the only change is the scheme in front of the proxy address:

# HTTP proxy: the hostname travels in the CONNECT line
curl -s -x "http://USER:PASS@HOST:HTTP_PORT" https://api.ipify.org

# SOCKS5 with name lookup at the proxy
curl -s -x "socks5h://USER:PASS@HOST:SOCKS_PORT" https://api.ipify.org

Both commands should print the same exit address. If they differ, the two endpoints exit through different devices or networks, which is worth knowing before you assign them to separate tools. If the SOCKS5 command fails while the HTTP one works, check that your curl build includes SOCKS support and that you used the SOCKS port, not the HTTP one.

Then repeat the test inside the real client: the browser profile, the scraper or the app. A command-line success proves the proxy works, not that your tool is configured to use it.

How we checked

Protocol behavior comes from the RFCs linked above. Client behavior comes from the curl manual, the Requests documentation and the Chromium proxy documentation, read on 30 October 2026. The Python script was run locally with Python 3.9 and its output is reproduced unchanged. We did not measure speed differences between the protocols and make no performance claim.

Frequently asked questions