What Is HTTP CONNECT? – Definition and How It Works

Learn how the CONNECT method builds a TCP tunnel through a proxy, and why it keeps TLS end-to-end.

CONNECT is the HTTP method that asks a proxy to open a raw TCP tunnel to a destination. It is how HTTPS travels through an HTTP proxy without the proxy decrypting it.

1. The Exchange

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic <credentials>

HTTP/1.1 200 Connection established

<from here, raw bytes pass through — the client's TLS handshake begins>

After the 200, the proxy stops interpreting and simply copies bytes in both directions. The TLS session is negotiated between client and origin, so the proxy sees ciphertext.

2. Why This Design Matters

It preserves end-to-end encryption through an intermediary:

That is exactly why an intercepting proxy needs its own trusted root: without one it cannot terminate TLS, and with plain CONNECT it never sees plaintext.

3. Forward Proxy Versus Tunnel

The distinction that clarifies proxy behaviour:

Plain HTTP through a proxy — the client sends a full absolute-URI request (GET http://example.com/path), and the proxy makes the request itself. It sees and can cache everything.

HTTPS through a proxy — the client sends CONNECT, gets a tunnel, and speaks TLS through it. The proxy cannot cache or inspect.

So the same proxy behaves very differently by scheme, which explains why HTTP and HTTPS traffic through one proxy can have different logging, caching, and failure characteristics.

4. What the Proxy Still Learns

Not nothing:

• The hostname and port, from the CONNECT target.
• The SNI, in the TLS handshake, unless encrypted client hello is in use.
• Timing and byte volumes, which leak a surprising amount about activity.
• Connection frequency and duration.

For anyone routing through a third-party proxy, that is the honest disclosure boundary: the operator knows every host you visit and how much you transferred, even without content.

5. Failure Modes

The hang is the nastiest: the tunnel appears established and then nothing arrives, which surfaces as a read timeout unrelated in appearance to the proxy. A short connect timeout separate from the read timeout is what catches it.

6. CONNECT and Non-HTTP Traffic

Because the tunnel is raw TCP, CONNECT can carry anything — which is why proxies restrict the ports they will tunnel to, commonly 443 and a small allowlist. An attempt to tunnel to an arbitrary port is frequently refused with a 403.

That restriction is also why an HTTP proxy generally cannot carry WebRTC's UDP traffic: CONNECT is TCP, and UDP needs a different mechanism.

7. Practical Notes

1. Expect two timeouts to matter — establishing the tunnel, and reading through it.
2. Send credentials in Proxy-Authorization, not Authorization; the latter is for the origin.
3. Do not assume caching. Nothing in a tunnel is cacheable by the proxy.
4. Test the destination port, since proxies allowlist ports.
5. Remember UDP does not tunnel this way, which is the root of WebRTC leaks.
6. Treat the proxy operator as able to see every hostname you request.

8. Summary

CONNECT asks a proxy to open a raw TCP tunnel, after which bytes pass through untouched and TLS is negotiated end-to-end with the origin — so the proxy sees hostnames, ports, timing, and volumes, but not content.

That is why intercepting proxies need an installed root certificate, why proxied HTTP and HTTPS behave differently, and why UDP-based protocols such as WebRTC do not travel through an HTTP proxy at all.

Potential Related Glossary

• Residential Proxies
• IP Rotation
• Browser Fingerprints
• Web Crawling