proxy_intercept_errors 仅作为开关启用错误拦截，必须与同作用域的 error_page 指令配合使用，由后者指定真实存在的自定义页面（如 /404.html）来呈现美化内容，二者缺一不可。
proxy_intercept_errors 本身不生成页面，也不自动美化错误；它只是一个“开关”，用来告诉 Nginx：当后端返回 4xx/5xx 这类错误响应时，别急着直接透传给用户，先停一下，交由 error_page 指令处理——而真正决定展示什么内容、是否美观的，是你配置的 error_page 目标页（比如 /50x.html）及其样式。
必须同时开启两个关键配置
只写 proxy_intercept_errors on; 是无效的。它必须和 error_page 在同一作用域（如同一个 location 或 server 块）中成对出现：
- 在代理 location 中启用拦截：
proxy_intercept_errors on; - 在同一 location 或其父级 server 中声明要接管哪些状态码：
error_page 404 /404.html;或error_page 500 502 503 504 /error.html; - 确保
/404.html这类文件真实存在，且路径可被 Nginx 访问（推荐放在root指向的目录下）
让自定义页面真正“美化”起来
error_page 指向的 HTML 文件就是你控制视觉效果的全部入口。建议这么做：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
- 把美化后的 HTML 放在
/usr/share/nginx/html/或你的站点根目录下，例如/var/www/myapp/error.html - 在对应 location = /error.html 中明确指定 root，避免路径解析错误：
location = /error.html { root /var/www/myapp; } - HTML 文件里可自由引入 CSS、图片、JS（注意静态资源路径需可访问），甚至用内联样式快速实现响应式布局
- 若想统一所有错误，用一行覆盖常见状态：
error_page 400 401 403 404 500 502 503 504 /error.html;
避开常见失效场景
明明配了却还是看到原始后端错误页？大概率掉进了这些坑：
- 后端返回的是
200 OK+ JSON body 里写"code":404—— proxy_intercept_errors 只认 HTTP 状态码，不解析业务字段 - 后端响应头不完整（比如缺
Status:行或协议版本错误），Nginx 无法识别为合法错误响应，自然不拦截 - 静态资源请求（如 /logo.png）也开了 proxy_intercept_errors —— 这类 404 更适合用
try_files处理，避免丢失 Content-Type 等头部 - error_page 定义在 server 层，但 proxy_intercept_errors 写在 location 层，而该 location 没有继承到 error_page（作用域不匹配）
快速验证是否生效
不用猜，用命令直接看结果：
- 用 curl 查响应头和状态码：
curl -I http://your-domain/api/bad-path，观察返回的是 404 还是 200，以及Content-Type是 text/html（说明走了自定义页）还是 application/json（说明后端透传） - 在 error_page 对应的 location 里临时加个标识头：
add_header X-Error-Handled "true";，再 curl 看有没有这个 header - 打开 Nginx 错误日志 debug 级别：
error_log /var/log/nginx/error.log debug;，搜索 “intercept” 或 “error_page” 关键词确认拦截动作
