The four protocols labelled "proxy" share little beyond the name. HTTP proxies parse Layer 7 and rewrite headers; SOCKS proxies do not read your traffic at all. The distinction governs which proxy fits browsing, scraping, and raw tunnelling.
HTTP Proxy
An HTTP proxy expects HTTP semantics. It opens the request, reads the URL, can attach headers like Via or X-Forwarded-For, and refuses anything that is not a valid HTTP request. Browsers, curl, and most scraping libraries default to HTTP proxies because configuration is essentially free — set a single environment variable or pass a flag.
The cost of that simplicity is visibility. The proxy sees the full URL, including the path and query string, and in plaintext HTTP it sees the body too. Caching proxies can rewrite responses; transparent proxies can strip cookies. Treat any HTTP proxy as a fully privileged intermediary and never send credentials over plaintext.
HTTPS Proxy and the CONNECT Method
"HTTPS proxy" is a slightly misleading label. It refers to an HTTP proxy that additionally implements the CONNECT method. CONNECT tells the proxy to open a raw TCP tunnel to a target host and shuttle bytes in both directions; the client and the destination then negotiate TLS as if the proxy were not there. The proxy sees the destination host and port, and the volume of bytes, but not the payload.
An "HTTPS-supporting" proxy is therefore a proxy that supports tunnelling TLS, not a proxy that itself runs over TLS. The link from your machine to the proxy can be plaintext or encrypted independently. If you care about that link being protected, use a SOCKS5-over-TLS implementation or a paid commercial proxy that publishes its TLS endpoint.
SOCKS4
SOCKS4 is the 1994 minimum: TCP only, IPv4 only, no UDP, no IPv6, no authentication, no hostname resolution at the proxy. The handshake is six bytes plus a one-byte response code. It survives in the wild because the protocol is so small that almost any TCP-aware tool can implement it correctly. If a list advertises SOCKS4, expect raw TCP forwarding to an IPv4 address — and nothing else.
SOCKS5
SOCKS5, defined in RFC 1928 (1996), is the version most modern tooling speaks. It adds UDP forwarding, IPv6 addresses, GSSAPI authentication, and the option to resolve hostnames at the proxy rather than the client. Because SOCKS5 makes no assumptions about the application layer riding on top, it is the most flexible choice for non-HTTP workloads: SSH, IRC, BitTorrent, custom RPC.
Performance and Overhead
SOCKS proxies have lower per-request overhead because they do not parse anything. HTTP and HTTPS proxies pay for full request parsing on every connection. For a single long-lived TLS session inside CONNECT, the difference is negligible. For thousands of short requests where the proxy opens a new connection each time, SOCKS5 measurably wins — typically 2–5 ms per request for the parsing path.
Anonymity, in Practice
An HTTP proxy that does not strip your headers can leak your client IP via Via, X-Forwarded-For, or Forwarded. SOCKS proxies have no such headers because they have no concept of headers. That is not an anonymity feature so much as the absence of a leak surface. Inside CONNECT-tunnelled HTTPS, the destination only sees the TLS handshake, so any HTTP-level leakage at the proxy is moot.
Port Conventions
You will see these in this directory: 80, 8080, 3128, 8888 for HTTP; 443 for endpoints that explicitly support CONNECT; 1080 for SOCKS. Many providers expose non-standard high ports (above 10,000) to evade casual port scanning. The port number says nothing about quality — it only signals what the operator chose to expose.