Last updated: 2026-10-18
An "HTTPS proxy" does not encrypt anything that SOCKS5 leaves open. Both carry an HTTPS site as the same end-to-end TLS session, and both send your proxy password to the gateway in plain text. In October 2026 we ran 11 proxies from 5 providers through both protocols side by side, 50 rounds each, on the same gateways with the same login.
On every proxy with a fixed IP, SOCKS5 was slower to connect, by exactly two round trips to the gateway: 37 ms on a nearby gateway, 574 ms on a distant one. Once the connection was open, downloads ran at the same speed. The differences that decide the choice are elsewhere: who resolves DNS, whether UDP works, what your browser accepts and what WebRTC sends around the proxy.
Short answer
- For websites, scrapers and headless browsers, use HTTP. Every tool supports it with a login and password, and it connects faster.
- Use SOCKS5 for software that is not a web client: Telegram, mail clients, SSH, game launchers, desktop apps.
- With SOCKS5, turn on remote DNS (
socks5h://in curl and Python). With plainsocks5://all 11 proxies left the DNS lookups to our own server's resolver. - Do not count on UDP. SOCKS5 defines it, but only 1 of the 11 proxies delivered a UDP packet.
- Neither protocol hides your IP from WebRTC in Chromium. One browser flag fixes it, see below.
What "HTTPS proxy" really means
When a provider lists "HTTP/HTTPS" next to "SOCKS5", HTTPS means the proxy can open HTTPS sites, not that your connection to the proxy is encrypted. Your client sends CONNECT example.com:443 to the gateway in plain text, the gateway opens a TCP connection to the site, and from then on it relays bytes. The TLS handshake runs between your client and the site. The proxy sees the domain name and the volume of traffic, not the pages, passwords or cookies.
SOCKS5 does the same job one layer lower. The client asks the gateway to connect to a host and port, and the gateway relays bytes. For an HTTPS site the result is the same. On all 11 proxies both protocols gave TLS 1.3, HTTP/2 and the site's own certificate, and the site received the same set of request headers.
The connection to the proxy itself is open in both cases. An HTTP proxy gets the login in a Proxy-Authorization: Basic header, which is base64, not encryption. SOCKS5 gets it as plain bytes, as RFC 1929 defines. On a network you do not trust, anyone who can watch the traffic can read the proxy password.
An encrypted connection to the proxy does exist. It is a proxy address that starts with https://: your client first runs a TLS handshake with the gateway, and the password travels inside it. We tried it on 14 proxies from 8 providers. Three gateways accepted it on their normal port, and two of them, Thordata and Proxmint, presented a certificate that passes verification. It added 40 to 130 ms to the first byte.
SOCKS5 vs HTTP proxy: the differences that are real
| HTTP(S) proxy | SOCKS5 | |
|---|---|---|
| What it carries | Web requests, and other TCP connections through CONNECT where the provider allows other ports | Any TCP connection, UDP in the standard |
| HTTPS sites | End-to-end TLS through CONNECT | End-to-end TLS, the same result |
Plain http:// sites | The proxy reads the request and can change it | The proxy relays bytes untouched |
| DNS | Always resolved on the proxy side | On the proxy side with socks5h, by your own resolver with socks5 |
| UDP | No | 1 of 11 proxies in our test delivered it |
| New connection with a login | One round trip to the gateway | Three round trips to the gateway |
| Download speed once connected | The same in our test | |
| Login and password in Chrome and Firefox | Supported | Not in Chrome, only through extensions in Firefox |
| Encryption to the proxy | Only with an https:// proxy address | No |
Our test: the same proxies through both protocols
Each proxy got 50 rounds. In every round we opened one fresh connection through HTTP and one through SOCKS5 with remote DNS, alternating which went first, and measured the time to the first byte of a small HTTPS page. Then we sent 10 more requests over an already open connection and downloaded a 1 MB file three times through each protocol. Success was 49 or 50 out of 50 on every proxy and protocol.
Proxies with a fixed IP give the cleanest comparison, because the exit does not change between rounds:
| Proxy | Round trip to the gateway | First byte, HTTP | First byte, SOCKS5 | SOCKS5 slower by | Open connection, HTTP / SOCKS5 |
|---|---|---|---|---|---|
| Proxy Seller, IPv6 | 19 ms | 99 ms | 136 ms | 37 ms | 28 / 26 ms |
| SpaceProxy, shared datacenter | 26 ms | 192 ms | 252 ms | 60 ms | 92 / 53 ms |
| Proxy Seller, ISP | 70 ms | 735 ms | 874 ms | 139 ms | 148 / 148 ms |
| Proxy Seller, dedicated datacenter | 290 ms | 2744 ms | 3318 ms | 574 ms | 592 / 554 ms |
The extra time is two round trips to the gateway on every proxy, whatever the type or provider. That is the protocol itself. SOCKS5 with a password needs a greeting, then the login, then the connect request, each waiting for an answer. An HTTP proxy gets the login and the destination in one request.
So the cost of SOCKS5 depends on how far you are from the gateway: small next to it, half a second on a gateway across the world.
Once the tunnel is open, both protocols just relay bytes. The 1 MB download ran at the same speed through both: 74 Mbit/s on the IPv6 proxy, 19 Mbit/s on ISP, 4.8 Mbit/s on the dedicated datacenter proxy. Requests on an open connection were also even, with one exception: SpaceProxy's HTTP port answered in 92 ms against 53 ms on its SOCKS5 port, so a long session there runs faster over SOCKS5.
Rotating proxies change the exit on every request, so each round lands on a different home or phone connection:
| Proxy | First byte, HTTP | First byte, SOCKS5 | Rounds where SOCKS5 was faster |
|---|---|---|---|
| Evomi, rotating residential | 514 ms | 608 ms | 35% |
| Evomi, rotating mobile | 620 ms | 769 ms | 38% |
| Evomi, rotating datacenter | 815 ms | 798 ms | 49% |
| NodeMaven, rotating residential | 880 ms | 970 ms | 48% |
| NodeMaven, rotating mobile | 1073 ms | 1255 ms | 43% |
| Proxmint, rotating residential | 1274 ms | 1216 ms | 51% |
| Proxy Seller, rotating residential | 686 ms | 655 ms | 50% |
Here the gap between two exits is far larger than the gap between protocols. Downloads through rotating gateways ranged from 0.5 to 58 Mbit/s, and two downloads in a row through the same gateway and protocol often differed several times over. On Evomi and NodeMaven, HTTP still came out ahead in the median, by 90 to 180 ms. On Proxmint, Proxy Seller and Evomi's datacenter pool the protocols were even. A single test request tells you nothing about a rotating proxy, so compare them over dozens of requests or not at all.
DNS: the leak that SOCKS5 adds
With an HTTP proxy the gateway always resolves the site's name, because the name is part of the request. SOCKS5 lets the client choose. With socks5:// your machine looks up the address first and sends the proxy only the IP. With socks5h:// it sends the name and the proxy side looks it up.
We looked up a unique test domain through each proxy in each mode and checked which resolver asked for it. With socks5:// it was our own server's resolver, an OVH data center in France, on all 11 proxies, while the site saw an exit IP in another country.
A website does not see your resolver, but DNS leak tests do, and the operator of that resolver sees every domain you open. With socks5h:// and with HTTP the lookups came from the proxy side: Google and Cloudflare public resolvers on most gateways, and the local internet provider's resolver on some residential and mobile exits.
Remote DNS has one side effect. The resolver was often in another country than the exit: a rotating residential exit in Colombia resolved through Google in the United States, a mobile exit in Russia through resolvers in Singapore. Large CDNs pick the server by the resolver's location, so such a request can be sent to a server far from the exit and take longer.
How to turn on remote DNS:
- curl:
--proxy socks5h://user:pass@host:portor--socks5-hostname host:port - Python requests:
proxies={"https": "socks5h://user:pass@host:port"}, afterpip install "requests[socks]" - Proxifier and similar tools: the option to resolve hostnames through the proxy
Plain HTTP sites: what an HTTP proxy can change
On a http:// address there is no TLS, so an HTTP proxy works as a real intermediary: it reads the request and sends its own copy. On NodeMaven and on the residential gateway of Proxy Seller that copy carried an Accept-Encoding header our client had not sent.
Through SOCKS5 and through a CONNECT tunnel the same request arrived unchanged on every proxy. None of the 11 proxies passed our server's IP to the site in X-Forwarded-For, in either protocol. The old rule that "SOCKS5 is more anonymous" did not hold for any provider we tested.
UDP: in the standard, rarely in practice
SOCKS5 has a UDP mode, UDP ASSOCIATE, and it is the usual reason to pick SOCKS5 for games, voice calls and QUIC. We asked each gateway for it and sent a DNS query to 1.1.1.1 through the relay.
- Delivered: SpaceProxy, shared datacenter. The query went out and the answer came back.
- Accepted the command, dropped the packets: Proxy Seller, rotating residential. No error, no answer.
- Refused: Evomi on all three gateways, Proxy Seller on IPv6, ISP and dedicated datacenter (reply "command not supported"), Proxmint ("not allowed").
- Closed the connection: NodeMaven on both gateways.
If you need UDP, test it on the smallest package before you buy volume. A gateway that accepts the command can still drop every packet, and most software falls back to TCP without telling you.
Browsers: SOCKS5 with a password does not work
Chrome has no support for a SOCKS5 login, and Firefox takes one only from extensions, not from its proxy settings. We launched Chromium and Firefox through Playwright with credentials that worked in curl, and both refused with "Browser does not support socks5 proxy authentication". The same login over HTTP worked in both. For a plain or headless browser that leaves two options: an HTTP proxy, or SOCKS5 authorized by your IP address, which most providers allow in the dashboard. Antidetect browsers and proxy extensions pass the SOCKS5 login themselves, so the limit applies to the browser on its own.
WebRTC goes around both protocols
WebRTC learns your public address by sending UDP to a STUN server. We opened a page through the proxies of Proxy Seller, SpaceProxy and NodeMaven and collected the WebRTC candidates. The result was the same on all three:
| Browser and proxy | IP seen by the page | Public IP in WebRTC |
|---|---|---|
| Chromium, HTTP proxy | Proxy | Our server's real IP |
| Chromium, SOCKS5 | Proxy | Our server's real IP |
Chromium, either protocol, with --force-webrtc-ip-handling-policy=disable_non_proxied_udp | Proxy | None |
| Firefox (Playwright build), HTTP proxy | Proxy | Our server's real IP |
| Firefox (Playwright build), SOCKS5 | Proxy | None |
SpaceProxy delivers UDP through SOCKS5, and Chromium still sent WebRTC around it, so a gateway with UDP does not fix this either. In Chromium the fix is the flag above or the same policy set by a WebRTC extension. Antidetect browsers replace the WebRTC address with the proxy's. Check your own setup with our WebRTC leak test after you connect the proxy.
Ports: where providers put SOCKS5
Providers do not sell SOCKS5 and HTTP as separate products. One plan gives both, and only the port or the scheme in the address changes:
| Provider | HTTP and SOCKS5 |
|---|---|
| Evomi | Separate ports: residential 1000 and 1002, mobile 3000 and 3002, datacenter 2000 and 2002 |
| NodeMaven | Separate ports: 8080 and 1080 |
| Proxmint | One port for both |
| Proxy Seller | One port for both, on the rotating gateway and on static IPs |
| SpaceProxy | Separate ports, SOCKS5 on the next port number |
A gateway with one port tells the protocols apart by the first bytes, so you only change http:// to socks5h://. With separate ports, a client pointed at the wrong one fails with an unclear error such as an empty reply, which is the most common reason behind "SOCKS5 does not work".
Which protocol to choose for your task
| Task | Protocol | Why |
|---|---|---|
| Web scraping with curl, Python, Node.js | HTTP | Faster to connect, no extra libraries. SOCKS5 only with remote DNS |
| Playwright, Puppeteer, Selenium | HTTP | Chromium and Firefox do not accept a SOCKS5 login |
| Antidetect browsers, multi-accounting | Either | The browser handles the login and WebRTC |
| Telegram, mail clients, SSH, desktop apps | SOCKS5 | They do not speak HTTP |
| Games, voice and video calls | SOCKS5 with working UDP | Test UDP first, few gateways deliver it |
| Public Wi-Fi | An https:// proxy address, where the provider supports it | The only option that encrypts the proxy password |
The protocol does not decide which sites let you in. That depends on the IP: its type, its network and its history. For that choice see our guide to choosing a proxy type and the weekly results in our proxy benchmark.
How to check your own proxy
- Exit and protocol:
curl -x socks5h://user:pass@host:port https://www.cloudflare.com/cdn-cgi/trace, then the same withhttp://. Both should show the same exit country andhttp=http/2. - Connection cost: add
-s -o /dev/null -w "%{time_connect} %{time_appconnect}\n"and run it 20 times per protocol. The first number is the round trip to the gateway. On a fixed IP, SOCKS5 should come out about two of those slower. - DNS: open a DNS leak test through the proxy with
socks5and withsocks5hand compare the resolvers. - Whether the proxy works at all, its type and location: our proxy checker.
Providers in this test
All five sell both protocols on one plan.
Evomi
https://evomi.com/
$0.49/GB
Proxy Type
Mobile Proxies, Residential Proxies, ISP Proxies, Datacenter Proxies
Pool of IPs
100M+ IP
Date established
2014
Headquarters
Switzerland
Pros & Cons
- Free trial
- 30-day refund window
- Up to 51% cheaper per GB at volume
- 5 proxy types in one account
- A pay-as-you-go plan is available with no monthly fees
- VAT is additionally charged when paying by card
Proxy Type
Mobile Proxies, Residential Proxies, ISP Proxies
Pool of IPs
30M+ IP
Date established
2023
Headquarters
Estonia
Pros & Cons
- Paid test for $3.50
- Up to 48% cheaper per GB at volume
- With monthly plans, unused traffic is carried over to the next month
- Pay-as-you-go option available
- Limited payment methods
Proxmint
https://proxmint.com/
$1.25/GB
Proxy Type
Mobile Proxies, Residential Proxies, Datacenter Proxies
Pool of IPs
90M+ IP
Date established
2026
Headquarters
Indonesia
Pros & Cons
- Up to 31% cheaper per GB at volume
- Low price per gigabyte
- Over 90 million IPs
- Traffic packs never expire
- Rotating datacenter pool billed per GB
- No refunds at all
- Cryptocurrency payment only
- No static or per-IP products
- Sub-country targeting doubles traffic use
Proxy Type
Mobile Proxies, Residential Proxies, Individual IPv6 Proxies, ISP Proxies, Datacenter Proxies
Pool of IPs
47M+ IP
Date established
2014
Headquarters
Cyprus
Pros & Cons
- 24-hour refund window
- Up to 63% cheaper per GB at volume
- 8 proxy types in one account
- SDKs: PHP, Python, Node.js, Java, GoLang
- 24/7 support
Proxy Type
Individual IPv6 Proxies, Datacenter Proxies
Pool of IPs
47M+ IP
Date established
2019
Headquarters
Cyprus
Pros & Cons
- 2-day refund window
- 8 payment methods
- IPv6 proxies available
- Wide selection of countries
- There are complaints about the quality of customer support.
How we tested
The test ran on 18 October 2026 from our server in a London data center, with curl 8.5. We used the test accesses from our proxy benchmark, the 11 that serve both protocols. Every comparison used the same gateway and the same login. Only the scheme changed and, where the provider requires it, the port.
- Timing: 50 rounds per proxy, a fresh connection for every request, alternating protocol order, to
https://www.cloudflare.com/cdn-cgi/trace. - Open connection: three runs of 11 requests on one connection, the first request of each run not counted.
- Speed: a 1 MB file from our server, three times per protocol, transfer time only.
- DNS: unique subdomains of a public DNS leak test service, one per mode.
- Headers: httpbin.org over plain HTTP and HTTPS.
- UDP: a SOCKS5
UDP ASSOCIATErequest and a DNS query to 1.1.1.1 through the relay. - Browsers: Chromium and Firefox through Playwright, WebRTC candidates from
stun.l.google.com. SOCKS5 in the browser ran through a local relay without a password, since neither browser accepts one.
This was a one-time test, separate from the weekly benchmark.
Sources
- RFC 1928: SOCKS Protocol Version 5
- RFC 1929: Username/Password Authentication for SOCKS V5
- RFC 9110: HTTP Semantics, the CONNECT method
- Everything curl: SOCKS proxies and socks5h
- Our proxy benchmark code on GitHub
FAQ
- Is SOCKS5 faster than an HTTPS proxy?
- No. In our test of 11 proxies, SOCKS5 with a login was slower to open each new connection, by two round trips to the gateway, from 37 ms to 574 ms depending on distance. Once the connection was open, download speed was the same through both.
- Is SOCKS5 encrypted?
- No. SOCKS5 relays bytes as they are and sends the login in plain text. An HTTPS site stays encrypted through it because TLS runs between your client and the site, exactly as it does through an HTTP proxy.
- Does an HTTPS proxy encrypt my traffic?
- Not the connection to the proxy. "HTTPS proxy" usually means an HTTP proxy that opens HTTPS sites through CONNECT, and the proxy password travels as base64. Only a proxy address that starts with https:// encrypts the link to the gateway, and 2 of the 14 proxies we tried supported it with a valid certificate.
- What is the difference between socks5 and socks5h?
- With socks5 your own computer resolves the site's name and sends the proxy only the IP, so your DNS resolver sees every domain. With socks5h the name goes to the proxy and it resolves it. With socks5 all 11 proxies in our test left the lookups to our own resolver.
- Does SOCKS5 support UDP?
- The protocol does, most gateways do not. Only 1 of the 11 proxies we tested delivered a UDP packet, one more accepted the request and dropped the packets, and the rest refused it.
- Can I use a SOCKS5 proxy with a login in Chrome?
- No. Chrome does not support SOCKS5 authentication, and Firefox accepts it only from extensions. Use an HTTP proxy with the same login, SOCKS5 authorized by your IP address, or an antidetect browser.
- Does SOCKS5 stop WebRTC leaks?
- No. In Chromium, WebRTC showed our server's real IP with an HTTP proxy and with SOCKS5 alike. The flag --force-webrtc-ip-handling-policy=disable_non_proxied_udp or a WebRTC extension stops it.
- Which is better for web scraping, SOCKS5 or HTTP?
- HTTP. It connects faster, every scraping library supports it without extras, and on HTTPS sites the target sees the same request either way. If you use SOCKS5, use socks5h so DNS goes through the proxy.
