SOCKS5 and HTTP proxies

Two protocols the browser uses to go through an intermediary. The difference is at what level the intermediary works.

An HTTP proxy understands web requests: it sees where you're going and can process them. For secure connections (https://) it opens a pass-through tunnel and doesn't see the content beyond that — only the destination's address.

SOCKS5 doesn't understand anything and doesn't want to: it just carries bytes between you and the destination. Because of that, not only the web but any other protocol can go through it.

What matters about this in practice

First — DNS. If your computer resolves the site's name instead of the proxy, the name lookup goes outside the tunnel and your provider sees where you're going. That doesn't show the site your address directly, but it is a leak. With SOCKS5 the behaviour depends on the setting, so check the result rather than the protocol's name.

Second — authorisation. A proxy with a login and password is more complex to set up in the browser than one without, and that's usually where something breaks.

What it is NOT

The choice of protocol is almost never the cause of a captcha. We checked this directly, during a week spent catching a looping check: we tried, among other things, HTTP versus SOCKS. There was no difference — the issue turned out to be the reputation of the address itself.

So the order of investigation is: first what kind of address (server or home), then where it actually exits from, and only then the protocol.

What to choose

If the seller offers both, take either — you won't notice the difference in the browser. SOCKS5 is more convenient when the same proxy is needed for more than just the browser. HTTP is slightly simpler to set up where authorisation is needed.

What matters more: check every address for whether it's alive and where it exits from before you assign it to an account, not after.