sendfile 不提升 Nginx 单机连接数上限，仅通过零拷贝降低静态文件传输的 CPU 开销，间接提高并发吞吐；连接数上限由 worker_connections、系统文件描述符限制和内核参数共同决定。
sendfile 技术本身不直接提升 Nginx 的单机连接数上限。
sendfile 主要优化的是静态文件传输效率
它通过零拷贝（kernel 内部直接从文件缓冲区到 socket 缓冲区）减少 CPU 拷贝和上下文切换，从而降低每个静态请求的 CPU 开销。这意味着：在相同硬件资源下，Worker 进程能更快处理完一个静态请求，腾出更多 cycles 去响应新连接——间接支持更高并发吞吐，但不改变连接数的硬性上限。
- 连接数上限由 worker_connections × worker_processes、系统级文件描述符限制（
ulimit -n）、内核参数（如net.core.somaxconn）共同决定 - sendfile 不增加可用文件描述符数量，也不放宽内核监听队列长度，因此不突破连接建立阶段的瓶颈
- 对反向代理场景基本无效，因为数据需经用户态处理（如修改 header、负载均衡逻辑），无法走 sendfile 路径
真正影响连接数上限的关键配置
若目标是支撑更多并发连接，应聚焦以下可量化调优项：
-
worker_rlimit_nofile 必须 ≥
worker_connections × worker_processes，否则进程启动失败或连接被拒绝 -
操作系统级 nofile 限制（
/etc/security/limits.conf中 soft/hard 值）需同步提高，否则 systemd 或 shell 启动时受限 -
listen 指令的 backlog 参数（如
listen 80 backlog=65535;）需与net.core.somaxconn匹配，避免新连接在队列满时被丢弃 - tcp_tw_reuse 和 tcp_fin_timeout 可加快 TIME_WAIT 状态回收，在短连接密集场景下释放端口资源
sendfile 与连接数的关联仅在特定负载下显现
当业务以静态资源服务为主（如 CDN、图片站、前端资源托管），开启 sendfile 能显著降低 CPU 占用率。CPU 不再成为瓶颈后，Nginx 才可能真正跑满设定的 worker_connections 上限；反之，若 CPU 因频繁 read/write 拷贝而饱和，即使配置了 10 万连接，实际能维持的活跃连接也会远低于该值。
- 典型表现：未开 sendfile 时，CPU 使用率在 70% 以上就出现响应延迟；开启后，同样连接压力下 CPU 降至 30%～40%
- 注意：
tcp_nopush应与 sendfile 配合使用，确保内核将多个小包合并发送，避免 Nagle 算法干扰零拷贝优势
