sendfile_max_chunk 并非 nginx 官方指令，标准版本中不存在；其功能可通过 aio threads、slice 模块或限速等机制间接实现，核心目标是避免 worker 进程被大文件传输长期阻塞。
sendfile_max_chunk 并不是 Nginx 官方支持的配置指令，它**不存在于标准 Nginx（包括主线版、稳定版及主流发行版打包版本）中**。你可能混淆了其他服务器（如某些定制版 Tengine 或旧版第三方补丁）的扩展参数，或误记了类似名称的选项。
为什么官方 Nginx 没有 sendfile_max_chunk？
Nginx 的 sendfile 实现依赖内核的 sendfile() 系统调用，其行为由内核控制，Nginx 本身不暴露“单次传输最大字节数”的直接配置项。官方更倾向通过以下方式间接影响 sendfile 行为：
-
启用/禁用 sendfile：用
sendfile on | off; -
配合 TCP 优化：如
tcp_nopush on;（在 sendfile 启用时，将数据凑满 TCP 报文段再发，提升吞吐） -
限制响应体大小或超时：如
client_max_body_size、send_timeout，但不干预 sendfile 内部分块逻辑
真正能缓解 sendfile 长时间阻塞的实用方法
所谓“sendfile 阻塞”，通常指大文件传输时占用 worker 进程过久，影响其他请求处理（尤其在高并发、低配机器上）。这不是因为单次 sendfile 太大，而是内核 sendfile() 在拷贝超大文件时可能持有 socket 锁或调度延迟。解决思路是「避免让一个请求独占 worker 太久」：
-
启用异步 sendfile（Linux 4.12+）：确保内核 ≥ 4.12，并编译 Nginx 时启用
--with-file-aio；然后配置：aio threads;sendfile on;
这会让大文件传输交由内核线程池异步完成，worker 进程立即返回处理其他请求 -
限制单个连接的带宽：用
limit_rate或limit_rate_after控制发送节奏，变相拉长传输时间但释放 worker：limit_rate 1m;（限速 1MB/s）limit_rate_after 10m;（前 10MB 不限速，之后限速） -
关闭 sendfile，改用 directio + read/send 组合（适合超大静态文件）：
sendfile off;directio 8m;（对 ≥8MB 文件启用 O_DIRECT）output_buffers 1 128k;
此时 Nginx 自行分块读取并发送，可精确控制每次 read 大小（如通过调整read_ahead或 buffer 大小间接影响），且支持中断与超时
如果你确实需要“分块 sendfile”——替代方案
标准 Nginx 不提供该功能，但可通过以下方式模拟效果：
-
用 slice 模块分片响应（Nginx 1.9.8+ 内置）：
slice 1m;location /big/ {
alias /data/;
add_header Content-Disposition "attachment";}
它会把大文件按 1MB 切片，每个 HTTP 请求只 sendfile 一帧，天然防长阻塞，客户端需支持 Range 请求（浏览器下载、curl -r 均支持） - 反向代理到支持 chunked sendfile 的后端：如用 Go/Python 写轻量服务，手动 read() + write() 分块，可控性更高
不复杂但容易忽略：真正影响性能的往往不是 sendfile 单次大小，而是是否阻塞 worker 进程。优先用 aio threads 或 slice，比寻找不存在的参数更可靠。
