排查Nginx代理大文件传输带宽跑满，核心是确认流量是否合理、路径是否异常、缓冲是否失当，需三步闭环：先验证是否Nginx承载大文件，再查其传输方式（缓冲/落盘/超时），最后确认后端与客户端行为匹配。
排查 Nginx 代理大文件传输导致带宽跑满，核心不是“看流量多大”，而是确认流量是否合理、路径是否异常、缓冲是否失当。重点在三步闭环：先验证是不是 Nginx 在传大文件，再查它怎么传（缓冲/落盘/超时），最后确认后端和客户端行为是否匹配。
确认大文件请求真实存在且由 Nginx 承载
别只看 iftop 显示高流量就认定是“下载”，得落到具体请求：
- 用 nethogs -d 2 eth0 查进程级流量，确认是 nginx worker 在发包，不是其他进程伪装或 fork 出的子进程
- 查 Nginx access_log，过滤出大响应体请求：awk '$10 > 10485760 {print $1, $7, $9, $10}' access.log | sort -k4nr | head -20（$10 是 $body_bytes_sent，单位字节；>10MB 即标为大文件）
- 检查这些请求的 URL 是否属于预期路径（如 /download/、/api/export），还是大量 404 却返回 200 的异常路径（常见于前端路由 fallback 导致首页被反复下载）
检查反向代理缓冲配置是否引发隐性卡顿与磁盘 IO
带宽跑满常因 Nginx 缓冲策略不当，把本该流式转发的请求拖成“先收后发”或频繁写临时文件：
- 确认 proxy_buffering 状态：对纯下载路径（如 location ^~ /download/），应设为 off；若为 on，Nginx 会等后端发完全部响应才开始推给客户端，首字节延迟高、连接堆积
- 若必须开启缓冲（如需改响应头或 gzip），则检查 proxy_buffers 是否足够：例如 proxy_buffers 8 128k（共 1MB 内存），配合 proxy_busy_buffers_size 256k（忙区上限不能超总和一半）
- 查 error.log 是否有 "client intended to send too large body" 或 "could not open temp file"；若有，说明 client_body_temp_path 或 proxy_max_temp_file_size 不足，正在高频小块写盘拖慢吞吐
验证后端响应行为与连接生命周期是否匹配
即使 Nginx 配置正确，后端不支持流式响应或连接管理不当，也会让带宽虚高：
- 用 curl -i http://your-domain/file.zip 检查响应头：必须含 Transfer-Encoding: chunked 或明确 Content-Length；若缺失且后端持续输出，Nginx 可能误判为未结束而不敢释放连接
- 检查超时设置是否过短：proxy_read_timeout（后端响应时间）和 proxy_send_timeout（发给客户端时间）建议 ≥600（10 分钟），避免大文件传输中途断连重试
- 确认启用了连接复用：proxy_http_version 1.1; + proxy_set_header Connection '';，否则 HTTP/1.0 下每文件建新连接，TCP 握手+慢启动反复吃带宽
排除日志与缓存带来的非业务带宽消耗
有些“跑满”根本不是用户下载，而是 Nginx 自身机制在偷偷刷流量：
- 检查 access_log 是否记录了大量 200 响应但无实际文件——可能是前端 fallback 规则把所有 404 路径都指向 index.html，导致一个错误请求触发整站 JS/CSS 下载（每页几十个请求 × 每个 200KB = 瞬间 Mbps）
- 查看 proxy_cache 是否误缓存大文件：若配置了 proxy_cache_valid 200 1h 且没按文件类型区分 location，Nginx 可能把 500MB 安装包也缓存下来，后续请求全走磁盘读，IO 拉满带宽
- 确认没有开启不必要的模块，如 realip 或 geoip 在高并发下频繁查表、DNS 解析（尤其 $http_x_forwarded_for 里含多个 IP 时），增加 CPU 和网络开销
