HTTP vs SOCKS5 proxy: what the difference actually is

An HTTP proxy understands the HTTP protocol: it reads your request, fetches the page on your behalf, and can see and change anything sent unencrypted. A SOCKS5 proxy understands nothing about what passes through it: it opens a TCP connection to the host and port you name and relays bytes in both directions. That single difference explains everything else people argue about, from DNS leaks to which one is "more anonymous".

In practice the choice matters less than the configuration. Both hide your address from the destination, neither encrypts anything, and both can leak DNS queries if the client resolves names itself. This article covers what each protocol does, where the hostname is resolved, what the destination can tell, how authentication differs, and how to test either type.

What an HTTP proxy does

RFC 9110, the 2022 HTTP standard, defines a proxy as "a message-forwarding agent that is chosen by the client, usually via local configuration rules". For a plain http:// URL the browser sends the whole request to the proxy, which reads it, makes its own request to the website, and passes the response back. Because it handles the message rather than a raw connection, it can cache, filter, log, rewrite and block by content.

For an https:// URL the proxy cannot read the request, because the browser wants to speak TLS to the site. HTTP solves this with the CONNECT method. RFC 9110 describes it as a request that the recipient "establish a tunnel to the destination origin server identified by the request target and, if successful, thereafter restrict its behavior to blind forwarding of data, in both directions, until the tunnel is closed". The request names only a host and port, for example CONNECT server.example.com:443 HTTP/1.1, and once the proxy answers with a 2xx status it switches to tunnel mode. From that moment the proxy sees encrypted bytes, nothing more.

Figure: Both proxies show the destination their own address. The HTTP proxy reads what it can; the SOCKS5 proxy reads nothing.

Two consequences follow. First, the hostname is visible to the proxy even for HTTPS, because it is in the CONNECT line: with an HTTP proxy "the hostname of the target URL is sent to the proxy server in the clear" (Chromium proxy docs). Second, the proxy decides which ports it will tunnel to. RFC 9110 warns that a CONNECT to port 25 "could trick the proxy into relaying spam email" and says proxies "SHOULD restrict its use to a limited set of known ports". That is why an HTTP proxy that works for websites often refuses a mail client or a game.

What a SOCKS5 proxy does

SOCKS is older and simpler. RFC 1928, from March 1996, describes version 5 as "a protocol for the application-layer traversal of IP network firewalls" and calls it "a 'shim-layer' between the application layer and the transport layer". The client connects to the proxy, conventionally on TCP port 1080, negotiates an authentication method, and sends one of three commands: CONNECT to open a TCP connection, BIND to accept an incoming one, and UDP ASSOCIATE to relay UDP datagrams.

The destination can be given in three forms: an IPv4 address, an IPv6 address, or "a fully-qualified domain name". That last option is the one that matters for privacy. RFC 1928 lists the additions over version 4 as UDP, "generalized strong authentication schemes" and an addressing scheme extended "to encompass domain-name and V6 IP addresses"; the original SOCKS 4 request carried only a 4-byte destination IP and a user ID, so the client had to resolve every name itself (SOCKS 4 protocol).

Because the proxy only sees a host, a port and a stream of bytes, it carries anything that runs over TCP: HTTP and HTTPS, SSH, mail, chat, game traffic. It cannot cache or filter by URL, and it adds nothing to what passes through. The same property makes an SSH connection usable as a proxy. The -D option in OpenSSH creates "a local 'dynamic' application-level port forwarding" where "the SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server" (ssh(1) manual).

A caution on the UDP command: support for it is uneven. Chrome's documentation states that "SOCKSv5 is only used to proxy TCP-based URL requests" and that it cannot relay UDP, so QUIC and HTTP/3, which run over UDP, do not go through a SOCKS5 proxy in Chrome.

Where the name is resolved

The question that separates a safe setup from a leaking one is who turns example.com into an IP address. If your computer does it, a DNS query leaves your real connection before the proxy is involved, and whoever runs your resolver sees every site you visit. That is the mechanism behind a DNS leak.

With an HTTP proxy the answer is fixed: the browser hands the proxy a URL or a hostname, and the proxy resolves it. Chrome's documentation says that for HTTP proxies "name resolution is always deferred to the proxy".

With SOCKS the answer depends on the client. The curl documentation lays out the four variants: SOCKS4, where "curl resolves the name"; SOCKS4a, "with resolving done by the proxy"; SOCKS5, where curl resolves locally; and SOCKS5-hostname, the socks5h:// scheme, which "sends the hostname to the proxy so there is no name resolving done by curl locally" (everything curl). The protocol allows the proxy to resolve the name; the client decides whether to let it.

Client	SOCKS version	Who resolves the name
curl socks5://	5	Your computer
curl socks5h://	5	Proxy
Chrome	5	Proxy, always
Firefox 128 and later	5	Proxy by default
Firefox before 128	5	Your computer by default

In Chrome, for SOCKSv5 "name resolution is always done proxy side", and Chrome "has no equivalent option" to Firefox's setting (Chromium proxy docs). Firefox exposes the choice as a proxy-DNS option in its connection settings. The reference for Firefox's proxy settings API says it "defaults to true when using SOCKS5 and false when using SOCKS4", and that "prior to Firefox 128, it defaulted to false for SOCKS4 and SOCKS5" (MDN proxy.settings). A tool configured with socks5:// rather than socks5h:// is resolving names locally.

