nginx调优需从四层执行上下文出发：网络层（epoll/socket buffer）、进程层（worker/共享内存zone）、代理层（proxy buffer/upstream keepalive）、文件层（sendfile/open_file_cache），每层资源消耗必须可解释、可验证、可收敛，拒绝盲目堆参数。
从 Nginx 执行上下文最底层存储架构出发做调优，不是堆参数，而是理清“请求进来后，数据在哪、怎么走、谁在管、卡在哪”。工业级防卷的核心是：不盲目加 worker 数、不狂开 buffer、不迷信 cache 大小——而是让每一层资源消耗都可解释、可验证、可收敛。
看清 Nginx 的四层执行上下文与对应存储载体
Nginx 不是单层黑盒，它的请求处理路径天然分层，每层依赖特定的内核/内存资源：
-
网络层（epoll + socket buffer）：连接建立、读取请求头/体。瓶颈常是
net.core.somaxconn、net.ipv4.tcp_tw_reuse和 socket 接收缓冲区大小（net.core.rmem_max），而非 Nginx 自身配置 -
进程层（worker 进程 + 共享内存 zone）：每个 worker 独占内存，但 limit_conn、limit_req、upstream 状态等靠
shared memory zone跨 worker 协同。zone 不够大会直接报no live upstreams或限流失效 -
代理层（proxy buffer + upstream keepalive）：转发请求时，Nginx 默认缓存整个响应体到内存（
proxy_buffering on）。大文件或慢后端易触发proxy_busy_buffers_size溢出，转而写临时文件，拖慢吞吐 -
文件层（sendfile/aio + open_file_cache）：服务静态资源时，真正零拷贝依赖
sendfile on和内核 page cache；频繁 stat 文件则靠open_file_cache缓存 inode 和 fd，否则每请求都 sys_open → 磁盘 I/O
三类典型场景下的基础参数守则（非推荐值，而是判断逻辑）
所谓“防卷”，就是拒绝抄别人配置。每个参数必须回答三个问题：它保护什么资源？放大什么风险？如何验证生效？
-
worker_processes / worker_connections：不是 CPU 核数 × 2。先看
ulimit -n和sysctl net.core.somaxconn，确保系统能支撑目标并发连接数；再用ab或wrk压测，观察nginx -s reload后的Active connections是否稳定在预期 70%~80%，超了说明连接池溢出，要调系统参数而非只加 worker -
proxy_buffer_size / proxy_buffers：若后端返回头固定（如 JSON API），
proxy_buffer_size 4k足够；若后端偶发返回大 HTML（比如含 base64 图片），且你又不想开proxy_buffering off（会阻塞 worker），那就配proxy_max_temp_file_size 1m+proxy_temp_path指向 SSD 目录，并监控proxy_temp目录文件增长 -
open_file_cache：不要设
max=65536 inactive=60s就完事。先用lsof -p $(cat /var/run/nginx.pid) | wc -l查当前打开文件数，再对比open_file_cache max是否显著大于该值；同时用strace -p $(cat /var/run/nginx.pid) -e trace=openat看是否还有高频 openat 系统调用 —— 有则 cache 未命中，需调inactive时间或min_uses
缓存策略必须绑定业务语义，而非 HTTP 状态码
工业级缓存不是 proxy_cache_valid 200 302 10m 一行搞定。关键在区分：
-
强一致性资源（如用户仪表盘数据）：即使返回 200，也应加
Cache-Control: no-cache, must-revalidate，Nginx 用proxy_cache_bypass $http_cache_control尊重客户端意愿 -
弱一致性资源（如地图瓦片、CDN 回源内容）：按 URI 特征分级，例如
/tiles/{z}/{x}/{y}.png可缓存 24h，但/api/v1/status只缓存 5s，用map指令打标：map $request_uri $cache_key { ~^/tiles/ "tile"; ~^/api/ "api"; }，再在 location 中引用 -
穿透保护：缓存未命中时，多个相同请求不该全部打到后端。启用
proxy_cache_lock on，并设proxy_cache_lock_timeout 3s—— 超时后允许第二个请求穿透，避免长尾阻塞
健康检查和失败转移必须可观测、可干预
upstream 的 max_fails 和 fail_timeout 不是调数字游戏。真实生产中：
- 用
health_check interval=3 fails=2 passes=2（需 stream 模块或 http_upstream_hc 模块），比被动失败更早发现异常 - 所有 upstream server 必须配
slow_start=10s，新节点上线后流量线性增加，避免雪崩 - 设置
proxy_next_upstream error timeout http_500 http_502 http_503 http_504，但必须配合日志记录$upstream_addr $upstream_status $upstream_response_time，否则无法区分是网络抖动、后端超时还是真故障
