nginx 无法直接修改上游状态码，但可通过 proxy_intercept_errors + error_page 实现动态重映射；支持 =n 覆盖、map 映射、lua 动态判断等方式，需注意缓存、循环及日志区分。
在 Nginx 中，状态码重映射不是指修改上游返回的真实状态码，而是控制最终发给客户端的响应状态码。核心在于：Nginx 本身不支持直接“重写”后端返回的状态码（如把 502 改成 404），但可通过 error_page、proxy_intercept_errors 和自定义响应等机制，实现语义上等效的重映射效果。
利用 error_page + proxy_intercept_errors 拦截并重定向状态码
这是最常用且符合 Nginx 原生逻辑的方式。关键点是启用错误拦截，再将特定状态码映射到自定义 location 处理，从而发出新状态码：
- 设置
proxy_intercept_errors on;，使 Nginx 对 upstream 返回的 4xx/5xx 响应不再透传，而是尝试匹配error_page - 用
error_page 502 =404 /_404;表示：当上游返回 502 时，内部重定向到/_404这个 location，并以 404 状态码响应 - 对应 location 需明确设置状态码，例如：
location = /_404 { return 404; }或返回自定义页面 - 注意：等号后的数字（如
=404）才是最终发给客户端的状态码；若省略等号，则默认为原错误码（仍为 502）
通过 return 指令配合 map 实现条件化重映射
适用于需根据请求特征（如路径、Header、上游状态）动态决定输出状态码的场景。Nginx 的 map 指令可将变量映射为新值，再结合 return 实现精准控制：
- 先定义映射关系：
map $upstream_http_x_status_code $mapped_status { default 200; "502" 404; "503" 503; }（需开启proxy_pass_request_headers off;并用add_header让上游注入标识） - 更可靠的做法是基于 Nginx 变量（如
$status）或自定义变量判断，例如：map $sent_http_content_type $new_status { ~text/html 200; default 500; } - 在 server 或 location 块中：
if ($mapped_status != "200") { return $mapped_status; }—— 注意return会中断处理流程并立即响应 - 该方式灵活但需谨慎使用
if，避免与 rewrite 规则冲突；建议仅用于简单判定
借助 Lua 模块（ngx_http_lua_module）实现精细控制
当标准配置无法满足复杂逻辑（如依据响应体内容、多次 upstream 调用结果、外部 API 查询等）时，Lua 是可行选择：
- 安装 OpenResty 或编译含 Lua 支持的 Nginx
- 在
access_by_lua_block或header_filter_by_lua_block中读取ngx.status，并在必要时调用ngx.status = 404 - 注意：修改
ngx.status必须在header_filter_by_lua_block阶段（响应头未发送前），且需配合ngx.header.Content-Length = nil避免长度不匹配 - 也可用
content_by_lua_block完全接管响应，但会失去 proxy 缓存等优势，适合兜底或特殊鉴权场景
不推荐的误区与边界说明
有些做法看似能“改状态码”，实则无效或违背设计原则：
-
add_header Status "404 Not Found";不起作用 ——Status是 CGI 协议头，Nginx 不识别，客户端也不会据此修改状态码 -
proxy_set_header无法修改上游返回的状态码，它只影响发给 upstream 的请求头 - 试图用
rewrite捕获状态码 —— rewrite 只处理 URI，不处理响应状态 - 直接修改日志格式中的
$status—— 日志变量反映实际发出的状态码，不能反向控制响应
