SOCKS4 proxy
An older version of the SOCKS protocol that relays TCP traffic but lacks authentication, UDP support and remote DNS.
Most people meet SOCKS4 the same way: filtering a public proxy list and finding a protocol column with four entries in it. It is worth knowing what the label buys you, because in that context it is usually the wrong pick and occasionally the only one available.
SOCKS4 carries the core SOCKS idea, a TCP tunnel the proxy relays without inspecting, and then stops. There is no authentication step in the protocol at all, so a SOCKS4 endpoint is open to anyone who knows the address and port. There is no UDP, so it cannot carry DNS lookups or real-time traffic. And the original specification addresses the destination as an IPv4 address only, which means no IPv6 targets and no handing the proxy a hostname.
That last gap produced a patch rather than a new version. SOCKS4a extends the request so a client can send a domain name and let the proxy resolve it. Support is inconsistent, and a list rarely tells you which of the two you are getting, so a SOCKS4 entry that quietly needs local DNS resolution will leak every lookup to your own resolver while appearing to work perfectly.
The absence of authentication has a second effect worth naming. An open relay attracts everyone who finds it, so a public SOCKS4 address tends to be carrying traffic from many uncoordinated strangers at once, which is exactly the reputation problem a shared address has, in its most extreme form.
None of this makes it useless. For plain outbound TCP to a known IP, on a network you control, it relays fine and always has. But when a client offers both, there is no scenario where picking SOCKS4 over SOCKS5 gains you anything.
How HProxy handles it
Our free list exposes protocol as a filter because the label changes what an entry can actually do, not because more facets look better. A SOCKS4 entry that a tool treats as SOCKS5 will fail in ways that look like the proxy being dead rather than the protocol being wrong.
Frequently asked questions
Should I ever choose SOCKS4 over SOCKS5?
Only when SOCKS4 is the only option available, which on public lists it sometimes is. Where a client offers both, there is no scenario in which SOCKS4 gains you anything: SOCKS5 adds authentication, UDP, IPv6 and hostname resolution and removes nothing.
What is SOCKS4a?
An extension to SOCKS4 that lets a client send a domain name and have the proxy resolve it, which the original specification could not do. Support is inconsistent and lists rarely tell you which variant an entry is, so a SOCKS4 entry that quietly needs local DNS resolution will leak every lookup to your own resolver while appearing to work.
Does SOCKS4 support authentication?
No. There is no authentication step in the protocol at all, which is why a SOCKS4 endpoint is open to anyone who knows the address and port. That is also why public SOCKS4 addresses tend to be carrying traffic from many uncoordinated strangers, with all the reputation consequences that implies.
Can SOCKS4 carry HTTPS traffic?
Yes, because SOCKS4 relays a raw TCP stream and does not care what rides inside it, so an encrypted connection passes through untouched exactly as any other bytes would. What it cannot do is resolve the destination hostname for you or carry UDP, so a client that resolves names locally still leaks its DNS lookups regardless of the encryption. The tunnel is fine; the missing features around it are the reason to prefer SOCKS5.
Back to the full glossary.