Introduction

Cloudflare Rate Limiting protects against abusive traffic by blocking requests that exceed thresholds. However, legitimate traffic can trigger blocks when thresholds are too aggressive, URL patterns match unintended endpoints, or legitimate high-volume clients (APIs, CDN syncs) exceed limits. Rate limiting rules need careful tuning to block attackers while allowing valid traffic patterns.

Symptoms

  • Legitimate users seeing 429 Too Many Requests or 1015 Access Denied
  • API clients blocked during normal high-volume operations
  • CDN synchronization or webhook delivery blocked
  • Rate limiting triggered on login or search pages with normal use
  • Specific IP ranges blocked despite being trusted sources
  • Error page shows "You are being rate limited"

Common Causes

  • Rate limit threshold set too low for normal traffic volume
  • URL pattern matching unintended endpoints (wildcards)
  • Rate limit counting all requests instead of specific methods
  • Missing IP whitelisting for trusted sources
  • Session-based rate limiting not accounting for shared IPs (NAT, proxies)
  • Rate limit duration too long causing extended blocks
  • Bot Fight Mode interfering with legitimate automation

Step-by-Step Fix

  1. 1.Identify which rate limiting rule is triggering:

Navigate to: Cloudflare Dashboard > Security > WAF > Rate Limiting Rules

Check: - Rule name and description - URL path pattern - Threshold (requests per period) - Duration of block - Action (Block, Challenge, Log)

  1. 1.Review rate limiting logs:

```bash # Check Security Events # Dashboard > Security > Events

# Filter by: # - Action: Rate Limit # - Rule ID: specific rate limit rule # - Time range: when issue occurred

# Look at request patterns that triggered block ```

  1. 1.Analyze legitimate traffic patterns:

```bash # Check your normal request volume # For APIs, check documentation or logs

# Example: Normal API burst curl -s "https://api.yourdomain.com/logs" | wc -l

# Determine realistic threshold: # - Normal burst: 50 requests in 10 seconds # - Set threshold above normal: 100 requests in 10 seconds ```

  1. 1.Adjust rate limit threshold:

In rate limiting rule: - Increase request count threshold - Increase time window (e.g., 60 requests per 2 minutes instead of per 1 minute) - Match actual traffic patterns

bash
# Good threshold examples:
- API endpoint: 200 requests per minute
- Login page: 20 requests per minute (lower for security)
- Search: 100 requests per minute
- Static assets: No rate limit needed
  1. 1.Narrow URL pattern to specific endpoints:

``` # Avoid overly broad patterns: # BAD: yourdomain.com/* (matches everything) # BAD: yourdomain.com/api/* (matches all API endpoints)

# Better specific patterns: # GOOD: yourdomain.com/api/v1/login # GOOD: yourdomain.com/api/v1/search # GOOD: yourdomain.com/admin/login ```

  1. 1.Add IP whitelisting for trusted sources:

In rate limiting rule: - Add "Skip" action for trusted IPs - Or create separate WAF rule to skip rate limit

bash
# Via API - create skip rule
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/rules" \
  -H "Authorization: Bearer API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "description": "Skip rate limit for trusted IPs",
    "expression": "(ip.src in {192.0.2.1 192.0.2.2})",
    "action": "skip",
    "products": ["rateLimit"]
  }'
  1. 1.Whitelist common legitimate sources:
bash
# IPs to consider whitelisting:
# - Your office/corporate IP ranges
# - CI/CD pipeline IPs
# - CDN origin pull IPs
# - Known webhook sources (Stripe, GitHub, etc.)
# - Monitoring services (Pingdom, Datadog, etc.)
  1. 1.Configure request counting properly:

In rate limiting rule options: - Count only specific HTTP methods if needed - Don't count OPTIONS requests (CORS preflight) - Count requests to specific paths only

bash
# Example: Rate limit POST requests only
# Expression: (http.request.method eq "POST")
  1. 1.Reduce block duration for temporary issues:

In rate limiting rule: - Set block duration shorter (10 minutes vs 1 hour) - Allows legitimate users to retry sooner - Use "Challenge" action instead of "Block" for suspicious patterns

  1. 1.Check Bot Fight Mode settings:

Navigate to: Security > Bots

``` # Bot Fight Mode can block legitimate automation # Consider: # - Super Bot Fight Mode: aggressive, may block APIs # - Bot Management: granular control

# For API traffic: # - Whitelist known good bots # - Use JavaScript detection sparingly ```

  1. 1.Test with adjusted settings:

```bash # Test rate limiting behavior for i in {1..50}; do curl -s -o /dev/null -w "%{http_code}\n" https://yourdomain.com/api/test done

# Should see 200s, not 429/1015, within threshold ```

  1. 1.Implement application-level rate limiting:

```javascript // For APIs, add application-level rate limiting // This gives more control than Cloudflare blanket rules

const rateLimiter = { windowMs: 60 * 1000, // 1 minute max: 100, // 100 requests per minute keyGenerator: (req) => req.ip, // or req.user.id }; ```

Verification

After applying fixes:

  1. 1.Normal traffic patterns don't trigger rate limits
  2. 2.Security Events show no false positive blocks
  3. 3.API clients can operate within normal burst limits
  4. 4.Trusted IPs bypass rate limiting via whitelist
  5. 5.Actual attack patterns still trigger blocks