SOCKS5 Proxy

SOCKS5 is a transport layer proxy protocol that forwards raw TCP, and optionally UDP, without parsing what it carries. An HTTP proxy understands the request it relays and can read, rewrite or add headers. A SOCKS5 proxy negotiates authentication, opens a connection to the destination and then moves bytes. It has no opinion about the payload because it never looks inside it.

For a scraping stack that buys three things. Protocols other than HTTP pass through unchanged, which matters for anything speaking a custom or non-web protocol. The proxy cannot inject or strip headers, so the request that arrives at the target is exactly what your client built, with no vendor added fields to explain away. And TLS terminates at the target rather than at the proxy, so the fingerprint the target measures is your client's, not a normalized version produced by an intermediary. When you have spent effort matching a real browser's TLS and header ordering, a proxy that cannot touch either preserves that work.

The costs run in the same direction. Because the vendor cannot see the request, the vendor side features built on seeing it are unavailable: automatic retry on a failed status code, header normalization, response rewriting and most managed unblocking. If you are paying for a product whose value is request level intelligence, running it over SOCKS5 removes the product. There is also a DNS trap. The curl manual documents the distinction plainly: --socks5 means "Use the specified SOCKS5 proxy - but resolve the hostname locally", while --socks5-hostname means "Use the specified SOCKS5 proxy - but let the proxy resolve the hostname". Plain socks5 resolves the target name on your machine, which sends the lookup to your own resolver from your own address. The scheme commonly written socks5h defers resolution to the proxy.

So the choice is fingerprint fidelity against vendor tooling. Run SOCKS5 when you control the client fingerprint and want nothing between you and the target, and run an HTTP proxy when you are buying the vendor's request handling. Whichever you pick, check the DNS path before trusting the setup: use socks5h or the equivalent library flag, then verify by watching which resolver actually sees the query. A stack that hides its exit IP while leaking every hostname it visits to a corporate or home resolver has undone the point of the exercise.