What this lab proves in 30 seconds
This lab validates four production-critical properties using direct evidence on the wire rather than dashboards or assumptions:
• Traffic routing actually traverses the intended proxy hop
• HTTP CONNECT establishes a clean, byte-transparent tunnel
• TLS handshakes occur strictly after tunnel establishment
• Backend applications receive the true client IP via PROXY protocol
The conceptual background is covered in
Proxy Protocols: HTTP CONNECT, SOCKS5, and PROXY protocol in production
This lab focuses entirely on verification.
In practice, these checks are routinely performed when validating production proxy paths built on providers such as MaskProxy.
Lab setup assumptions
This lab assumes an operator-level environment with direct access to packet capture and application logs.
• Client host with curl, openssl, and tcpdump
• An HTTP proxy that supports CONNECT
• A TCP load balancer capable of injecting PROXY protocol
• A backend service configured to accept PROXY protocol
Terminology is used precisely throughout:
• proxy protocols refer to HTTP CONNECT and SOCKS5
• PROXY protocol is an L4 header injected before application payload
Operational behavior aligns with standard HTTP proxy semantics as documented by curl.
Verify HTTP CONNECT tunnel establishment
This test confirms that the proxy establishes a raw TCP tunnel and stops interpreting bytes.
curl -v -x http://PROXY_IP:PROXY_PORT https://example.com/
Success signals
• CONNECT example.com:443 HTTP/1.1 is sent
• HTTP/1.1 200 Connection established is returned
• Binary TLS bytes appear immediately after
Failure signals
• Any HTTP error code before 200
• Response bodies instead of raw bytes
• Headers injected after the tunnel is declared
A correct CONNECT tunnel behaves as a transparent TCP pipe.
This behavior is fundamental to forward proxy implementations such as
HTTP Proxies.
Verify TLS handshake ordering through the tunnel
This test validates ordering rather than basic connectivity.
openssl s_client \
-proxy PROXY_IP:PROXY_PORT \
-connect example.com:443 \
-servername example.com
Expected behavior
• CONNECT completes first
• TLS ClientHello appears only after tunnel establishment
• Certificate chain matches the origin server
Common failure indicators
• TLS alerts before CONNECT completion
• Proxy-issued certificates
• Successful handshakes even when CONNECT is blocked
TLS ordering violations typically indicate TLS interception or incorrect proxy mode configuration.
Confirm PROXY protocol presence at the start of the stream
This test verifies that PROXY protocol is injected before any application data.
sudo tcpdump -nn -A -s 256 'tcp port 443'
Inspect the first payload bytes after the TCP handshake.
Valid indicators
• PROXY v1 appears as an ASCII line starting with PROXY TCP4
• PROXY v2 appears as the binary signature \r\n\r\n\0\r\nQUIT\n
These bytes must appear before any TLS records.
Invalid indicators
• TLS bytes appear first
• PROXY header appears mid-stream
• Header appears inconsistently across connections
This pattern is common in proxy chains that combine HTTP CONNECT or SOCKS5 forwarding with load balancers injecting PROXY protocol, including deployments built on
SOCKS5 Proxies.
Verify backend logs the real client IP
Wire-level correctness must be consumed correctly by the application layer.
Example NGINX listener configuration:
listen 443 proxy_protocol;
real_ip_header proxy_protocol;
Log format example:
log_format lab '$proxy_protocol_addr $remote_addr';
Generate traffic through the proxy and inspect backend logs.
Correct result
• $proxy_protocol_addr shows the true client IP
• $remote_addr reflects the load balancer address
• Rate limiting and ACLs behave consistently
Incorrect result
• Both fields show the balancer IP
• Client IP varies unpredictably
• Behavior changes after reloads
This validation step is frequently required when integrating rotating infrastructure such as
Rotating Datacenter Proxies.
Evidence bundle checklist
Capture and archive the following artifacts for each validation run:
• curl -v output proving CONNECT success
• openssl s_client transcript proving TLS ordering
• tcpdump capture showing PROXY header position
• Backend logs showing PROXY-derived client IP
Pass criteria
• CONNECT precedes TLS
• PROXY header precedes application data
• Client IP remains stable and correct
Fail criteria
• Any ambiguity in ordering or identity attribution
Troubleshooting reference for common failure patterns
TLS appears before CONNECT
Likely cause: TLS interception is enabled at the proxy or load balancer.
First fix: Disable TLS termination and ensure CONNECT establishes a raw TCP tunnel before any handshake.
Backend sees the load balancer IP instead of the client IP
Likely cause: PROXY protocol is not enabled or not consumed by the backend.
First fix: Enable proxy_protocol on the listener and configure the backend to trust the PROXY header.
Random connection resets during handshake
Likely cause: PROXY protocol version mismatch between sender and receiver.
First fix: Align both sides to the same PROXY protocol version, preferably v2 in production.
Configuration works in development but fails in production
Likely cause: Different load balancer defaults or implicit TLS handling in production.
First fix: Perform a byte-level configuration diff and verify listener modes.
Client identity appears intermittently incorrect
Likely cause: Mixed backend pools where some listeners expect PROXY protocol and others do not.
First fix: Separate listeners clearly and isolate PROXY-enabled traffic paths.
Retries should never be introduced until ordering and identity propagation are proven correct on the wire.
Safe defaults to enforce in production environments
• These defaults prevent silent identity corruption:
• Separate listeners for PROXY and non-PROXY traffic
• Explicit PROXY v2 configuration end-to-end
• Packet capture validation after any proxy or load balancer change
• Backend rejection of connections missing PROXY headers
• Logs always record both socket and PROXY-derived IP
Top comments (0)