499表示客户端在nginx未发出响应首字节前主动断连，非服务端错误；502因上游服务提前关闭连接（如超时或崩溃）；504是nginx等待上游响应超时；需据error.log关键词定位中断环节，分层排查超时、大小限制及资源瓶颈。
大文件在长连接上传或下载过程中被 Nginx 中断，不是“连接断了”，而是某一层主动切断——关键要分清是 谁在什么时候、因为什么理由放弃了这次传输。常见报错如 502、504、499、Connection reset by peer、upstream prematurely closed connection，背后逻辑各不相同，不能统一调大 timeout 就完事。
先看日志，锁定中断发生的位置
打开 /var/log/nginx/error.log，重点关注错误行中的关键词：
- while reading response header from upstream → 中断发生在等后端响应头时，问题大概率出在后端（PHP-FPM/Tomcat/Node.js）没及时返回，或已崩溃
-
while sending request to upstream 或 upstream prematurely closed connection → Nginx 正把文件数据发给后端，但后端突然关闭连接，常见于
proxy_send_timeout触发，或后端接收卡住（如磁盘满、鉴权阻塞） - while sending to client 或单独出现 499 → 客户端自己关了连接（浏览器刷新、APP切后台、网络切换），Nginx 记录为“对方先走”
- Connection reset by peer + 源 IP 是后端地址 → 后端进程发了 TCP RST，可能是 OOM 被杀、keepalive 超时比 Nginx 短、或响应格式违规（如 Content-Length 错）
上传中断：重点查三段大小 + 三段超时是否对齐
上传失败常表现为前端“网络错误”、$_FILES 为空、或中途卡住无响应。这不是 PHP 没运行，而是 Nginx 在转发请求体时就被拦下了。
-
大小限制必须逐层放开：
client_max_body_size（Nginx）、upload_max_filesize和post_max_size（PHP）、request_terminate_timeout（PHP-FPM）三者都要设，且 location 级配置优先级最高——别只在 http 块设，上传路径的 location 里必须显式写一遍 - proxy_send_timeout 不是“上传总时间”，而是 Nginx 向后端“每一段数据发出后等待 ACK”的上限。比如后端接收慢（Java 读流不及时、Python Gunicorn 缓冲策略不当），哪怕总上传才到 30%，只要某次发包后 60 秒没收到确认，Nginx 就断连 → 建议按最大文件 ÷ 后端稳定接收速率 × 1.5 来设，例如 2GB 文件、后端能稳收 8MB/s，timeout 至少设为 300 秒
- fastcgi_send_timeout / fastcgi_read_timeout / fastcgi_connect_timeout 必须一致（PHP-FPM 场景）。面板默认只改 read，send 和 connect 仍为 60 秒，上传大文件极易卡在 send 阶段直接 504
下载中断：确认 Range 支持是否真正生效
视频播放卡顿、PDF 下载一半失败，往往不是带宽问题，而是服务端没正确支持断点续传。
-
206 不等于支持续传：必须检查响应头含
Accept-Ranges: bytes；每次 206 响应都带准确的Content-Range（如bytes 0-1023/10485760），且Content-Length严格等于该段字节数 -
中间层会吞掉 Range：如果用了 proxy_pass，必须加两行透传头：
proxy_set_header Range $http_range;和proxy_set_header If-Range $http_if_range;；CDN 或 WAF 也要确认未强制缓存全量响应 -
gzip 压缩可能破坏 206：旧版 Nginx 对分段响应做 gzip，会导致解压后长度与
Content-Length不符，触发ERR_CONTENT_LENGTH_MISMATCH。建议对下载路径禁用压缩：gzip off;
临时路径和资源瓶颈常被忽略
很多中断根本不是超时或协议问题，而是底层资源扛不住：
-
client_body_temp_path默认在/tmp，上传大文件时先写临时磁盘再转发。若磁盘满或权限不对（nginx用户不可写），上传一半就失败，日志报No space left on device或Permission denied -
client_body_buffer_size太小（默认 8K–16K）会导致频繁磁盘 I/O，高并发下拖慢整体性能。建议设为 512K～1M，甚至与client_max_body_size同值（内存充足时），让中小文件全程走内存 - 检查系统级限制：
ulimit -n是否够用、net.core.somaxconn是否过低（影响连接队列）、dmesg | grep -i "killed process"看是否有 OOM 杀进程记录
