Who chose it? Who does it pretend to be?
Clients configure a forward proxy and send it the full URL. The site points DNS at a reverse proxy, so clients send only the path.
The bank allowlists two IPs. Your pods change IP every deploy.
Send partner calls through egress proxies with fixed IPs. They also refuse non-public addresses, so a webhook can’t fetch cloud credentials from 169.254.169.254.
Decrypt HTTPS at the egress proxy?
Bad: Intercept TLS
Clients verify only the proxy, whose CA key can impersonate any site.
Good: CONNECT tunnel
One TLS session, end to end. Host and port still feed the allowlist.
40/s
max for 64 workers serving slow phones directly
Each worker waits 1.6 s per 200 KB page on a 1 Mbps phone. A buffering proxy takes it in 1.6 ms and frees the worker.
10,000 clients keep mostly idle connections open. Does your app need 10,000 too?
Little’s law
No. 2,000/s × 25 ms = 50 in flight. The proxy holds the clients; 4 × 50 = 200 pooled connections leave ample headroom.
Any client can type X-Forwarded-For. Read it from the right.
Each proxy appends who connected to it. Skip the addresses of proxies you run; the first one left is the client, never the leftmost.
Where proxies bite
- Run at least two, sized to lose one
- Timeouts shrink inward: client 10 s, proxy 9 s
- Turn off buffering for SSE and streams
- Reject requests with both Content-Length and Transfer-Encoding
Remember
A forward proxy hides the clients from the server; a reverse proxy hides the servers from the clients. One gives partners fixed egress IPs; the other ends TLS and routes by path.