proxy_intercept_errors 是拦截开关而非错误页生成器，需与同作用域的error_page成对使用；仅当后端返回≥400状态码、配置对应error_page、启用该指令且响应体非空时才生效。
proxy_intercept_errors 不是错误页生成器，而是一个“拦截开关”——它只决定 Nginx 是否介入后端返回的 4xx/5xx 响应；真正呈现什么内容、是否美观、跳转到哪，全由配套的 error_page 指令和它指向的资源决定。
必须成对出现：proxy_intercept_errors 和 error_page
单独写 proxy_intercept_errors on; 完全无效。它必须与 error_page 在同一作用域（如同一个 location 或其父级 server）中同时存在：
- 在代理块中启用拦截：
proxy_intercept_errors on; - 在同一作用域声明要接管的状态码：
error_page 404 /404.html;或error_page 500 502 503 504 /error.html; - 确保
/404.html这类路径真实存在，且位于 Nginx 可访问的根目录下（如root /var/www/myapp;）
让错误响应真正被拦截的四个前提
Nginx 只有在以下条件全部满足时，才会中断透传、执行 error_page：
- 后端返回 HTTP 状态码 ≥ 400（如 404、502）
- 配置了对应状态码的
error_page指令 -
proxy_intercept_errors on;已启用 - 响应体非空——Nginx 默认忽略空响应体的错误（例如某些框架返回 404 但 body 为空），此时需配合
proxy_buffering off;或后端补全响应体
两种典型处理方式：跳转 or 渲染
通过 error_page 的目标写法，可灵活选择行为：
-
重定向到首页或维护页：
error_page 404 =302 /;或error_page 502 504 = @fallback;，再配合location @fallback { internal; return 302 /maintenance; } -
直接返回美化 HTML：
error_page 500 /50x.html;，并确保location = /50x.html { root /usr/share/nginx/html; }明确指定静态资源路径 - 注意：
=后跟数字（如=302）表示强制修改状态码；不带数字的= @name是内部命名 location 跳转，更安全可控
避开高频失效场景
配置看似正确却仍透传原始错误？常见原因包括：
- 后端返回的是
200 OK+ JSON 中含"code":404—— proxy_intercept_errors 只看 HTTP 状态码，不解析业务字段 -
error_page写在server层，但proxy_intercept_errors on;写在子location中，作用域不匹配导致未继承 - 对静态资源代理（如
location ~ \.(png|js)$）也开了该指令，结果 404 时丢失Content-Type头——这类请求更适合用try_files处理 - 自定义页面路径错误，或文件权限不足，Nginx 日志中会报
open() "/path/404.html" failed (13: Permission denied)
