Rate Limiting Quick Reference¶

A quick reference for every rate limit defined in the shipped rate-limiting.yml preset. See Using Presets for how to include and override it.

Default Limits¶

• General Traffic: 60 requests per minute
• Status Code: 429 (Too Many Requests)
• Expiration: 300 seconds (5 minutes)

Rate Limit Rules by Category¶

Authentication & Security¶

API Endpoints¶

WordPress Specific¶

Forms & User Input¶

Admin & Management¶

File Operations¶

Static Assets (Relaxed)¶

Webhooks¶

Monitoring & Health¶

Feeds & Sitemaps¶

Special Paths¶

Storage Backends¶

Redis (Recommended)¶

Pros: - Extremely fast (in-memory) - Distributed/clustered support - Automatic TTL/expiration - Horizontal scaling - Battle-tested for rate limiting

Cons: - External dependency - Requires Redis server

Use when: - Production environment - Load-balanced/distributed system - High traffic (>1000 req/min) - Need sub-millisecond performance

Database (MySQL/PostgreSQL)¶

Pros: - Uses existing infrastructure - Persistent across restarts - SQL query capabilities - Familiar tooling

Cons: - Slower than Redis - More disk I/O - May impact database performance

Use when: - Already using database - Don't want external dependencies - Moderate traffic (<500 req/min) - Need audit trail

File Storage¶

Pros: - No external dependencies - Simple setup - Works immediately

Cons: - Single server only - Slowest option - File locking overhead - Manual cleanup needed

Use when: - Development/testing - Single server deployment - Low traffic (<100 req/min) - Simple infrastructure

PSR-6 Cache¶

Pros: - Integrates with existing cache - Framework-agnostic - Flexible backend

Cons: - Depends on cache implementation - Performance varies

Use when: - Using Symfony/Laravel with cache - Want to use existing cache layer - Framework integration important

Common Customizations¶

Stricter Login Protection¶

plugins:
  - plugin: "Kanopi\\Firewall\\Plugins\\RateLimit"
    response: block
    weight: 0
    enable: true
    config:
      - path: /login
        rate: 3      # Only 3 attempts
        sample: 600  # Per 10 minutes

Higher API Limits for Premium Tier¶

plugins:
  - plugin: "Kanopi\\Firewall\\Plugins\\RateLimit"
    response: block
    weight: 0
    enable: true
    config:
      - path: /api/premium/*
        rate: 500
        sample: 60

Disable Rate Limiting for Specific Path¶

Remove the path from config or set very high limits:

plugins:
  - plugin: "Kanopi\\Firewall\\Plugins\\RateLimit"
    response: block
    weight: 0
    enable: true
    config:
      - path: /unlimited-endpoint
        rate: 999999
        sample: 60

Custom Endpoint¶

plugins:
  - plugin: "Kanopi\\Firewall\\Plugins\\RateLimit"
    response: block
    weight: 0
    enable: true
    config:
      - path: /my-custom-api
        rate: 50
        sample: 60

Troubleshooting¶

Rate limit not working¶

1. Check storage is configured correctly
2. Verify Redis/Database is accessible
3. Check file permissions (if using file storage)
4. Enable debug logging to see rate limit checks

Too many false positives¶

1. Increase rate limits for affected endpoints
2. Add an IpAddress response: allow plugin entry for trusted sources
3. Increase time window (sample)
4. Check if behind proxy (ensure X-Forwarded-For is trusted)

Performance issues¶

1. Switch to Redis if using file/database
2. Optimize database queries (add indexes)
3. Use connection pooling for database
4. Consider caching layer

Rate limits not resetting¶

1. Check expiration time settings
2. Verify Redis/Database TTL working
3. For file storage, manually clean old entries
4. Check system time is correct

Best Practices¶

1. Start Conservative: Begin with stricter limits, then relax if needed
2. Monitor First: Run in log-only mode initially, then enable blocking
3. Bypass Trusted IPs: Whitelist monitoring services, internal IPs
4. Different Tiers: Use different limits for authenticated/premium users
5. Progressive Limits: Start lenient, tighten after detecting abuse
6. Clean Up: Regularly clean old rate limit data (especially file storage)
7. Test Thoroughly: Test rate limits in staging before production
8. Document Changes: Keep track of customizations for troubleshooting

Performance Benchmarks¶

Approximate overhead per request:

• Redis: < 1ms
• Database: 2-5ms
• File: 5-20ms
• Cache: 1-3ms (varies by implementation)

For high-traffic sites (>1000 req/sec), Redis is strongly recommended.