HTTP CONNECT
The HTTP method that turns a proxy into a blind tunnel, which is how an HTTP proxy carries HTTPS traffic it cannot read.
CONNECT is the request that changes an HTTP proxy's job from reading your traffic to merely carrying it. For a plain HTTP request the proxy sees the whole thing and can parse, cache or rewrite it. For an HTTPS destination that would be impossible, because the traffic is encrypted end to end, so the client instead sends CONNECT naming the host and port, the proxy opens a raw connection to that destination, replies that the tunnel is established, and from then on copies encrypted bytes in both directions without understanding any of them.
This one mechanism resolves an apparent contradiction people hit early: how an HTTP proxy handles HTTPS at all. It does not handle it in the HTTP sense; it steps out of the way and becomes a pipe. Which is also why an HTTP proxy and an HTTPS proxy are usually the same endpoint, since supporting encrypted destinations is a matter of accepting CONNECT rather than a different product.
The tunnel has a privacy consequence worth stating precisely. Because the proxy only relays the encrypted stream, it cannot read your request or the response, but it does see the target named in the CONNECT line itself, which travels in the clear, along with the timing and volume of what follows. So an HTTPS destination through an HTTP proxy is confidential in content and not in metadata, which is exactly the boundary that makes the operator's identity still matter.
It is also a practical failure point. Restrictive networks frequently allow CONNECT only to port 443, so a proxy or destination on an unusual port is refused by the network between you and it while working fine elsewhere, a failure that looks like a dead proxy and is not. And the method is the reason a SOCKS5 proxy and an HTTP proxy end up feeling similar for HTTPS: both are ultimately relaying an opaque byte stream, one by design and one via CONNECT.
Frequently asked questions
What does the HTTP CONNECT method do?
It asks a proxy to open a raw tunnel to a named host and port rather than to fetch something on your behalf. The proxy connects to the destination, confirms the tunnel, and then relays bytes in both directions without reading them. It is the mechanism that lets an HTTP proxy carry HTTPS traffic it cannot decrypt.
Why does my HTTP proxy work for HTTP but not HTTPS?
Almost always because CONNECT is being blocked or unsupported on the path. HTTPS through an HTTP proxy requires the CONNECT method to open a tunnel, and some restrictive networks permit it only to port 443, or a misconfigured proxy refuses it. Plain HTTP needs no tunnel, so it succeeds while HTTPS fails, which points at CONNECT rather than at the proxy being down.
Can a proxy see my HTTPS traffic through a CONNECT tunnel?
Not the contents. Once the tunnel is open the proxy relays encrypted bytes it cannot read. It does see the destination host and port from the CONNECT request itself, which is sent in the clear, plus the timing and volume of the traffic. That metadata is meaningful, which is why the tunnel protects you from the operator's eyes only partway.
Back to the full glossary.