动静分离是性能优化的前提而非终点，Nginx反向代理通过精准分流、减压后端、提升缓存效率和降低网络开销实现优化，需围绕请求识别、缓存策略、连接管理与资源隔离四方面展开。
动静分离本身不是性能优化的终点，而是为后续优化提供前提。Nginx反向代理在这一架构中，核心价值在于精准分流、减少后端压力、提升缓存效率和降低网络开销。优化路径需围绕请求识别、缓存策略、连接管理与资源隔离四方面展开。
精准识别静态资源，避免误判穿透
静态资源识别不准会导致本该本地响应的请求被转发至后端，白白消耗代理和应用层资源。关键不在扩展名列表多长，而在匹配逻辑是否前置、是否可维护。
- 用 location ^~ /static/ 或 location ~* \.(js|css|png|jpg|gif|woff2)$ 明确静态路径前缀或后缀，优先级高于正则匹配
- 避免在 location / 中用 if ($request_filename ~ …) 判断文件是否存在——这会触发额外的文件系统调用，且 if 在 location 外不支持 break，易引发重写混乱
- 对构建产物带哈希（如 app.a1b2c3.js）的项目，可统一收口到 /static/ 目录下，用前缀匹配替代大量正则，提升路由匹配速度
静态资源启用高效缓存，减少重复传输
缓存不是简单加个 expires，而是要区分资源类型、生命周期和客户端行为，兼顾 CDN 协同与浏览器复用。
- 对指纹化资源（含 hash 的 js/css/img），设置 expires max 和 add_header Cache-Control "public, immutable"，让浏览器长期缓存且不校验
- 对无版本控制的通用资源（如 /favicon.ico、/robots.txt），设 expires 1h + Cache-Control "public, max-age=3600"，平衡更新及时性与缓存收益
- 禁用 ETag（etag off）：Nginx 默认基于 mtime+size 生成 ETag，但静态文件常由构建工具产出，mtime 不稳定；关闭后配合强缓存更可靠
动态请求精简代理链路，降低延迟抖动
反向代理不该成为动态请求的瓶颈。重点是减少不必要的处理、复用连接、限制资源滥用。
- 关闭动态 location 下的 sendfile 和 tcp_nopush（它们针对文件传输优化，对 upstream 响应无效甚至有害）
- 配置 proxy_http_version 1.1 + proxy_set_header Connection ""，启用上游 keepalive，避免频繁建连；同时 upstream 块中定义 keepalive 32（连接池大小）
- 对非 GET/HEAD 请求（如 POST），默认不缓存，但可加 proxy_cache_bypass $http_pragma $http_authorization 防止脏缓存误生效
资源隔离与连接管控，防止单点拖垮整体
静态与动态流量特征差异大，混用 worker 连接或超时参数易相互干扰。需从进程、连接、超时三层面做硬隔离。
- 用不同 upstream 块分别定义静态服务（如本地磁盘）和动态服务（如 http://backend:8000），不共用 name 和参数
- 静态 location 中设 proxy_read_timeout 5（足够读取文件头），动态 location 中设 proxy_read_timeout 60（容忍慢业务），避免超时一刀切
- 限制单 IP 并发连接数：limit_conn perip 16（配合 limit_conn_zone $binary_remote_addr zone=perip:10m），尤其防范爬虫或异常请求打爆静态资源线程
不复杂但容易忽略的是：所有优化都依赖真实请求路径与资源部署方式的一致性。上线前用 curl -I 和 Chrome Network 面板交叉验证响应头、状态码与缓存行为，比调参数更重要。
