HTTP proxy is the boring default
For browser automation and most HTTP clients, the plain HTTP proxy is the right place to start. It carries ordinary HTTP requests directly, and it reaches HTTPS targets by issuing a CONNECT request that asks the proxy to open a raw tunnel to the destination. Crucially, the client and the target still negotiate TLS end to end through that tunnel, so the proxy never sees inside the encrypted session. This is also the best-documented path in nearly every library, which is reason enough to reach for it first.
Keep two URLs separate in your head. The target can be https://example.com while the proxy URL is http://host:port; those describe different hops, and an HTTP proxy fetching an HTTPS page is completely normal rather than a misconfiguration.
HTTPS proxy transport is about the client-to-proxy hop
An HTTPS proxy adds one specific thing: it encrypts the connection between your client and the proxy, so that first hop is no longer in the clear. It does nothing to change how the target sees you and grants no extra trust at the destination. When the target itself is HTTPS, the proxy still reaches it through the same CONNECT tunnel, so HTTPS-on-HTTPS is just transport encryption stacked on top of ordinary tunneling. Plenty of tools support plain HTTP proxies more reliably than HTTPS proxy transport, so confirm your specific client handles it before committing.
SOCKS5 is useful when the client supports it well
SOCKS5 sits below HTTP and is protocol-agnostic (RFC 1928): it forwards a TCP (or UDP) connection without caring whether the payload is HTTP, a database wire protocol, or anything else, which is what makes it handy for mixed-protocol work and for apps that only expose SOCKS fields. Two practical notes go with it. Python Requests needs its SOCKS extra installed before any socks5 URL will work, and you should prefer socks5h:// when you want the proxy to resolve the target hostname instead of leaking that lookup to your local resolver.
One sharp edge catches people in browsers: browsers do not send proxy credentials to a SOCKS proxy. If a SOCKS5 line needs a username and password, a browser configured to use it straight will typically fail to authenticate, which is why SOCKS auth in browser work usually runs through a local helper or an automation framework that handles the credentials itself.
| Scheme | DNS location | Common use |
|---|---|---|
http:// | Client resolves proxy host | Browsers, curl, most HTTP clients. |
https:// | Client resolves proxy host | Encrypted client-to-proxy transport when supported. |
socks5:// | Often local DNS | Apps with SOCKS support. |
socks5h:// | Proxy resolves target host | Avoiding local target DNS leaks. |
Bandwidth looks different by scheme and client
Switching schemes does not make failed traffic free. Redirects, CONNECT setup, failed attempts, and retries all count against the meter no matter which protocol carried them. The bigger lever is the client itself: browser jobs usually burn far more than a plain HTTP client because they pull down every page asset unless you explicitly block images, fonts, and trackers.
Two different connections
Most proxy confusion clears up the moment you split the path into two connections. First your client connects to the proxy; then the proxy connects to the target. The proxy scheme mainly describes that first hop, while the target URL describes the second, and they do not have to match.
That is exactly why http://proxy-host:port can fetch https://target.example. The client asks the proxy to open a CONNECT tunnel to the target, and once the tunnel is up the target TLS session runs end to end between client and target, with the proxy only shuttling encrypted bytes it cannot read.
| Question | Look at |
|---|---|
| Can my client speak to the proxy? | Proxy scheme and client support. |
| Can the target use HTTPS? | Target URL and CONNECT behavior. |
| Where does DNS happen? | socks5 vs socks5h. |
| Why is traffic billed? | Both hops, redirects, retries, and assets. |
Choose by client support first
Protocol debates turn abstract quickly, but the decision rarely is. The practical question is which scheme your particular client handles with the fewest surprises. Browser automation tends to have the best-documented HTTP proxy behavior, Python handles SOCKS well once the extra dependency is installed, and a random desktop app may only give you SOCKS fields to fill in. Let those constraints, not a preference for one protocol, narrow the choice.
When more than one scheme works, the tie-breaker is operational: pick the one that produces clearer logs and fewer parser errors. Reliability you can debug beats theoretical elegance you cannot.
Writing this down for your team
If you are documenting setup for other people, spell out the exact scheme per client instead of writing "use the proxy" and hoping every library behaves alike. Playwright, Puppeteer, Requests, axios, and a desktop app can each want a different shape for the same underlying line, and a guide that papers over those differences just moves the confusion downstream.
Protocol FAQ
Is SOCKS5 always better? No. It is better only when your client supports it cleanly and you need its behavior.
Does HTTPS proxy mean the target sees HTTPS? No. It describes the client-to-proxy transport. The target URL is separate.
What should beginners use? HTTP proxy for browser automation. socks5h for Python when proxy DNS matters.