CONNECT

When a client behind a proxy needs a direct TCP channel to a remote host, it uses the HTTP CONNECT method to establish a tunnel through the intermediary.

Table of Contents

Usage

A CONNECT request tells an HTTP proxy to establish a TCP connection to the specified host and port, then relay raw bytes in both directions. The request target uses authority-form (host:port) rather than a path.

The primary use of CONNECT is HTTPS tunneling. When a client behind a proxy needs to reach an HTTPS site, the sequence works as follows:

  1. The client sends CONNECT example.re:443 to the proxy.
  2. The proxy opens a TCP connection to example.re on port 443.
  3. The proxy responds with a 2xx success status to confirm the tunnel is open.
  4. The client performs the TLS handshake directly with the destination server through the tunnel.
  5. All subsequent traffic passes through the proxy as an opaque byte stream.

Because the proxy forwards raw bytes after the tunnel is established, the proxy has no visibility into the encrypted traffic. This is the mechanism corporate and network proxies use to allow HTTPS access to external servers.

If the proxy requires Authentication, the client includes a Proxy-Authorization header in the CONNECT request. A missing or invalid credential results in a 407 Proxy Authentication Required response.

The WHATWG Fetch Standard lists CONNECT as a forbidden method, preventing JavaScript from issuing CONNECT requests through browser APIs.

In HTTP/2 and HTTP/3, CONNECT creates a tunnel over a single stream rather than the full TCP connection. The HTTP/2 spec defines basic CONNECT for individual streams. The extended CONNECT protocol upgrade adds a :protocol pseudo-header enabling WebSockets and other protocols over a multiplexed connection, with support in both HTTP/2 and HTTP/3. The base stream tunnel and extended CONNECT are complementary: one provides raw tunneling, the other enables non-TCP protocols over multiplexed connections.

Properties

Property Value
Safe No
Idempotent No
Cacheable No

Example

HTTPS tunnel through a proxy

A client requests a TLS tunnel to www.example.re on port 443 through a proxy. The proxy authenticates the client using the Proxy-Authorization header, opens the TCP connection, and confirms with 200 OK.

Request

CONNECT www.example.re:443 HTTP/1.1
Host: www.example.re:443
Proxy-Authorization: Basic dXNlcjpwYXNz

Response

HTTP/1.1 200 Connection Established

After receiving the 200 response, the client begins the TLS handshake with www.example.re through the open tunnel. The proxy forwards all subsequent data without inspecting or modifying the content.

Tunnel without authentication

When the proxy does not require credentials, the request contains only the target host and port.

Request

CONNECT www.example.re:443 HTTP/1.1
Host: www.example.re:443

Response

HTTP/1.1 200 Connection Established

CORS

CONNECT is a CORS forbidden method. Browsers block all attempts to send CONNECT through browser APIs such as fetch() and XMLHttpRequest.

HTTP tunneling

HTTP tunneling encapsulates non-HTTP traffic within HTTP messages, allowing protocols like HTTPS, SSH, and FTP to traverse HTTP proxies. CONNECT is the primary mechanism for establishing these tunnels. The proxy opens a raw TCP connection to the target host and port, then relays bytes bidirectionally without inspecting the content.

Without a proxy between client and server, CONNECT is unnecessary. Clients connect to servers directly using the target protocol.

Security

Open proxies that accept CONNECT to arbitrary ports enable abuse: spam relay through SMTP (port 25), port scanning of internal networks, and bypassing network access controls. Production proxies restrict CONNECT to port 443 (HTTPS) or a whitelist of approved destinations.

OWASP identifies unrestricted CONNECT as a security risk. The WHATWG Fetch Standard classifies CONNECT as a forbidden method, preventing browsers from sending CONNECT requests directly through fetch() or XMLHttpRequest.

See also

Last updated: April 4, 2026