生产环境nginx.conf需四维校准：资源调度（worker_processes与worker_connections须匹配系统ulimit）、传输链路（sendfile/tcp_nopush/tcp_nodelay协同启用零拷贝与TCP优化）、安全头（add_header后加always且禁用if块）、日志结构（固定字段顺序并包含upstream_time等关键指标）。
nginx.conf 生产环境不能靠“改几行再 nginx -t 就上线”，真正稳定压得住流量、扛得住扫描、经得起审计的配置，必须从资源调度、传输链路、安全头、日志结构四个层面同步校准——缺一不可。
worker_processes 和 worker_connections 怎么设才不翻车
盲目设成 auto 或堆高 worker_connections 是线上雪崩常见起点。关键不在数值本身，而在它和系统限制是否咬合。
-
worker_processes auto适合裸金属或独占 CPU 的 VM；容器场景建议显式设为2或4，避免与宿主机其他进程争核 -
worker_connections 4096是合理起点，但必须同步检查：ulimit -n输出 ≥ 65535，且在/etc/security/limits.conf中固化nginx soft nofile 65535和nginx hard nofile 65535 - 漏掉
worker_rlimit_nofile 65535在全局块里？Nginx 启动时不会报错，但高并发下会静默降级为默认 1024，连接直接被拒绝
sendfile / tcp_nopush / tcp_nodelay 组合为什么不能拆开用
这三个指令是 Linux 下零拷贝 + TCP 包调度的黄金三角，单独开某个可能反而拖慢响应。
-
sendfile on：启用内核态文件传输，省掉用户态拷贝，但要求后端文件不经过任何过滤（如 Lua 脚本修改响应体时就得关） -
tcp_nopush on必须配合sendfile才生效，作用是把多个sendfile块攒成一个 TCP 包发出去，减少小包数量 -
tcp_nodelay on则相反：对非sendfile场景（如动态 JSON 响应），禁用 Nagle 算法，确保小响应不等待 200ms
典型错误是只开 sendfile 却关了 tcp_nopush，结果大量 40–60 字节的 HTTP 头被拆成独立小包，TCP 重传率飙升。
安全头不是加了就安全：X-Content-Type-Options 和 X-Frame-Options 的 always 语义
没加 always 标志的安全头，在 304、错误页、子请求等场景下根本不会发送，等于白配。
-
add_header X-Content-Type-Options "nosniff" always：强制浏览器不根据响应体猜测 MIME 类型，防 XSS 诱饵文件（如上传xxx.jpg<script>...</script>） -
add_header X-Frame-Options "SAMEORIGIN" always：防止页面被嵌入非同源 iframe，但注意它已被现代 CSP 的frame-ancestors取代，老浏览器才依赖它 - 别用
if块包裹安全头——Nginx 官方明确说add_header在if内无效，要用map或直接写在server或http块顶层
log_format 里 request_time 不是万能耗时指标
$request_time 记录的是从接受第一个字节到发送完最后一个字节的总时间，但它不包含客户端网络延迟和请求排队时间——这两个恰恰是真实用户体验瓶颈。
- 必须同时记录
$upstream_response_time（如果用了反向代理）和$upstream_connect_time，才能区分是 Nginx 自身慢，还是后端挂了 - 日志字段顺序要固定，比如
'$remote_addr $request_time $upstream_response_time "$request" $status'，否则 Loki 或 Filebeat 解析时字段错位 - 别在
log_format里用未定义变量（如误写$req_time），Nginx 不报错，但该字段恒为空，日志失去诊断价值
最易被忽略的是：所有这些配置改完后，nginx -t 只验语法，不验效果。必须用 curl -I http://localhost 实际看响应头，再用 ab -n 1000 -c 100 http://localhost/ 压测验证连接吞吐是否真提升——否则只是纸上谈兵。
