Nginx配置proxy_pass时出现301重定向而非代理的问题咨询

这是Nginx处理location与proxy_pass组合时的路径匹配拼接规则导致的，具体可以拆解为以下核心原因：

1. 无结尾斜杠的location /foo的路径处理逻辑 #

当你配置location /foo（不带结尾斜杠）时，Nginx会匹配所有以/foo开头的请求（比如/foo/bar）。结合proxy_pass http://localhost:7777/（带结尾斜杠），Nginx会执行两步路径拼接：

• 从请求URI中完整移除location匹配的前缀/foo，得到剩余路径/bar
• 将剩余路径直接拼接到proxy_pass的目标地址后，最终生成http://localhost:7777//bar（注意这里出现了双斜杠//）

2. 双斜杠触发后端服务的标准化重定向 #

Nginx本身不会直接返回301，但你的后端服务（localhost:7777）收到//bar这类非标准化URI时，绝大多数HTTP服务（比如Nginx自身、Apache、Node.js Express等）都会自动执行URI标准化——将多个连续斜杠合并为单个斜杠，并通过301永久重定向到规范后的路径/bar，这就是你看到301响应的根源。

3. 带结尾斜杠的location /foo/的修复逻辑 #

当你给location加上结尾斜杠（改为location /foo/）时，Nginx的路径拼接规则发生了关键变化：

• 此时location匹配的前缀是/foo/，对于请求/foo/bar，移除前缀后得到的剩余路径是bar（前面没有斜杠）
• 拼接到proxy_pass的目标地址后，生成的是http://localhost:7777/bar（单斜杠的标准化路径）
• 后端服务收到规范URI后，不会触发重定向逻辑，直接返回正常响应

额外验证建议 #

你可以在配置中添加proxy_set_header Host $host;，然后查看后端服务的访问日志，就能直观看到两种配置下后端收到的请求URI分别是//bar和/bar，进一步坐实双斜杠是引发301的核心原因。

关于官方文档的细节：其实在proxy_pass的文档中隐含了这种拼接差异——当location为不带结尾斜杠的前缀匹配，且proxy_pass带结尾斜杠时，会严格按剩余路径拼接，容易产生非标准化URI；而带结尾斜杠的location会自动适配拼接逻辑，避免这类问题。

备注：内容来源于stack exchange，提问作者javamonster