What the destination can tell

Both proxy types replace your address with theirs. The difference is in the headers.

RFC 9110 requires that "a proxy MUST send an appropriate Via header field" in each message it forwards, so a compliant HTTP proxy announces itself on every plain http:// request. Many proxy products deliberately omit Via, and some add X-Forwarded-For with your real address, the behaviour behind the transparent, anonymous and elite labels explained on the proxy headers page. For an HTTPS site the headers inside the tunnel come from your browser untouched, so the Via distinction only applies to unencrypted traffic.

A SOCKS5 proxy cannot add a Via header because it never sees an HTTP message. Whatever headers the site receives are the ones your browser sent. This is the source of the belief that SOCKS5 is "more anonymous", and it is accurate only for the header question. The address is judged the same way for both: a site looks up the network behind the IP, checks it against datacenter, VPN and Tor lists, and compares your browser's time zone and language with the address's location. A SOCKS5 proxy on a hosting network is still a hosting address. The guide to checking a proxy before you log in covers those signals in order.

Authentication and encryption

An HTTP proxy authenticates with the same mechanisms as a website, through the Proxy-Authorization header; RFC 9110 gives the example Proxy-Authorization: basic aGVsbG86d29ybGQ= on a CONNECT request. Chrome supports Basic, Digest, Negotiate and NTLM for HTTP proxies.

SOCKS5 negotiates a method at the start of every connection. RFC 1928 defines "NO AUTHENTICATION REQUIRED" and "USERNAME/PASSWORD" among others, and the username/password scheme is specified separately in RFC 1929. That document is candid about its weakness: "Since the request carries the password in cleartext, this subnegotiation is not recommended for environments where 'sniffing' is possible and practical." The same applies to Basic credentials sent to a plain HTTP proxy; Chrome's documentation describes that channel without qualification: "Communication to HTTP proxy servers is insecure."

Browser support for SOCKS5 passwords is the practical trap. Chrome's documentation says "No authentication methods are supported for SOCKSv5 in Chrome" and that Chrome "will not use any credentials embedded in the proxy settings". A user:pass@host:port SOCKS5 proxy in Chrome's settings, or in a system setting Chrome inherits, will fail to authenticate. Providers work around this with IP allowlisting, where the proxy accepts connections from your current public address without a password, or with an HTTP endpoint for the same proxy.

Neither protocol encrypts your traffic. An HTTP proxy relays HTTPS as a blind tunnel, so the site's TLS protects the content, but plain http:// pages are readable by the proxy and by anyone between you and it. A SOCKS5 proxy relays whatever the application sends, ciphertext or plain text. An encrypted link to the proxy itself needs an HTTPS proxy, which Chrome supports and describes as protecting the connection with TLS so that "https:// requests sent through the proxy are not sent in the clear as with an HTTP proxy", or a VPN, which is a different mechanism.

Which one to use

Use an HTTP proxy when the traffic is web traffic and the client is a browser, a scraper, or any tool that speaks HTTP. It works with every browser's password support and it resolves names for you. Expect many to refuse ports other than 80 and 443.

Use SOCKS5 when the application is not a web browser, when you need a port an HTTP proxy will not tunnel, or when you do not want any HTTP header added. It is the natural choice for SSH tunnels, mail clients and desktop software with its own proxy settings. Check two things first: that the client sends the hostname to the proxy, and that it supports the proxy's authentication method.

Many providers expose the same exit addresses over both protocols, in which case the exit IP, its reputation and its location are identical and the choice comes down to the client.

How to test either type

1. Run the proxy through the proxy tester as ip:port, user:pass@ip:port, or a full http://, socks5:// or socks5h:// URL. It connects from our server with the protocol you select, reports alive or dead with the reason, and shows the exit address. A "connection cut" result usually means the protocol is wrong: an HTTP proxy spoken to as SOCKS5, or the reverse.
2. Configure the proxy in your browser, then open the proxy checker. The address shown should be the proxy's exit, and the proxy headers row tells you whether a Via or X-Forwarded-For header reached our server. For a SOCKS5 proxy there should be none.
3. Run the IP leak test on the same connection. It checks the DNS resolver, WebRTC and IPv6 paths. A resolver in your home country while the proxy is elsewhere means your client is resolving names itself: turn Firefox's proxy DNS option on, or use socks5h:// in command-line tools.
4. For an HTTP proxy, load any https:// page through it. A "CONNECT refused" result in the tester, or an error on every HTTPS site, means the proxy only handles plain HTTP.

The difference that matters

The protocol decides what the proxy can see and which applications it can carry. It does not decide how anonymous you are, how fast the connection is, or whether your DNS leaks; those come from the exit address, the network it sits in, and how your client is configured. An HTTP proxy that tunnels HTTPS and a SOCKS5 proxy with remote DNS give a website almost the same picture: a request from the proxy's address with your browser's headers. Pick the protocol your software needs, then spend the real effort on the exit address and the leaks around it.