Debugging 429 errors and header stripping when routing traffic from mobile script clients?

1

Hi everyone,
I’m hoping someone here might have some insight into a specific rate-limiting behavior I’m seeing with the Kong Gateway. I’m currently building a small analytics middleware that sits between a mobile application and our backend database. We are using the Kong Rate Limiting plugin to prevent abuse, but I’ve run into a strange edge case with a specific group of power users.

These users are running delta scripts to automate data reporting from within a mobile sandbox environment. I’m noticing that when the requests originate from these delta scripts, Kong intermittently returns 429 Too Many Requests, even though the total request count for that specific IP is well below the threshold we’ve set in our YAML config.

I have a suspicion that the way the mobile environment handles connection pooling or keep-alive headers might be causing Kong to misinterpret the request frequency or reuse a consumer identity in a way that triggers the limit prematurely. Has anyone else experienced issues with Kong’s policy: local vs policy: redis when handling traffic from automated client-side executors like this? I’m also seeing some custom headers being stripped before they reach the upstream service, and I can’t figure out if it’s the executor’s networking library or a default Kong transformation plugin that’s causing the cleanup. If anyone has experience fine-tuning Kong to handle high-velocity traffic from mobile-based automation without accidentally flagging it as a DDoS attempt, I’d love to hear your thoughts on the best plugin configuration to use!

2

@merris009 Thank you for the excellent question. I wish I was able to help you directly but I do not have experience with the specifics of this particular issue. I passed your question through our Developer site AI Agent and pasted a response here in hopes that it could clue you in to some known behavior or other considerations. If you want to experiment with the documentation AI agent you can find it on the docs home page: https://developer.konghq.com/ If you continue to have issues please respond back I can try and find assistance.

Rate Limiting Strategy: local vs redis

Your observation about intermittent 429s despite being below the threshold is a well-known behavior tied to the local policy in Kong’s rate limiting plugins.

Why local causes this

With policy: local, each Kong Gateway node (or Pod) maintains its own independent in-memory counter. Requests are not synchronized across nodes. This means:

  • If your mobile clients’ requests are distributed across multiple Kong nodes, each node tracks its own counter separately.

  • A client could be flagged as over-limit on one node while other nodes show remaining capacity — or conversely, a client could exceed the global limit because each node only enforces its own local threshold. [Scale to multiple pods]

This is likely what you’re seeing: the counters diverge across nodes, causing inconsistent 429 responses even when the total request count appears to be under the limit. [Rate Limiting Strategies]

Recommendations

1. Switch to redis policy for accuracy

The redis strategy stores counters on a shared Redis server, synchronized across all nodes. This gives you accurate, consistent enforcement regardless of which node handles the request. [Rate Limiting Strategies]

For maximum accuracy, set config.sync_rate to 0 (synchronous behavior). [Rate Limiting plugin strategies]

2. Redis fallback behavior to be aware of

If your Redis connection drops, the plugin automatically falls back to local counters and re-syncs when the connection is restored. During this period, users may exceed the global limit (but will still be limited per node). [Fallback from Redis]

3. If you must use local

Consider placing a consistent-hashing load balancer in front of Kong. This ensures a given client (by IP or consumer identity) always routes to the same Kong node, reducing counter divergence. [Backend protection]

You can also set the local limit higher than your actual threshold to account for multi-node distribution. For example, with a 5-node cluster and a 100 req/s limit, setting local to ~30 req/s per node is a common approach. [Backend protection]

Regarding the custom headers being stripped, the knowledge sources available to me don’t contain information about header transformation behavior or connection pooling interactions. That would be worth investigating separately — potentially in Kong’s request/response transformer plugin documentation or your networking library’s behavior.