HTTPS Proxy
An HTTP proxy that supports the CONNECT method to tunnel encrypted HTTPS traffic between client and destination.
An HTTPS proxy is an HTTP proxy that can carry encrypted HTTPS traffic. It uses the HTTP CONNECT method to open a tunnel: the client asks the proxy to connect to the destination on port 443, the proxy establishes the TCP connection, and encrypted data then flows through it end-to-end. The proxy relays the encrypted bytes without decrypting them.
This is different from a plain HTTP proxy handling unencrypted traffic, where the proxy can read and modify requests. With HTTPS via CONNECT, the TLS handshake happens directly between your client and the target, so the proxy sees only that a connection exists - not its contents. Your data stays confidential from the proxy operator.
In practice, almost every modern site uses HTTPS, so "HTTP proxy" from a commercial provider means one that supports CONNECT and handles HTTPS. When you configure a scraper with an HTTP proxy, it automatically uses CONNECT for https:// URLs. The same endpoint carries both http:// and https:// traffic.
HTTPS proxies are the default choice for web scraping because they work with every provider and every target. SOCKS5 is the alternative when you need to proxy non-HTTP protocols. For standard web data collection over HTTPS, an HTTP/HTTPS proxy is all you need.
Two different things called HTTPS proxy
The phrase is used for two arrangements that people constantly confuse. The first is a normal HTTP proxy carrying HTTPS traffic through a CONNECT tunnel, which is what almost everyone means and what almost every provider sells.
The second is a proxy you reach over TLS: the connection between your client and the proxy is itself encrypted. This protects your credentials and your destination list from anyone watching your local network, and it is rare because it requires the proxy to present a certificate.
In the first arrangement, your HTTPS traffic is encrypted end to end between your client and the destination. The proxy sees the hostname in the CONNECT line, the timing and the byte counts, and nothing else.
How ours works
Our endpoints speak HTTP for the proxy connection and tunnel HTTPS end to end:
The scheme confusion, resolved
curl -x http://login:password@proxy.sotaproxy.com:10000 https://example.com
^^^^ how you talk to us ^^^^^ how we talk to the target
# Writing http:// as the proxy scheme while fetching an https:// page
# is correct and trips up almost everyone once.- Your HTTPS content is not readable by us or anyone in between. CONNECT builds a tunnel and the TLS session runs inside it.
- The hostname is visible to us in the CONNECT request, which is unavoidable in this design and true of every provider.
- If you need the local hop encrypted as well, use SOCKS5 over an SSH tunnel or a VPN to reach the proxy.
- Certificate errors through a proxy usually mean interception somewhere on your network, not a fault at our end.
HTTPS proxy confusions
The proxy scheme is not the target scheme
http:// as the proxy and https:// as the target is the normal, correct combination.
A proxy does not decrypt your HTTPS
That requires a certificate your client trusts, which is a corporate arrangement rather than a public product.
SOCKS5 is not encrypted either
Neither protocol adds encryption. Your security comes from TLS at the application layer.
verify=False does not fix proxy errors
It hides them. A 407 disguised as a certificate problem is still a 407.
Related terms
See this in practice
Ready to use https proxy?
SotaProxy gives you access to rotating residential, mobile, datacenter, and ISP proxies. No minimum commitment.
Get started