Proxy Protocols — Forward, Reverse & SOCKS
Forward proxies act on behalf of clients for egress control and caching; reverse proxies act on behalf of servers for load balancing and TLS termination; SOCKS5 tunnels any protocol at Layer 4.
The Problem
Direct client-to-server communication cannot provide load balancing, caching, access control, or anonymity. Proxies insert an intermediary that can make routing decisions, cache responses, enforce policies, and terminate TLS — but each proxy type serves a fundamentally different purpose and operates at a different network layer.
Mental Model
Forward proxy is a personal assistant who makes calls on behalf of someone — the recipient does not know who really called. Reverse proxy is a receptionist at a company — callers reach the receptionist, who routes them to the right person inside.
Architecture Diagram
How It Works
Proxies are intermediaries in network communication. They receive traffic, make decisions about it, and forward it — but the type of proxy, the direction it faces, and the layer it operates at determine everything about its behavior and use case. Conflating forward proxies, reverse proxies, and SOCKS proxies leads to architectural mistakes and security gaps.
Forward Proxy: Client-Side Intermediary
A forward proxy sits between clients and the internet. The client is explicitly configured (or transparently intercepted) to send requests to the proxy, which then forwards them to the destination. The destination server sees the proxy's IP address, not the client's.
The request flow:
Client → Forward Proxy → Internet → Destination Server
↓
Client ← Forward Proxy ← Internet ← Destination Server
Why forward proxies exist:
- Access control: Corporate networks use forward proxies to restrict which websites employees can reach. The proxy maintains a URL categorization database and blocks requests to unauthorized categories.
- Caching: A caching forward proxy (Squid) stores responses and serves them to subsequent clients without contacting the origin. In office environments with hundreds of users, this significantly reduces bandwidth consumption.
- Anonymization: The destination sees the proxy's IP. Multiple clients sharing a proxy are indistinguishable to the server. Tor extends this concept with multiple proxy hops.
Explicit vs. transparent: An explicit forward proxy requires client configuration — browser proxy settings, HTTP_PROXY environment variable, or application-level proxy config. A transparent proxy intercepts traffic at the network level (via iptables REDIRECT or WCCP routing) without any client awareness.
The HTTP CONNECT Tunnel
Forward proxies understand HTTP natively. When a client requests GET http://example.com/page, the proxy can read the URL, apply policy, cache the response, and forward it. But HTTPS presents a problem — the request is encrypted, and the proxy cannot read it.
The solution is HTTP CONNECT:
1. Client → Proxy: CONNECT api.example.com:443 HTTP/1.1
2. Proxy opens TCP connection to api.example.com:443
3. Proxy → Client: HTTP/1.1 200 Connection Established
4. Client performs TLS handshake directly with api.example.com
5. Proxy relays encrypted bytes bidirectionally (opaque tunnel)
The proxy sees the destination hostname and port (from the CONNECT request), but never the request path, headers, or body. It is a blind TCP relay. This is why HTTPS traffic through a forward proxy cannot be cached or content-filtered — unless the proxy performs TLS interception (MITM) by presenting its own certificate to the client and establishing a separate TLS session with the server.
Reverse Proxy: Server-Side Intermediary
A reverse proxy sits in front of backend servers. Internet clients connect to the reverse proxy, which routes requests to the appropriate backend. The client sees the proxy's IP and certificate, not the backend's.
Internet Client → Reverse Proxy (NGINX/Envoy) → Backend Server A
→ Backend Server B
→ Backend Server C
Core responsibilities of a reverse proxy:
- TLS termination: The reverse proxy holds the TLS certificate and handles all cryptographic operations. Backend servers receive plaintext HTTP, simplifying their configuration and reducing CPU load.
- Load balancing: Distribute requests across multiple backends using round-robin, least connections, consistent hashing, or weighted algorithms.
- Request routing: Route by Host header (virtual hosting), URL path, or header values. A single reverse proxy can front hundreds of services.
- Caching: Cache static and semi-dynamic responses to reduce backend load.
- Security: Apply rate limiting, WAF rules, and request validation before traffic reaches the application.
Header propagation is the most common operational issue with reverse proxies. When the reverse proxy connects to the backend, the backend sees the proxy's IP as the source. To preserve client identity:
# NGINX configuration
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $host;
The X-Forwarded-For (XFF) header accumulates IPs through the proxy chain: X-Forwarded-For: client-ip, proxy1-ip, proxy2-ip. The backend trusts the leftmost IP as the original client — but only if the proxy chain is trusted. An attacker can spoof XFF by including it in the original request, which is why the application must be configured to trust XFF only from known proxy IPs.
SOCKS5: Protocol-Agnostic Tunneling
SOCKS (Socket Secure) version 5 operates at Layer 4. Unlike HTTP proxies that understand HTTP, SOCKS5 proxies tunnel raw TCP and UDP streams. The client tells the SOCKS5 proxy where to connect, and the proxy establishes the connection and relays bytes.
The SOCKS5 handshake:
1. Client → Proxy: Greeting (supported auth methods)
2. Proxy → Client: Selected auth method
3. Client → Proxy: Auth credentials (if required)
4. Client → Proxy: CONNECT request (destination IP/hostname + port)
5. Proxy → Client: Connection result
6. Bidirectional data relay begins
SOCKS5 advantages over HTTP proxies:
| Feature | HTTP Proxy | SOCKS5 |
|---|---|---|
| Protocols supported | HTTP/HTTPS only | Any TCP/UDP |
| Layer | Application (L7) | Transport (L4) |
| Can tunnel SSH | Only via CONNECT | Natively |
| Can tunnel database connections | No | Yes |
| DNS resolution | Client-side or proxy-side | Proxy-side (SOCKS5h) |
| Performance overhead | HTTP parsing per request | Minimal (raw relay) |
The most common SOCKS5 usage: ssh -D 1080 bastion-host creates a dynamic SOCKS5 proxy that tunnels all traffic through the SSH connection to the bastion. Configure the browser or application to use socks5://127.0.0.1:1080 and all traffic appears to originate from the bastion.
HAProxy PROXY Protocol: Preserving Client Identity at L4
L4 (TCP) load balancers and proxies face a fundamental problem: they forward TCP connections, and the new connection's source IP is the load balancer's IP, not the client's. The backend has no way to know who the real client is.
HTTP reverse proxies solve this with X-Forwarded-For, but that only works for HTTP traffic. For generic TCP connections (database, SMTP, custom protocols), there is no application-layer header to carry client identity.
The PROXY Protocol solves this by prepending a header to the TCP stream before any application data:
# PROXY Protocol v1 (text)
PROXY TCP4 192.168.1.100 10.0.0.50 56789 443\r\n
[original TCP stream follows]
# PROXY Protocol v2 (binary)
\x0D\x0A\x0D\x0A\x00\x0D\x0A\x51\x55\x49\x54\x0A [binary header]
[original TCP stream follows]
The header contains: protocol family, source IP, destination IP, source port, destination port. The backend reads this header once, extracts the real client IP, and then processes the rest of the stream normally.
Both sides must agree on PROXY Protocol usage. If the proxy sends the header but the backend does not expect it, the header is interpreted as malformed application data — causing connection failures with confusing error messages.
Transparent Proxying
A transparent proxy intercepts traffic without client configuration. The client sends a normal request to the destination, but network-level redirection (iptables, policy-based routing, or WCCP) diverts the traffic to the proxy.
# iptables rule to transparently redirect all outbound HTTP to Squid
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128
Transparent proxying works well for HTTP (the proxy can reconstruct the destination from the Host header). For HTTPS, transparent proxying is more complex — the proxy cannot read the encrypted request, so it must either:
- Use SNI (Server Name Indication) from the TLS ClientHello to determine the destination and tunnel blindly
- Perform TLS interception with a local CA certificate installed on all clients
Option 1 allows routing decisions without decryption. Option 2 enables full content inspection but requires certificate distribution and breaks certificate pinning in applications.
Choosing the Right Proxy Architecture
| Need | Solution |
|---|---|
| Load balance HTTP traffic | Reverse proxy (NGINX, Envoy) |
| Load balance TCP traffic with client IP | HAProxy + PROXY Protocol |
| Corporate internet access control | Forward proxy (Squid, Zscaler) |
| Tunnel arbitrary protocols securely | SOCKS5 (ssh -D) |
| Debug HTTPS traffic locally | mitmproxy |
| CDN / global edge caching | Reverse proxy at scale (Cloudflare, Fastly) |
The proxy landscape converges at scale: modern service meshes (Istio, Linkerd) embed reverse proxies (Envoy) as sidecars next to every service, proxying both inbound and outbound traffic for observability, mTLS, and traffic management. The "proxy" is no longer a single chokepoint — it is distributed across the entire infrastructure.
Key Points
- •A forward proxy acts on behalf of the client — the server sees the proxy's IP, not the client's. A reverse proxy acts on behalf of the server — the client sees the proxy's IP, not the server's.
- •HTTP CONNECT creates an opaque TCP tunnel through a forward proxy. The proxy relays bytes without inspection, which is how HTTPS works through corporate proxies — the proxy never sees the encrypted content.
- •SOCKS5 operates at Layer 4 (transport), making it protocol-agnostic. It can tunnel HTTP, SSH, database connections, or any TCP/UDP traffic — unlike HTTP proxies which only understand HTTP.
- •The PROXY Protocol (v1 and v2) solves the client IP preservation problem for L4 load balancers. Without it, HAProxy, AWS NLB, and similar L4 proxies replace the client IP with the proxy's IP in the TCP header.
- •Transparent proxies intercept traffic without client configuration — the client does not know it is being proxied. Explicit proxies require client configuration (browser proxy settings, HTTP_PROXY env var).
Key Components
| Component | Role |
|---|---|
| Forward Proxy | Sits between clients and the internet, forwarding outbound requests on behalf of clients — used for access control, caching, and anonymization |
| Reverse Proxy | Sits in front of origin servers, receiving inbound requests from the internet and routing them to the appropriate backend — used for load balancing, TLS termination, and caching |
| SOCKS5 Proxy | A protocol-agnostic proxy that operates at the transport layer, tunneling any TCP or UDP traffic without inspecting or understanding the application protocol |
| HTTP CONNECT Method | An HTTP method that converts a forward proxy connection into a raw TCP tunnel, enabling the client to perform TLS handshakes through the proxy without the proxy decrypting traffic |
| HAProxy PROXY Protocol | A header prepended to the TCP connection that preserves the original client IP and port through L4 proxies and load balancers that would otherwise lose this information |
When to Use
Deploy a reverse proxy (NGINX, Envoy, Caddy) in front of every production web service for TLS termination, load balancing, and request routing. Use forward proxies for corporate egress control and compliance. Use SOCKS5 for protocol-agnostic tunneling through restricted networks. Enable PROXY Protocol on L4 load balancers when backend services need the real client IP.
Tool Comparison
| Tool | Type | Best For | Scale |
|---|---|---|---|
| Squid | Open Source | Forward proxy with caching, access control, and SSL bumping — the standard choice for corporate internet gateways and content filtering | Small-Enterprise |
| NGINX | Open Source | Reverse proxy with load balancing, TLS termination, and caching — handles millions of concurrent connections with event-driven architecture | Small-Enterprise |
| HAProxy | Open Source | High-performance L4/L7 load balancer with PROXY Protocol support — excels at TCP proxying where connection metadata preservation is critical | Medium-Enterprise |
| mitmproxy | Open Source | Interactive HTTPS proxy for debugging and testing — performs TLS interception with a local CA to inspect encrypted traffic during development | Small |
Debug Checklist
- Check X-Forwarded-For header: curl -v through the proxy chain and verify each proxy appends its IP — a missing or single-value XFF indicates a proxy is not configured to forward client identity.
- Test PROXY Protocol: tcpdump on the backend shows the PROXY header prepended to the TCP stream — if the backend expects PROXY Protocol but it is not sent, connections fail immediately.
- Verify reverse proxy routing: curl -H 'Host: target.example.com' http://proxy-ip confirms the reverse proxy routes based on the Host header — wrong routing means the Host header is not being matched.
- Debug SOCKS5 connectivity: curl --socks5 127.0.0.1:1080 http://target tests the SOCKS5 tunnel end-to-end — connection refused means the SOCKS proxy is not running or not listening.
- Inspect TLS termination: openssl s_client -connect proxy:443 shows the proxy's certificate, not the backend's — if the backend cert appears, TLS is not being terminated at the proxy.
Common Mistakes
- Using a forward proxy to cache HTTPS traffic without understanding the implications. HTTPS through CONNECT creates an opaque tunnel — the proxy cannot cache what it cannot see without performing TLS interception (MITM).
- Forgetting to set X-Forwarded-For and X-Real-IP headers in reverse proxy configurations. Without these, the application sees every request as coming from the proxy's IP, breaking rate limiting, geo-location, and audit logging.
- Enabling PROXY Protocol on a listener that also accepts direct connections. PROXY Protocol prepends a binary or text header — clients connecting directly (without the header) get malformed request errors.
- Configuring SOCKS5 proxy without authentication in production. An open SOCKS proxy becomes a relay for spam, attacks, and data exfiltration — a liability that gets the proxy's IP blacklisted.
- Assuming a reverse proxy adds security by default. A misconfigured reverse proxy that passes through Host headers, allows request smuggling, or leaks internal paths can amplify vulnerabilities rather than mitigate them.
Real World Usage
- •Cloudflare operates the world's largest reverse proxy network, sitting in front of millions of websites. All requests hit Cloudflare's edge first, which handles DDoS mitigation, WAF, caching, and TLS termination before forwarding to origin.
- •Corporate networks use Squid or Zscaler as forward proxies to enforce internet access policies — blocking categories of sites, scanning downloads for malware, and logging all outbound HTTP traffic for compliance.
- •SSH over SOCKS5 is a common pattern for reaching private network resources. Running ssh -D 1080 bastion creates a local SOCKS5 proxy, and all traffic routed through it appears to originate from the bastion host inside the private network.
- •AWS Network Load Balancer uses PROXY Protocol v2 to preserve client IPs for TCP-passthrough targets. Without PROXY Protocol enabled, backend services behind NLB see the NLB's private IP as the source of every connection.