Quick Answer
The Hypertext Transfer Protocol (HTTP) CONNECT method asks a proxy to open a tunnel to a specified host and port. After any successful 2xx response, the proxy relays bytes in both directions until the tunnel closes. CONNECT itself adds no encryption, but clients commonly perform a Transport Layer Security (TLS) handshake for HTTPS.
Key Takeaways
- HTTP CONNECT names a destination host and port, then asks a proxy to create a two-way tunnel.
- Any 2xx response establishes the tunnel; every non-2xx response means the tunnel was not formed.
- CONNECT provides transport, not encryption. HTTPS gains confidentiality from TLS running inside the tunnel.
- A standard tunnel hides encrypted HTTP content, but the proxy still sees connection and destination metadata.
- HTTP/1.x converts one connection into a tunnel, while HTTP/2 and HTTP/3 use individual streams.
- Reliable operation requires correct authentication, bounded concurrency, clear timeouts, and separate tunnel and destination diagnostics.
How Does HTTP CONNECT Differ From Ordinary Proxy Forwarding?
HTTP CONNECT creates a byte tunnel, while ordinary proxy forwarding lets the proxy process individual HTTP requests and responses. The difference determines which protocol layer the proxy handles after setup.
| Factor | Ordinary HTTP proxy forwarding | HTTP CONNECT tunnel |
|---|---|---|
| Client request target | Absolute-form Uniform Resource Identifier (URI) in HTTP/1.1 | Destination host and port |
| Proxy role | Processes and forwards HTTP messages | Relays bytes after successful setup |
| Common destination | Plain HTTP website or service | HTTPS website or another permitted network service |
| Destination TLS | Absent for plain HTTP | Commonly negotiated inside the tunnel |
| Content visibility | Proxy can read plain HTTP messages | Encrypted content remains unreadable without TLS termination |
| Lifetime | One or more forwarded HTTP exchanges | Until either tunnel side closes |
During ordinary forwarding, a client can send `GET http://example.com/page HTTP/1.1` to an HTTP proxy. The request line uses an absolute-form URI. The proxy can inspect the method, target, headers, and unencrypted content while forwarding the request.
CONNECT uses an authority-form target instead of an absolute-form URI. Once the proxy accepts the request, the existing path becomes a general byte channel. The client then speaks the destination protocol through that channel.
This behavior belongs to a forward proxy because the proxy acts for the requester. A reverse proxy instead accepts traffic for services operated behind it. The distinction depends on which side the proxy represents.
The client connects to a proxy endpoint, while the destination observes an exit address. CONNECT links those two sides for one live tunnel. A stable endpoint can still select different exits across later connections.
What Is the HTTP CONNECT Method?
HTTP CONNECT asks an intermediary to establish a bidirectional data tunnel to a destination host through a specified network port. It is intended mainly for proxies, although an origin server may implement it.
RFC 9110 defines the target as an authority containing a host and explicit port. CONNECT has no default target port, so the client must include one. A CONNECT request message does not have content; subsequent data follows version-specific rules.
An HTTP/1.1 request can look like this:
The proxy validates the request, authenticates the client when required, and applies its destination policy. It can connect directly to the named server or forward CONNECT through another configured proxy.
CONNECT is not permission to reach every destination or port. A proxy should restrict approved targets because arbitrary relay access can support abuse.
A successful HTTP/1.1 response often looks like this:
The reason phrase is conventional, but `200` is not the only valid success status. Every 2xx response tells the client that tunnel mode begins after the response headers. Every other response leaves the tunnel unformed.
Successful CONNECT responses do not carry ordinary response content. Servers must not send `Content-Length` or `Transfer-Encoding` in those responses, and clients must ignore either field. CONNECT responses are also not cacheable.
The method identifies a destination, not an individual web page. For tunneled HTTPS, paths, query strings, cookies, and origin authorization appear after setup. Proxy authentication remains separate from destination authentication.
How Does an HTTP CONNECT Tunnel Work?
An HTTP CONNECT tunnel forms through separate client-to-proxy setup, proxy-to-destination setup, and tunneled application communication. Each stage can succeed or fail independently.
The complete HTTP/1.1 sequence is:
- Connect to the proxy: The client opens a transport connection to its configured proxy endpoint. With an HTTPS proxy, the client first establishes TLS on this leg.
- Name the destination: The client sends CONNECT with the required host and port. It can include proxy credentials preemptively.
- Authenticate when challenged: The client answers a supported `407` challenge and retries CONNECT. Source-address authorization can remove this credential exchange.
- Apply proxy policy: The proxy checks authentication, allowed destinations, ports, capacity, and routing rules. A denied request returns an HTTP error response.
- Open the outbound path: The proxy resolves a hostname when necessary and connects to the requested destination. A configured proxy chain can handle that step instead.
- Enter tunnel mode: The proxy returns a successful response after the outbound path opens. Both sides then treat later bytes as tunnel data.
- Negotiate the carried protocol: An HTTPS client performs its destination TLS handshake through the tunnel. Other permitted protocols can begin their own negotiation.
- Relay and close: The proxy forwards bytes in both directions until either side closes. It attempts to forward outstanding data before closing both connections.
A tunnel is one live transport path. A proxy connection and proxy session can have different lifetimes. Closing one tunnel may leave a provider-defined sticky session available for another connection.
Name resolution also depends on the request target. When the client sends a hostname, the proxy or next intermediary usually resolves it. When the client sends an address, resolution may already have happened locally.
What Can a Proxy See Through a CONNECT Tunnel?
A CONNECT proxy sees setup and traffic metadata, while destination TLS hides protected HTTP content from a non-intercepting proxy. Exact visibility depends on every protocol used along the path.
Before tunnel setup, the proxy sees the incoming source address, requested host, requested port, and any supplied authentication identity. It also knows whether the request passed its policy. The CONNECT authority already reveals a hostname when the client supplies one.
During the tunnel, the proxy can measure timing, duration, connection state, and transferred byte counts. It may also observe unencrypted handshake metadata. Exact fields vary with the TLS version, client, destination, and deployed privacy features.
Destination TLS normally protects HTTP methods, paths, headers, cookies, bodies, and returned content. The proxy relays encrypted records without acting as the destination TLS endpoint. Certificate validation still occurs between the client and destination.
Authorized TLS inspection uses a different design. An inspection system terminates the client's TLS connection and creates another TLS connection to the destination. Managed clients must trust its certificate authority, and the deployment requires appropriate privacy and security controls.
CONNECT does not protect the first network leg by itself. With an `http://` proxy endpoint, the CONNECT request and proxy authentication lack transport encryption. An `https://` proxy endpoint adds TLS between the client and proxy.
The official cURL HTTPS proxy guide explains that distinction. The destination still needs HTTPS for end-to-end content protection. Teams should also secure proxy credentials and redact verbose traces before sharing them.
How Do HTTP CONNECT, HTTPS Proxies, and SOCKS5 Differ?
HTTP CONNECT is an HTTP method, an HTTPS proxy encrypts the client-to-proxy leg, and SOCKS5 uses an independent relay protocol. These terms describe separate choices and should not be treated as synonyms.
| Term | What it describes | Setup mechanism | Built-in content encryption |
|---|---|---|---|
| HTTP CONNECT | A tunnel request sent to an HTTP proxy | HTTP method with a host and port | No |
| HTTPS proxy | An HTTP proxy reached through TLS | TLS to proxy, then HTTP forwarding or CONNECT | Protects the client-to-proxy leg |
| SOCKS5 CONNECT | A TCP relay command within SOCKS5 | SOCKS5 negotiation and request | No |
An HTTP proxy can carry an HTTPS destination without being an HTTPS proxy. The client connects to an `http://` endpoint, requests a tunnel, then runs destination TLS inside it. Only the destination exchange receives TLS protection on that path.
An HTTPS proxy changes the first leg. The client establishes TLS with the proxy before sending HTTP messages, including CONNECT. The client and HTTPS destination then establish a second TLS connection through the tunnel.
SOCKS5 does not send the HTTP CONNECT method. It defines its own `CONNECT` command for outbound Transmission Control Protocol (TCP) relays. The shared word describes a similar result, but the wire formats, authentication, and name-resolution rules differ.
The wider comparison of HTTP and SOCKS5 proxies covers protocol selection. Neither proxy protocol automatically encrypts the carried application data. HTTPS, Secure Shell, or another protected application protocol must provide that confidentiality.
Choose the proxy scheme supplied by the provider. Do not change `http://` to `https://` merely because the destination begins with `https://`. Client support and proxy configuration must agree on the first-leg protocol.
How Does CONNECT Change Across HTTP Versions?
HTTP/1.x converts the proxy connection into one tunnel, while HTTP/2 and HTTP/3 place each tunnel on an individual stream. The method's purpose remains the same across those mappings.
In HTTP/1.x, the request line contains the authority-form target, such as `example.com:443`. After a successful response ends, every following byte on that connection belongs to the tunnel. The connection no longer carries ordinary HTTP messages outside the tunneled protocol.
HTTP/2 CONNECT uses `:method` set to `CONNECT` and `:authority` set to the destination. It omits the usual `:scheme` and `:path` pseudo-headers. A successful response converts that stream into a tunnel, and DATA frames carry the tunneled bytes.
HTTP/3 CONNECT follows the same stream-level model over QUIC. Other streams on the HTTP/2 or HTTP/3 connection can remain available. One proxy transport connection can therefore carry several independent tunnels.
That difference affects proxy concurrency measurements. A provider can count transport connections, open streams, destination connections, or another defined unit. Buyers should confirm the counted resource before comparing limits.
Extended CONNECT is a separate extension. It adds a `:protocol` pseudo-header for negotiated protocols. For HTTP/2, RFC 8441 uses this mechanism for WebSockets.
A server must advertise support before a client uses that extension. Ordinary HTTPS tunneling does not require Extended CONNECT. Both the client and proxy must support the chosen version and extension.
Which Status Codes and Failures Matter for CONNECT?
CONNECT succeeds after any 2xx response, while every non-2xx response means the requested tunnel was not established at that stage. The responder and failure stage matter more than the status alone.
| Result | What it can indicate | First check |
|---|---|---|
| 2xx | Proxy established the requested tunnel | Continue with the carried protocol |
| 400 | Invalid authority, port, or malformed request | Inspect the CONNECT target and syntax |
| 403 | Proxy policy denied an otherwise understood request | Confirm account, destination, and port policy |
| 405 or 501 | Recipient disallows or does not implement CONNECT | Confirm the configured proxy endpoint |
| 407 | Proxy requires acceptable authentication | Check credentials, challenge, or source allowlist |
| 502 | Proxy encountered an upstream gateway or connection problem | Check destination reachability and proxy diagnostics |
| 504 | Proxy did not complete an upstream operation in time | Check timeouts, destination latency, and route health |
These interpretations are diagnostic starting points, not universal root causes. Proxy products can apply different policies or return product-specific details. Logs should record the responder, status, timing, and tunnel stage without exposing credentials.
An HTTP `407 Proxy Authentication Required` response occurs before the tunnel exists. The proxy supplies a `Proxy-Authenticate` challenge, and a compatible client can retry with `Proxy-Authorization`. The guide to Error 407 covers that exchange in detail.
A successful tunnel can still carry a later destination failure. For example, a website can return `403` inside destination TLS after CONNECT succeeded. That response does not retroactively make the tunnel setup a proxy `403`.
Likewise, a TLS alert after `200 Connection Established` points beyond basic CONNECT acceptance. Check the destination hostname, certificate validation, TLS compatibility, and interception policy. Broader proxy error codes require the same layer-by-layer diagnosis.
How Do You Test an HTTP CONNECT Tunnel With cURL?
cURL automatically sends CONNECT when an HTTPS destination uses an HTTP proxy, and verbose output shows the setup exchange. The example below uses placeholders instead of working credentials. An `http://` proxy leaves proxy authentication without transport encryption on the first leg.
A production script should inject credentials through an approved secret mechanism. Literal arguments can enter shell history or process listings.
The command first connects to `proxy.example.com`, not `example.com`. cURL then sends a CONNECT request for `example.com:443`. After a successful response, cURL performs the destination TLS handshake through the tunnel.
Verbose output should contain a request and response resembling these lines:
The exact HTTP version, headers, reason phrase, and TLS messages can differ. A successful CONNECT response confirms tunnel setup. The destination's HTTP response appears only after the tunnel and TLS setup succeed.
The official cURL HTTP proxy documentation confirms that HTTPS triggers tunneling automatically. `--proxytunnel` forces a tunnel where cURL would not otherwise select one. It is unnecessary for an ordinary HTTPS destination through an HTTP proxy.
Use `--proxy-user`, not `--user`, for proxy authentication. Use `--proxy-header` for a header intended only for the proxy. A normal `--header` value belongs to the destination request.
The complete guide to using cURL with a proxy covers authentication and proxy schemes. The guide to showing response headers with cURL explains multiple status blocks. Never disable certificate verification as a routine fix, and redact verbose output before sharing it.
How Should You Operate CONNECT Tunnels at Scale?
CONNECT tunnels at scale need bounded admission, reuse, separate timeouts, failure classification, and destination-aware traffic controls. More open tunnels do not guarantee more valid work.
Set separate ceilings for the complete workload and each destination. An open tunnel consumes client, proxy, network, and destination resources even while no application request completes. HTTP/2 or HTTP/3 stream multiplexing can change counts without removing those costs.
Configure connection, handshake, inactivity, and overall operation timeouts separately where the client permits. A short timeout can abort valid but slow work, while a long timeout can leave stalled tunnel operations pending. Measure the actual stage before changing a value.
Reuse established tunnels when the client, destination, and session rules make reuse safe. Reuse avoids repeated transport and TLS setup, but stale connections need detection and recovery. A sticky routing session does not guarantee that one socket remains open.
Classify failures before retrying. Authentication rejection, port policy, destination refusal, TLS failure, timeout, and invalid content need different responses. Give retries a fixed budget, add backoff and jitter, and retry only safe operations.
Track attempted and accepted tunnels, setup latency, active duration, transferred bytes, closures, and failure categories. Pair those metrics with valid destination results. A tunnel can be technically open while the application receives incomplete or unsuitable content.
Managed proxy pools still need per-host controls and response validation. Respect destination policies, applicable terms, and permitted request rates. Rotation cannot convert a disallowed or excessive workload into an acceptable one.
How Do Proxidize Proxy Tunnels Work?
Proxidize HTTP access points accept standard proxy connections and let compatible clients tunnel HTTPS destinations with CONNECT. The client uses the generated endpoint and authentication settings, then requests the destination URL.
For an HTTPS destination, the client asks the access point to connect to the target host and port. Proxidize authenticates the client, applies the access point's route settings, and selects an eligible exit. The destination TLS handshake then passes through the established tunnel.
The access point, tunnel, session, and exit remain separate concepts. One access point can provide stable client configuration while eligible exits change across connections. A sticky session requests temporary exit continuity, but it does not keep one tunnel open indefinitely.
Use the proxy scheme generated by the dashboard. A destination beginning with `https://` does not justify changing an HTTP proxy endpoint to an HTTPS endpoint. Standard clients, including cURL, handle the destination tunnel automatically.
Proxidize Residential Proxies support HTTP proxy access for HTTP and HTTPS destinations, plus SOCKS5. They also support rotating or sticky sessions.
Targeting includes country, city, and Internet service provider (ISP), subject to available inventory. Residential routes fit global workflows that need broad geographic selection across permitted public destinations.
Best For: Residential Proxies suit global HTTPS collection that needs location controls and temporary route continuity.
Proxidize Mobile Proxies provide United States mobile exits for permitted tunnel traffic, with city and carrier controls. Mobile routes fit tests where the destination experience must use a mobile-network exit.
Best For: Mobile Proxies suit United States mobile testing that needs standard proxy tunnels and controlled session behavior.
Application logs should separate CONNECT acceptance from target validity. Proxidize connection and usage records can identify access-point activity, while the client validates certificates, responses, and required content. This separation shows whether a failure occurred before, during, or after tunnel setup.
What Should You Remember About HTTP CONNECT Tunnels?
HTTP CONNECT creates a transport path through a proxy; it does not replace TLS, authentication, or application validation. Clear layer boundaries make configuration and troubleshooting much easier.
- CONNECT identifies a destination with a host and explicit port rather than a page path.
- Every 2xx response establishes tunnel mode, while every non-2xx response leaves the tunnel unformed.
- Destination TLS protects HTTPS content inside the tunnel; CONNECT supplies no encryption by itself.
- A proxy can observe tunnel metadata even when it cannot read protected destination content.
- HTTP/1.x uses a whole connection, while HTTP/2 and HTTP/3 use individual streams.
- Proxy authentication errors occur before tunnel setup, while destination errors can occur after successful setup.
- Scaled tunnel workloads need bounded concurrency, distinct timeouts, controlled retries, and validated application results.
Frequently asked questions
HTTP CONNECT itself does not encrypt traffic. It creates a tunnel that can carry TLS, Secure Shell, or another protected protocol. For HTTPS, the client negotiates destination TLS through the tunnel, while an HTTPS proxy separately encrypts the client-to-proxy connection.
A standard non-intercepting HTTP proxy cannot read HTTP content protected by destination TLS. It can still see the requested authority, connection timing, transferred volume, and any proxy authentication details the client supplies. Authorized TLS inspection changes this model by terminating TLS with certificates trusted by managed clients.
`200 Connection Established` is a common HTTP/1.1 response showing that the proxy accepted CONNECT and opened the requested tunnel. The reason phrase is descriptive rather than decisive. Any 2xx status establishes tunnel mode, while every non-2xx response means the tunnel remains unformed.
HTTP CONNECT is not inherently limited to port 443, because its request target includes an explicit port. Proxies commonly restrict CONNECT to approved ports or destinations for security. A client can request another port, but the proxy's policy determines whether that request succeeds.
A proxy returns `407 Proxy Authentication Required` when the client must provide acceptable proxy authentication. Missing credentials, rejected credentials, an incorrect authentication method, or a mismatched source allowlist can cause it. The client must satisfy the proxy challenge before any destination tunnel exists.
No, an HTTP CONNECT tunnel usually serves one proxy-aware connection to one named host and port. A virtual private network (VPN) commonly routes a broader set of device or network traffic. Encryption also differs because CONNECT itself adds none, while typical remote-access VPNs protect the gateway tunnel.
No, SOCKS5 defines its own `CONNECT` command inside the SOCKS5 protocol. It does not send an HTTP request method or receive an HTTP 2xx response. Both mechanisms can create TCP relays, but their negotiation, authentication, name resolution, and error formats are different.