Your rate limiter is broken behind a tunnel — the X-Forwarded-For problem

You put your app behind a tunnel (or any reverse proxy) to test Congratulations, you've met the X-Forwarded-For problem. When a request flows through a tunnel, the TCP connection to your app comes from the relay, not the real client. So request.remote_addr — The consequences are quiet and nasty: Your rate limiter now rate-limits the relay, not the client. One aggressive user trips the limit and everyone gets blocked. Or worse, the The proxy already tells you the real client IP — in the X-Forwarded-For header. Every framework has a setting to trust it. ProxyFix. Express: app.set('trust proxy', ...). Rails, Here's the trap: trust that header blindly and anyone can spoof it. A client can send X-Forwarded-For: 1.2.3.4 directly, and if your The correct setup has two halves: 1. Trust `X-Forwarded-For` only when the immediate connection comes from a proxy you control (your tunnel relay, your load balancer). Most frameworks express this as "trusted proxies" — a list of proxy IPs whose forwarded headers you believe. Set it. It's five minutes of Tunnels used to be a demo-day tool. Now they're how teams test webhooks, preview for clients, and let AI agents reach local If you're picking a tunnel, this is one of the details that separates serious ones: does the relay set and document its forwarded headers? We 21tunnel to pass real client IPs through Your rate limiter will thank you.