没错，504确实需要针对性调整——因为Nginx在处理**网关超时（504）**时，会因为上游服务响应逻辑或自身默认配置的优先级问题，容易跳过你定义的自定义错误规则。下面给你两种靠谱的修复方案：

方法一：直接在error_page中返回JSON（最简洁） #

不需要用命名location绕一圈，直接在error_page指令里指定返回内容，能确保Nginx直接输出你定义的JSON，不会触发默认的HTML错误页：

error_page 504 =504 '{"code":"504","message":"Server Timeout"}';
default_type application/json;

如果要和其他错误码统一处理，也可以把所有需要自定义的错误码列在一起，同时确保default_type在server或全局块中生效：

server {
    # 其他业务配置...
    default_type application/json;

    error_page 400 401 403 404 500 502 503 504 = @custom_error;

    location @custom_error {
        return $status '{"code":"$status","message":"$status"}';
        # 要是想给不同状态码配不同提示，还可以用map指令做更细的区分
    }
}

方法二：确保命名location的优先级（排查代理场景冲突） #

如果坚持用命名location的写法，还要检查是否漏开了拦截上游错误的指令——如果你是通过反向代理上游服务得到的504，必须开启proxy_intercept_errors（FastCGI场景用fastcgi_intercept_errors），否则Nginx会直接把上游返回的HTML错误页透传给客户端：

server {
    # 反向代理上游服务的场景
    proxy_pass http://your_upstream_service;
    proxy_intercept_errors on; # 关键：让Nginx接管上游返回的错误码

    error_page 504 =504 @res;

    location @res {
        default_type application/json;
        return 504 '{"code":"504","message":"Server Timeout"}';
    }
}

额外注意事项 #

• 测试的时候别光看浏览器，建议用curl -v请求，查看响应头的Content-Type是否为application/json，避免浏览器缓存旧的HTML页面干扰判断。
• 如果是Nginx自身生成的504（比如代理超时），还要检查proxy_connect_timeout、proxy_read_timeout等超时配置是否合理，确保错误触发逻辑符合预期。

内容的提问来源于stack exchange，提问作者suresh