nginx反向代理配置里的location 反斜杠用法

两台nginx服务器

nginx A: 192.168.1.48

nginx B: 192.168.1.56

一. 测试方法

在nginx A中配置不同的规则,然后请求nginx A: http://192.168.1.48/foo/api

观察nginx B收到的请求,具体操作是查看:'http://'.$_SERVER['HTTP_HOST'].$_SERVER['PHP_SELF'].'?'.$_SERVER['QUERY_STRING'];

二. 测试过程及结果

案例1

nginx A配置:

 

location /foo/ {
  proxy_pass http://192.168.1.56/;
} 

 

nginx B收到的请求:/api

案例2

nginx A配置:

 

location /foo {
  proxy_pass http://192.168.1.56/;
} 

 

nginx B收到的请求://api

案例3

nginx A配置:

 

location /foo {
  proxy_pass http://192.168.1.56;
} 

 

nginx B收到的请求:/foo/api

案例4

nginx A配置:

 

location /foo/ {
  proxy_pass http://192.168.1.56;
} 

 

 

nginx B收到的请求:/foo/api

案例5

nginx A配置:

 

location /foo/ {
  proxy_pass http://192.168.1.56/bar/;
} 

 

nginx B收到的请求:/bar/api

案例6

nginx A配置:

 

location /foo {
  proxy_pass http://192.168.1.56/bar/;
} 

 

nginx B收到的请求:/bar//api

案例7

nginx A配置:

 

location /foo/ {
  proxy_pass http://192.168.1.56/bar;
} 

 

nginx B收到的请求:/barapi

案例8

nginx A配置:

 

location /foo {
  proxy_pass http://192.168.1.56/bar;
} 

 

nginx B收到的请求:/bar/api

看到这里是不是都晕了呢,其实是有规律的

现在把这些案例按表格排列起来,结果表示nginx B收到的请求

表一

 
案例locationproxy_pass结果
1 /foo/ http://192.168.1.48/ /api
2 /foo http://192.168.1.48/ //api
3 /foo/ http://192.168.1.48 /foo/api
4 /foo http://192.168.1.48 /foo/api

 

 

 

 

 

 

 

表二

 
案例locationproxy_pass结果
5 /foo/ http://192.168.1.48/bar/ /bar/api
6 /foo http://192.168.1.48/bar/ /bar//api
7 /foo/ http://192.168.1.48/bar /barapi
8 /foo http://192.168.1.48/bar /bar/api

 

 

 

 

 

 

 

. 解析

原请求路径:本文中统一为 "/foo/api"

location: 上面表格中的location列

proxy_pass:上面表格中的proxy_pass列

新请求路径:nginx将原请求路径处理过后的字符串

重点对 proxy_pass 进行分析,可以分为3种形式

然后按照ip:port后是否接了字符串归为2类,"/"也是字符串,因此1归为一类,2、3归为一类,下面对这两类情况进行说明

当 proxy_pass 的 ip:port 后未接字符串的时候,nginx 会将原请求路径原封不动地转交给下一站 nginx,如案例3和4

当 proxy_pass 的 ip:port 后接了字符串的时候,nginx 会将 location 从 原请求路径 中剔除,再将剩余的字符串拼接到 proxy_pass 后生成 新请求路径,然后将 新请求路径 转交给下一站nginx(上面一种情况实际上和这个是一样的,只不过剔除的字符串是空串~~)

举个最让人疑惑的例子:案例7。proxy_pass 的 ip:port 后接了字符串 "/bar",因此将 location:"/foo/" 从 原请求路径:"/foo/api" 中剔除,变为"api",再将"api"拼接到proxy_pass: http://192.168.1.48/bar 后生成了新请求url:" http://192.168.1.48/barapi ",因此下一站的nginx收到的请求就是 "/barapi"。

案例6:proxy_pass 的 ip:port 后接了字符串 "/bar/",因此将 location:"/foo" 从 原请求路径 "/foo/api" 中剔除,变为 "/api",再将 "/api" 拼接到proxy_pass: http://192.168.1.48/bar/ 后生成了 新请求路径:" http://192.168.1.48/bar//api ",因此下一站的nginx收到的请求就是 /bar//api。

其它的案例都可以以此类推,现在终于搞明白了,再也不用一头雾水。

转载 https://www.jb51.net/article/146975.htm,仅供自己学习

posted on   泽一年  阅读(21514)  评论(2编辑  收藏  举报

编辑推荐:
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
阅读排行:
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· C#/.NET/.NET Core优秀项目和框架2025年2月简报
· Manus爆火,是硬核还是营销?
· 终于写完轮子一部分:tcp代理 了,记录一下
· 【杭电多校比赛记录】2025“钉耙编程”中国大学生算法设计春季联赛(1)

导航

< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5
点击右上角即可分享
微信分享提示