HTTP vs SOCKS5 proxy: what changes and which to use

Guides · Published November 2, 2026 · 11 min read

For web work, use the HTTP proxy. In the http vs socks5 proxy choice, SOCKS5 earns its place when you need to carry something other than web traffic, send UDP, or run software that has a SOCKS field and nothing else. For https:// sites both protocols end up as the same encrypted tunnel to the destination, so the protocol rarely changes what the site sees.

Short answer: an HTTP proxy understands HTTP and tunnels HTTPS with CONNECT, while a SOCKS5 proxy relays raw TCP, and UDP when the server supports it, without reading what's inside. Either can ask for a username and password. Neither encrypts the leg to the proxy by itself, and HTTPS stays encrypted end to end through both.

What an HTTP proxy and a SOCKS5 proxy each do

An HTTP proxy is a server your client speaks HTTP to. For a plain http:// URL, the client puts the whole URL in the request line and the proxy fetches it for you. RFC 9112 section 3.2.2 calls this the absolute-form, and its example is GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1. The proxy can read that request, answer it from a cache, add headers or refuse it, because HTTP is what it was built to handle.

For https:// URLs the client asks for something else. It sends CONNECT example.com:443, and if the proxy answers with any 2xx status, both sides stop speaking HTTP. The proxy forwards bytes in both directions until one end closes (RFC 9110 section 9.3.6), and the TLS handshake runs inside that pipe, from your client to the site.

SOCKS5 sits lower. RFC 1928 describes it as a shim layer between the application and the transport layer, so it has no idea what HTTP is. Your client connects to the SOCKS server, agrees an authentication method, then sends one request: a command, an address type, a destination and a port. The address can be an IPv4 address, an IPv6 address or a fully qualified domain name. After a success reply, bytes flow.

The command is where SOCKS5 gets wider. CONNECT opens a TCP stream. BIND is for protocols where the server connects back to you, and the RFC's own example is FTP. UDP ASSOCIATE sets up a relay for datagrams that lives only as long as the TCP connection that asked for it. A classic CONNECT tunnel on the HTTP side is a byte stream to one host and port, so it has no datagram equivalent.

What the proxy can see of your request

Three cases cover nearly everything. With plain http:// through an HTTP proxy, the proxy sees the full URL, every header and the body, and it's allowed to change them. RFC 9110 section 7.6.3 also says a proxy MUST add a Via header to each message it forwards, so the destination can learn a proxy was involved. With https:// through either kind of proxy, the proxy sees the host and port you asked for and then only ciphertext.

SOCKS5 behaves the same way on HTTPS. On plain HTTP the relay can see the bytes but nothing in the protocol makes it read them, so it has no request to rewrite and no header to add.

Two things the picture doesn't say. The proxy operator sees where you connect in all three rows, so "private" here means private from the site, not from whoever runs the proxy. And the leg between you and the proxy is a separate matter: RFC 1929 states that its password request carries the password in cleartext and isn't recommended where sniffing is practical, and the Proxy-Authorization example in RFC 9110 is a base64 string that decodes to hello:world.

Adding TLS to that first hop is possible with some clients, for example curl accepts an https:// proxy URL, but the server on the other end has to listen with TLS too. Our dashboard offers HTTP / HTTPS and SOCKS5 as the protocol choices and generates a connection URL that starts with http://, so in that setup the first hop is plain.

How the HTTP CONNECT and SOCKS5 handshakes differ

Before your first real byte reaches an https:// site, each protocol runs a short exchange with the proxy. They differ mostly in how many messages that takes.

HTTP is a single exchange. The client sends CONNECT example.com:443, adding Proxy-Authorization if it has credentials, and the proxy answers 2xx. If credentials are missing or wrong the proxy answers 407 Proxy Authentication Required with a Proxy-Authenticate challenge (RFC 9110 section 15.5.8) and the client may try again. Don't read a 407 in your logs as a failure by itself. A Chromium-based browser pointed at a stub proxy sent a bare CONNECT first and retried with credentials after the 407, while curl sends the header up front.

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic TE9HSU46UEFTU1dPUkQ=
User-Agent: curl/8.23.0
Proxy-Connection: Keep-Alive

What a proxy receives from curl 8.23.0 for https://example.com with LOGIN and PASSWORD, captured on a local stub.

SOCKS5 negotiates, so it takes more steps. The client's greeting lists the methods it can do: 00 for no authentication, 01 for GSSAPI, 02 for username and password. The server picks one, or answers FF and the client must hang up. If it picks 02, RFC 1929 adds a sub-negotiation: a version byte of 1, a length-prefixed username and password, then a status where 00 means success. Only after that does the client send its request, and the reply carries a code. 00 is success, 05 is connection refused, 07 means the command isn't supported, which is how a server says no to UDP.

