nginx 本身不直接实现动静分离，而是通过 location 匹配规则结合 proxy_pass 转发至不同 upstream 组来调度动静资源；需先定义 static_backend 和 app_backend 等用途明确的 upstream 分组，再用正则或前缀匹配静态路径/后缀并分别代理，动态请求默认走应用集群，同时注意缓存头设置、斜杠处理及调试方法。
Nginx 通过 upstream 模块本身不直接实现动静分离，而是配合 location 匹配规则 + proxy_pass 转发到不同 upstream 组，从而完成动静资源的流量调度。核心在于“按请求路径或后缀分类”，再将静态请求交给静态资源服务器（如 CDN、对象存储或专用静态节点），动态请求交给应用集群（如后端 API 服务）。
定义多个 upstream 分组
先在 http 块中声明用途明确的 upstream 组，比如：
upstream static_backend {
server 192.168.10.10:8080 weight=3;
server 192.168.10.11:8080 backup;
}
upstream app_backend {
ip_hash; # 保证同一用户会话落到同一台后端
server 192.168.20.100:8000 max_fails=2 fail_timeout=10s;
server 192.168.20.101:8000 max_fails=2 fail_timeout=10s;
}
用 location 匹配规则区分动静请求
在 server 块中，利用正则或前缀匹配识别静态资源路径或后缀，并分别 proxy_pass 到对应 upstream：
- 匹配常见静态后缀（如 .js、.css、.png、.woff2 等）
- 匹配约定好的静态路径前缀（如 /static/、/assets/、/images/）
- 注意：正则 location 优先级高于普通前缀，需合理安排顺序
示例配置：
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2|ttf|eot)$ {
expires 1y;
add_header Cache-Control "public, immutable";
proxy_pass http://static_backend;
}
location ^~ /static/ {
proxy_pass http://static_backend;
}
location / {
# 其他所有请求默认走动态后端
proxy_pass http://app_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
补充关键细节
- 静态 upstream 可进一步对接 CDN 或对象存储（如用
proxy_pass https://cdn.example.com或 OSS endpoint） - 若静态资源托管在本地磁盘，建议直接用
root或alias，避免无谓代理；只有跨机器/跨域/需统一缓存策略时才走 upstream - 动静分离后，务必在静态响应中设置合适的
Expires和Cache-Control，减少重复回源 - 可结合
map指令做更灵活的路由判断（例如根据 User-Agent 或请求头决定是否走静态集群）
验证与调试技巧
- 用
curl -I查看响应头中的X-Upstream（可自定义添加）确认转发目标 - 开启
error_logdebug 级别，观察 location 匹配过程 - 注意：
proxy_pass后的 URL 尾部斜杠会影响路径重写行为（如proxy_pass http://static_backend/会剥离匹配前缀）
