alias 仅用于静态文件路径映射，不可与 proxy_pass 混用；反向代理中路径改写应使用 rewrite + proxy_pass，或规范使用 proxy_pass 末尾 uri 实现前缀替换。
alias 在 Nginx 中不适用于反向代理场景，它仅用于 本地文件系统路径映射，与 proxy_pass 无直接配合关系。若在 location 块中同时使用 alias 和 proxy_pass，Nginx 会报错或行为异常（如 404、路径拼接错误），因为二者语义冲突：前者重写 URI 到文件路径，后者转发请求到上游服务。
alias 的真实作用：替换 location 匹配的 URI 前缀为指定目录
它只在 location 块中处理静态资源时生效，例如：
location /static/ {
alias /var/www/assets/;
}
访问 /static/js/app.js 会实际读取 /var/www/assets/js/app.js。注意：alias 值末尾的斜杠必须与 location 路径结尾风格一致，否则易出错。
反向代理中实现“辅助路径映射”的正确方式是 proxy_pass + rewrite
当需要将客户端请求的某段路径（如 /api/v2/）转发到上游服务的另一路径（如去掉 v2 或改写为 /v3/），应使用 rewrite 配合 proxy_pass：
- 用
rewrite修改 $uri，在转发前调整路径 -
proxy_pass后不带 URI（即末尾无斜杠或路径），才能让重写后的路径完整透传 - 示例：把
/api/v2/user改为/user发给后端
location /api/v2/ {
rewrite ^/api/v2/(.*)$ /$1 break;
proxy_pass http://backend;
}
常见误用：proxy_pass 末尾带路径时的隐式路径替换
如果 proxy_pass 指令值包含 URI（如 http://upstream/api/），Nginx 会自动剥离 location 匹配部分，并拼接该 URI —— 这种行为常被当作“路径映射”使用，但本质是 proxy_pass 的内置逻辑，与 alias 无关：
location /old-api/ {
proxy_pass http://backend/new-api/;
}
此时访问 /old-api/users 会转发为 http://backend/new-api/users。这种写法简洁，但灵活性不如 rewrite，且容易因斜杠缺失导致路径粘连（如 proxy_pass http://b/api + location /a/ → 实际发 /a/users 变成 /apiusers）。
总结：别用 alias 做代理路径映射
alias 是静态文件路径重定义指令，proxy_pass 是请求转发指令。两者不可混用。需要路径改写就用 rewrite；需要简单前缀替换就规范使用 proxy_pass 末尾 URI；所有操作都应在 location 精确匹配下进行，避免正则过度捕获或嵌套干扰。
