proxy_pass 后面的斜杠：后端为什么突然收到 404

归档日期：2026-10-27；补录发布：2026-10-28。

反向代理不仅决定请求发给谁，还可能改变后端收到的路径。proxy_pass 尾部有没有斜杠，是功能差别，不只是排版习惯。这篇是学习整理，不表示本站已经部署多节点负载均衡。

先确认后端路径

客户端访问 /api/item.txt，而应用只提供 /item.txt 时，原样转发可能得到 404。下面讨论普通前缀 location，且没有 rewrite 的简单情况。

location /api/ {
    proxy_pass http://127.0.0.1:9001;
}

这里 proxy_pass 没有 URI 部分，后端收到 /api/item.txt。

location /api/ {
    proxy_pass http://127.0.0.1:9001/;
}

有 URI 部分 / 时，匹配的 /api/ 前缀会被替换，后端收到 /item.txt。正则 location、变量和 rewrite 组合另有规则，不能机械套用。

请求头是随行信息

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

这些告诉后端域名、地址与协议，真正决定目标的仍是 proxy_pass。后端需要正确配置可信代理，不能无条件相信公网请求提供的转发头。

分两段验证

先直连后端请求正确路径，再经过 Nginx 请求，比较状态码和后端日志。直连正常而代理失败时，重点看 URI、Host、访问权限和超时。

502 常与上游连接或响应异常有关，504 常与等待超时有关，但仍应以错误日志为依据，不要立即重启所有服务。

本站 PHP-FPM 使用 fastcgi_pass，它不是普通 HTTP 后端，不能把 proxy_pass 地址随手改成 FPM socket。先在隔离环境理解请求路径，再判断业务是否需要代理。

把路径、查询参数与请求头分别核对

示例转发路径先用普通 GET 验证，再加入 ?page=1 观察后端日志。参数、编码、rewrite 和变量可能改变行为，正式配置前需要覆盖业务路径。X-Forwarded-For 可能包含不可信客户端输入，应用必须只信任受控代理链。不要把代理配置当权限认证，也不要靠增加超时掩盖持续缓慢的后端。

内容复核与修订：2026-10-29。实验示例与本站运行记录分别说明；原始归档日期保留。