Nginx 无法直接修改上游状态码，但可通过 proxy_intercept_errors + error_page 实现状态码重写；支持 =N 覆盖、Lua 动态判断、map 映射 header 等方式，需注意缓存、循环及日志区分。
Nginx 的 location 块本身不能直接“修改”上游返回的状态码，但可以通过配合 error_page、proxy_intercept_errors 和自定义响应等机制，实现对特定 API 路径的响应状态码进行动态重写或伪装。核心思路是：拦截原始响应 → 判断条件（如 body 内容、header、状态码）→ 触发重定向或自定义错误页 → 返回期望的状态码。
启用代理响应拦截并绑定 error_page
要干预上游返回的状态码，必须让 Nginx 有机会“看到”响应并介入。关键配置是开启 proxy_intercept_errors on，并为需处理的状态码显式声明 error_page：
-
proxy_intercept_errors on：使 Nginx 在收到 4xx/5xx 响应时，不直接透传给客户端，而是尝试查找匹配的error_page指令 -
error_page 404 =200 /api/v1/fallback;：将上游返回的 404 映射为内部重定向到/api/v1/fallback，且最终以 200 状态码返回 - 注意：
=200表示“覆盖状态码为 200”，不是重定向（302），而是透传内容+改状态码
基于响应内容动态判断并重写状态码
仅靠状态码不够灵活？可结合 ngx_http_sub_module（sub_filter）或 OpenResty 的 Lua 脚本做更细粒度控制。例如：上游返回 200，但 body 中含 "code":403，你想对外返回 403：
- 使用 OpenResty +
access_by_lua_block在请求发出前或body_filter_by_lua_block在响应体流中解析 JSON - 示例逻辑：
if ngx.arg[1]:match('"code"%s*:%s*403') then ngx.status = 403 end - 纯 Nginx（无 Lua）下较难实现“读 body 改 status”，此时建议上游规范返回状态码，或用
map+add_header标记再配合前端处理
用 map + proxy_hide_header 实现“伪状态码”兼容层
若无法修改上游，又不想引入 Lua，可用间接方式模拟状态码语义：
- 用
map指令根据 upstream response header（如$upstream_http_x_api_code）映射出目标状态码变量 - 在
location中设置proxy_pass_request_headers off或proxy_hide_header X-API-Code隐藏原始标记 - 配合
error_page和自定义return，例如：error_page 403 = @rewrite_403; location @rewrite_403 { return 403 '{"error":"forbidden"}'; } - 本质是“协议层伪装”——客户端收到真实 403，但内容由 Nginx 生成，与上游解耦
注意事项与典型陷阱
这类操作易引发缓存、调试和可观测性问题，需特别留意：
-
proxy_intercept_errors默认只拦截 400–499 和 500–599；若需拦截 301/302，需手动添加error_page 301 =301 ... - 使用
=N语法时，Nginx 会丢弃上游响应体，改用自定义内容（如return或 error_page 指向的文件），若需保留 body，须用 Lua 或sub_filter替换后再返回 - 避免循环：确保
error_page指向的内部 location 不再触发相同拦截逻辑（例如不要在@fallback中再次 proxy_pass 到同一后端） - 日志中记录原始状态码需依赖
$upstream_status变量，$status是最终返回值，二者不同
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
