响应时间优化需从连接建立、请求处理、后端交互、内容传输、缓存命中五环节逐层收紧：调优worker_processes与worker_connections、启用epoll和keepalive、配置sendfile与gzip/brotli、合理设置proxy超时与缓冲、分级实施浏览器/代理/文件缓存。
响应时间优化不是调一个参数就能见效的事，得从连接建立、请求处理、后端交互、内容传输、缓存命中这五个环节逐层收紧。
连接与并发配置
Nginx 启动多少进程、每个进程能同时处理多少连接，直接决定它能不能扛住瞬时流量。进程数设少了会排队，设多了反而争抢 CPU；连接数太低会频繁断连，太高又吃光内存。
-
worker_processes 设为
auto或等于 CPU 核心数（如 8 核就设 8），避免空转或过度调度 - worker_connections 按内存调整：16GB 内存可设 4096，32GB 可设 8192
- 在
events块中启用use epoll;（Linux）和multi_accept on;，让每个进程一次收完所有待处理连接 - 开启
keepalive_timeout 75;和keepalive_requests 1000;，复用 TCP 连接，省掉三次握手开销
传输效率与压缩
发出去的数据越小、越快打包、越少分包，用户感知的延迟就越低。尤其对文本类资源，压缩和传输方式影响巨大。
- 启用
sendfile on;和tcp_nopush on;，让内核直接送文件到网卡，绕过用户态拷贝 - Gzip 开启并设合理阈值：
gzip on; gzip_min_length 500; gzip_comp_level 6; - 支持 Brotli 更进一步（需编译模块）：
brotli on; brotli_comp_level 8; brotli_min_length 20; - HTTP/2 必开：
listen 443 ssl http2;，多路复用+头部压缩，减少队头阻塞
反向代理与上游交互
很多慢响应其实卡在 Nginx 等后端——连不上、发不出、收不到。超时和缓冲设置不当，会让一个慢请求拖垮整条流水线。
- 为每个
location明确设置超时：proxy_connect_timeout 3s; proxy_send_timeout 5s; proxy_read_timeout 5s; - 增大缓冲区避免流式响应被截断：
proxy_buffer_size 128k; proxy_buffers 8 128k; - 加
proxy_set_header Connection '';防止后端错误关闭 keepalive - 用
$upstream_response_time日志字段判断是 Nginx 本身慢，还是后端拖后腿
缓存策略与静态资源
不查数据库、不跑脚本、不走网络，直接从内存或磁盘返回结果，这是响应时间最硬的压缩方式。
- 浏览器端缓存：对图片、JS、CSS 加
expires 365d;和Cache-Control public - 代理缓存：配置
proxy_cache_path+proxy_cache，对 API 响应按状态码分级缓存（如200 10m; 404 1m;） - 文件句柄缓存：
open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s;，减少 stat 系统调用 - 日志里加
cache=$upstream_cache_status，一眼看出 MISS 是策略问题还是冷启动
