这确实是个戳中HTTP规范和实际工具设计差异的好问题——从RFC定义来看，429 Too Many Requests 完全是为限流场景量身打造的状态码，Nginx选择503作为默认值，主要有几个历史和设计层面的考量：

• 历史兼容性优先：Nginx的核心限流模块（limit_conn 和 limit_req）早在HTTP 429状态码正式标准化之前就已经存在了。429是2012年才在RFC 6585中定义的，而在此之前，Nginx已经采用503 Service Unavailable 作为限流时的响应码——在没有专门限流状态码的年代，503是最贴合“服务暂时无法处理请求”这个场景的选择。为了不破坏大量现有用户的配置逻辑和依赖，官方后续版本一直保留了这个默认行为。

• 语义的宽泛适配性：503的语义本身更宽泛，除了限流，还可以覆盖服务维护、资源耗尽等多种临时不可用场景。Nginx限流的核心目的是保护服务器资源，防止过载崩溃，从这个角度看，返回“服务不可用”也符合逻辑——当请求量超出服务器承载上限时，服务确实暂时无法处理更多请求，用503也能传递“请稍后重试”的核心信号。

• 预留自定义灵活性：正如你注意到的，Nginx（包括Ingress Controller）并没有强制要求用503，而是提供了自定义响应码的选项。比如limit-req-status-code参数就允许你把限流响应改成符合规范的429，官方默认值只是兼顾了历史习惯和通用场景，同时给用户留足了适配自身业务需求的空间。

补充下你提到的相关定义：

HTTP规范说明：HTTP 429 Too Many Requests响应状态码表示用户在给定时间内发送了过多请求（即“限流”场景）。
Nginx Ingress限流注解默认行为：

• nginx.ingress.kubernetes.io/limit-connections：单个IP超过允许的并发连接数时，返回503错误
• nginx.ingress.kubernetes.io/limit-rps：单个IP每秒请求数超过限制时，默认返回503，可通过limit-req-status-code修改响应码

备注：内容来源于stack exchange，提问作者Marc Wittke