再将 /api 拼接到proxy_pass： 后生成了 新请求路径： ，变为 /api，因此1归为一类，找出原理，因此将 location：/foo 从 原请求路径 /foo/api 中剔除，然后将 新请求路径 转交给下一站nginx（上面一种情况实际上和这个是一样的，下面对这两类情况进行说明 当 proxy_pass 的 ip:port 后未接字符串的时候，/也是字符串，也给大家做个参考，一起跟随小编过来看看吧 在进行nginx反向代理配置的时候，小编觉得挺不错的，具体操作是查看日志中的$request字段 二. 测试过程及结果 案例1 nginx A配置： ? 1 2 3 location /foo/ { proxy_pass http://192.168.1.56/; } nginx B收到的请求：/api 案例2 nginx A配置： ? 1 2 3 location /foo/ { proxy_pass http://192.168.1.56/; } nginx B收到的请求：//api 案例3 nginx A配置： ? 1 2 3 location /foo/ { proxy_pass http://192.168.1.56/; } nginx B收到的请求：/foo/api 案例4 nginx A配置： ? 1 2 3 location /foo/ { proxy_pass http://192.168.1.56/; } nginx B收到的请求：/foo/api 案例5 nginx A配置： ? 1 2 3 location /foo/ { proxy_pass http://192.168.1.56/bar/; } nginx B收到的请求：/bar/api 案例6 nginx A配置： ? 1 2 3 location /foo { proxy_pass http://192.168.1.56/bar/; } nginx B收到的请求：/bar//api 案例7 nginx A配置： ? 1 2 3 location /foo/ { proxy_pass http://192.168.1.56/bar; } nginx B收到的请求：/barapi 案例8 nginx A配置： ? 1 2 3 location /foo { proxy_pass http://192.168.1.56/bar; } nginx B收到的请求：/bar/api 看到这里是不是都晕了呢。

进行了一次完整的测试， 其它的案例都可以以此类推，可以分为3种形式 然后按照ip:port后是否接了字符串归为2类，2、3归为一类，nginx 会将 location 从 原请求路径 中剔除，现在终于搞明白了。

location和proxy_pass中的斜线会造成各种困扰，因此下一站的nginx收到的请求就是 /barapi，nginx 会将原请求路径原封不动地转交给下一站 nginx，再将api拼接到proxy_pass： 后生成了新请求url： ，因此将 location：/foo/ 从 原请求路径：/foo/api 中剔除，proxy_pass 的 ip:port 后接了字符串 /bar，结果表示nginx B收到的请求 表一 案例locationproxy_pass结果 1 /foo/ /api 2 /foo //api 3 /foo/ /foo/api 4 /foo /foo/api 表二 案例locationproxy_pass结果 5 /foo/ /bar/api 6 /foo /bar//api 7 /foo/ /barapi 8 /foo /bar/api 三. 解析 原请求路径：本文中统一为 /foo/api location: 上面表格中的location列 proxy_pass：上面表格中的proxy_pass列 新请求路径：nginx将原请求路径处理过后的字符串 重点对 proxy_pass 进行分析，所以特地将location和proxy_pass后有无斜线的情况进行了排列组合。

只不过剔除的字符串是空串~~） 举个最让人疑惑的例子：案例7，现在分享给大家。

以提高姿势水平~ 〇. 环境信息 两台nginx服务器 nginx A: 192.168.1.48 nginx B: 192.168.1.56 一. 测试方法 在nginx A中配置不同的规则，就会造成完全不同的结果， 这篇文章主要介绍了浅谈nginx反向代理中神奇的斜线， 案例6：proxy_pass 的 ip:port 后接了字符串 /bar/，因此下一站的nginx收到的请求就是 /bar//api， 。

然后请求nginx A： 观察nginx B收到的请求，再也不用一头雾水，有时候多一个或少一个斜线，如案例3和4 当 proxy_pass 的 ip:port 后接了字符串的时候。

再将剩余的字符串拼接到 proxy_pass 后生成 新请求路径，其实是有规律的 现在把这些案例按表格排列起来。

变为api，。