Nginx 中怎么排查 proxy_pass 结尾斜杠语法隐患
排查 nginx proxy_pass 的斜杠隐患，核心是检查请求 uri 与后端路径拼接时是否出现双斜杠或路径丢失。当 proxy_pass 指令后的 url 包含路径且没有以斜杠结尾时，nginx 会将客户端请求的完整 uri 追加到该 url 之后；若 url 以斜杠结尾，则仅传递 location 匹配部分之后的剩余 uri。这种差异会导致后端应用收到错误的请求路径，从而引发 404 错误或逻辑异常。
如何验证无尾随斜杠时的路径拼接行为
在无尾随斜杠的情况下，Nginx 执行的是“替换前缀”操作。假设配置为 proxy_pass http://backend/api;，当客户端请求 /api/user/list 时，Nginx 会尝试将 /api 替换为空字符串，并将剩余的 /user/list 拼接到后端地址后，最终转发给后端的请求路径为 /user/list。如果后端应用期望接收的路径是 /api/user/list，就会因为路径不匹配而失败。这种行为类似于字符串的前缀替换，而非简单的拼接。
server {
listen 80;
server_name example.com;
# 场景：无尾随斜杠
location /api/ {
proxy_pass http://127.0.0.1:8080/api;
}
}
在上述配置中，访问 http://example.com/api/test，Nginx 实际向后端发送的请求行是 GET /test HTTP/1.1。这是因为 location 匹配了 /api/，而 proxy_pass 指定了 /api（注意这里没有斜杠），Nginx 会用 /api 替换掉请求中的 /api/ 部分，剩下的 test 被保留并加上根路径 / 发送给后端。如果后端服务部署在 /api 上下文下，它可能无法识别 /test 这个路径。
如何验证有尾随斜杠时的路径截取行为
在有尾随斜杠的情况下，Nginx 执行的是“路径截取”操作。配置为 proxy_pass http://backend/api/; 时，Nginx 会将客户端请求中位于 location匹配路径之后的部分传递给后端。例如，客户端请求 /api/user/list，Nginx 会截取 /api/ 之后的 user/list，并将其附加到后端地址的根路径下，最终转发给后端的请求路径为 /user/list。这与无斜杠的情况在某些特定配置下结果相似，但逻辑完全不同，特别是在处理嵌套 location 或正则匹配时差异巨大。
server {
listen 80;
server_name example.com;
# 场景：有尾随斜杠
location /api/ {
proxy_pass http://127.0.0.1:8080/api/;
}
}
在上述配置中，访问 http://example.com/api/test，Nginx 实际向后端发送的请求行是 GET /test HTTP/1.1。这是因为 location 匹配了 /api/，而 proxy_pass 也指定了 /api/，Nginx 会移除请求中与 location 匹配的部分（即 /api/），将剩余的 test 附加到后端地址后。如果后端应用期望接收的路径是 /api/test，同样会失败。关键在于理解 Nginx 是如何决定“保留”还是“替换” URI 部分的。
基于 proxy_pass 路径与 location 匹配关系的冲突问题
当 proxy_pass 的路径与 location 的定义不一致时，会产生难以察觉的路径错误。例如，location /app/ 配合 proxy_pass http://backend/service/;，请求 /app/foo 会被转换为 /service/foo 吗？不会。Nginx 会先匹配 /app/，然后因为 proxy_pass 有斜杠，它会截取 /app/ 之后的 foo，并拼接到 http://backend/service/ 后面，得到 /service/foo。这通常不是开发者想要的，开发者往往希望保持原始路径结构或进行更精确的重写。排查此类问题时，应仔细比对 location 前缀和 proxy_pass 前缀的一致性，确保它们要么都带斜杠，要么都不带，或者使用 rewrite 指令显式控制 URI 变换。
