sendfile_max_chunk的核心目标是调度权衡而非提速，通过限制单次传输量（如512K～2M）防止大文件独占worker，保障小请求及时响应；必须配合sendfile on、gzip off使用，并推荐按location精细化配置。
调优 sendfile_max_chunk 的核心目标不是提升单文件速度，而是让大文件不“霸占”worker，同时保障小文件能及时响应——本质是调度权衡，不是带宽分配。
理解 chunk 大小如何影响两类请求
设 chunk 为 1M：一个 500MB 视频会被拆成约 500 次 sendfile 调用，每次传输后 worker 主动让出 CPU，可插入处理新来的图片请求；若设为 0（默认），内核可能一次搬 200MB，该 worker 在此期间无法响应任何其他事件，小图请求排队、TTFB 升高。
但 chunk 过小（如 64K）会带来副作用：系统调用次数剧增，上下文切换变多，对 SSD 或高并发小图场景反而增加 CPU 开销。
按业务混合特征选值
无需一刀切，应依据实际流量构成选择：
-
小文件为主（如图标、JS/CSS、API 返回体）+ 少量大文件下载：选
512k。兼顾小资源的响应灵敏度与大文件的基本可控性。 -
大小文件比例接近（如 CDN 边缘节点分发网页+视频）：选
1M。平衡点明确，多数生产环境验证稳定。 -
超大文件占绝对主导（如内部镜像仓库、备份归档服务）且连接数有限：可上探至
2M，减少系统调用频次，但需确保worker_connections足够冗余，避免因少量长连接拖慢整体接纳能力。
必须同步调整的配套配置
单独改 sendfile_max_chunk 几乎无效，以下三项必须协同：
-
保持
sendfile on：这是前提，否则该指令完全不生效。 -
关闭
gzip on：压缩必须在用户态完成，一旦启用 gzip，Nginx 自动退回到 read+write 模式，sendfile和sendfile_max_chunk全部失效。 -
慎用
tcp_nopush：它只在 sendfile 场景下合并包，但现代 HTTP/2 + keepalive 已自带缓冲优化；若开启，需确认响应头极短、且无首屏关键小资源被延迟发送的风险。
针对特定路径做精细化控制
全局设置易误伤，推荐按 location 精准作用：
例如，仅对下载类路径启用更保守的 chunk 值：
location ^~ /dl/ {alias /data/assets/;
sendfile on;
sendfile_max_chunk 512k;
gzip off;
limit_rate 5m;
}
而对静态资源目录（/static/）可维持更高值（如 1M），因其文件体积较均匀、并发更密集，更需吞吐稳定性。
