An HTTP CONNECT tunnel is a byte-forwarding connection created when a client asks an HTTP proxy to connect to a destination host and port. After a successful 2xx response, the proxy stops treating subsequent bytes as ordinary HTTP messages and relays them in both directions until the tunnel closes.
The request target uses authority form, such as CONNECT example.com:443, and includes an explicit port. Any successful 2xx response means tunnel mode starts immediately after the response headers; a non-2xx response means the tunnel was not established. CONNECT responses are not cacheable.
For an HTTPS destination, the client normally performs the TLS handshake through the tunnel after CONNECT succeeds. The proxy can see the requested host and port and connection metadata, but an ordinary forwarding proxy does not see the encrypted HTTP messages inside unless it separately performs TLS interception trusted by the client.
A proxy can require credentials and answer with 407 Proxy Authentication Required before opening the tunnel. Those credentials authorize use of the intermediary; they are distinct from cookies, Authorization headers, or client certificates used with the destination after the tunnel exists.
An HTTP proxy can tunnel an HTTPS destination with CONNECT even when its own URL begins with http://. An https:// proxy URL additionally encrypts the client-to-proxy hop; the TLS connection to the destination still starts separately inside the tunnel. Avoid placing proxy secrets in logs, command histories, or error messages.
The destination sees the proxy's exit IP, but TLS fingerprints, HTTP headers, cookies, timing, and application behavior still identify the client session. Whether DNS resolution occurs locally or through the proxy also depends on the client and proxy protocol configuration.
Proxies should restrict allowed destination ports because an unrestricted tunnel can relay non-web protocols or abuse internal network access. Scraping clients should use approved targets and treat tunnel failures, TLS failures, and destination HTTP errors as three separate diagnostic layers.
How Crawlora handles this
Crawlora manages proxy transport inside its hosted scraping infrastructure, so API consumers do not open CONNECT tunnels or distribute proxy credentials themselves. The concept still matters when diagnosing a custom HTTP client or browser behind an explicit proxy.
Related reading
Glossary
FAQ
An ordinary CONNECT proxy only forwards the encrypted TLS bytes after the tunnel opens. Decryption requires a separate interception setup whose certificate the client trusts.
No. CONNECT is an HTTP method used mainly by HTTP proxies to create a tunnel to a host and port. SOCKS5 is a separate general-purpose proxy protocol with its own handshake and address commands.
The proxy requires valid proxy authentication before it will open the tunnel. It is a failure at the proxy layer, before the destination's own HTTP authentication can occur.
Beyond HTTP CONNECT Tunnel, Crawlora's own docs cover the rest of the stack — browse the APIs, test a request in Playground, and move from scraping infrastructure work to production data workflows.