What Is an HTTP Tunnel? How HTTP CONNECT Works

An HTTP tunnel is a communication channel created by an HTTP proxy that forwards raw TCP traffic between a client and a destination without inspecting the payload. The tunnel is initiated using the HTTP CONNECT method, the client asks the proxy to connect to a specific host and port, and the proxy becomes a transparent relay for all subsequent data.

The word "tunnel" is deliberate: once established, the proxy is invisible to both endpoints. The client and destination communicate directly over a byte-for-byte pipe that happens to pass through the proxy's infrastructure. The proxy sees only the initial CONNECT request and the volume of data transferred, not the content.

HTTP tunneling differs from standard HTTP proxying in one critical way: the proxy stops interpreting the protocol. In a standard HTTP proxy request, the proxy reads the HTTP method, modifies headers, and forwards the request on behalf of the client. In a tunnel, the proxy sets up a connection and then steps aside. This is why HTTPS can work through an HTTP proxy, the TLS handshake and encrypted payload flow through the tunnel unchanged.

The CONNECT method is specified in RFC 7231 §4.3.6. It is the only standard HTTP method explicitly designed to create a tunnel rather than transfer a resource.

---

The CONNECT handshake follows a three-step sequence:

Step 1, Client sends CONNECT request:

CONNECT api.example.com:443 HTTP/1.1
Host: api.example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNz

The request line uses the CONNECT method with the destination as host:port. No path is included, the tunnel is to a host and port, not a specific resource. Proxy-Authorization is included if the proxy requires authentication (RFC 7235, IETF 2014).

Step 2, Proxy opens TCP connection to destination and responds:

HTTP/1.1 200 Connection Established

The proxy opens a TCP connection to api.example.com:443 and sends back 200 Connection Established. This is the tunnel confirmation. If the proxy can't reach the destination, it returns an appropriate error:

Step 3, Raw TCP relay begins:

After the 200 response, the TCP connection between client and proxy becomes a raw byte-stream relay. The proxy forwards all bytes from client to destination and vice versa without parsing. From this point, the client and destination exchange data as if they had a direct TCP connection, including TLS handshakes, application-layer protocols, keep-alive pings, and close signals.

The proxy holds the TCP connection open as long as either side keeps it alive. When either side closes the connection, the proxy tears down both legs.

INFO-GAIN: RFC 7231 §4.3.6 specifies that a proxy implementing CONNECT "MUST NOT" interpret or validate the data flowing through the tunnel after the 200 response. This means a properly implemented proxy cannot perform SSL inspection on a CONNECT tunnel unless it acts as a man-in-the-middle by substituting its own certificate, a fundamentally different operation that breaks end-to-end TLS semantics and requires explicit client trust configuration.

---

In practice, your HTTP client uses both modes automatically. When you configure an HTTP proxy and request an http:// URL, the client makes a standard proxy request, the proxy reads the response. When you request an https:// URL, the client sends CONNECT first, establishes a tunnel, then completes the TLS handshake inside that tunnel. The proxy sees the volume of data but not the content.

This means your --proxy http://host:port configuration in curl handles both modes transparently:

# Standard HTTP proxy request (proxy reads the response)
curl --proxy http://user:pass@proxy.example.com:8080 http://httpbin.org/ip

# Automatically uses CONNECT tunnel for HTTPS (proxy sees only encrypted bytes)
curl --proxy http://user:pass@proxy.example.com:8080 https://httpbin.org/ip

---

Any TCP-based protocol can be tunneled through an HTTP CONNECT proxy, provided the proxy allows the destination port. Protocols commonly tunneled this way:

HTTPS (TLS on port 443), The universal use case. Every HTTPS request through an HTTP proxy uses a CONNECT tunnel. This is standard browser and HTTP client behavior.

WebSockets, After the CONNECT tunnel is established to port 443, a WebSocket upgrade handshake proceeds normally inside the TLS connection. Corporate proxies that support CONNECT to port 443 also support WebSockets through those tunnels, as the proxy can't distinguish WebSocket traffic from HTTPS.

SSH (port 22 or 443), SSH clients like OpenSSH support proxy tunneling via ProxyCommand. By routing SSH through a CONNECT tunnel to port 443, SSH connections can pass through HTTP proxies that allow port 443. This is a common method for accessing remote servers from restrictive corporate networks.

# ~/.ssh/config, SSH through HTTP CONNECT proxy
Host bastion.example.com
    ProxyCommand nc -X connect -x proxy.corp.example.com:8080 %h %p

SMTP/IMAP over TLS (ports 465/993), Mail clients can use CONNECT tunnels to reach mail servers through HTTP proxies, provided the proxy allows those destination ports. Many proxies restrict CONNECT to port 443 only.

Custom TCP applications, Any application that uses TCP can be routed through an HTTP CONNECT tunnel using a tool like proxytunnel, corkscrew, or proxychains. This is useful when SOCKS5 isn't available but an HTTP proxy is.

