504超时需分层调优：协同调整proxy_connect_timeout（3–5秒）、proxy_send_timeout（30秒）、proxy_read_timeout（略大于后端P99耗时，如300秒）；同步收紧客户端超时、启用upstream keepalive、按需关闭proxy_buffering以适配流式响应。
当后端服务需要长时间计算（比如报表生成、大文件处理、复杂模型推理），Nginx 默认的超时设置极易触发 504 Gateway Timeout。调优核心不是“一味加长”，而是分层对齐、精准匹配业务节奏，同时避免资源滞留。
对齐后端真实耗时，设好三类代理超时
关键参数必须协同调整，不能只改 proxy_read_timeout：
- proxy_connect_timeout：控制与后端建连时间，建议保持 3–5 秒。过长会掩盖网络或服务未就绪问题
- proxy_send_timeout：发送完整请求到后端的时限，一般 30 秒足够（除非传巨量 body）
- proxy_read_timeout：这是重点——设为略大于后端最长预期响应时间，例如后端平均耗时 120 秒、P99 是 240 秒，则设为 300 秒（5 分钟）
同步收紧客户端侧超时，防止错位等待
Nginx 等后端，但客户端（浏览器或 App）可能先放弃。需确保前端发起方也支持长连接并配置合理超时：
- 若前端是浏览器，配合设置 keepalive_timeout 300;（告知客户端可保持连接 5 分钟）
- 若前端是移动端 SDK 或内部服务，确认其 HTTP 客户端的 socket timeout ≥ Nginx 的 proxy_read_timeout
- 避免出现“Nginx 还在等，客户端已断开”的隐性失败
启用长连接复用，减少握手开销
长时间请求本身不频繁，但若每次都要新建 TCP+TLS 连接，延迟和 CPU 开销反而更大：
- upstream 块中添加 keepalive 16;（数值按后端连接池容量设，如 Spring Boot max-connections=20，就设 16）
- 对应 location 中必须配：proxy_http_version 1.1; 和 proxy_set_header Connection '';
- 验证方式：用 ss -tnp | grep :backend_port 观察 ESTABLISHED 连接是否稳定存在，而非反复新建/关闭
缓冲区与流式响应适配
大计算结果往往是一次性返回，但若后端边算边推（如 SSE、分块响应），需禁用缓冲以避免阻塞：
- 默认开启 proxy_buffering on; 适合常规响应；但对长计算+流式场景，应设为 proxy_buffering off;
- 同时搭配 proxy_buffer_size 128k; 和 proxy_buffers 4 256k; 防止小包堆积
- 注意：proxy_buffering off 后，Nginx 将同步转发数据，不缓存整条响应，因此后端必须保证响应流稳定
