nginx性能监控、压缩加速与缓存调优需分层协同：监控覆盖连接/请求/资源三层并对接prometheus+grafana；压缩按类型分级启用gzip/brotli，排除已压缩格式；缓存实施客户端/cdn/nginx三级策略，动静分离；全部配置标准化为可审计、可灰度的代码化交付单元。
要在 Nginx 中构建一套可落地、可度量、可持续维护的性能监控、压缩加速与缓存调优标准化体系，关键不是堆砌参数，而是分层协同：监控是眼睛，压缩是减负，缓存是分流。三者需统一规划、配置闭环、验证反馈。
一、性能监控：让服务状态“看得见、说得清”
监控不是加个 status 页面就完事，而是要覆盖连接、请求、资源三层指标，并支持自动化采集。
-
启用 stub_status 模块（编译时必须含
--with-http_stub_status_module）：
在 server 或 location 块中配置：location /nginx-status {<br> stub_status on;<br> access_log off;<br> allow 127.0.0.1;<br> deny all;<br>}
返回内容含 Active connections、accepts、handled、requests 等核心计数器。 -
暴露 Prometheus 格式指标（推荐使用 nginx-lua-prometheus）：
通过 Lua 脚本采集 request time、upstream response time、cache hit/miss 等细粒度数据，直接对接 Prometheus + Grafana 实现可视化告警。 -
日志结构化输出：
定义自定义 log_format，嵌入 $request_time、$upstream_response_time、$cache_status、$bytes_sent：log_format main '$remote_addr - $remote_user [$time_local] "$request" '<br> '$status $body_bytes_sent "$http_referer" '<br> '"$http_user_agent" $request_time $upstream_response_time $cache_status';
配合 Filebeat + ELK 或 Loki 可快速分析慢请求、缓存失效率、异常响应分布。
二、压缩加速：精准压缩，不压不传
Gzip 是基础，但仅开 gzip on 远不够；Brotli 是进阶，但需客户端支持；关键是按内容类型、大小、响应码分级处理。
-
启用 Gzip 并精细控制：
gzip on;<br>gzip_vary on;<br>gzip_min_length 1024;<br>gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;<br>gzip_comp_level 5;<br>gzip_disable "msie6";
注意：gzip_vary on让 CDN/代理知道响应可能被压缩，避免缓存歧义。 -
补充 Brotli（需编译时加入 --with-http_brotli_module）：
brotli on;<br>brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;<br>brotli_comp_level 6;
现代浏览器（Chrome/Firefox/Edge）均支持，压缩率比 Gzip 高 15%~20%，建议与 Gzip 共存，由 Accept-Encoding 自动协商。 -
禁止压缩已压缩资源：
对 .jpg、.png、.webp、.woff2 等二进制格式，明确排除在 gzip_types/brotli_types 外，避免 CPU 浪费和体积增大。
三、缓存调优：分层缓存，动静有别
缓存不是“全开 expires”，而是建立三级缓存策略：客户端强缓存 → CDN 边缘缓存 → Nginx 本地代理缓存，各司其职。
-
静态资源：客户端 + CDN 双强缓存：
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2|ttf|eot)$ {<br> expires 1y;<br> add_header Cache-Control "public, immutable";<br> add_header Last-Modified "";<br> access_log off;<br>}immutable告诉浏览器该资源永不变更（配合文件名哈希），彻底规避协商请求。 -
动态接口：反向代理级缓存（proxy_cache）：
proxy_cache_path /var/cache/nginx/api levels=1:2 keys_zone=api_cache:100m max_size=1g inactive=30m use_temp_path=off;<br>upstream api_backend {<br> server 127.0.0.1:8000;<br>}<br>location /api/ {<br> proxy_pass http://api_backend;<br> proxy_cache api_cache;<br> proxy_cache_valid 200 302 10m;<br> proxy_cache_valid 404 1m;<br> add_header X-Cache-Status $upstream_cache_status;<br>}
通过$upstream_cache_status返回 HIT/MISS/EXPIRED，便于前端或监控识别缓存效果。 -
文件系统级缓存优化（open_file_cache）：
open_file_cache max=10000 inactive=60s;<br>open_file_cache_valid 30s;<br>open_file_cache_min_uses 2;<br>open_file_cache_errors on;
显著降低频繁读取静态文件时的 stat() 系统调用开销，尤其适用于大量小文件场景。
四、标准化落地：配置即代码，变更可追溯
避免手工改 conf，把整套体系固化为可复用、可审计、可灰度的交付单元：
- 将监控、压缩、缓存相关配置抽离为独立 include 文件（如
conf.d/monitor.conf、conf.d/compress.conf、conf.d/cache.conf）； - 所有配置项附带注释说明作用、适用场景、生效条件（例如 “仅当启用 stub_status 模块时有效”）；
- 配合 CI/CD，在 reload 前自动执行
nginx -t+ 基础语法校验 + 关键 header 检查（如是否漏配Cache-Control）； - 每次变更记录 commit message 明确标注影响范围（如 “/static/ 缓存周期从 7d 延至 1y，需同步更新构建流程哈希策略”）。
