SOCKS5 Proxy: What the Standard Says and What Vendors Leave Out

A SOCKS5 proxy relays whatever connection you hand it without caring what is inside. It is a protocol from 1996, still Standards Track, and its own specification describes its purpose as letting applications "conveniently and securely use the services of a network firewall" rather than anything to do with privacy.

That gap between what it was built for and what it gets sold as is where the confusion starts. It does not encrypt. Its username and password login is specified in a document that recommends against using that login where anyone could be listening. And the browser you are probably reading this in cannot use it with a password at all.

The protocol details below come from RFC 1928, RFC 1929 and the IANA registry they point at. The client behavior comes from the documentation of the software concerned, or from its source where the documentation is silent. Where a standard and a program disagree, I have said which is which rather than picking the tidier answer.

Author: Robert Harrison OSINT & Network Utility Expert

If you are here because a provider gave you a host, a port, a username and a password and none of it works, skip to the testing section at the end. The command there settles in one line whether your credentials are the problem or your client is, and the client is worth suspecting first, because the two places people paste those details most often cannot authenticate at all: Chrome, by its own documentation, and the Windows Socks box, because that field is version 4.

The rest is the protocol, because the answers are in it. The registry assigns nine method numbers and the software you have implements one or two of them. The handshake returns numbered failure codes that name the problem. None of that is hidden, and none of it is in the marketing.

What a SOCKS5 Proxy Is

What is a socks5 proxy, stripped of the sales language? The useful way to hold it is by contrast. An HTTP proxy reads your request. It knows the method, the URL and the headers, which is how it can cache a page, rewrite a header or block a hostname. A SOCKS5 proxy knows none of that. You tell it an address and a port, it opens the connection, and from then on it copies bytes in both directions without an opinion about them.

That is the whole advantage and the whole limitation in one sentence. Because it does not parse the payload it will carry SSH, a mail client or a database session as happily as a web page. Because it does not parse the payload it cannot cache anything, cannot filter anything, and cannot add or protect anything either.

It also does not encrypt. Webshare's guide puts that correctly: "Unlike HTTPS proxies or VPNs, SOCKS5 proxies do not encrypt the data they transmit." Worth agreeing with plainly, because a page that gets this right deserves the credit. There is a distinction underneath it worth making: an HTTPS proxy encrypts the hop between you and the proxy, and a SOCKS5 proxy has no equivalent. Whatever your application produced is what crosses that hop. If it was already HTTPS it stays protected; if it was plain text it stays plain text.

A socks proxy server, then, is nothing more exotic than a program listening on a port and speaking the exchange the next section sets out: a commercial endpoint, a machine in an office, or the SSH client already on your laptop. So it is a transport, not a shield. For where a relay like this sits in a network in the first place, our explainer on where a proxy sits relative to the application trying to talk is the wider frame. Everything below is detail, and the detail is where the useful parts are.

SOCKS Proxy: The Protocol Rather Than the Product

What is a socks proxy, as distinct from the thing companies sell under that name? It is a specification: RFC 1928, "SOCKS Protocol Version 5", March 1996, Standards Track. Nine pages. Reading it changes what you think the thing is for.

Here is its own statement of purpose, from the introduction: the protocol is "designed to provide a framework for client-server applications in both the TCP and UDP domains to conveniently and securely use the services of a network firewall." A framework for getting through a firewall you are permitted through, in other words. That original purpose explains design decisions that look strange if you assume it was built for anonymity.

The conversation opens with a negotiation rather than a request. The client offers a list of authentication methods it supports and the server picks one, or refuses them all:

Three methods in the RFC. But the RFC also reserves X'03' through X'7F' as IANA assigned, and the registry those values live in holds rather more. IANA's SOCKS Methods page carries a registry table titled SOCKS Method Values, whose registration procedure is IESG Approval. It assigns nine method numbers, leaves 04 and the whole of 0A to 7F unassigned, reserves 80 to FE for private use, and registers FF as the server's refusal:

One oddity worth noticing there. The registry has a value registered for Secure Sockets Layer, which sits strangely beside the correct and widely repeated statement that SOCKS5 does not encrypt. A value being registered is not a feature being implemented, and no implementation I am aware of offers method 06, so treat the row as a historical curiosity rather than an option. The method you will actually be issued is 02.

The Username and Password Warning in the Standard Itself

Method 02 is defined by RFC 1929, "Username/Password Authentication for SOCKS V5", March 1996, Standards Track, and that document contains this:

"Since the request carries the password in cleartext, this subnegotiation is not recommended for environments where 'sniffing' is possible and practical."

The standard that created SOCKS5 password authentication recommends against using it where anyone could be watching. Compare that with how it gets sold. Oxylabs, in its SOCKS-versus-HTTP comparison, writes that "SOCKS5 is an upgraded version that offers improved security and authentication." The authentication is real and registered. Improved security is the half RFC 1929 qualifies in its own text, and since the credentials go across before any tunnel exists, there is nothing to hide them behind.

