When a proxy provider's site says "HTTPS supported", it almost always means something different from what you think. What gets sold under that label is a regular HTTP proxy that tunnels HTTPS destinations. A real HTTPS proxy is a separate category where the channel between your client and the proxy is itself encrypted. The difference is visible to your ISP, to public Wi-Fi operators, and to corporate monitoring. And it decides whether third parties learn which sites you're accessing.
This article covers where the line actually runs between the two products, why it matters, and which scenarios make HTTPS proxies hard to replace. No marketing filler. Just protocol mechanics and real situations.
Two different things sold under one name
To avoid confusion, here's what each one looks like at the protocol level.
A regular HTTP proxy. Your client (browser, curl, scraper) opens an unencrypted TCP connection to the proxy. For an HTTPS destination, the client sends CONNECT www.bank.com:443 HTTP/1.1 in cleartext over that TCP connection. The proxy opens a TCP connection to the bank, replies with "200 Connection Established", and relays bytes back and forth. The TLS handshake runs between your client and the bank; the handshake bytes flow through the proxy, but the proxy doesn't decrypt them.
Here's the important part. The ClientHello message, which starts a TLS handshake, is sent in the clear. It carries the Server Name Indication (SNI) extension, which contains the destination hostname. SNI exists so the server knows which virtual host you want (necessary when one IP fronts thousands of domains). SNI is readable by anyone observing traffic on the client-to-proxy leg: your ISP, a Wi-Fi operator, a corporate DPI appliance. On top of that, the CONNECT command itself already contains the same hostname in plaintext. Two separate leaks on the same path. BANK.COM shows up in two places between you and the proxy.
A real HTTPS proxy. Your client opens TCP to the proxy and immediately wraps it in TLS, exactly like connecting to a regular HTTPS site. Only the valid certificate belongs to the proxy, not to the bank. Once the TLS session with the proxy is established, every subsequent command, including CONNECT www.bank.com:443, runs inside that encrypted tunnel. In parallel, the client starts its own TLS to the bank inside that tunnel. An observer between you and the proxy sees one TLS connection to proxy.host.com. No BANK.COM in cleartext anywhere.
TLS has Encrypted Client Hello (ECH) too, which also hides SNI, but ECH needs support from the destination server and its CDN, and deployment is slow. An HTTPS proxy works today regardless of whether the destination supports ECH.
Verify it in one command
To tell a real HTTPS proxy from "an HTTP proxy that supports HTTPS destinations", run:
openssl s_client -connect proxy.host.com:50001If you get a TLS handshake back with a valid certificate, it's an HTTPS proxy. If you get plain HTTP ("400 Bad Request" or "407 Proxy Authentication Required"), the channel to it isn't encrypted, regardless of what the marketing says.
Try it on your current provider. On every Geekproxy endpoint, for example, this command returns TLS 1.3 with a valid Let's Encrypt certificate and Verify return code: 0 (ok).
Why this matters in practice
SNI leakage sounds abstract until you map it to real situations. Here's where the difference between HTTP and HTTPS proxies turns into real consequences.
Public Wi-Fi and working away from home. In a café, hotel, or airport, you don't control who else is on the access point. If you route work through an HTTP proxy to reach a CRM, banking site, or mail server, the destination hostname goes out over the air. Someone with a laptop and Wireshark at the next table sees where you're going. An HTTPS proxy closes this. To everyone on the access point, you look like you're connected to the proxy host and nothing else.
Corporate networks with egress inspection. Any serious enterprise routes outbound traffic through a security gateway that logs the SNI of every outbound TLS. If you route to competitors, consultants, or internal investigations through an HTTP proxy, your activity is partially visible to the security team. An HTTPS proxy hides everything except the fact of a connection to the proxy host.
ISPs with DPI. In Iran, Pakistan, Kazakhstan, China, partly Russia and Belarus, both consumer ISPs and transit carriers run deep packet inspection that classifies sites by SNI and can tear down connections selectively. Through an HTTP proxy, every CONNECT line and every ClientHello is visible and inspected. Through an HTTPS proxy, the carrier sees one TLS connection to one host, which by itself says nothing about where you go from there.
Fintech due diligence and M&A work. A firm preparing an acquisition doesn't want its ISP to see repeated visits to the target company's site. That information is itself market-moving. An HTTPS proxy keeps those visits invisible to external networks.
Compliance — GDPR, PCI DSS 4.0.1, HIPAA. The standards require encryption "in transit". As auditors caught up with the fact that proxies are part of transit, the requirement started being read as encryption on every leg, including client-to-proxy. In regulated industries, HTTPS proxies are quietly becoming a compliance default.
Journalists and activists in censored countries. For them, network-level surveillance is not a hypothetical threat model. When a state collects statistics on who visited what, an HTTPS proxy hides the hostname list from the observer. It doesn't make you invisible, but it changes what ends up in the logs.
Ad verification on restrictive networks. Verification services operate from networks that filter outbound traffic. A regular HTTP proxy gets flagged by anti-proxy systems by its traffic pattern. An HTTPS proxy blends into regular HTTPS traffic and sidesteps that detection.
Anti-detect browsers. Multilogin, Dolphin Anty, GoLogin, Kameleo, AdsPower, Undetectable all accept HTTPS-scheme proxies natively. Their users (affiliate marketers, ad ops, multi-account operators) work in environments where HTTP proxies get blocked at the firewall, while HTTPS gets through. A large and active user base that needs HTTPS proxies constantly.
When you don't need an HTTPS proxy
Not every workflow calls for TLS to the proxy. If you're rotating IPs for scraping e-commerce, public APIs, or sites that don't block proxies, a plain HTTP proxy is faster and usually cheaper. A TLS handshake to the proxy adds roughly 100–200 ms per new connection. At millions of requests, that matters. If you're on a trusted network and you control the path to the proxy, HTTP is enough.
The second case: your tool doesn't support the HTTPS scheme. For example, Scrapy without a custom downloader middleware silently treats https:// in a proxy URL as HTTP.
Tool compatibility
HTTPS proxy support across client tools is fragmented. Here's the state of things at the start of 2026.
curl. Full support via --proxy https://user:pass@host:port. TLS verification is on by default. You can disable it with --proxy-insecure, but don't do that in production.
Python httpx. Built in: httpx.Client(proxy="https://user:pass@host:port"). Python requests doesn't officially support HTTPS-scheme proxies; workarounds exist but are fragile.
Playwright. Accepts HTTPS proxies via proxy={"server": "https://...", "username": "...", "password": "..."}. Works across all three browser engines.
Selenium, Puppeteer. Partial support, through driver-specific capabilities. Reliability depends on the Chromium version underneath.
Chrome/Chromium. Common misconception here. The --proxy-server=https://host:port flag does not force Chrome to connect to the proxy over TLS. It silently falls through to plain HTTP. The only way to make Chrome use an HTTPS proxy is a PAC script where FindProxyForURL returns HTTPS host:port (uppercase, not PROXY). OS-level proxy settings (Windows, macOS, Linux) also reject the https:// scheme and interpret it as HTTP.
Firefox. Same picture. HTTPS proxies work only through a PAC script that returns HTTPS host:port. The standard GUI proxy config rejects the scheme. The feature has been in Firefox since 2007 (Bugzilla #378637), but most users don't know about it.
Anti-detect browsers. Multilogin, Dolphin Anty, GoLogin, Kameleo, AdsPower, Undetectable all accept HTTPS proxies natively when you add a custom proxy to a profile, with type, host, port, login, password in separate fields.
Scrapy. No HTTPS-scheme support without a custom middleware. With one (in practice, a hand-written downloader middleware or a switch to an httpx-based pipeline), it works.
Connection examples
curl:
curl --proxy https://username:[email protected]:50001 https://www.target-site.com/Python httpx:
import httpx
client = httpx.Client(
proxy="https://username:[email protected]:50001"
)
response = client.get("https://www.target-site.com/")
print(response.text)Playwright:
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.launch(
proxy={
"server": "https://proxy.host:50001",
"username": "username",
"password": "password",
}
)
page = browser.new_page()
page.goto("https://www.target-site.com/")Minimal PAC script for Chrome and Firefox:
function FindProxyForURL(url, host) {
return "HTTPS proxy.host.com:50001";
}Save as proxy.pac, then point the browser at the file path (or a URL if you host it on an internal web server). Credentials are prompted by the browser's standard auth dialog on the first request through the proxy. Chrome and Firefox then store them in their own credential managers.
Multilogin and other anti-detect browsers — open the profile proxy settings, pick Custom Proxy, choose type HTTPS, then fill host and port in separate fields along with login and password. Settings are stored per profile.
How we built this at Geekproxy
Short version, to keep this from sliding into an ad. On every endpoint, the HTTPS proxy runs on its own port, accepts TLS 1.3, and uses a valid Let's Encrypt certificate. The client-to-proxy channel is fully encrypted. The CONNECT command and the target hostname never go out in cleartext to anyone in between. Anti-detect browsers connect natively; curl and Playwright use the standard syntax shown above.
TL;DR
Most providers' "HTTPS proxy" is an HTTP proxy with CONNECT tunneling. The target hostname shows up in the CONNECT line and in the SNI on the client-to-proxy segment.
A real HTTPS proxy wraps the client-to-proxy channel in TLS as the first layer. On that segment, nothing is visible except the fact of a connection to the proxy host itself.
You can verify it in one command: openssl s_client -connect proxy:port should return a TLS handshake with a valid certificate.
You need it on public networks, under corporate inspection, in DPI countries, in compliance environments, with anti-detect browsers, and for research where the mere fact of a connection to the target is information.
You don't need it for plain IP rotation in high-throughput scraping, or with tools that don't support the HTTPS scheme.
Chrome and Firefox accept HTTPS proxies only through a PAC script with the HTTPS host:port directive. They don't accept them from the GUI or the command line.