Proxy Protocol Internals: What Actually Happens When You Route a Request

Most engineers who use proxies treat them as a black box. Set the proxy parameter, point it at the endpoint, assume the IP gets rotated. That mental model works until something breaks, and when it breaks, the lack of mental model makes debugging take three times longer than it should.

Understanding what actually happens at the protocol level makes you a better proxy user and a better debugger. It takes 20 minutes to understand. It pays back in hours.

The Two Fundamental Proxy Types

Proxies split into two categories based on what they see and how they route traffic: forward proxies and transparent proxies. For scraping, you're almost always using forward proxies, explicitly configured on the client side. Transparent proxies intercept traffic without client awareness; useful for network infrastructure, irrelevant for scraping.

Within forward proxies, there are two protocols you'll encounter: HTTP proxying and CONNECT tunneling. They behave differently, and mixing them up explains a lot of confusing behavior.

HTTP Proxying: How It Actually Works

For plain HTTP requests through a proxy, the flow is simpler than most people expect. Your client doesn't connect to the target server at all, it connects to the proxy and sends the full request with the absolute URI.

Without proxy:

With HTTP proxy:

The proxy receives the full request, strips the proxy-specific headers, opens its own connection to example.com, forwards the request, receives the response, and returns it to your client. Your client never has a TCP connection to example.com. The proxy is a middleman at the HTTP layer.

This has a critical implication: the proxy can read your HTTP traffic. It's decrypting nothing because nothing is encrypted, HTTP is plaintext. The proxy sees every header, every request body, every response.

For scraping, this matters because HTTP proxy headers like X-Forwarded-For can expose your real IP if the proxy adds them. Quality proxy providers strip or don't add these headers. Verify this with a service that echoes headers back to you before trusting a provider.

CONNECT Tunneling: The HTTPS Story

HTTPS through a proxy is fundamentally different. The proxy can't read the encrypted traffic, that would break TLS. Instead, the client establishes a tunnel through the proxy using the CONNECT method.

Client → Proxy:
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Proxy → Client:
HTTP/1.1 200 Connection Established

[TCP tunnel open — proxy is now forwarding raw bytes]

Client → Proxy → Server:
[TLS ClientHello]
[TLS handshake]
[Encrypted HTTP request]

The proxy responds 200 Connection Established and becomes a dumb TCP forwarder. Everything after that is encrypted bytes the proxy cannot read. Your TLS session is directly with example.com, not with the proxy.

This is why TLS fingerprinting (JA3) isn't blocked by the proxy, the TLS handshake goes from your client, through the tunnel, to the target server. The target server sees the TLS ClientHello directly. If your TLS fingerprint looks like Python's httpx rather than Chrome, the target sees that regardless of what proxy you're using.

Debugging implication: If your HTTPS requests through a proxy fail, check the CONNECT step first. A 407 Proxy Authentication Required on the CONNECT means authentication failed. A 503 or 502 on the CONNECT means the proxy couldn't reach the target.

import httpx

# To see what's happening, enable logging
import logging
logging.basicConfig(level=logging.DEBUG)
# This will show the CONNECT handshake in the logs

SOCKS5: Lower Level, More Capable

SOCKS5 operates below the HTTP layer, at the TCP level. It's more general-purpose than HTTP proxying: it can proxy any TCP or UDP traffic, not just HTTP/HTTPS.

The SOCKS5 handshake:

1. Client → Proxy: Version negotiation
   [05 01 00]  (SOCKS5, 1 auth method, no auth)
   
2. Proxy → Client: Method selection
   [05 00]  (SOCKS5, no auth)
   
   -- Or with username/password auth:
   [05 02]  → Client sends [01 len username username len password password]
              Proxy responds [01 00] (success)

3. Client → Proxy: Connection request
   [05 01 00 03 0b example.com 01 bb]
   (SOCKS5, CONNECT, reserved, domain type, 
    11-char hostname "example.com", port 443)

4. Proxy → Client: Response
   [05 00 00 01 00 00 00 00 00 00]
   (SOCKS5, success, reserved, IPv4, bound address/port)

