proxy_intercept_errors 用于控制 Nginx 是否拦截后端返回的 ≥400 错误响应并交由 error_page 处理；需同时启用 proxy_intercept_errors on 并配置对应 error_page 才生效，否则仍透传原始错误。
proxy_intercept_errors 是 Nginx 中用于控制是否将后端（如应用服务器）返回的 HTTP 错误响应（如 404、500、502 等）交由 Nginx 自己的错误页面机制处理的关键指令。
作用原理：接管还是透传？
默认情况下，Nginx 会把后端返回的任何响应（包括错误状态码）原样转发给客户端。启用 proxy_intercept_errors on; 后，当后端返回的状态码 ≥ 400 且未被 error_page 显式捕获时，Nginx 会中断原始响应，转而查找匹配的 error_page 指令来生成替代响应（比如自定义 500 页面或跳转到其他 location）。
注意：它只对 proxy_pass 场景生效，且仅影响 Nginx 收到的后端响应状态码，不影响 Nginx 自身产生的错误（如 502/503/504）。
必须配合 error_page 才有效
单独开启 proxy_intercept_errors on; 不会自动显示错误页——它只是“允许拦截”，真正展示什么内容，取决于你是否配置了对应的 error_page：
- error_page 404 /404.html; → 后端返回 404 时，Nginx 返回本地 /404.html
- error_page 500 502 503 504 /error.html; → 多个状态码共用一个错误页
- error_page 404 = @fallback; → 重定向到命名 location @fallback 进行进一步处理（如降级逻辑）
若未配置对应 error_page，即使开启了 intercept，Nginx 仍会透传原始错误响应。
常见配置陷阱与注意事项
以下情况容易导致预期外行为：
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- location 中未设置 proxy_intercept_errors on; —— 它默认是 off，需显式开启
- error_page 路径未在 root 或 alias 下真实存在，导致返回 404（二次错误）
- 使用 error_page 404 =200 /index.html; 将 404 转为 200 响应时，注意前端可能依赖状态码做判断
- 与 fastcgi_intercept_errors 类似，但仅适用于 proxy_pass；FastCGI 场景要用后者
典型实用配置示例
一个常见静态兜底 + 错误页分离的写法：
location /api/ {
proxy_pass http://backend;
proxy_intercept_errors on;
error_page 404 /static/404.html;
error_page 500 502 503 504 /static/error.html;
root /var/www/html;
}
若希望对某些错误做特殊处理（如记录日志或调用健康检查接口），可结合 named location 使用：
error_page 502 = @handle_502;
<p>location @handle_502 {
internal;
proxy_pass <a href="https://www.php.cn/link/8a06615d4abacff23bb8cde6c87e911c">https://www.php.cn/link/8a06615d4abacff23bb8cde6c87e911c</a>;</p><h1>可加 proxy_set_header、limit_req 等增强控制</h1><p>}</p>
不复杂但容易忽略：开启拦截却不配 error_page，等于没开；配了 error_page 却没开 intercept，也无效。两者必须协同工作。