Important constraint: The proxy must permit the destination port. Many corporate and commercial proxies restrict CONNECT to port 443 (and sometimes 80 or 22) to prevent the tunnel mechanism from being used to bypass security controls. A proxy that permits CONNECT to any port is called an "open" or "unrestricted" CONNECT proxy, this is a security risk in corporate environments and intentional behavior in commercial proxy services.

---

HTTPS through an HTTP proxy is a direct application of the CONNECT tunnel. Understanding this sequence removes a common point of confusion: the proxy doesn't need to terminate TLS to forward HTTPS traffic.

1. Client sends CONNECT to proxy: CONNECT api.example.com:443 HTTP/1.1
2. Proxy opens TCP to api.example.com:443 and returns 200 Connection Established
3. Client initiates TLS handshake directly with api.example.com through the tunnel. The TLS handshake bytes flow through the proxy untouched.
4. TLS handshake completes between client and destination. The proxy sees only encrypted bytes.
5. Encrypted HTTPS requests flow through the tunnel. The proxy has no visibility into headers, methods, URLs, or response content.

The proxy authenticated the client at step 1 (via Proxy-Authorization if required) and will log the CONNECT event (destination host and port, connection duration, bytes transferred). It cannot log individual HTTPS requests or responses, only that the client connected to api.example.com:443.

This is why certificate-based SSL inspection proxies must actively intercept the TLS handshake and substitute their own certificate. This breaks the "proxy cannot modify content" property of CONNECT and requires clients to trust the proxy's CA certificate. See the transparent proxy guide for a detailed treatment of SSL interception architectures.

---

Corporate firewalls and next-generation firewalls (NGFWs) use several techniques to control HTTP tunnel usage:

Port restriction on CONNECT. The most common control: the proxy is configured to allow CONNECT only to port 443 (and sometimes 80, 22, or explicit allow-lists). This prevents tunneling arbitrary protocols to non-HTTPS ports while maintaining HTTPS support. Most enterprise HTTP proxy products (Squid, Zscaler, Blue Coat, Netskope) enforce this by default.

Destination host filtering. Proxies can maintain allow-lists or deny-lists of hosts that CONNECT is permitted to. A CONNECT request to a known VPN or proxy infrastructure host can be blocked while CONNECT to legitimate cloud services is allowed.

TLS inspection (SSL bumping). Some NGFWs act as a MitM on CONNECT tunnels by substituting a proxy-issued certificate and terminating TLS themselves. This gives the firewall visibility into the HTTPS payload, HTTP methods, URLs, request/response bodies, at the cost of breaking end-to-end TLS certificate validation. Clients inside the corporate network must trust the proxy's CA for this to be transparent.

Traffic volume anomaly detection. A CONNECT tunnel to port 443 that transfers gigabytes of data in a session is anomalous compared to typical HTTPS browsing. NGFWs with behavioral analysis can flag or throttle these connections.

Protocol detection inside tunnels. Advanced inline security products can analyze the traffic patterns of CONNECT tunnels to determine the application protocol (SSH, VPN, P2P) even without decrypting TLS, using JA3/JA4 TLS fingerprinting and byte-pattern analysis. See the proxy anonymity levels guide for how TLS fingerprinting works as a detection layer.

For commercial proxy services, the inverse applies: the proxy intentionally permits broad CONNECT destinations and ports to support the variety of protocols that clients need to route through the service.

---

Tunnel bypass of proxy policy. Because CONNECT creates an opaque byte pipe, standard content filtering, malware scanning, and DLP tools applied at the proxy layer cannot inspect tunneled content. An HTTPS CONNECT tunnel carrying HTTP traffic inside TLS is invisible to network-layer filtering. This is expected behavior for HTTPS, but the same mechanism can be used to exfiltrate data or carry unauthorized protocols through a proxy that was deployed to control those protocols.

Data exfiltration via DNS and HTTPS tunnels. DNS-over-HTTPS (DoH) and DNS tunneling tools can encode arbitrary data in DNS queries carried inside HTTPS CONNECT tunnels. Port 443 CONNECT traffic to a DNS-over-HTTPS provider looks identical to a legitimate browser connecting to a CDN. Detecting this without TLS inspection requires behavioral analysis.

Open CONNECT proxies. A proxy that accepts CONNECT to any destination and port without authentication functions as a TCP relay for any protocol to any host on the internet. Open CONNECT proxies are frequently abused for port scanning, spam relay, credential stuffing, and DDoS. If you're operating a proxy service or corporate proxy, always restrict CONNECT destinations and require authentication.

Proxy-Authorization credentials in plaintext. If the initial CONNECT request flows over HTTP (not HTTPS) between client and proxy, the Proxy-Authorization: Basic header is base64-encoded but not encrypted. Anyone who can intercept the client-proxy connection can read the credentials. Use authenticated proxies over TLS connections or restrict access by IP allowlist.

