proxy_intercept_errors on需配合error_page使用才能拦截上游错误响应，仅开启该指令无效；它根据error_page定义的状态码映射返回本地页面，且受响应体大小限制影响。

在 Nginx 中启用 proxy_intercept_errors on，核心是让 Nginx 在上游服务器返回错误状态码（如 404、500）时，不直接透传给客户端，而是尝试用本地定义的 error_page 指令来拦截并响应。

必须配合 error_page 使用

单独设置 proxy_intercept_errors on 不会生效。它只是开启“拦截开关”，真正起作用的是后续的 error_page 配置：

• 例如：上游返回 404，Nginx 才会检查是否有 error_page 404 /404.html;
• 若未定义对应状态码的 error_page，即使开启了 intercept，Nginx 仍会原样返回上游响应
• 支持批量映射：如 error_page 404 500 502 503 504 /error.html;

作用域需正确（通常在 location 块内）

该指令只能出现在 http、server 或 location 块中，且对当前作用域及子块生效。推荐写在 location 内，避免影响其他代理逻辑：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

location /api/ {
    proxy_pass https://backend;
    proxy_intercept_errors on;
    error_page 500 502 503 504 /5xx.html;
    error_page 404 /404.html;
}

注意响应体大小限制

Nginx 默认只拦截响应头中 Content-Length 小于 512 字节的错误响应。如果上游返回的大体积错误页（比如带详细堆栈的 500 页面），可能无法被拦截。

可通过 proxy_buffer_size 和 proxy_buffers 调整缓冲区，但更稳妥的做法是确保上游错误响应简洁，或用 proxy_redirect off 配合自定义响应头控制。

验证是否生效的小技巧

临时让上游返回一个明确错误（如用 curl 模拟 500），再观察 Nginx 访问日志和实际返回内容：

• 看到日志中出现 "GET /api/test HTTP/1.1" 500 → 上游返回了 500
• 但浏览器收到的是你配置的 /5xx.html 内容 → 拦截成功
• 若浏览器仍看到上游原始错误页 → 检查 error_page 路径是否存在、是否可访问、状态码是否匹配