5. [Raw TCP tunnel established — same as CONNECT for HTTPS]

After the SOCKS5 handshake, the proxy is a raw TCP forwarder. TLS negotiation, HTTP/2, WebSockets, all of it flows through unchanged.

Why SOCKS5 matters for scraping: HTTP proxies can only proxy HTTP/HTTPS. SOCKS5 proxies can tunnel any TCP traffic, including non-HTTP protocols your scraper might need. Also, SOCKS5 doesn't add Proxy-* headers to your requests (there are no headers at the SOCKS level), which reduces the proxy's footprint in your traffic.

Evomi provides all three on distinct ports for residential proxies:

• rp.evomi.com:1000 — HTTP

• rp.evomi.com:1001 — HTTPS (HTTP proxy for HTTPS targets via CONNECT)

• rp.evomi.com:1002 — SOCKS5

In Python with httpx:

# HTTP proxy (handles both HTTP and HTTPS via CONNECT)
proxies = {"http://": "http://user:pass@rp.evomi.com:1000",
           "https://": "http://user:pass@rp.evomi.com:1001"}

# SOCKS5 proxy
proxies = {"http://": "socks5://user:pass@rp.evomi.com:1002",
           "https://": "socks5://user:pass@rp.evomi.com:1002"}

Proxy Chaining: Routing Through Multiple Hops

Proxy chaining routes a request through two or more proxies sequentially. Each proxy in the chain sees only the previous hop's IP, not your real IP.

From the target server's perspective, the request originates from Proxy B. Proxy B sees traffic from Proxy A. Proxy A sees traffic from you.

In practice, scraping use cases rarely need true proxy chaining, a single residential proxy provides sufficient origin IP obfuscation. Chaining adds latency (each hop adds RTT) and complexity. The more common use case: using a SOCKS5 proxy within a VPN, which creates a de facto two-hop chain.

The scenario where chaining is genuinely useful: routing through a geo-specific proxy via a residential IP in the same region. Some proxy management tools support this natively.

What Gets Leaked and What Doesn't

Understanding what the proxy hides and what it doesn't:

DNS leak prevention: Some HTTP library configurations resolve the hostname locally before passing it to the proxy. This leaks DNS queries to your ISP/resolver. Ensure your HTTP client sends the hostname to the proxy for resolution, not a pre-resolved IP.

# httpx resolves hostnames via proxy by default — no DNS leak
# requests can leak DNS if misconfigured; check your setup:
import requests
session = requests.Session()
session.proxies = {'https': 'socks5h://user:pass@host:port'}
#                          ^ Note: socks5h not socks5
# The 'h' means: let the proxy resolve the hostname (no local DNS)

Sticky Sessions vs. Rotating Sessions

The proxy protocol has no native concept of session stickiness, that's an application-level feature built on top. Providers implement it by encoding session identifiers into the proxy username:

The proxy server maps session-abc123 to a specific exit node for the duration of the session (typically 10–30 minutes). Subsequent CONNECT or HTTP requests with the same session ID are routed through the same exit IP, allowing cookie-bearing sessions to maintain consistency.

Understanding this mechanism tells you where stickiness can break: if the exit node goes offline mid-session, the proxy server may route the next request to a different IP, breaking cookie state. Design your session handling to detect IP changes and rebuild the session if needed.

The Practical Debugging Checklist

When proxy issues arise, work through this in order:

1. Test the proxy directly — curl -x http://user:pass@host:port https://httpbin.org/ip. If this fails, it's the proxy, not your code.

2. Check authentication — 407 means auth failed. Verify username/password and encoding.

3. Check CONNECT for HTTPS — If HTTP targets work but HTTPS doesn't, the CONNECT step is failing. Check firewall rules on port 443.

4. Check DNS — If some hostnames work and others don't, DNS resolution via the proxy may be failing. Try IP address directly.

5. Check TLS fingerprint — If CONNECT succeeds but the target blocks you, it's not the proxy. It's the TLS fingerprint or downstream detection.

The protocol layer and the detection layer are separate problems. Confusing them wastes hours.

Know your stack from the socket up. The proxy is just one layer.