SOCKS5 vs HTTP proxy

9 November 2026

An HTTP proxy speaks the web's own protocol, so it can read, change and cache unencrypted requests. A SOCKS5 proxy opens a connection to whatever destination you ask for and then relays the bytes unchanged, whatever the protocol. Neither one encrypts the path between you and the proxy.

How an HTTP proxy works

A program set to use an HTTP proxy talks to it in HTTP. What it sends depends on the kind of site.

For a plain http:// site, the program puts the full URL in the request line. RFC 9112, section 3.2 calls this the absolute-form, and requires clients to use it when talking to a proxy:

GET http://example.com/page HTTP/1.1
Host: example.com

The proxy reads the whole request: path, headers and body. It can cache the response, block a page, or add headers before passing the request on.

For an https:// site, the program sends a CONNECT request that carries only the host name and port. The proxy connects to the site, answers with success, and from then on relays bytes in both directions without reading them.

The TLS handshake happens between the program and the site, inside that tunnel. The steps are covered in CONNECT and HTTPS proxies.

How SOCKS5 works

RFC 1928 describes SOCKS version 5 as a thin layer between the application layer and the transport layer. It knows nothing about the web or email. It carries out one of three commands: open a TCP connection (CONNECT), wait for an incoming one (BIND), or relay UDP (UDP ASSOCIATE).

The exchange uses short binary messages, in this order:

Greeting. The client sends version 5 and the list of authentication methods it supports, such as "no authentication" (00) and "username/password" (02).
Method selection. The server replies with the method it picked, or FF if none is acceptable, and the connection is closed.
Authentication. If the server picked username/password, the client sends them as described in RFC 1929.
Request. The client sends the command, the address type, the destination and the port. The address type is one of IPv4, domain name or IPv6.
Reply. The server tries to reach the destination and answers with a result code. Zero means success, and from then on application data flows through unchanged.

These are the actual bytes for a connection to example.com on port 443, without authentication:

-> 05 01 00
<- 05 00
-> 05 01 00 03 0b "example.com" 01 bb
<- 05 00 00 01 <IPv4 address> <port>

Arrows show direction: client to server, then back. The client offers version 5 with one method, no authentication, and the server accepts it. The request is CONNECT (01) to a domain name (03) of 11 characters, port 0x01bb, which is 443.

The 00 in the final reply means success. The program then starts its TLS handshake with the site over the same connection, and the proxy sees nothing but encrypted bytes.

Relaying UDP

UDP ASSOCIATE works differently. The client asks for the relay over the usual TCP connection, and the server replies with an address and port where it will accept datagrams. The client then sends each UDP datagram to that address, with a small header carrying its real destination.

The original TCP connection must stay open the whole time; when it closes, the relay ends. Not every SOCKS5 server supports this command, so check before relying on it.

Where site names get resolved

This detail is easy to miss, and it can cause a DNS leak. With SOCKS5 the client can send the site's name (type 03) and let the proxy resolve it, or resolve it first and send a numeric address. The standard allows both, and the program decides.

In curl, for example, socks5:// resolves the name on your machine and socks5h:// hands it to the proxy, as the curl guide explains. Firefox has a "Proxy DNS when using SOCKS v5" option that does the same. An HTTP proxy always receives the name in the request, so the proxy resolves it.

When the name is resolved locally, your local DNS server learns which sites you visit. Its answer may also differ from what the proxy would get in its own country. The full explanation is in What is a DNS leak.

Side by side

	HTTP proxy	SOCKS5
Protocols	The web, and any TCP connection through CONNECT if the proxy allows it	Any TCP connection
UDP	Not carried by classic CONNECT	Yes, through UDP ASSOCIATE if the server supports it
Reads content	Reads http:// requests, not the inside of an https tunnel	Does not parse content
Adds headers	Possible on http:// requests	Not possible
Name resolution	On the proxy	On the proxy or on your device, depending on the program
Authentication	407 and the Proxy-Authorization header	Username and password per RFC 1929
Encryption to the proxy	No, unless it is an HTTPS proxy	No

Program support

Browsers, command-line tools and most programming libraries support both types, but not always completely. Chrome, for instance, supports no authentication method at all for SOCKS5, as the Chromium documentation states. A SOCKS5 proxy with a password therefore needs an extension or a local helper program.

Some programs only accept an HTTP proxy. Others depend on UDP, such as voice and video calls and some games. A CONNECT tunnel is not enough for them, because it carries TCP only.

How to test both

Request the same page through each type, with -v to see the connection steps:

curl -v -x http://USER:PASS@proxy.example.com:8080 https://example.com/
curl -v -x socks5h://USER:PASS@proxy.example.com:1080 https://example.com/

The first shows a CONNECT example.com:443 line followed by the proxy's answer. The second shows curl handing the name to the SOCKS5 server. If authentication fails, the HTTP proxy answers 407 and the SOCKS5 server closes the connection.

To measure response time and the exit address without a command line, use the proxy checker, which accepts both types.

Which one to use

Browsing and web tools: either works. Pick the one your program supports with a password and no add-ons.
Programs that are not web clients: SOCKS5, because it carries any TCP connection, and UDP too where the server supports it.
Keeping site names private: use socks5h or your program's equivalent, or an HTTP proxy, so names are resolved by the proxy.
Untrusted networks: neither. Use an HTTPS proxy or a VPN, because both types send the destination and the password unencrypted.

At syriaproxy

We offer both types, plus an encrypted HTTPS proxy. Traffic exits from the Syriatel network inside Syria, and names we receive are resolved there by Syriatel's resolvers. Configuration examples are in Proxy setup.

FAQ

Is SOCKS5 faster than an HTTP proxy?

The difference is usually small. SOCKS5 adds a few short messages when a connection opens, and CONNECT adds one request and response. The network behind the proxy matters far more than the protocol.

Is SOCKS5 more secure because it does not read content?

Not necessarily. With https sites, neither type can read the content. With http:// sites, a proxy of either type can see the bytes passing through, because they were never encrypted.

What is the difference between SOCKS4 and SOCKS5?

Version 4 handles TCP and IPv4 only and has no password authentication. Version 5 added UDP, IPv6, domain names as a standard address type, and authentication methods.

Why does a site work through an HTTP proxy but not through SOCKS5?

One known cause is resolving the name locally. If your local DNS returns an address the proxy cannot reach, the connection fails. Try socks5h or your program's equivalent.

Check where site names are resolved with the free DNS leak test, with the proxy turned on in your browser.