hello everyone, we've been using self hosted infisical with the infisical operator for the past 3 years, recently we noticed that the operators are getting

connect: connection refused

technically failing to connect to our infisical instance, not all of the requests are being dropped, only some of them, which makes me think that this is a rate limit issue, I've double checked our setup and I'm fairly sure that we don't have a rate limiter anywhere, is there a rate limit configuration on infisical?

Hey @Mohamad Tahir Infisical does have built-in rate limiting on all instances. There's a global 600 req/min per IP limit, and secrets endpoints are capped at 60 req/min per IP. If your operator pods share the same source IP, they all share one bucket. However, "connection refused" is a TCP error, not a rate limit response (that would be HTTP 429). This sounds more like pod restarts or resource exhaustion than rate limiting. Could you please check your Infisical pod logs for 429s to confirm. Let me know! Thanks

Hello, I double checked the infisical and the operator resources and they're both completely fine, no load on them. I meant in the case of DOS attack, if you're flagged as an attacker all your requests will be dropped, and you would get an error like the one shared above. I checked the infisical logs and I can not find any 429 If you'd like we can jump on a quick huddle to check the issue

Thanks for those details . I double-checked our codebase and want to correct my earlier message: self-hosted Infisical applies no rate limiting at all. The limiter only runs on our cloud instances, and there's no IP blocking or DoS-style ban layer anywhere in the app. That also rules us out as the cause here.

connect: connection refused

is a TCP-level error, which Infisical never produces. The most our app returns for abuse is an HTTP 429 or 403, never a refused connection. So the intermittent drops are almost certainly coming from infrastructure in front of the instance: a load balancer or reverse proxy, a WAF or Cloudflare, a Kubernetes NetworkPolicy, or host-level limits like conntrack or SYN backlog exhaustion. Only some requests failing points more toward connection backlog or LB throttling than a hard block. I'd start with the ingress/LB and WAF logs plus host conntrack on the node. Please let me know if there's anything else I can clear up on our side. Thanks!

Hello @Jake Hulberg apologies for the late response, you were right, we figured that the issue was on our end, we resolved it, thanks!