SOCKS5 Proxy
A proxy protocol that routes any TCP or UDP traffic - not just HTTP - through a proxy server, with authentication support.
SOCKS5 is a proxy protocol operating at the transport layer. Unlike HTTP proxies, which only handle web traffic, SOCKS5 routes any TCP or UDP connection through the proxy - email, FTP, gaming traffic, custom protocols - not just HTTP and HTTPS.
The "5" in SOCKS5 refers to the fifth version of the SOCKS protocol. Key improvements in v5 over v4: UDP support (needed for some real-time applications), IPv6 support, and multiple authentication methods including username/password.
HTTP proxies work at the application layer and understand HTTP/HTTPS. They can modify headers, cache responses, and strip metadata. SOCKS5 is protocol-agnostic - it just forwards raw packets without inspecting or modifying them.
When to use SOCKS5: applications that are not HTTP-based, tools that explicitly support SOCKS5 (many scraping frameworks, SSH tunneling, game clients), and when you need UDP traffic proxied.
When to use HTTP proxy: web scraping with standard HTTP clients, browser-based automation, and when header modification or SSL inspection is required. Most web scraping setups use HTTP/HTTPS proxies - SOCKS5 is only necessary when your target or tool requires it.
SotaProxy endpoints support both SOCKS5 and HTTP/HTTPS. Choose the protocol your tool or language library works with natively.
Why SOCKS5 sits lower in the stack
An HTTP proxy understands the requests it forwards. It reads the method and the URL, can rewrite headers, can cache, and can only carry protocols it knows. SOCKS5 does none of that. It opens a TCP connection to a destination on your behalf and moves bytes in both directions without interpreting them.
That indifference is the feature. Anything that runs over TCP goes through a SOCKS5 proxy unchanged: an SMTP session, a database connection, a game protocol, a WebSocket upgrade. An HTTP proxy handles the first of those poorly and the rest not at all.
SOCKS5 also carries UDP, which matters for protocols that do not use TCP at all, and it supports authentication as part of the handshake rather than as an HTTP header, which is why a SOCKS client asks for a username and password in its own dialog.
The other significant difference is name resolution. The protocol allows the client to send a hostname instead of an address and let the proxy resolve it. Whether your client uses that capability is the difference between your resolver seeing every domain you visit and it seeing none of them.
SOCKS5 on our endpoints
Both product families speak SOCKS5, but the port arrangement differs:
SOCKS5 connection strings
# Residential: same port as HTTP, the service detects the protocol
curl -x socks5h://login_c_US:password@proxy.sotaproxy.com:10000 https://api.ipify.org
# Static addresses: SOCKS5 lives one port above HTTP
curl -x socks5h://login:password@your-ip:50101 https://api.ipify.org
# Python needs an extra package:
# pip install requests[socks]- Use socks5h, not socks5. The h means the hostname travels to us and gets resolved here. Without it your own resolver sees every target, which both leaks the target list and can route you to a geographically wrong server.
- Targeting suffixes work exactly the same under SOCKS5 as under HTTP. The protocol changes, the login does not.
- Some libraries need an extra dependency for SOCKS support. requests needs the socks extra, Node needs socks-proxy-agent, and Scrapy needs a downloader that supports it.
- If HTTP works and SOCKS5 does not on a static address, you are almost certainly still pointed at 50100.
Common SOCKS5 misconceptions
SOCKS5 is not more anonymous
It carries no forwarding headers because it carries no headers at all. An elite HTTP proxy reveals just as little, and the exit address is what a site judges either way.
SOCKS5 is not encrypted
The protocol adds no encryption. Your HTTPS traffic is protected because it is HTTPS, and plain HTTP over SOCKS5 is as readable as it ever was.
socks5 and socks5h are not interchangeable
They differ in who resolves the hostname, and that single letter decides whether your DNS queries leak.
SOCKS5 is not always faster
It skips header processing, which saves a little. On a residential route the exit device dominates the timing and the protocol choice is noise.
SOCKS5 next to SOCKS4 and an HTTP proxy
The three are often named as alternatives, but they differ in what they can carry rather than in how good they are. Rows below are properties of the protocols themselves, not of any particular provider.
| Property | SOCKS4 | SOCKS5 | HTTP proxy |
|---|---|---|---|
| What it carries | TCP only | TCP and UDP | HTTP and HTTPS only |
| Where it sits | Below the application | Below the application | Inside the application protocol |
| Authentication | A user id field, nothing more | Username and password, or GSSAPI | Basic or Digest, as an HTTP header |
| Who resolves the hostname | The client | Client, or the proxy with socks5h | The proxy |
| IPv6 | No | Yes | Yes |
| Encryption of its own | None | None | None |
| Conventional port | 1080 | 1080 | 8080 or 3128 |
The encryption row is the one people get wrong most often. None of the three encrypts anything by itself. What protects your traffic is TLS inside the tunnel, which is why an https:// address stays private through a plain HTTP proxy and an http:// address does not, whichever protocol you picked.
Questions people actually type
Does SOCKS5 encrypt my traffic?
No. SOCKS5 moves bytes and adds nothing of its own. If you load an https:// address, TLS protects it end to end and the proxy sees only where you went, not what you read. If you load an http:// address, the proxy operator can read and change it. Choosing SOCKS5 over HTTP does not alter this.
What is the difference between socks5 and socks5h?
Who resolves the hostname. With socks5 your machine resolves it and sends the proxy an address, so your own DNS server learns every site you visit. With socks5h the proxy resolves it. For anything where the point is not to leak your lookups, or where the target only resolves correctly from inside the destination country, use socks5h.
SOCKS5 or an HTTP proxy, which should I use?
An HTTP proxy if your tool speaks HTTP and you want the proxy to understand requests, which some caching and filtering setups need. SOCKS5 if the traffic is not HTTP at all, or if you want the proxy to stay out of the way. For plain scraping and browser work the difference in practice is small, and both run on the same port on our residential gateway.
Is SOCKS5 the same as a VPN?
No. A SOCKS5 proxy applies to the application you configured, and everything else on the machine keeps using the normal connection. A VPN moves the whole device. That is an advantage when you want one browser profile routed and the rest untouched, and a trap when you assumed the whole system was covered.
What port does SOCKS5 use?
By convention 1080, because the specification used it in examples. In practice providers assign whatever they like. On our residential gateway SOCKS5 answers on the same ports as HTTP, anywhere in 10000-10999, and the scheme in your client picks the protocol rather than the number.
Does SOCKS5 support UDP, and is SOCKS4 still worth using?
The protocol does support UDP, which is the main practical gain over SOCKS4 along with IPv6 and real authentication. Whether a given provider actually passes UDP is a separate question worth asking before you build on it. SOCKS4 is worth using only when something old refuses to speak anything else.
Related terms
See this in practice
Ready to use socks5 proxy?
SotaProxy gives you access to rotating residential, mobile, datacenter, and ISP proxies. No minimum commitment.
Get started