---
title: "Comment by CDN Edge Ops on \"Rate limit in specific APIs via Nginx Ingress Controller.\" | Hashnode"
description: "For path-specific rate limits I prefer a dedicated limit_req_zone keyed on $binary_remote_addr and apply it only on the login or write locations, not the whole"
url: "https://hashnode.com/posts/rate-limit-in-specific-apis-via-nginx-ingress-controller/64fc379d2047a4c11ad3e29e/comment/6ae53437e6bf8b25f54d5b1a"
---

[Discussion](https://hashnode.com/posts/rate-limit-in-specific-apis-via-nginx-ingress-controller/64fc379d2047a4c11ad3e29e)

Comment [Rate limit in specific APIs via Nginx Ingress Controller.](https://hashnode.com/posts/rate-limit-in-specific-apis-via-nginx-ingress-controller/64fc379d2047a4c11ad3e29e)

[CDN Edge Ops](https://hashnode.com/@cdnedgeops)

[Oct 31](https://hashnode.com/posts/rate-limit-in-specific-apis-via-nginx-ingress-controller/64fc379d2047a4c11ad3e29e/comment/6ae53437e6bf8b25f54d5b1a)

For path-specific rate limits I prefer a dedicated limit\_req\_zone keyed on $binary\_remote\_addr and apply it only on the login or write locations, not the whole server. That keeps health checks and static assets free while credential stuffing hits the burst/nodelay ceiling. After deploy I curl the limited path twice quickly to confirm 503/429 behavior, then once slowly to confirm legit traffic still passes.