Per IP Rate Limiting: Anonymous Traffic Protection

When You Do Not Know Who They Are
Per user limits require authenticated identity. But what about login pages, signup flows, public APIs, or any endpoint that anyone can hit without authenticating? You need a fallback identifier, and the IP address is the primary option for anonymous traffic. Per IP limiting is essential for protecting unauthenticated endpoints from abuse.
How IP Extraction Works
Extract the source IP from the request. For direct connections, use the socket remote address. Behind proxies/load balancers, check X-Forwarded-For header (the leftmost IP is typically the original client) or X-Real-IP if your proxy sets it. Warning: these headers can be spoofed. Only trust them if your infrastructure guarantees they are set correctly by a trusted proxy.
The NAT Problem
Many users share one IP. Corporate offices, universities, coffee shops, mobile carrier NAT can have 10,000+ users behind one IP. If you limit that IP to 100 requests/minute, legitimate users suffer. Set IP limits high enough for shared scenarios (say 1,000/minute) or use IP rate limiting only for abuse scenarios, not primary quota management.
Best Use Cases
Login endpoints: limit to 10/minute per IP to prevent credential stuffing. Signup: limit to 5/hour to prevent account spam. Public search: limit to 100/minute to prevent scraping. Password reset: limit to 3/hour to prevent enumeration. These are protective limits, not usage quotas.
Combining with User Limits
For authenticated endpoints, check both: per user (primary quota) and per IP (abuse protection). A legitimate user hitting per IP limits is unusual and worth investigating. For unauthenticated endpoints, IP is your only option. Implement adaptive limits: start generous, tighten for IPs showing suspicious patterns (failed logins, error rates, unusual request patterns).

💡 Key Takeaways

✓Bluesky enforces 3,000 API calls per 5 minutes per IP globally; with 3,000 customers behind one corporate proxy, each averages only 1 operation per 5 minutes, forcing workarounds like multiple IPs

✓NAT and CGNAT scenarios mean thousands of legitimate users often share a single public IP address, making strict per IP limits punish entire organizations for one abusive user

✓Set per IP thresholds 10x to 100x higher than per user limits to account for shared IPs: if per user is 100 requests per minute, set per IP to 1,000 or 10,000 requests per minute

✓Memory scales with unique IP count: at 10 million unique IPs in a 5 minute window with 16 bytes per counter, expect roughly 160 megabytes of state storage

✓IPv6 privacy extensions and vast address space allow attackers to rotate IPs easily, reducing the effectiveness of IP based blocking without additional signals

✓Per IP limiting works best as a pre authentication DDoS shield combined with allowlists for known good sources like monitoring systems and partner networks

📌 Interview Tips

1GitHub applies 60 requests per hour per IP for unauthenticated clients, rising to 5,000 per hour once authenticated with a token, showing tiered protection

2Extract IP from X Forwarded For header by taking the leftmost untrusted address to prevent spoofing: if header is "1.2.3.4, 5.6.7.8, 9.10.11.12" and your proxy is 9.10.11.12, use 5.6.7.8 as the client IP

← Back to Rate Limit Strategies (Per-User, Per-IP, Global) Overview