By Mojahid Ul HaqueUpdated May 11, 20268 min read

Rate Limiting by IP in Node.js: What You Need to Know First

A practical guide to IP-based rate limiting in Node.js — covering express-rate-limit, proxy trust, shared IPs, and when IP limits are not enough.

VPN and Proxy IP Checker

Basic Express setup

A simple TypeScript setup with `express-rate-limit` can protect public endpoints quickly: `app.use(rateLimit({ windowMs: 60_000, limit: 100, standardHeaders: true, legacyHeaders: false }));`. Start with conservative limits and monitor real traffic before tightening them.

Rate limits should match endpoint cost. A login endpoint, password reset flow, search API, and static page do not need the same threshold or response behavior.

Proxy trust and shared IPs

If your Node.js app sits behind a proxy, configure Express with the correct trust setting, such as `app.set("trust proxy", 1)` when there is exactly one trusted proxy hop. Without this, `req.ip` may show the load balancer instead of the client.

Be careful with CGNAT, offices, schools, and public Wi-Fi because many legitimate users can share one IP. A strict IP-only limit can accidentally block unrelated people.

Beyond IP-only limits

Combine IP limits with account, API token, session, device, route, and organization limits. Authenticated APIs often work better with token or account limits, while anonymous endpoints still benefit from IP throttling.

Choose a fixed window for simple protection or a sliding window/token bucket for smoother behavior. Use Crafzo during investigations to understand whether a noisy IP is residential, mobile, hosting, VPN, or already risky.

Implementation details developers should not skip

A reliable IP workflow starts with normalization and validation. Accept both IPv4 and IPv6, reject malformed input, and decide how your application should treat private, loopback, link-local, and reserved addresses before calling external services.

Logging should preserve enough context to explain a decision later: timestamp, normalized IP, endpoint, account or token when appropriate, risk fields, and the action taken. Avoid logging unrelated personal data simply because it is available.

Production enforcement works best when IP intelligence is one input into a broader policy engine. Combine IP risk with account limits, device trust, authentication signals, request cost, and business-specific rules.

For a live example, run the relevant address through Crafzo IP Lookup or open the VPN and Proxy IP Checker to compare the article guidance with real lookup fields.

Signals to compare before acting

Signal	What to check	Practical use
Validation	Does the input parse as IPv4 or IPv6, and is it public when public lookup is required?	Prevents wasted API calls and confusing results.
Normalization	Are IPv6 compression and string casing handled consistently?	Makes logs, cache keys, and rules easier to compare.
Caching	Can non-sensitive lookup fields be cached briefly without hiding freshness problems?	Reduces cost and latency while preserving correctness.
Fallbacks	What happens when an enrichment provider times out or rate-limits?	Keeps user workflows resilient during provider issues.

Practical checklist

Validate IP input before external requests.
Design fallbacks for rate limits and provider outages.
Log reason codes for automated decisions.
Test IPv6 paths, not only IPv4 examples.

Frequently Asked Questions

How do I rate limit by IP in Express?

Use middleware such as `express-rate-limit`, then make sure `req.ip` reflects the real client behind your proxy. Configure `trust proxy` carefully before relying on the value.

What happens if many users share one IP?

They can all hit the same limit even if only one user is active or abusive. For shared networks, combine IP limits with account, session, or token-level limits.