背景

最早是由于配置的反向代理服务总是返回403，踩坑无数后把我的一些总结归纳一下，可以直接跳过看结果。
这篇文章主要是就拼接规则的一些讨论。

https://www.jianshu.com/p/b010c9302cd0
https://juejin.cn/post/7096064105844310024
https://www.doubao.com/thread/w0952b484c0de55c7

然而实际使用过程中，让我产生很多困惑。比如

请求： /XXX
location /{
		proxy_pass http://192.168.23.25/k3cloud 
		proxy_pass http://192.168.23.25/k3cloud/ 
		
}

根据末尾/的理论，后端请求的地址第一个由于末尾没有带/ ，请求地址应该是直接拼接/XXX，而第二个由于带了/，请求地址应该是请求地址/XXX 去掉匹配规则 /，然后拼接到proxy_pass地址后面，得到的都是 http://192.168.23.25/k3cloud/XXX ，但是这时候第二个配置就可以正常访问，第一个地址会返回403提示权限不足。然而ai回复的前后缀匹配和实际nginx向后端传递的值是一个完整的url前后矛盾。为验证实际过程实操记录一下。

验证

首先配置nginx.conf ，以下面两个为例配置所有转发方法

  server{
            listen 8081  ;
            server_name localhost;
            location /online/wxapi/{
                    proxy_pass http://192.168.23.25;
            	}
            }
    server{
            listen 8082  ;
            server_name localhost;
            location /online/wxapi/{
                    proxy_pass http://192.168.23.25/;
            	}
            }

通过sudo tcpdump -i any host 192.168.23.25 -A 抓包得到后端请求地址

整理所有请求后可以得到下列表格

结论

根据对比可以知道规则其实很简单，对于proxy_pass，直接将 / ,/XXX,/XXX/都识别为带路径的地址，实行的是prox_pass + 请求url - 匹配规则location。
之所以还会出现这么多的问题，我的猜测是nginx的补偿机制，有时候匹配失败后会对//,和无/情况进行自动校准，然而这个机制并不一定发挥作用。当然也可能是nginx 版本迭代了规则但并没有找到相关资料，我的版本是1.24 ，大家可以参考。