SOCKS5 vs HTTP proxy: DNS, speed, security, which to use

Originally published on proxymint.

SOCKS5 vs HTTP proxy compared: what each carries, where DNS resolves (socks5 vs socks5h), speed, auth, client support, and which one your job needs.

TL;DR

• An HTTP proxy speaks HTTP; a SOCKS5 proxy relays any TCP stream. For HTTPS sites both end up as a blind tunnel around the client's own TLS session.
• Neither protocol encrypts anything, credentials included. TLS protects the content inside either tunnel, while the proxy login crosses the first hop in plain text on both.
• DNS is the difference that bites. In curl and Python requests, socks5:// resolves hostnames locally and socks5h:// sends them to the proxy, while an HTTP CONNECT from curl, requests or a browser hands the hostname to the proxy.
• Client support often settles the choice. Chrome cannot log in to a SOCKS5 proxy, and Scrapy's default download handlers cannot use SOCKS at all.

Key takeaways

• Default to an HTTP proxy for HTTP and HTTPS jobs. Nearly every client supports it, credentials work in browsers, and the hostname goes to the proxy with no extra setting.
• Use socks5h:// whenever a job runs over SOCKS5. DNS then happens on the proxy side instead of on your machine.
• Run the three-command tcpdump check once per client. Send one request over http, socks5 and socks5h and confirm only the socks5 variant resolves locally.
• Keep SOCKS5 for non-HTTP protocols and SOCKS-only tools. Mail, database and custom TCP clients need it; web scraping rarely does.

Read the full guide on proxymint, with the commands, tables and sources.