Counting those exchanges as the RFCs lay them out: the greeting and method choice, the authentication, and the request and reply make three round trips with a password, two without. Take a made-up 100 ms round trip to the proxy. CONNECT adds 100 ms before the TLS handshake can start, SOCKS5 with a password adds about 300 ms. That's arithmetic, not a measurement, and a client that sends messages back to back would pay less. You pay it once per new connection, so connection reuse hides most of it.

HTTP vs SOCKS5 proxy comparison

Here are the differences that can change what you build, with the RFC section where one applies.

RFC 9110 section 9.3.6 says proxies that support CONNECT SHOULD restrict it to known ports. That restriction, not the protocol, is why HTTP proxies often look web-only.

socks5 vs socks5h: who resolves the hostname

This is the detail that bites people. In curl's SOCKS documentation, socks5:// means curl resolves the name itself, and socks5h:// sends the name to the proxy to resolve. The Requests documentation says the same and notes it matches curl: use socks5h if you want the proxy to do it.

The difference is visible on the wire. Pointing curl 8.23.0 and Requests 2.34.2 at a local listener that logs raw bytes, a request for example.com arrived as address type 03 carrying the name under socks5h, and as address type 01 carrying an IPv4 address under socks5. That's the RFC 1928 address field doing exactly what section 5 describes.

Who resolves matters for two reasons. With socks5, your own resolver sees every hostname you visit, which may be the leak you were trying to avoid. And CDNs and geo-DNS answer based on who's asking, so a local lookup can return an address near you instead of near the proxy's exit. How much that matters varies by site and we haven't measured it, so treat it as a reason to default to proxy-side resolution, not as a known penalty.

With an HTTP proxy the question doesn't come up. The hostname travels in the CONNECT line or the absolute URL, so the proxy resolves it. For SOCKS5, write socks5h:// unless you have a reason not to.

What curl, Requests, Node and browsers support

Both protocols work in most clients, but the edges differ enough to decide the choice for you.

• curl: the scheme in -x picks the protocol, and no scheme or http:// means an HTTP proxy. If you leave out the port, curl assumes 1080, so always write it. Credentials can sit in the URL, where curl URL-decodes them, so write @ as %40 and : as %3a. Or use --proxy-user, which curl warns is briefly visible to other users in process listings (curl manual).
• Python Requests: SOCKS needs the extra, installed with pip install "requests[socks]". Without it you get InvalidSchema: Missing dependencies for SOCKS support. Set both the http and https keys, as the docs do.
• Node: SOCKS5 comes from undici's Socks5ProxyAgent, which supports username and password and sends hostnames to the proxy as domain names. Its docs mark it experimental, so pin your version and expect changes (undici docs).
• Chromium: its SOCKS5 client greets with 05 01 00, a single method, no authentication, and the source says SOCKS5 authentication isn't supported. It always sends the hostname, so DNS happens at the proxy (Chromium source).
• Playwright: the proxy option accepts http:// or socks5:// servers, but the username and password fields are documented for HTTP proxies. Playwright 1.63 throws Browser does not support socks5 proxy authentication if you give them with a socks5:// server.

The browser rows are the ones to remember. If you automate Chromium through an authenticated proxy, that means HTTP. A local relay that adds the credentials can work around it, but it's one more process to run and debug.

Is SOCKS5 faster or safer than an HTTP proxy?

Not by anything in the specs. On speed, the only protocol-level difference is the setup count above, paid once per connection. After setup both are blind relays for HTTPS, so throughput comes down to the proxy's network and how far you are from it. Caching is a small point for HTTP. It only applies to plain http:// responses, only if the operator enables it, and RFC 9110 section 9.3.6 says responses to CONNECT aren't cacheable.

On safety, neither protocol encrypts anything. What protects your content is TLS between you and the site, and you get that from https:// through either one. Plain HTTP over SOCKS5 is exactly as readable on the wire as plain HTTP over an HTTP proxy. Nor does SOCKS5 hide you better: the site sees the proxy's exit address in both cases. When a page claims otherwise, ask which RFC it's reading.

Connecting to TierProxy over HTTP or SOCKS5

Both protocols are on the same gateway host, proxy.tierproxy.com. An active residential order in the dashboard shows a Host, an HTTP Port and a separate SOCKS5 Port, which is the HTTP port plus one: 823 and 824 as we write this. Copy the values from your own order rather than from this page.

The username is identical on both ports. The dashboard builds the targeting string, for example LOGIN__cr.us for a US exit, and appends sessid.<id> when you want a sticky session. None of that depends on protocol, and the proxy list generator's Protocol dropdown only changes the port in the lines it writes. Sessions are covered in rotating vs sticky proxies.

# HTTP proxy
curl -x http://LOGIN:PASSWORD@proxy.tierproxy.com:823 https://api.ipify.org

# SOCKS5, hostname resolved by the proxy
curl -x socks5h://LOGIN:PASSWORD@proxy.tierproxy.com:824 https://api.ipify.org

# credentials kept out of the URL
curl -x socks5h://proxy.tierproxy.com:824 --proxy-user LOGIN:PASSWORD https://api.ipify.org

Replace LOGIN and PASSWORD with the values from your dashboard.