Certificate substitution detection. When an SSL-inspecting proxy intercepts a CONNECT tunnel, the TLS certificate the client receives is issued by the proxy's CA, not the destination's actual CA. This is detectable by clients that perform certificate pinning. Applications that pin certificates will fail or throw errors when routed through SSL-inspecting proxies, a useful indicator that inspection is occurring.

---

curl, verifying CONNECT tunnel behavior:

# curl automatically uses CONNECT for HTTPS targets
curl -v --proxy http://user:pass@proxy.example.com:8080 https://httpbin.org/ip 2>&1 | grep -E "CONNECT|Establish|tunnel"

The -v verbose output will show CONNECT httpbin.org:443 HTTP/1.1 and the 200 Connection Established response, confirming the tunnel was used.

Python (requests), same automatic behavior:

import requests

proxies = {
    "https": "http://user:pass@proxy.example.com:8080",
}

# requests automatically issues CONNECT for https:// URLs
response = requests.get("https://httpbin.org/ip", proxies=proxies, timeout=15)
print(response.json())

SSH through an HTTP CONNECT proxy:

# Using OpenSSH ProxyCommand with netcat
ssh -o "ProxyCommand nc -X connect -x proxy.example.com:8080 %h %p" user@remote-server.com

# Or using corkscrew
ssh -o "ProxyCommand corkscrew proxy.example.com 8080 %h %p" user@remote-server.com

Python, raw CONNECT request (for testing):

import socket

def open_connect_tunnel(proxy_host: str, proxy_port: int, target_host: str, target_port: int) -> socket.socket:
    """Open a raw CONNECT tunnel through an HTTP proxy."""
    sock = socket.create_connection((proxy_host, proxy_port), timeout=10)
    connect_request = (
        f"CONNECT {target_host}:{target_port} HTTP/1.1\r\n"
        f"Host: {target_host}:{target_port}\r\n"
        f"\r\n"
    )
    sock.sendall(connect_request.encode())
    response = sock.recv(4096).decode()
    if "200" not in response:
        sock.close()
        raise ConnectionError(f"CONNECT failed: {response.splitlines()[0]}")
    return sock  # Raw TCP pipe is now open to target_host:target_port

tunnel = open_connect_tunnel("proxy.example.com", 8080, "api.example.com", 443)
# Now wrap with ssl.wrap_socket() for TLS, or use directly for raw TCP

---

No UDP support. HTTP CONNECT establishes a TCP tunnel only. UDP traffic, DNS queries, real-time media, gaming, cannot be tunneled via CONNECT. For UDP tunneling, SOCKS5 with UDP ASSOCIATE is the appropriate protocol, though many providers don't enable it.

Connection overhead per tunnel. Each CONNECT tunnel requires its own TCP connection to the proxy, plus the proxy's TCP connection to the destination. For workloads that open many parallel short-lived connections (e.g., scraping many different hosts), the CONNECT handshake adds per-connection latency. HTTP/2 proxying and connection pooling can mitigate this, but support varies by client and proxy.

Port restriction enforcement. Most production proxies restrict CONNECT to port 443 only. Applications that need to tunnel to non-standard ports (SSH on 22, SMTP on 465, custom TCP ports) may find their CONNECT requests blocked. This is a policy constraint, not a protocol limitation, commercial proxy services targeting developers typically allow a broader port range.

No intrinsic anonymity improvement. An HTTP CONNECT tunnel routes traffic through the proxy's IP, which changes the visible origin IP at the destination. But the CONNECT request itself reveals the destination hostname in plaintext to the proxy and any network observer before the tunnel is established. The proxy logs the target of every CONNECT request. For proxy anonymity, the tunnel mechanism is neutral, the anonymity properties come from the proxy's IP reputation and configuration, not from the use of CONNECT.

HTTP/1.1 dependency for CONNECT. The CONNECT method as defined in RFC 7231 applies to HTTP/1.1. HTTP/2 extended CONNECT semantics are defined in RFC 8441 (IETF, 2018) to support WebSocket over HTTP/2, but full generalized TCP tunneling over HTTP/2 via CONNECT isn't universally supported across proxy implementations.

---

An HTTP tunnel is the mechanism that makes HTTPS possible through proxy infrastructure, and understanding CONNECT is foundational for working with any proxy-based architecture.

The CONNECT method creates a raw TCP pipe through an HTTP proxy. Once established, the proxy steps aside and forwards bytes without interpretation. That opaque channel is how TLS handshakes complete through proxies, how SSH sessions pass through corporate firewalls, and how WebSocket connections work through proxy-aware environments.

For practical proxy configuration, the key points: HTTP clients handle CONNECT automatically for HTTPS targets, you don't need to do anything special. For non-HTTPS TCP protocols, use CONNECT host:port directly or route through a tool like proxytunnel. For UDP requirements, switch to SOCKS5. For environments where CONNECT is blocked or restricted, verify which ports the proxy allows and whether TLS inspection is active before debugging connection failures.

---

Related guides: What Is a Forward Proxy? · What Is a SOCKS Proxy? · What Is a Transparent Proxy? · Proxy Anonymity Levels · What Is a Residential Proxy?