企业级大文件上传下载代理性能调优核心是系统性收敛数据流路径：上传侧需放开体大小、延长超时、控制缓冲与临时目录；下载侧启用sendfile零拷贝、保障range断点续传、区分缓存策略并关闭proxy_buffering；传输链路需优化tcp窗口、复用长连接、绑定cpu及提升句柄数；同时强化可观测性与防护。
企业级大文件上传与下载代理的性能调优，核心是让 Nginx 在高吞吐、长连接、低中断场景下稳定工作。不是单纯调大某个参数，而是围绕“数据流路径”做系统性收敛：从客户端请求接入 → 内存/磁盘中转 → 后端交互 → 响应输出，每一段都要消除瓶颈。
上传侧：防超时、保完整、减落盘
大文件上传（如 500MB–5GB）失败，90% 源于默认配置过严或缓冲策略不当：
-
放开体大小限制：在 http 或 server 块中设
client_max_body_size 5g;（注意单位用 g，避免写成 5000m 导致解析歧义） -
延长等待时间：上传耗时取决于带宽，需同步调大
client_body_timeout 600;（10 分钟）和client_header_timeout 60; -
控制缓冲行为：小文件走内存，大文件直写磁盘。设
client_body_buffer_size 256k;+client_max_temp_file_size 4g;，避免小缓冲频繁刷盘 -
指定临时目录：用
client_body_temp_path /data/nginx/upload 1 2;将临时文件落到高速 SSD，并支持两级子目录散列，防 inode 瓶颈
下载侧：零拷贝、断点续传、缓存分层
下载优化重点不在“提速”，而在“不断、不卡、不重拉”：
-
启用 sendfile 零拷贝：对静态文件直出（root/alias），必须开
sendfile on;+tcp_nopush on;+tcp_nodelay off; -
确保 Range 可用：禁用任何覆盖
Accept-Ranges的 header；反向代理时，后端必须返回206且 Nginx 不缓存 206 响应（proxy_cache_valid 206 0s;） -
区分缓存策略：静态资源用
expires 1y;+Cache-Control "public, immutable"；动态源（如 OSS）用proxy_cache，但只缓存 200，不缓存 206 -
调大代理超时：若后端是 Java/PHP，设
proxy_read_timeout 3600;+proxy_send_timeout 3600;，并配proxy_buffering off;避免大文件积压在 proxy buffer 中
传输链路：TCP 与连接复用深度调优
大文件场景下，网络栈效率比应用逻辑更重要：
-
增大 TCP 接收窗口：在系统级加
net.core.rmem_max = 16777216，Nginx 中配tcp_recieve_buffer_size 2m;（需内核支持） -
复用长连接：设
keepalive_timeout 300;+keepalive_requests 1000;，upstream 中加keepalive 32;和proxy_http_version 1.1;+proxy_set_header Connection ""; -
绑定 CPU 减少调度抖动：用
worker_cpu_affinity auto;+worker_processes auto;，让每个 worker 固定在独立核心运行 -
提升文件句柄容量：设
worker_rlimit_nofile 65535;，并同步调高系统 limit（ulimit -n 65535）
可观测与防护：不只调优，更要稳控
上线后必须能快速定位异常，同时防滥用：
-
按业务分离日志格式：上传用
log_format upload ... "$request_time $status $body_bytes_sent";，下载用log_format download ... "$upstream_http_content_range $bytes_sent"; -
限制单 IP 并发与速率：用
limit_conn addr 10;+limit_req zone=download burst=20 nodelay;，防爬虫扫包 -
启用 stub_status 并接入 Prometheus：暴露
/nginx_status，监控Active connections、Writing、Reading实时分布 -
关键路径加健康检查：upstream 中配
health_check interval=3 fails=2 passes=2;，避免故障节点拖垮整条链路
