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 版本与文档一致性，优先查阅官方指令索引，避免依赖非标准或已废弃的配置项。
