关键不是堆高数值，而是按请求生命周期分层设值、匹配业务真实耗时，并防止资源被低效连接长期占用：worker_processes设auto，worker_connections设65535并同步调高worker_rlimit_nofile和ulimit；client_header_timeout 12s、keepalive_timeout 15–30s（api）、proxy_read_timeout严格对齐后端真实耗时。
修改 nginx.conf 优化连接数与超时时间，关键不是堆高数值，而是按请求生命周期分层设值、匹配业务真实耗时，并防止资源被低效连接长期占用。
调大并发连接能力
连接数上限由 worker_processes 和 worker_connections 共同决定，需协同调整：
-
worker_processes：建议设为
auto或等于 CPU 核心数，避免默认的 1 导致单核瓶颈 -
worker_connections：每 worker 进程最大连接数，常见设为
65535；但必须同步调高系统级限制：worker_rlimit_nofile 65535，并确认ulimit -n≥ 该值 - use epoll 和 multi_accept on 要开启，提升高并发下事件处理效率
客户端侧超时要“够用且克制”
这部分控制浏览器或 App 与 Nginx 之间的交互，过长易被慢速攻击利用，过短会误伤弱网用户：
- client_header_timeout 10–15s：请求头（URL、Method、Headers）传输超时，普通服务设 12 秒较稳妥
-
client_body_timeout 20–60s：POST 或上传体到达的“静默间隔”，非总上传时长；大文件服务可设 60 秒，但需同步调大
client_max_body_size - send_timeout 10–30s：Nginx 向客户端发响应时，两次写操作间的空闲等待上限；流式接口可放宽至 60 秒，但不宜超过 120 秒
-
keepalive_timeout 15–60s：Keep-Alive 空闲保持时间；API 服务建议 15–30 秒，静态资源站可压到 5–10 秒；注意它应大于
client_body_timeout，否则上传中途连接可能被断开
代理后端通信超时必须显式配置
Nginx 默认所有代理超时都是 60 秒，不改极易触发 504 错误，尤其在调用 Java、Python 或 AI 服务时：
- proxy_connect_timeout 3–5s：建立 TCP 连接到上游的等待上限，跨机房或容器网络不稳定时务必缩短
- proxy_send_timeout 300–3600s：Nginx 把完整请求（含 body）发给后端的总时限，大文件上传或批量任务需调高
- proxy_read_timeout 300–1800s：Nginx 等待后端返回响应的最长时间，应严格对齐后端真实业务耗时（如报表导出设 600 秒，AI 推理设 1800 秒）
验证与生效要点
改完配置不能直接重启，要走标准流程：
- 先执行
nginx -t检查语法和路径是否正确 - 确认无误后用
nginx -s reload平滑重载，避免连接中断 - 用
ss -ant | grep :80 | wc -l或netstat -an | grep ESTAB | wc -l观察连接数变化 - 重点看错误日志：
tail -f /var/log/nginx/error.log，关注 408、504、"upstream timed out" 等关键词