None of this means a paid endpoint is useless. It means the password protects the endpoint from strangers, not you from the network, and that is a smaller claim than the one being sold.

Ports, Addresses, and Who Resolves the Name

The socks proxy port you were handed may not be 1080, and that is not a mistake. The RFC gives a number and gives it with a word people drop. "The SOCKS service is conventionally located on TCP port 1080." Conventionally. Nothing requires 1080, and an endpoint on another port is not misconfigured. curl agrees with the convention rather than a rule: its documentation says that if the port is not specified "it is assumed at port 1080."

The address field is where version 5 gets more interesting, because the request carries an address type byte:

That choice is the honest answer to every argument about whether this leaks DNS, and it is not a matter of opinion. DOMAINNAME exists, so a client may pass the hostname and let the proxy look it up, in which case your own resolver never sees it. A client may equally resolve locally and send X'01', in which case it does. Which happens depends on the client. curl splits it into two options and documents the difference: --socks5-hostname means "use the specified SOCKS5 proxy (and let the proxy resolve the hostname)". Chromium documents that Chrome always resolves on the proxy side when the scheme is SOCKSv5, even though the protocol permits otherwise.

If the distinction between who asks and who answers is new, our guide to who resolves the name, and why that decides what leaks is where that question gets settled.

One last thing about the address itself. A socks5 proxy ip is not a special class of address; it is an ordinary public address belonging to whoever runs the relay, which is why the closing section ends on what that address may already be carrying.

SOCKS4, SOCKS4a, and Where the Version Gap Bites

A socks4 proxy is the older protocol and the differences are not cosmetic. RFC 1928 sets them out itself, in a single sentence that is usually quoted only as far as its first comma: "This new protocol extends the SOCKS Version 4 model to include UDP, and extends the framework to include provisions for generalized strong authentication schemes, and extends the addressing scheme to encompass domain-name and V6 IP addresses."

Four gaps come out of that one sentence, because its last clause covers two of them. Version 4 has no UDP, so no UDP ASSOCIATE command; the RFC says as much again when it describes the older protocol as providing "unsecured firewall traversal for TCP-based client-server applications". It has no domain-name address type and no IPv6 address type, both of which version 5 added to the addressing scheme, and version 5 numbers them ATYP X'03' and X'04'. Chromium's documentation states the second one as a matter of wire format rather than inference: "SOCKSv4 encodes target address as 4 octets, so IPv6 targets are not possible." And the authentication framework is a version 5 addition, so in version 4 there is no step at which credentials could be negotiated. An interim revision called SOCKS4a is widely described as having added hostnames before version 5 did, though SOCKS4 and 4a have no RFC of their own, so I am not citing a specification for that one.

This is not archaeology, because Windows speaks the old version. On Windows, the Socks field in Internet Options writes a WinINet configuration, and Microsoft's own reference lists SOCKS4 support as present for WinINet and absent for WinHTTP, explicitly noting it "Doesn't include v4a." There is no SOCKS5 field anywhere in the Windows proxy settings.

Before blaming a client for any of this, check the endpoint is listening at all. A socks5 proxy server that is down and one that rejects your method produce different failures, and our confirm the port is listening before you blame the client check separates them in one step.

SOCKS5 vs HTTP Proxy: What Each One Can See

The http vs socks proxy question usually gets answered with a list of benefits. It is better answered by what each one is able to know about your traffic, because every difference that matters follows from that.

Which to choose follows from the first row. If the thing you need to move is not web traffic, an HTTP proxy is the wrong shape and no amount of configuration fixes that. If it is web traffic and somebody needs to cache or filter it, a SOCKS proxy cannot do that job at all.

There is one browser-shaped trap here worth naming, and it is not the one usually reported. Chrome will accept a SOCKS5 endpoint by more than one route: a command-line flag, or a PAC script, which Chromium's documentation writes as SOCKS5 proxy:8080. What it will not do is authenticate: the same document states that "no authentication methods are supported for SOCKSv5 in Chrome (although some do exist for the protocol)". So a provider endpoint with a username and password cannot be used in Chrome at all, by any of those routes. The whole ranking of what Chrome reads is in how Chrome takes a SOCKS endpoint, and what it refuses to do with it.

And if you are staring at a settings screen with several pairs of boxes on it, wondering which pair a SOCKS host belongs in, that has a definite answer: which box a SOCKS host and port actually belong in covers it, and it is not the web proxy pair.

How to Get One Free, and SOCKS5 Proxy vs VPN

Search for how to get a SOCKS5 proxy and you land on pricing pages. There is a free answer that involves no provider and no list of endpoints, and it is documented by software you already have. Chromium's own proxy documentation points at it too, calling ssh -D "a handy way to create a SOCKSv5 proxy".

OpenSSH's manual describes the -D flag as a "local 'dynamic' application-level port forwarding", and then says this: "Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server." So if you have a shell account on a machine you trust, you have a SOCKS5 server. That last condition is the catch, and it is the whole catch.

