Troubleshoot API gateway rate limits not triggering at the edge

If your API gateway rate limits are not triggering at the edge, the issue is usually one of these:

1) Confirm where the limit is enforced

Some gateways have separate controls for:

• Edge / CDN / reverse proxy
• Gateway layer
• Upstream service
• Per-route / per-consumer / per-IP limits

Make sure the policy is attached to the edge-facing listener/route, not only to an upstream service.

---

2) Check the rate limit algorithm and threshold

Verify:

• The limit is actually enabled
• The correct window is configured (e.g., 10 req/s, 100 req/min)
• The burst setting isn’t masking the behavior
• You’re testing with enough volume to exceed the threshold

Example issue:

• Config is 1000/min, but your test only sends 50/min

---

3) Look for bypass paths

Requests may avoid the edge limiter if:

• There’s a direct origin/backend path
• Internal traffic is exempted
• Health check or service account traffic is excluded
• A separate host/path doesn’t have the same policy attached

---

4) Validate client identity used by the limiter

Rate limiters often key on:

• IP address
• API key
• JWT subject
• Consumer ID
• X-Forwarded-For header

Problems happen when:

• All traffic appears to come from one proxy IP
• The gateway uses the wrong header
• X-Forwarded-For isn’t trusted/parsed correctly
• NAT/CDN collapses many clients into one identity or the opposite

---

5) Check if caching is preventing requests from reaching the limiter

If responses are cached at the edge:

• Subsequent requests may be served from cache
• The gateway may never see enough origin hits to trip the limit

Test with:

• Cache-Control: no-cache
• A unique query param
• An endpoint that is not cached

---

6) Inspect distributed rate limiting configuration

In multi-node setups:

• Each node may enforce its own local counter
• The counter store (Redis, Memcached, etc.) may be unavailable or misconfigured
• Sticky sessions may skew counts

If the limiter is meant to be global, confirm:

• Shared backend store is connected
• Nodes can write/read counters
• No fallback to local-only mode

---

7) Review error handling and logging

Look for:

• 429 responses in gateway logs
• Rate-limit headers:
  • X-RateLimit-Limit
  • X-RateLimit-Remaining
  • X-RateLimit-Reset
• Debug logs showing counter increments

If headers are missing, the policy may not be executed.

---

8) Confirm policy ordering

Some gateways evaluate:

• Auth before rate limit
• WAF before rate limit
• Routing before rate limit
• Transformations before limit key extraction

If the request is rejected or rerouted earlier, the rate limit may never run.

---

9) Test with a simple reproducible case

Use a single client and send a burst:

for i in {1..50}; do
  curl -s -o /dev/null -w "%{http_code}\n" https://api.example.com/test
done

If possible:

• Disable retries
• Disable caching
• Use one identity
• Target one edge POP/region

---

10) Edge/CDN-specific issues

If the “edge” includes a CDN or external proxy:

• Rate limits may be configured in the wrong layer
• WAF rules may override or short-circuit
• POP-level propagation delays may mean config hasn’t deployed everywhere
• Geo/IP reputation rules may interfere

---

Quick checklist

• Policy attached to edge route/listener
• Correct threshold/window
• Correct identity key
• No bypass or direct origin access
• No caching masking requests
• Shared counter store working
• Logs show counter increments
• 429s visible in gateway responses

If you want, I can help you troubleshoot this for a specific platform like Kong, Apigee, AWS API Gateway, NGINX, Cloudflare, Akamai, or Envoy.