NG 性能调优与 FAQ

首先要看进程是否真的需要更多连接。通常把 worker_processes 设为 auto，再把 worker_rlimit_nofile 打开，并通过连接状态确认 TIME_WAIT 与 ESTABLISHED 的比例。若只是等待中的请求很多，需要看 upstream 处理速度与后端应用线程，不能只依赖前端排队。

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 4096;
    multi_accept on;
    use epoll;
}

修改后用 nginx -s reload 加载，并检查错误日志是否仍出现 worker_connections are not enough。若仍然出现，再考虑 worker_connections 与单连接内存占用之间的平衡。

日志中出现 upstream timed out 时，先确认是针对单次慢请求，还是一段时间内普遍超时。若属于应用正常处理需超过默认 60 秒的场景，可把 read 超时放宽；若大量请求都在连接阶段失败，则应观察后端健康状态与连接队列。

location /api/ {
    proxy_connect_timeout 5s;
    proxy_read_timeout  30s;
    proxy_send_timeout  30s;
    proxy_next_upstream error timeout http_504;
}

设置完可用 curl -I http://127.0.0.1/ 测试连通与首包时间。真正的慢接口建议在前端看耗时分布，而不是用同一组超时覆盖全部请求。

常用 proxy_cache 前，需要确认上游返回的 Cache-Control 是否允许缓存。Nginx 不会把带 no-cache、Set-Cookie 或私有标记的响应写入共享缓存。可以先查看静态资源响应头，确认是否有较长 max-age，再检查 proxy_cache_path 的空间与 key 是否匹配。

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=imgcache:64m max_size=2g inactive=60m;

location /static/ {
    proxy_cache imgcache;
    proxy_cache_valid 200 60m;
    proxy_set_header Host $host;
}

验证缓存命中时，可关注响应头中的 HIT / MISS 状态，并检查 /var/cache/nginx 下是否产生实际缓存文件。

499 是客户端在 Nginx 收到完整响应前主动断开连接，常见原因为客户端超时或请求被取消；504 是 Nginx 在设定的 proxy_read_timeout 内没有等到上游响应。两者处理路径不同：499 优先查客户端等待时长与负载均衡策略；504 优先查上游应用耗时与健康检查。

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$upstream_response_time"';

access_log /var/log/nginx/access.log main;

若同一上游频繁 504，可在 upstream 配置中加入 max_fails 与 fail_timeout，让临时不健康节点尽快被切出，而不是在单台机器上反复等待。

开启 gzip 还要注意 gzip_types 是否包含目标 MIME 类型，以及客户端请求是否携带 Accept-Encoding: gzip。代理场景下，Nginx 需要与被代理端协商压缩来源，否则上游可能已经输出未压缩内容。

gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/plain text/css text/js
           application/javascript application/json
           application/xml image/svg+xml;

用一条命令就能确认当前响应内容编码：

curl -I -H 'Accept-Encoding: gzip' http://127.0.0.1/static/app.js

返回头中出现 Content-Encoding: gzip，说明压缩生效。图片、音视频等已压缩格式通常不在 Gzip 收益范围内。

绝大多数配置变更不需要 restart，使用 nginx -t 校验后执行 nginx -s reload 即可完成平滑加载。reload 会让 worker 进程逐个更新，master 进程 PID 保持不变，连接不会全部中断。

nginx -t && nginx -s reload

# 用 -T 查看当前真正生效的配置
ps -ef | grep nginx
nginx -T 2>/dev/null | grep -E 'worker_|proxy_'

若不放心，可以在 reload 后立刻观察 error.log 是否出现正常加载记录，再用 curl 访问一个受影响的 URL，确认状态码与耗时没有异常。