CONNECT
Establishes a tunnel to the server identified by the target resource, typically used for HTTPS proxying.
What it does
CONNECT asks an HTTP proxy to open a raw TCP tunnel to a destination host and port, then get out of the way. Once the tunnel is established, the proxy just shuttles bytes back and forth — it doesn't interpret them as HTTP anymore. This is how HTTPS traffic gets through forward proxies: the browser can't send an encrypted request to a proxy that doesn't hold the TLS certificate, so instead it asks the proxy to tunnel a raw connection to the real server, then does the TLS handshake through that tunnel, end-to-end with the origin.
Unlike every other method here, CONNECT doesn't really target a "resource" in the REST sense — the target is host:port, not a URI path.
Semantics
| Property | Value | Why it matters |
|---|---|---|
| Safe | No | Opens a network connection, a real side effect |
| Idempotent | No | Each CONNECT establishes a new tunnel |
| Cacheable | No | There's no representation to cache — it's a raw byte pipe |
| Request body | No | The request line is the whole ask |
| Response body | No (before tunnel) | After the 200, everything is raw tunneled bytes, not HTTP |
Syntax & example request
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
HTTP/1.1 200 Connection Established
After this response, the proxy stops parsing anything as HTTP — it just relays raw bytes both directions. The client immediately starts a TLS handshake with example.com through that tunnel.
curl example
curl -x http://proxy.example.com:8080 -v https://example.com
curl issues the CONNECT automatically here when you request an HTTPS URL through an explicit -x proxy — you rarely type CONNECT by hand.
Common status codes returned
- 200 OK / Connection Established — tunnel opened successfully → see 200
- 407 Proxy Authentication Required — proxy needs credentials before tunneling → see 407
CONNECT vs everything else
| CONNECT | GET/POST/etc | |
|---|---|---|
| Target | host:port |
A resource URI |
| Interpreted by | The proxy itself | The origin server |
| After success | Raw byte tunnel, no more HTTP | Normal HTTP request/response |
| Used directly by app code | Almost never | Constantly |
CONNECT is infrastructure-level — application code basically never issues it explicitly. Your HTTP client library handles it transparently whenever you go through a forward proxy to reach an HTTPS origin.
Real-world usage
- Forward proxies (corporate proxies,
HTTP_PROXYenv vars) tunneling HTTPS traffic - VPN-like tools and SSH tunneling-over-HTTP setups
- WebSocket connections through proxies (in some configurations)
- TLS-terminating vs TLS-passthrough proxy architectures — CONNECT is the passthrough case
Security considerations
Because CONNECT hands the proxy a raw tunnel with no visibility into the traffic, it's a common target for proxy misconfiguration abuse — an open or poorly-restricted CONNECT proxy can be used to tunnel traffic to arbitrary internal hosts, effectively turning the proxy into an SSRF (server-side request forgery) primitive. Production proxies should restrict which destination hosts/ports CONNECT is allowed to reach (commonly locking it to port 443 and a host allowlist).
FAQ
Do I ever write CONNECT requests by hand?
Essentially never in application code. It's issued automatically by HTTP clients and libraries whenever a request needs to go through a forward proxy to reach an HTTPS (or other tunneled) destination.
Is CONNECT used for HTTP/2 or HTTP/3?
Yes, with an evolved role — HTTP/2's "Extended CONNECT" (RFC 8441) is how WebSockets get tunneled over HTTP/2, and it's foundational to HTTP/3's handling of proxied UDP traffic too.
Why can't a proxy just decrypt and re-encrypt HTTPS traffic instead of tunneling it?
Some do (TLS-terminating "MITM" proxies, common in corporate security stacks), but that requires installing a trusted root certificate on every client, and it fully breaks end-to-end encryption between client and origin. CONNECT-based tunneling keeps TLS intact end-to-end; the proxy never sees the plaintext or the key material.
Fun fact
CONNECT was formally added to HTTP in RFC 2817 (2000) specifically to solve the "how do you proxy HTTPS" problem — a full seven years after SSL/HTTPS itself existed, during which proxying encrypted traffic was mostly ad hoc and non-standardized.