ntex-ratelimiter
A rate limiting middleware for the ntex web framework.
Installation
tokio(default): Enable Tokio runtime supportsmol: Enable smol runtime support (smol is the maintained successor of async-std)json(default): Enable JSON serialization for error responses
[]
# Default features (tokio + json)
= "^0.3"
# With smol instead of tokio
= { = "^0.3", = false, = ["smol", "json"] }
# Minimal build without JSON support
= { = "^0.3", = false, = ["tokio"] }
Usage
The primary components are RateLimiter and RateLimit.
RateLimiter: Manages the rate limiting logic and state. You create an instance of this, often shared across your application.RateLimit: Thentexmiddleware that wraps your services and applies the rate limiting rules defined by aRateLimiterinstance.
Quick Start
use web;
use ;
async
Advanced Configuration
For more control over the rate limiter behavior:
use ;
use Duration;
let config = RateLimiterConfig ;
let limiter = with_config;
// Get statistics
let stats = limiter.stats;
println!;
How It Works
This middleware uses the token bucket algorithm for rate limiting:
- Each client IP gets a token bucket with a configured capacity
- Tokens are consumed on each request
- Tokens are refilled at a constant rate based on the time window
- When the bucket is empty, requests are rate limited
Client IP Detection
By default the middleware uses only the peer socket address — zero-allocation and not spoofable by the client. Set trust_proxy_headers = true in RateLimiterConfig to also honor proxy headers; do this only behind a trusted proxy that overwrites (not appends to) them, since clients can otherwise forge these headers to bypass limiting:
X-Forwarded-Forheader (first IP, only whentrust_proxy_headers = true)X-Real-IPheader (only whentrust_proxy_headers = true)- Peer socket address (default and fallback)
⚠️ Behind a reverse proxy / load balancer, leaving
trust_proxy_headers = falsemeans the peer address is the proxy's for every request, so all clients share a single bucket and are throttled together. Settrust_proxy_headers = truein that deployment (the proxy must overwrite the headers).
Memory Safety
The number of tracked client buckets is bounded by max_entries (default 100_000). Once the cap is reached, previously-unseen clients share a single overflow bucket (still rate-limited, and itself counted toward the cap), so an attacker rotating source identifiers — whether real IPs or forged proxy headers — cannot exhaust memory. The bound is best-effort: concurrent requests may transiently exceed it by roughly the number in flight, but never unboundedly.
Response Headers
The middleware adds these headers to all responses:
| Header | Description |
|---|---|
x-ratelimit-remaining |
Number of requests remaining in current window |
x-ratelimit-limit |
Total request limit for the window |
x-ratelimit-reset |
Unix timestamp when the rate limit resets |
Error Response
When rate limits are exceeded, a 429 Too Many Requests response is returned:
Module Structure
limiter: Contains the coreRateLimiterlogic,TokenBucketimplementation,RateLimiterConfig, and theRateLimitntex middleware.
Contributing
Contributions are welcome! Please feel free to open an issue or submit a pull request.
License
MIT All contributor.