504错误本质是Nginx向后端发送大文件请求体时超时中断，需调优client_body_timeout、proxy_send_timeout及proxy_buffering，并同步检查后端接收配置。
大文件上传引发的 504 错误，本质是 Nginx 在等待后端接收并处理完整个上传体（request body）的过程中超时中断。这不是单纯的“后端响应慢”，而是上传阶段卡在了数据传输途中——Nginx 已连上后端，但后端还没收完文件，Nginx 就因超时主动断开连接，返回 504。
确认是否为上传路径超时
先看 Nginx error.log 中的关键线索：
- 出现 while sending request to upstream —— 表明问题出在 Nginx 向后端发送请求体（即上传的数据）阶段，不是读响应；
- 若日志中同时有 client_body_timeout 或 client_max_body_size 相关报错，则更指向客户端上传环节；
- 注意区分：504 是 Nginx 等后端，而上传失败若发生在 Nginx 接收客户端数据时，可能触发的是 413（实体过大）或 408（请求头/体超时），不是 504。
调整 Nginx 上传相关超时参数
默认配置对大文件上传极不友好。需重点修改以下三项（建议加在 http 或 server 块中）：
- client_body_timeout 300s：客户端发送请求体的间隔超时，防止上传中途停顿被断开；
- proxy_send_timeout 300s：Nginx 向后端发送完整请求（含大 body）的最大耗时；
- proxy_buffering off（可选但推荐）：关闭代理缓冲，让大文件以流式直传后端，避免 Nginx 内存积压或缓冲区满导致假死。
同步检查后端服务的接收能力
Nginx 只是“中转站”，后端才是最终接收方。常见瓶颈包括：
-
PHP-FPM：检查
request_terminate_timeout和max_execution_time是否足够长； -
Node.js（如 Express）：确认
body-parser或multer的limits.fileSize和limits.fieldSize已放宽； -
Java（如 Spring Boot）：检查
spring.servlet.multipart.max-file-size和max-request-size配置； - 所有后端都需验证其自身是否有反向代理前的超时限制（例如 Tomcat 的
connectionTimeout）。
验证上传流程是否真正走通
用 curl 模拟真实上传，观察各环节耗时：
curl -X POST http://your-domain.com/upload \-F "file=@large-file.zip" \
-w "\nTime: %{time_total}s\n" -o /dev/null -s
如果耗时接近你设置的 proxy_send_timeout，说明上传本身就在临界点，需进一步优化网络或分片上传；如果远低于该值却仍报 504，说明问题不在上传时间，而是后端提前断连（此时应查后端日志中的 connection reset 或 OOM）。
