A team ships a scraper that works perfectly against plain HTTP endpoints, then points it at an HTTPS target through the same proxy and everything falls apart. The logs show a 407, then a hang, then a 502. Nothing in the application code changed. What changed is the mechanism: plain HTTP through a forward proxy and HTTPS through a forward proxy are two different protocol flows, and only one of them uses a tunnel.
That tunnel is created by the HTTP CONNECT method. It is the single most important piece of protocol plumbing in commercial proxy usage, and it is also the piece most developers never read the spec for. Understanding it changes how you debug failed requests, how you reason about what a proxy can and cannot see, and how you budget round trips in latency-sensitive workloads.
Two Ways an HTTP Proxy Forwards Traffic
An HTTP forward proxy has two operating modes, and the client picks between them based on the scheme of the target URL.
Absolute-form requests for plain HTTP
For http:// targets, the client does not open a tunnel at all. It sends a normal request to the proxy, but with the full URL in the request line instead of just the path:
GET http://example.com/products?page=2 HTTP/1.1Host: example.comProxy-Authorization: Basic dXNlcjpwYXNzUser-Agent: my-crawler/1.2
The proxy parses that request, opens its own connection to the origin, replays the request in origin-form, and streams the response back. It is a full HTTP intermediary here: it sees the method, the path, the headers, the body, and the response. It can cache, rewrite, or inject headers. This is why plain HTTP through a proxy behaves so differently from HTTPS, and why old-school header-manipulation tricks only ever worked on the unencrypted path.
CONNECT tunnels for HTTPS and everything else
For https:// targets, rewriting is not an option, because the client intends to negotiate TLS directly with the origin. So instead of asking the proxy to fetch something, the client asks the proxy to become a dumb pipe:
CONNECT example.com:443 HTTP/1.1Host: example.com:443Proxy-Authorization: Basic dXNlcjpwYXNz
Note the request target format. It is authority-form: host and port only, no scheme, no path. A port is mandatory. If the proxy is willing and able to reach that host, it replies:
HTTP/1.1 200 Connection Established
From that point the bytes on the socket are no longer HTTP. The client starts a TLS handshake, and the proxy blindly relays octets in both directions until one side closes. The tunnel is protocol-agnostic, which is why CONNECT also carries WebSocket upgrades, SMTP over TLS, IMAP, gRPC, and arbitrary TCP if the proxy allows non-standard ports.
Anatomy of the Handshake, Field by Field
A few details in that exchange cause the majority of real-world failures.
Any 2xx means success. RFC 9110 says any 2xx response establishes the tunnel. The familiar reason phrase Connection Established is conventional, not normative. Client code that string-matches on the reason phrase instead of the status class is fragile.
Headers in the 200 response are not part of the tunnel. Once the tunnel exists, response headers from the proxy carry no meaning for the inner stream. Some proxies include a Via or a diagnostic header, which is useful for debugging and for confirming which node handled you.
Proxy-Authorization is hop-by-hop. It authenticates you to the proxy, not to the origin, and it must not be forwarded upstream. Confusing it with Authorization is a classic source of leaked credentials in homegrown proxy chains.
No message body, no Content-Length. A CONNECT request has no payload. Any bytes after the blank line belong to the tunnel. Buffering libraries occasionally read ahead past the header block, swallow the first TLS bytes, and produce a handshake that hangs for no visible reason.
Proxy-Connection is a legacy hack. It never made it into a standard. Modern stacks rely on Connection semantics and HTTP/1.1 persistence, but you still see Proxy-Connection: keep-alive in the wild from older clients.
Status Codes That Tell You What Actually Broke
Proxy errors before the tunnel opens are ordinary HTTP responses, which makes them one of the cheapest diagnostic signals available.
407 Proxy Authentication Required. Your credentials were missing, malformed, or rejected. It arrives with Proxy-Authenticate describing the scheme. A 407 loop after a successful first request usually means the client is not resending credentials on a new connection, or the session token embedded in the username has expired.
403 Forbidden. The proxy understood you and refused the destination: blocked port, blocked host, or a policy rule on the plan.
502 Bad Gateway. The proxy could not complete the upstream TCP connection. On a residential or mobile network this frequently means the exit node went offline mid-request rather than that the target is down.
503 or 429. Concurrency or rate ceilings on the proxy side, not the target side. Worth separating in your metrics, because the remediation is completely different.
A tunnel that opens then dies during TLS. The proxy did its job. The failure is between your client and the origin, and it is often a fingerprint or IP reputation rejection rather than a proxy fault.
The fastest way to isolate these is to reproduce the exchange by hand. curl -v -x http://user:[email protected]:port https://target.example prints the CONNECT request, the proxy response, and the TLS negotiation as separate stages, so you can see exactly which step failed. Before deploying, it is also worth confirming egress IP, geolocation, and reachability with a dedicated proxy testing tool rather than trusting a single successful request.
What the Proxy Can and Cannot See Inside a Tunnel
This is where security assumptions get sloppy. A CONNECT tunnel does hide your request paths, headers, cookies, and bodies from the proxy operator, because those live inside TLS. It does not hide everything.
The proxy learns the destination hostname and port from the CONNECT line itself. It sees the TLS ClientHello, including the SNI value and the ALPN list. It sees packet sizes, timing, and total bytes transferred. That metadata is enough to reconstruct which sites a session visited and roughly how much was pulled, even with perfect encryption of content.
It also matters in the other direction. When you tunnel HTTPS through a proxy that itself speaks TLS (an HTTPS proxy, as opposed to an HTTP proxy carrying an inner TLS session), you get TLS inside TLS. Detection systems can spot the characteristic double handshake pattern and the record size signatures it produces. This is one of several reasons that the transport layer, not just the IP address, decides whether automation looks plausible.
CONNECT Beyond HTTP/1.1
The method has quietly evolved, and the differences matter for anyone building modern clients.
HTTP/2 tunnels. In HTTP/2, CONNECT uses the :method pseudo-header with :authority set to host and port, and no :scheme or :path. The tunnel becomes a single stream inside a multiplexed connection, so many concurrent tunnels share one TCP connection to the proxy. That reduces connection setup overhead substantially at high concurrency, at the cost of head-of-line blocking at the TCP layer.
Extended CONNECT (RFC 8441). Adds a :protocol pseudo-header so WebSockets can ride over HTTP/2 streams. If your automation stack uses WebSocket transports, for example a headless browser control channel, this is the path it will take through a modern proxy.
CONNECT-UDP and MASQUE (RFC 9298). Classic CONNECT is TCP only, which is why UDP workloads historically needed SOCKS5. CONNECT-UDP proxies UDP datagrams over HTTP, opening the door to QUIC and HTTP/3 traffic through an HTTP proxy. Support is still uneven across providers and clients, but it is the direction the standards are heading.
Performance Mechanics Worth Budgeting For
Every tunnel costs round trips: TCP to the proxy, the CONNECT exchange, then TLS to the origin. Over a residential exit with 120 ms of latency, that is easily half a second before the first byte of your actual request leaves the client.
Three practical consequences. First, reuse tunnels. A tunnel to example.com:443 can carry many sequential HTTPS requests, so tearing it down after each one triples your setup cost. Second, treat CONNECT establishment time and origin response time as separate metrics, because they degrade for different reasons. Third, remember that rotation policy interacts with this: per-request rotation forces a fresh tunnel every time, which is sometimes correct and often just expensive.
Common Mistakes That Look Like Proxy Failures
Omitting the port in the authority-form target. Sending CONNECT to a plain HTTP target that never needed a tunnel. Assuming credentials survive across new connections without being resent. Following redirects in a client that silently rebuilds the tunnel to a different host than you intended. Setting a single timeout that covers both tunnel setup and the full response, so slow-but-healthy exits get killed alongside dead ones. Logging the raw Proxy-Authorization header into a shared observability platform.
None of these are proxy defects. All of them show up in support tickets as "the proxy is broken".
Where Proxies Fit In
Once you understand that CONNECT is a request the proxy can accept or refuse, the quality differences between providers stop being abstract. A network that refuses non-standard ports cannot tunnel anything except web traffic. A network with unstable exit nodes produces 502 responses in the middle of long-lived tunnels, which breaks any workflow depending on session continuity. A network without genuine geographic depth cannot give you a tunnel that terminates where your test or your data collection actually needs to appear from.
This is why pool composition matters more than raw IP counts. EnigmaProxy operates residential, ISP, datacenter, and mobile pools, which lets you match the tunnel endpoint to the job: datacenter exits where throughput and cost per gigabyte dominate, ISP or residential exits where trust signals matter, mobile exits where carrier-grade NAT gives an IP unusual resilience. Sticky session control is the other half of the picture, since a tunnel is only as useful as the identity behind it stays stable.
Ethical sourcing belongs in the same conversation. If you are routing business traffic through residential proxy pools, you are inheriting the consent model behind those peer nodes, and that is a due diligence question as much as a technical one. Predictable pricing and business-grade reliability are what turn a working prototype into infrastructure you can put a production workload on.
Strategic Insights and Where This Is Heading
UDP proxying goes mainstream. As HTTP/3 adoption grows, targets increasingly prefer QUIC. Clients that can only tunnel TCP will look progressively less like real browsers. Expect CONNECT-UDP support to become a differentiator in provider selection.
Transport fidelity becomes a first-class requirement. Detection has moved down the stack. The shape of your TLS handshake, your ALPN ordering, and your HTTP/2 settings frames now carry as much weight as the IP. Proxy setups that mangle any of this create signals that no amount of IP rotation hides.
Multiplexed tunnels change concurrency planning. As HTTP/2 and HTTP/3 proxy frontends replace one-tunnel-per-connection models, throughput ceilings shift from socket counts to stream limits and flow control windows. Capacity models built on the old assumptions will misprice.
Observability moves to the tunnel boundary. Mature teams already log CONNECT latency, status code distribution, and exit node identity per attempt. That data is what makes the difference between guessing why success rates dropped and knowing.
Conclusion
CONNECT is a small piece of protocol, four lines on the wire, and it determines almost everything about how proxied HTTPS behaves. Knowing that absolute-form requests and tunnels are different modes explains why plain HTTP and HTTPS fail differently. Knowing that 407, 403, and 502 come from the proxy rather than the target cuts debugging time sharply. Knowing what leaks even inside an encrypted tunnel keeps your threat model honest.
The protocol side is learnable in an afternoon. The infrastructure side, exits that stay up for the length of a session and geographic coverage that matches your targets, is what you buy. Providers such as EnigmaProxy sit in the professional tier of that market, with multiple pool types and transparent sourcing, which is the combination that makes tunnel behaviour predictable enough to build on.