proxy_intercept_errors 本身不拦截或替换页面，仅作为开关启用对后端4xx/5xx状态码的接管能力，必须与同作用域的error_page指令配合且响应体非空时才生效。
在 Nginx 中，无法直接“屏蔽返回特定状态码的后端”，因为状态码是后端响应的一部分，Nginx 本身不决定后端返回什么状态码。但你可以通过配置，在 Nginx 层拦截、重写或拒绝那些由后端返回的特定状态码（如 500、404、403 等），从而控制客户端看到的内容或行为。
使用 error_page 拦截并自定义响应
这是最常用的方式：当上游返回指定状态码时，Nginx 跳转到本地处理（如返回空白页、跳转、返回静态内容等）。
- 在 location 或 server 块中添加：error_page 500 502 503 504 /5xx.html;
- 确保 /5xx.html 文件存在（可放在 root 目录下），或用 =200 强制返回 200：error_page 403 =200 /blank.html;
- 注意：error_page 不会阻止后端返回状态码，只是拦截响应并替换内容；原状态码仍可能被记录在 access_log 中，除非用 proxy_intercept_errors on;
启用 proxy_intercept_errors 控制是否透传错误码
该指令决定 Nginx 是否将后端错误响应（如 4xx/5xx）交给 error_page 处理，还是直接透传给客户端。
- 默认为 off，即后端返回什么，客户端就收到什么
- 设为 on 后，Nginx 才会根据 error_page 规则介入：proxy_intercept_errors on;
- 必须配合 error_page 使用，否则开启也无效果
用 return 或 rewrite 主动干预响应流程
适用于更精细控制，比如根据 upstream 响应头或变量做判断（需搭配 map 或第三方模块，原生 Nginx 不支持直接读取后端状态码做 if 判断）。
- 简单场景：所有请求统一返回 444（关闭连接）或 204（无内容）：return 444; 或 return 204;
- 复杂逻辑（如仅对某类路径拦截 500）：需借助 map 定义变量 + add_header 标记，再结合 Lua（via lua-nginx-module）或 OpenResty 实现状态码检测——纯 Nginx 配置做不到运行时读取后端状态码
日志与调试建议
验证配置是否生效，关键看 access log 和 error log：
- 开启 log_format 记录 upstream_status：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $upstream_status';
- 检查 error log 中是否有 upstream sent no valid HTTP/1.0 header 类报错，说明 proxy_intercept_errors 开启但后端未返回完整响应
- 用 curl -I 测试响应头，确认最终返回的状态码是否符合预期
