反向代理通过路径和文件类型识别实现动静分离，静态资源由Nginx直接响应并缓存，API请求才转发至后端upstream；SPA的HTML入口需兜底返回/index.html，构建哈希文件可正则匹配，CDN与灰度路径进一步优化分流。
反向代理本身不“显式绑定”静态资源流，而是通过配置规则实现对请求路径、文件类型或响应头的识别与分流。在大型单页应用（SPA）中，所谓“精准提取静态负载均衡流”，本质是把 HTML 入口、JS/CSS/图片等静态资源与 API 接口请求分离处理——前者走缓存+CDN+本地响应路径，后者才进入后端服务器集群做负载均衡。关键不在“绑定”，而在“区分”和“路由”。
明确 SPA 的静态资源特征
大型 SPA 通常只有一个 HTML 入口（如 /index.html），其余 JS、CSS、字体、图片等由构建工具（Webpack/Vite）生成带哈希的文件名（如 main.a1b2c3.js）。这类资源具备强缓存性、无状态性、可预判路径规律等特点，是反向代理精准识别和分流的基础。
- 所有以 .js、.css、.png、.woff2 等结尾的请求，基本可判定为静态资源
- 构建产物常集中于 /static/、/assets/ 或根路径下带哈希的文件，可通过正则匹配（如
^/(static|assets|.*\.(js|css|png|jpg|woff2))$）捕获 - HTML 入口需特殊处理：除 / 外，SPA 路由（如 /user/profile）也应返回 /index.html，避免 404
用 location 块做细粒度路径分流
Nginx 中不依赖 upstream 就能完成静态资源的“零转发”——直接从本地磁盘读取并返回，这才是真正的“提取”而非“均衡”。只有非静态路径（如 /api/、/graphql）才交由 upstream 做负载均衡。
- 静态资源全部命中
location ~* \.(js|css|png|jpg|gif|ico|woff2|ttf|svg)$，启用expires 1y和add_header Cache-Control "public, immutable" - HTML 入口统一由
location = /和location /（配合try_files $uri $uri/ /index.html）兜底 - API 请求限定在
location ^~ /api/或location /graphql，内部 proxy_pass 到 upstream server group
避免把静态资源也塞进 upstream
常见误区是把所有请求都丢给 upstream，再靠后端判断是否静态——这完全违背反向代理的设计初衷，徒增延迟、浪费连接、绕过缓存。真正高效的方案是让 Nginx 在第一层就完成“动静分离”：
- upstream 块只定义后端应用服务器（如 Tomcat、Node.js API 服务），不包含静态文件服务节点
- 静态资源不走 proxy_pass，而是用
root或alias指向构建产物目录（如/var/www/dist） - 若使用 CDN，可将静态资源域名（如
static.example.com）CNAME 到 CDN，Nginx 仅负责 HTML 和 API，进一步卸载压力
补充：灰度与版本路径可辅助识别
部分 SPA 会通过 URL 路径携带版本信息（如 /v2.3.1/）或环境标识（如 /staging/），这些前缀可用于更精细的静态资源路由：
-
location ^~ /v[0-9]+\.[0-9]+\.[0-9]+/→ 直接映射到对应版本静态目录 -
location ^~ /staging/→ 指向 staging 构建产物，与 production 物理隔离 - 配合
map指令，还可根据请求头（如X-Env）动态切换 root 路径，实现多环境共存
