v1.9.4-99ab90b
← Back to Hex Proxies

HTTPS Proxy Protocol

HTTPS proxies provide encrypted end-to-end tunneling between client and destination. The proxy establishes a secure tunnel using the HTTP CONNECT method, ensuring that interceptors — including the proxy itself — cannot read the payload.

Technical Details

HTTPS proxying works fundamentally differently from HTTP proxying. Instead of the proxy reading and forwarding individual HTTP requests, the proxy creates an opaque TCP tunnel between the client and the destination server. The process uses the HTTP CONNECT method: 1. Client connects to the proxy over TCP 2. Client sends: CONNECT example.com:443 HTTP/1.1 3. Proxy establishes a TCP connection to example.com:443 4. Proxy responds: HTTP/1.1 200 Connection Established 5. Client performs the TLS handshake directly with example.com through the tunnel 6. All subsequent data is encrypted end-to-end between client and origin The proxy only sees: - The target hostname and port (from the CONNECT request) - Encrypted byte streams in both directions - Connection metadata (timing, byte counts) The proxy CANNOT see: - The actual URL path or query parameters - Request/response headers within the TLS tunnel - Request/response bodies - Cookies or authentication tokens This architecture means the proxy acts as a TCP relay, not an HTTP intermediary. The TLS certificate is verified directly between the client and the origin server, maintaining the full security guarantees of HTTPS.

Advantages

  • End-to-end encryption — proxy cannot read traffic content
  • Full TLS security — certificate validation happens directly with the origin
  • Works with all HTTPS websites and APIs transparently
  • Protects sensitive data like credentials and personal information
  • Widely supported — all modern HTTP clients support CONNECT proxies
  • Compatible with HTTP/2 and modern TLS versions

Disadvantages

  • Proxy cannot cache responses (traffic is encrypted)
  • No content filtering or inspection capability
  • Slightly higher latency due to TLS handshake overhead
  • Some networks block the CONNECT method on non-standard ports
  • Cannot modify request headers after the tunnel is established

Use Cases

  • 1Secure web browsing through proxy infrastructure
  • 2Accessing HTTPS APIs through proxy rotation
  • 3E-commerce monitoring where sites enforce HTTPS
  • 4Financial data collection requiring encrypted connections
  • 5Social media scraping where platforms mandate TLS
  • 6Any workflow where data privacy is required

Code Example

# Python — HTTPS proxy with requests
import requests

proxies = {
    "https": "http://USER:PASS@gate.hexproxies.com:8080",
}

response = requests.get("https://httpbin.org/ip", proxies=proxies, verify=True)
print(response.json())

# Node.js — HTTPS proxy with node-fetch
const { HttpsProxyAgent } = require('https-proxy-agent');
const fetch = require('node-fetch');

const agent = new HttpsProxyAgent('http://USER:PASS@gate.hexproxies.com:8080');

const response = await fetch('https://httpbin.org/ip', { agent });
const data = await response.json();
console.log(data);

# cURL — HTTPS via CONNECT tunnel
curl -x http://USER:PASS@gate.hexproxies.com:8080 https://httpbin.org/ip

# Explicit CONNECT with openssl (debugging)
openssl s_client -connect gate.hexproxies.com:8080 \
  -proxy gate.hexproxies.com:8080 \
  -servername httpbin.org

How HTTPS Proxies Work

HTTPS proxies solve a fundamental challenge: how to route encrypted web traffic through an intermediary server without breaking the encryption. The solution is the HTTP CONNECT method, which transforms the proxy from an HTTP-aware intermediary into a transparent TCP tunnel.

The CONNECT Method in Detail

When a client wants to access an HTTPS site through a proxy, the following sequence occurs:

  1. **TCP connection to proxy**: The client connects to the proxy server — with Hex Proxies, this is `gate.hexproxies.com` on the configured port.
  2. **CONNECT request**: The client sends a special HTTP request: `CONNECT target.com:443 HTTP/1.1`. This tells the proxy which server to connect to. Proxy authentication headers are included in this request.
  3. **Proxy connects to target**: The proxy opens a TCP connection to the target server on port 443.
  4. **Tunnel confirmation**: The proxy responds with `HTTP/1.1 200 Connection Established`, signaling that the tunnel is ready.
  5. **TLS handshake**: The client now performs a TLS handshake directly with the target server through the tunnel. The proxy relays bytes but cannot decrypt them.
  6. **Encrypted communication**: All subsequent data flows encrypted through the tunnel. The proxy is merely a relay.

Security Guarantees

The HTTPS proxy model preserves full TLS security. The client verifies the target server's certificate directly — the proxy never presents its own certificate (unlike SSL-intercepting proxies). This means:

  • Certificate pinning still works correctly
  • HSTS (HTTP Strict Transport Security) is enforced normally
  • The proxy operator cannot perform man-in-the-middle attacks
  • Perfect forward secrecy (PFS) protections remain intact

SNI and Domain Visibility

One important detail: during the TLS handshake, the Server Name Indication (SNI) extension sends the target hostname in cleartext. This means the proxy (and any network observer) can see which domain the client is connecting to, but not the specific URL path, parameters, or content. Modern standards like Encrypted Client Hello (ECH) aim to address this, though adoption is still limited.

Performance Impact

HTTPS proxying adds overhead compared to HTTP proxying due to the TLS handshake. The typical additional latency breakdown:

  • TCP handshake to proxy: ~10-30ms
  • CONNECT request/response: ~5-15ms
  • TLS handshake through tunnel: ~30-80ms (depending on TLS version and cipher)

With Hex Proxies' infrastructure, total added latency for HTTPS proxy connections is typically under 100ms. TLS 1.3 further reduces this with its single-roundtrip handshake.

Proxy Authentication for HTTPS

Authentication for HTTPS proxying happens in the CONNECT request, before the tunnel is established. The `Proxy-Authorization` header is sent in the cleartext CONNECT request. This means proxy credentials are visible on the connection between the client and proxy — so it is recommended to also encrypt the connection to the proxy itself when possible. Hex Proxies supports this configuration.

HTTP/2 and Modern Protocols

Modern clients can negotiate HTTP/2 with the target server through an HTTPS proxy tunnel. Since the proxy only sees encrypted bytes, it is transparent to the protocol version negotiated inside the tunnel. This means you get full HTTP/2 performance (multiplexing, header compression, server push) even when routing through a proxy.

Integration with Hex Proxies

Hex Proxies supports HTTPS tunneling on all proxy types. The gateway `gate.hexproxies.com` handles CONNECT requests seamlessly. When your client accesses an HTTPS URL through our proxy, the CONNECT tunnel is established automatically — no special configuration beyond standard proxy settings is required.

All Hex Proxies plans include unlimited HTTPS tunneling bandwidth. The proxy infrastructure is optimized for low-latency TLS tunnel establishment, with connection pooling and keep-alive support to amortize handshake costs across multiple requests.

Best Practices

Always use HTTPS proxying when accessing sites that handle sensitive data. Configure your HTTP client to verify TLS certificates even when using a proxy — this is the default behavior in most libraries. Hex Proxies never intercepts or inspects HTTPS traffic, ensuring your data remains private end-to-end.

Ready to Get Started?

Use HTTPS Proxy Protocol with Hex Proxies for reliable, fast connections.

Cookie Preferences

We use cookies to ensure the best experience. You can customize your preferences below. Learn more