nginx 没有 sendfile_max_chunk 指令，该名称属常见误解；实际影响 sendfile 的配置是 sendfile、tcp_nopush、tcp_nodelay 和 limit_rate，内核参数间接影响传输行为。

nginx 并没有 sendfile_max_chunk 这个配置指令。

常见误解来源

这个名称常被误传，可能源于对以下两个真实指令的混淆：

• sendfile：启用或禁用内核级零拷贝传输（on/off）
• sendfile_max_chunk：**不存在于官方 nginx（包括主线版和 Tengine 等主流分支）中**。部分定制化 fork 或第三方模块曾短暂引入类似功能，但未被上游采纳，也不具备通用性

真正影响 sendfile 行为的关键配置

若你希望控制 sendfile 的单次传输行为，实际可调的是：

• tcp_nopush：配合 sendfile on 使用，让 nginx 在发送响应时尽量填满 TCP 包，减少小包数量（非限制字节数，而是优化打包策略）
• tcp_nodelay：禁用 Nagle 算法，适用于需要低延迟的小响应（与 tcp_nopush 通常互斥）
• limit_rate：限制客户端整体响应速率（字节/秒），作用于整个响应流，非单次 sendfile 调用
• 内核参数（如 net.ipv4.tcp_wmem）会影响底层 TCP 发送窗口，间接影响每次系统调用写入的数据量，但不属于 nginx 配置范畴

为什么 nginx 不提供 sendfile 单次 chunk 控制？

sendfile 是 Linux 内核提供的系统调用，其内部 chunk 大小由内核根据 socket 缓冲区、文件系统块大小、page cache 状态等动态决定。nginx 作为用户态服务器，仅触发该调用，并不介入或拆分内核的传输过程。强行限制单次 size 可能破坏零拷贝优势，甚至引发额外内存拷贝或逻辑复杂度，违背设计初衷。

如需精细控制传输行为，替代方案

若业务场景确实要求分块传输（例如大文件断点续传、带进度反馈的下载、规避特定代理限制等），应：

• 关闭 sendfile on，改用常规 read/write 流式响应（sendfile off）
• 结合 chunked transfer encoding 或自定义分片逻辑（如通过 Lua 模块或后端应用控制）
• 使用 slice 模块（nginx 1.9.8+ 内置）实现基于 range 的分片加载，适合大静态文件

不复杂但容易忽略：确认 nginx 版本与文档一致性，优先查阅官方指令索引，避免依赖非标准或已废弃的配置项。