proxy_pass在动静分离中精准转发动态请求并直供静态资源，需严格匹配location路径、透传X-Forwarded头信息、调优超时与健康检查，并确保静态规则优先级高于动态代理。
在动静分离架构中，proxy_pass 的核心作用是把动态请求（如 /api/、/user/）精准转发给后端应用服务，同时让静态资源（如 .js、.css、/static/）由 Nginx 直接响应，不经过后端。配置关键不在“能不能写”，而在于路径匹配是否严谨、协议与头信息是否透传、以及是否规避常见陷阱。
明确 location 匹配规则，避免路径错位
动静分离依赖精确的 location 分段。动态接口通常有统一前缀（如 /api/），需用带尾部斜杠的前缀匹配，确保子路径完整传递：
- ✅ 正确写法（推荐）：
location /api/ { proxy_pass http://backend_server/; }
→ 请求/api/v1/users会被转为http://backend_server/v1/users（自动剥离/api/） - ❌ 错误写法：
location /api/ { proxy_pass http://backend_server; }（末尾无/）
→ 同样请求会变成http://backend_server/api/v1/users，后端可能 404 - ⚠️ 注意：若后端要求保留
/api前缀，应改用重写：location /api/ { rewrite ^/api/(.*)$ /$1 break; proxy_pass http://backend_server; }
透传必要请求头与协议信息
后端服务常依赖原始客户端 IP、协议类型（HTTP/HTTPS）做鉴权或生成跳转链接。默认情况下，Nginx 不传递这些信息，需显式配置：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 添加标准代理头：
proxy_set_header Host $host;<br>proxy_set_header X-Real-IP $remote_addr;<br>proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;<br>proxy_set_header X-Forwarded-Proto $scheme;
- 若前端使用 HTTPS，但 Nginx 与后端走 HTTP，
X-Forwarded-Proto可帮后端识别真实协议，避免重定向循环 - 避免覆盖原始
Host：不设proxy_set_header Host会导致后端收到的是 upstream 地址（如backend_server），影响虚拟主机路由或 CORS 判断
适配后端健康与超时行为
动态接口往往耗时较长（如含数据库查询、远程调用），默认超时值（60 秒）易触发 Nginx 504。需按业务特征调整：
- 延长关键超时参数：
proxy_connect_timeout 5s;<br>proxy_send_timeout 60s;<br>proxy_read_timeout 120s;
- 启用健康检查（配合 upstream）：
在upstream块中加入health_check interval=3 fails=2 passes=2;，Nginx 会主动探测后端可用性，自动摘除异常节点 - 对非幂等接口（如 POST /api/order），禁用重试可避免重复提交：
proxy_next_upstream off;或仅限特定错误码：proxy_next_upstream error timeout http_500;
与静态资源规则共存，确保无冲突
动静分离要求静态规则优先级高于动态代理。Nginx 的 location 匹配遵循“最长前缀匹配 + 精确匹配优先”原则，需注意顺序和修饰符：
- 静态资源建议用
=（精确）或^~（前缀不正则）提升效率：location = /favicon.ico { log_not_found off; expires 1d; }location ^~ /static/ { root /data/www; expires 1h; } - 动态接口用普通前缀匹配即可：
location /api/ { proxy_pass http://java_backend/; ... } - 避免用正则 location（
~或~*）包裹所有路径，否则可能意外覆盖静态规则或降低性能
