Nginx 主动设置状态码可提升业务语义表达：用429配合limit_conn_status限流、proxy_cache_valid按状态码差异化缓存、error_page定制响应、stub_status暴露运行指标。
在 Nginx 中主动设置状态码，不是为了“报错”，而是让响应更贴合业务语义——比如用 429 明确表示连接过载，用 301/302 区分永久或临时跳转，用 404 配合自定义页面提升用户体验。关键在于选对指令、放对位置、配好上下文。
用 limit_conn_status 统一控制连接超限状态码
当启用 limit_conn 限制单 IP 连接数时，Nginx 默认返回 503。若希望更精准表达“请求过于频繁”，可直接改用 429 Too Many Requests：
- 必须使用 Nginx 1.7.12 及以上版本（推荐 1.20+），执行
nginx -v确认 - 在
http或server块中，紧随limit_conn_zone后声明：limit_conn_status 429; - 该设置仅影响
limit_conn触发的拒绝，不作用于限速（limit_rate）或请求数限制（limit_req） - 如需返回 JSON 提示，需额外配合
error_page 429 /429.json;和对应 location 块
用 proxy_cache_valid 按状态码差异化缓存
后端返回不同状态码，代表不同业务含义，缓存策略也应区别对待：
-
proxy_cache_valid 200 301 302 10m;→ 成功和重定向响应，适合中长期缓存 -
proxy_cache_valid 404 30s;→ “资源不存在”结果不宜缓太久，避免掩盖新上线内容 -
proxy_cache_valid 500 502 503 504 10s;→ 故障类错误短时缓存，缓解雪崩，再配合proxy_cache_use_stale提升容错 -
proxy_cache_valid any 5s;→ 兜底规则，确保未显式声明的状态码也有默认缓存期 - 注意：该指令生效需同时满足三项——
proxy_cache_path已定义、proxy_cache在 location 中启用、上游响应本身可缓存（如无Set-Cookie或Cache-Control: no-store）
用 error_page 实现状态码驱动的响应定制
error_page 是将特定状态码映射到自定义行为的核心机制：
- 返回静态页：
error_page 404 /404.html;+location = /404.html { root /usr/share/nginx/html; internal; }，浏览器 URL 不变，状态码仍为 404 - 触发重定向：
error_page 404 = @moved;+location @moved { return 301 https://example.com/home; }，状态码变为 301，URL 自动更新 - 代理后端错误拦截：反向代理场景下，必须加
proxy_intercept_errors on;，否则后端返回的 404 不会被 Nginx 捕获 - 多个状态码可合并处理：
error_page 500 502 503 504 /50x.html;，但 404 通常单独配置，因语义和处理逻辑差异大
用 stub_status 暴露服务运行状态供监控
这不是设置业务状态码，而是暴露 Nginx 自身运行指标，便于运维判断负载瓶颈：
- 编译时需启用
--with-http_stub_status_module模块 - 在 server 块中配置：
location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } - 返回字段含
Active connections（当前活跃连接）、accepts/handled/requests（累计统计）、Reading/Writing/Waiting（各阶段连接数） - 常被 Prometheus、Zabbix 等工具抓取，用于绘制连接数趋势、请求速率、错误率等核心 SLO 指标
