在 nginx 中使用 proxy_pass 时，代理路径丢失通常是因为 uri 拼接规则未正确配置。若 proxy_pass 指令后的 url 包含路径（如 /api/），nginx 会将匹配到的 location 中的 uri 替换该部分；若 url 不包含路径（如 http://backend），则原始 uri 会完整传递给后端。要解决路径丢失或错误拼接的问题，需根据后端服务的路径结构，显式指定 proxy_pass 的目标地址及尾部斜杠。
带尾随斜杠的 proxy_pass 如何影响 URI 传递
当 proxy_pass 的值包含 URI 路径且以斜杠结尾时，Nginx 会用 location 匹配到的 URI 前缀替换掉 proxy_pass 中的对应路径部分。例如，请求 /api/users 会被转发为 /users。这种机制会导致前端期望的 /api 前缀在后端消失，从而引发 404 错误。解决方法是确保 proxy_pass 的目标地址与后端实际接收的路径前缀严格一致，或者通过正则 location 精确控制匹配行为。
server {
listen 80;
server_name example.com;
# 场景：后端服务运行在 http://127.0.0.1:8080/api/
# 客户端请求 /api/users
location /api/ {
# 注意末尾的斜杠
proxy_pass http://127.0.0.1:8080/api/;
}
}
在上述配置中，客户端请求 /api/users，Nginx 匹配到 location /api/。由于 proxy_pass 包含路径 /api/ 且以斜杠结尾，Nginx 将匹配到的 /api/ 替换为 proxy_pass 中的 /api/，剩余部分 users 追加其后，最终发送给后端的 URI 为 /api/users。如果省略 proxy_pass 末尾的斜杠，即 proxy_pass http://127.0.0.1:8080/api;，则匹配到的 /api/ 会被完全替换为 /api，导致后端收到 /apiusers，造成路径错误。
不带路径的 proxy_pass 如何处理原始 URI
当 proxy_pass 的值仅包含主机名和端口，不包含 URI 路径时，Nginx 会将客户端请求的完整原始 URI 原封不动地传递给后端服务器。这种方式适用于后端服务需要处理完整路径前缀的场景，或者后端应用自身负责路由解析的情况。此时，无论 location 如何定义，URI 都不会被修改。
server {
listen 80;
server_name example.com;
# 场景：后端服务需要接收完整路径 /api/users
location /api/ {
# 注意：无末尾斜杠，且无额外路径
proxy_pass http://127.0.0.1:8080;
}
}
在此配置下，客户端请求 /api/users，Nginx 匹配到 location /api/。由于 proxy_pass 没有指定 URI 路径，Nginx 不会进行任何替换操作，直接将完整的 /api/users 作为 URI 发送给 http://127.0.0.1:8080。后端服务器将接收到 /api/users，这符合大多数 RESTful API 的设计习惯，即由后端根据完整路径进行路由分发。
使用 rewrite 强制保留或修改代理路径
除了调整 proxy_pass 的格式，还可以使用 rewrite 指令在代理前显式修改 URI。这种方法提供了更细粒度的控制，特别适用于需要将特定前缀剥离或添加复杂逻辑映射的场景。通过在 location 块中先执行 rewrite，可以改变内部重定向的 URI，进而影响 proxy_pass 的行为。
server {
listen 80;
server_name example.com;
location /api/ {
# 将 /api/ 开头的请求重写为根路径 /
rewrite ^/api/(.*)$ /$1 break;
proxy_pass http://127.0.0.1:8080;
}
}
当客户端请求 /api/users 时，rewrite 指令将其重写为 /users，并设置 break 标志停止后续 rewrite 规则匹配。随后，proxy_pass 将重写后的 /users 发送给后端 http://127.0.0.1:8080。这种写法常用于后端服务部署在根路径下，而前端需要通过子路径访问的情况。通过 rewrite 显式剥离前缀，确保了后端接收到的是其预期的路径结构，避免了因 proxy_pass 默认拼接规则导致的歧义。