Two things to understand before you rely on it. The listening socket's exposure follows your SSH configuration, not the command above: the manual says "the local port is bound in accordance with the GatewayPorts setting", and the switch that opens it up is -g, documented as allowing "remote hosts to connect to local forwarded ports". Do not add that flag casually. OpenSSH's own source is explicit about what its SOCKS server accepts: channels.c defines a single method constant, SSH_SOCKS5_NOAUTH 0x00, and refuses the handshake outright if the client did not offer it, logging "didn't request SSH_SOCKS5_NOAUTH". So an exposed dynamic forward is an open proxy with no password available to put on it. Open relays get found and used, and an address used that way can end up classified in ways that follow you around.

If instead somebody handed you an endpoint to configure, the shape is smaller than it looks. You need four values: host, port, username, password. They go into the SOCKS fields, which are a separate pair from the HTTP and HTTPS boxes on the same screen, and putting a SOCKS host into the web proxy box is a configuration error that produces no error message, only a connection that quietly does not use the proxy. Then, if the client offers the choice, decide whether it resolves names itself or hands them over, because that is the setting from the section above wearing a different label.

The second thing is what the tunnel actually protects. The hop from your machine to your server is inside SSH, so it is encrypted, but that is SSH's doing rather than anything SOCKS5 contributes. Beyond your server the traffic continues exactly as your application sent it.

The alternative on offer is a free public endpoint from a list, and that trade is worse than it looks. Whoever operates the relay is in a position to see every destination you connect to and, for anything not already encrypted, the contents. We set out the rest in what a free endpoint costs you in practice.

On the VPN comparison: a VPN is a tunnel the operating system routes traffic into, and this is an address you configure one application at a time. Three differences matter. Scope, because a VPN captures everything by default while a relay catches only what you pointed at it. Encryption, which a VPN provides and this does not. And failure mode, because when a relay dies the configured application simply cannot connect, which is noisier than a VPN dropping and, for troubleshooting, better. A provider selling both under one label has not merged the two capabilities, and the full comparison is in how the comparison with a VPN really breaks down.

One thing none of this gives you is a phone. There is no SOCKS field in iOS proxy settings, which we cover in why there is no SOCKS field on an iPhone at all, and Android models proxy support end to end as HTTP, which is the same missing option on Android, for a documented reason. On both, an app offering SOCKS5 is running its own tunnel beside the operating system rather than filling in a field.

How to Test a SOCKS5 Proxy, and What It Never Protects

Here is the whole post in one line before the procedure. The protocol is clear and complete; the software is where it falls apart. Authentication and UDP are both fully specified, and the clients people actually reach for are the ones that do not implement them.

If you were handed a host, port, username and password, start with the command below rather than with a settings screen. It is verbose on purpose: -v prints the handshake, so you see which step failed instead of guessing.

If that works and your application does not, the endpoint and the credentials are fine and the client is the problem, which is the case this section exists for. If it fails, the verbose output tells you where, and the four steps below are what you are reading it for.

A note on UDP, because it fails in two different places and step 3 only catches one of them. UDP ASSOCIATE is in RFC 1928, so UDP is a real capability of the protocol, but both ends have to implement it. A server that does not will answer with command not supported, which step 3 will show you. A client that never asks produces no reply code at all, and Chrome is one: Chromium states that "In Chrome SOCKSv5 is only used to proxy TCP-based URL requests. It cannot be used to relay UDP traffic." On the server side, OpenSSH's channels.c accepts only the CONNECT command and logs "only socks5 connect supported" for anything else, so a dynamic forward carries no UDP either.

So what should you actually use. If you hold a purchased endpoint with a username and password, you need a client that implements method 02, and the command above proves curl does. Chrome does not, by its own documentation, and no amount of configuration will change that, so stop trying to make Chrome carry a paid endpoint.

And if what you wanted was a working SOCKS5 proxy for Chrome specifically, there is a combination in this post that fits together, though you have to hold three of its pages open at once to see it. Chrome supports no SOCKS5 authentication methods. An SSH dynamic forward requires none, because it accepts only method 00. And Chromium's own proxy documentation recommends exactly that, calling ssh -D "a handy way to create a SOCKSv5 proxy". The endpoint Chrome can use is the one you run yourself, and it is free. The paid one with credentials is the one it cannot.

What it never protects is the last thing to be clear about. It adds no encryption, so it contributes nothing to traffic that was not already protected. And it does not make the connection look unremarkable: your traffic arrives at the destination from the relay's address, and relay addresses accumulate reputations. A site checking that address against an anonymizer database is not examining your protocol at all, which is what what happens when the endpoint's address is already classified is about.

Which is also the honest reading of "residential SOCKS5", sold as a single feature and explained as neither. It names a protocol and an address class and guarantees neither, and what a vendor means when it advertises a residential endpoint unpacks what is actually being sold.