HTTP CONNECT
The request a client sends to open a raw tunnel through a proxy. Everything after it is encrypted end to end, so the proxy forwards bytes it cannot read.
For plain HTTP a forward proxy reads the request, fetches the resource and returns it. For HTTPS that model does not work, because reading anything would mean breaking the encryption. CONNECT solves it: the client asks the proxy to open a connection to a host and port, and after the proxy answers with 200 the two ends negotiate TLS directly through it.
What the proxy sees after that is the host name from the CONNECT line, the size and timing of the bytes, and nothing else. It does not see paths, headers, cookies or payloads, because it does not hold the keys.
This is the technical answer to a question customers ask carefully and rarely out loud: what can the provider read. On CONNECT tunnels, the contents are not available to us. The destination host is, and so is how much traffic moved, which is exactly what per-gigabyte billing requires.
It is also why intercepting proxies are a different product. A proxy that inspects HTTPS has to terminate TLS and present its own certificate, which the client must be configured to trust. We do not do that, and any provider that does is holding your plaintext.
What happens on the wire
The client opens a connection to the proxy and sends a CONNECT line naming the destination host and port, with credentials in a Proxy-Authorization header where authentication is used.
The proxy answers 200 once the upstream connection is open. From that moment it copies bytes in both directions without interpreting them, and the TLS handshake that follows is between the client and the destination.
Failures at this stage are distinguishable: a 407 means the credentials did not arrive in the form expected, a 502 means the proxy could not reach the destination, and a timeout after a 200 means the tunnel opened and the far end went quiet.
Watching the tunnel open
Verbose output shows every stage, which makes debugging a matter of reading rather than guessing:
The tunnel, step by step
# -v prints the CONNECT exchange before the TLS handshake
curl -v -x login_c_DE:password@proxy.sotaproxy.com:10000 https://api.ipify.org 2>&1 | head -20
# a static address uses the same method on its own port
curl -v -x login:password@YOUR-ISP-IP:50100 https://api.ipify.org 2>&1 | head -20- If you never see a 200 to the CONNECT, the problem is authentication or reachability, not the target site.
- Both our HTTP endpoints tunnel HTTPS this way; SOCKS5 on the static port achieves the same result with a different handshake.
- Because the tunnel is opaque, request-level features some people expect from a proxy, such as header rewriting, cannot exist on HTTPS traffic.
Common misreadings
An HTTPS proxy does not decrypt HTTPS
It carries it. Decryption would require terminating TLS and a certificate your client trusts.
The proxy still sees the host
The CONNECT line names it. Contents are hidden, destinations are not.
A 407 is not a block
It is the tunnel refusing to open because credentials did not arrive as expected. Nothing reached the target.
It is not the same as SOCKS5
Both tunnel. CONNECT is an HTTP method; SOCKS5 is a separate protocol with its own handshake and its own authentication.
Términos relacionados
Ver esto en práctica
¿Listo para usar http connect?
SotaProxy te da acceso a proxies residenciales rotativos, móviles, de centro de datos e ISP. Sin compromiso mínimo.
Empezar