Nginx超时默认返回504，需用error_page指令将504精准重映射为503或自定义状态码（如599），并配合日志监控验证；须关闭proxy_next_upstream timeout、禁用fastcgi_intercept_errors，且error_page须置于正确location作用域内。
当 Nginx 代理请求因后端响应过慢触发超时（如 proxy_read_timeout 到期），默认返回 504 Gateway Timeout。若需统一暴露为其他状态码（如 503 或自定义错误码），不能靠简单重写，而要结合超时机制、错误拦截与状态码重映射实现精准控制。
识别并捕获超时类错误
Nginx 不会直接将“超时”作为可匹配的 HTTP 状态码，但可通过以下方式间接识别：
- proxy_read_timeout / proxy_connect_timeout 触发时，Nginx 内部生成 504，这是唯一可靠信号；
- 502（Bad Gateway）通常来自后端连接失败或返回非法响应，与超时无关；
- 务必关闭
proxy_next_upstream timeout（避免自动重试掩盖真实超时），确保 504 真实反映单次请求耗尽等待时间。
用 error_page 实现 504 → 目标状态码转换
在 location 或 server 块中配置 error_page 指令，将原始 504 显式转为指定状态码：
- 转为标准 503：
error_page 504 =503 /50x.html; - 转为自定义状态码（如 599）并返回 JSON：
error_page 504 =599 @timeout_json;<br>location @timeout_json {<br> default_type application/json;<br> return 599 '{"code":"TIMEOUT","message":"Request processing too slow"}';<br>} - 注意：
=503中的等号表示“替换状态码”，不带等号则为重定向（HTTP 302），不符合预期。
配合日志与监控验证转换效果
仅改状态码不够，需确认是否生效且不干扰正常链路：
- 在 log_format 中加入
$status和$upstream_status，区分 Nginx 返回码与上游真实码； - 超时请求的
$upstream_response_time会接近proxy_read_timeout值，而$request_time略长（含发送响应开销）； - 若发现大量 504 未被转换，检查 error_page 是否位于正确作用域（必须在能捕获该请求的 location 内，且无更上层同名指令覆盖）。
避免常见陷阱
几个容易出错的操作点：
- 不要在 http 块全局设置
error_page 504 =503—— 它无法作用于 stream 模块或非 proxy 场景，且可能误影响静态资源； - 禁用
fastcgi_intercept_errors on（若用 FastCGI），否则会屏蔽 error_page 对 504 的捕获； - HTTPS 正向代理场景下，CONNECT 隧道超时不产生 504，而是直接断连（状态码不可控），该转换仅适用于 HTTP 代理路径。