import requests  # pip install "requests[socks]"

HOST = "proxy.tierproxy.com"
http_proxy = f"http://LOGIN:PASSWORD@{HOST}:823"
socks_proxy = f"socks5h://LOGIN:PASSWORD@{HOST}:824"

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

Both keys point at the same proxy URL, as the Requests docs show.

import { chromium } from "playwright";

const browser = await chromium.launch({
  proxy: {
    server: "http://proxy.tierproxy.com:823",
    username: "LOGIN",
    password: "PASSWORD",
  },
});

For browsers, use the HTTP port, because Chromium can't authenticate to SOCKS5.

We haven't run these against the live gateway for this article. The syntax was checked against the documentation above and against curl 8.23.0, Requests 2.34.2 and Playwright 1.63 talking to a local stub that logs what they send, all on 2 November 2026. To confirm a login works before it goes into code, paste it into the proxy checker, which tries HTTP first and falls back to SOCKS5. Then compare your exit address with what /my-ip shows from your own connection. If you need UDP, test it with your own client before you build on it, because we don't promise UDP relay on the SOCKS5 port.

HTTP or SOCKS5: a rule for choosing

Start with HTTP. It has one handshake, every HTTP library supports it, browsers can authenticate to it, and the hostname goes to the proxy by default. Switch to SOCKS5 only when one of these is true.

• The traffic isn't HTTP: SSH, IMAP, a database driver, a game client. A SOCKS5 CONNECT carries any TCP stream with no HTTP framing, while many HTTP proxies limit which ports CONNECT may reach.
• You need UDP. That means UDP ASSOCIATE, and you have to confirm the server implements it, since RFC 1928 lets a server refuse with reply 07.
• Your software has a SOCKS setting and no HTTP one. Some desktop apps are built that way. Use socks5h if it lets you choose.

Plenty of the time it doesn't matter. Fetching https:// pages from curl, Requests, Go or any HTTP client gives you the same encrypted tunnel to the site, the same exit for the same username, and a setup difference you pay once per connection. Pick whichever your library documents better and move on. What decides whether a request works is usually the exit and the targeting, which is why how to test a proxy is a better use of an afternoon than protocol benchmarks. Our residential plans include both protocols on one gateway, so you can switch later without reordering.

Next step: run one request through each protocol with the commands above, check that the exit address matches what you ordered, and keep whichever your client handles with less configuration. Follow each site's terms, its robots.txt and the law that applies to you.

Frequently asked questions

Is SOCKS5 faster than an HTTP proxy?

Nothing in the specs says so. SOCKS5 needs two or three setup exchanges where HTTP CONNECT needs one, paid once per connection, and after that both are blind relays for HTTPS. The proxy's network and your distance to it decide the speed.

Is SOCKS5 more secure than HTTP?

No. Neither encrypts the connection to the proxy, and the RFC 1929 password travels in cleartext. HTTPS content is protected by TLS between you and the site through either protocol, and plain HTTP is readable on the wire through both.

What is the difference between socks5 and socks5h?

Who resolves the hostname. With socks5:// your client looks it up and gives the proxy an IP address, and with socks5h:// the client sends the name and the proxy resolves it. curl and Python Requests both work this way, so socks5h is the safer default.

Can an HTTP proxy handle HTTPS sites?

Yes, through the CONNECT method. The client asks the proxy for a tunnel to the host and port, the proxy answers 2xx, and TLS then runs from your client to the site inside that tunnel. The proxy sees the destination but not the page.

Do I need SOCKS5?

Usually not. You need it for non-HTTP TCP such as SSH or a database connection, for UDP through UDP ASSOCIATE, or for software that only offers a SOCKS field. For scraping and browsing over HTTPS, an HTTP proxy does the same job with one fewer handshake.

Why does my browser fail with an authenticated SOCKS5 proxy?

Chromium's SOCKS5 client offers only the no-authentication method, so a server that demands a password can't be satisfied. Playwright refuses socks5 credentials for that reason. Use an HTTP proxy with Proxy-Authorization for browsers.

Sources

• RFC 1928: SOCKS Protocol Version 5
• RFC 1929: Username/Password Authentication for SOCKS V5
• RFC 9110: HTTP Semantics (CONNECT, Via, proxy authentication)
• RFC 9112: HTTP/1.1 (absolute-form request target)
• everything curl: SOCKS proxy
• curl manual: --proxy and --proxy-user
• Requests documentation: Proxies and SOCKS
• Chromium source: net/socket/socks5_client_socket.cc
• Playwright API: BrowserType launch options (proxy)
• undici documentation: Socks5ProxyAgent

Keep reading

• Rotating vs sticky proxies: how proxy sessions work
• How to test a proxy: six checks, in order, with commands you can paste
• Residential vs datacenter proxies: how to choose

See residential plans

Explore TierProxy

• Residential proxies
• Buy IPv4 proxy
• Pricing
• Proxies by country
• Proxy checker
• What is my IP
• Blog