nginx下URL末尾自动加斜杠

服务器上用的nginx，在地址栏输入网址，例如www.xxx.com.cn/aaa后会跳到localhost/aaa

而如果输入的是www.xxx.com.cn/aaa/则正常

一直找不到原因，今天抽时间查了查终于找到解决方案了

其实就是加一条配置

server {

    listen 80;

}

改为

server {

    listen 80;

    server_name_in_redirect off;

}

即可，这时再访问www.xxx.com.cn/aaa即可正常访问

 

PS. 好像这种问题只会在老版本的nginx里出现，0.8.48版本之后的似乎已经变为默认配置了，未经验证
————————————————
版权声明：本文为CSDN博主「geagerg」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/geagerg/article/details/46480779

 

 

 

一、首先对比说明Nginx以下两个现象：

1. 访问的uri最后带斜杠

　　http://localhost/product/    >>>>  查找 product下的index页面，存在就返回；不存在且未开启自动索引目录选项(指令是:autoindex on)，则报403错误

2. 访问的uri最后不带斜杠

　　http://localhost/product     >>>>  查找product文件，存在就返回；若存在product的文件夹，会产生301跳转，且自动将uri补全为http://localhost/product/ ，跳转的域名由server_name_in_redirect 指令控制（下文介绍）

二、server_name_in_redirect 指令配置

1、server_name_in_redirect on ，URL 重定向为： server_name 中的第一个域名 + 目录名 + /；例如 配置文件中 server_name  www.baidu.com;  则http://localhost/product   时会重定向到http://www.baidu.com/product/（这是个坑）
2、server_name_in_redirect off （默认值）URL 重定向为： 原 URL 中的域名 + 目录名 + /。

 

转载于:https://www.cnblogs.com/jedi1995/p/11320357.html

 

今天配置Nginx时，我设置了一个域名： http://www.yuhongchun027.com ，下面有web目录为www；现在的问题就是如果我访问 http://www.yuhongchun027.com/www/ 就可以显示出地址，但如果我访问 http://www.yuhongchun027.com/www 结果却提示说找不到所需要的页面。哈哈，又开始犯老错了，nginx不会自动在请求的最后加上一个/的，原因是nginx不会自动判断请求的是一个文件还是一个目录，解决方法为:
在配置文件中location里加入如下代码
if (-d $request_filename) {
rewrite ^/(.*)([^/])$ http://$host/$1$2/ permanent;
}
这样再对 http://www.yuhongchun027.com/www 请求，nginx就会进行判断了，如果请求的是一个文件夹，会自动在最后加上/符号，如果请求的是一个文件，则不会改变原有url
接下来对这段代码进行一个解释
1、if (-d $request_filename)，如果请求的是一个文件夹，则为真，进到if语句中执行
2、rewrite是执行url重写操作
3、^/(.*)([^/])$表示以/符号开始并紧跟着任何字符，同时不是以/为结束的字符串，在我的url中，(.*)表示的ww，([^/])表示的w
4、 http://$host/$1$2/ 表示的重写后的地址，$host是请求的域名，$1是前面第一个括号里的内容ww，在我的url里就是wordpres $2是前面第二个括号里的内容，在我的url里是w
5、permanent表示，返回永久重定向的HTTP状态301

※这里值得一说的是，抚琴煮酒浏览IE的习惯一般是 http://www.yuhongchun027/www ，相信大家习惯跟我一样，不会在www后面加上/的；在为客户设计网站时，首页不考虑这些问题，但牵涉到二级目录时，我一般会加上以上正则，这样会使整个网站设计更人性化点。

 转自：https://blog.csdn.net/hhq163/article/details/5851942
 
 
 
 
?
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
1、proxy_pass 只是HOST
proxy_pass 只是HOST，不包含任何路径，比如
 
* http://host - √
* https://host - √
* http://host:port - √
* https://host:port - √
* http://host/ - x
* http://host:port/ - x
这种情况下，会把匹配到的所有路径直接穿透转发。比如以下的配置
 
location /api/ {
    proxy_pass http://127.0.0.1:3000;
}
访问 http://127.0.0.1:80/api/cc , 后端请求的地址是/api/cc
 
2、proxy_pass 包含路径
这里的路径哪怕只是一个 / 也是存在的，如：
 
http://host - x
https//host/ - √
http://host :port- x
https://host :port/ - √
http://host/api - √
http://host/api/ - √
这种情况下，url 里面会 去掉 location 匹配的字符串，拼接到 proxy_pass 再进行转发。
 
location /api/ {
    proxy_pass http://127.0.0.1:3000/;
}
访问 http://127.0.0.1:81/api/cc , 后端请求的地址是/cc
 
3、重写代理链接 - url rewrite
使用 rewrite 指令并且生效后，proxy_pass url 链接中的路径会被忽略，如：
 
server {
    listen  83;
    location / {
        rewrite ^/api/(.*) /fixpath=$1 break;
        proxy_pass http://127.0.0.1:3000/node/;
    }
     
    location ^/api/ {
        rewrite ^/api/(.*) /fixpath=$1 break;
        proxy_pass http://127.0.0.1:3000/node/;
    }
}
访问 http://127.0.0.1:83/bb/cc 得到的请求地址是/node/bb/cc （匹配上 / 了，没有匹配 rewrite）
 
访问 http://127.0.0.1:83/api/cc 得到的请求地址是/fixpath=cc (我们写的 proxy_pass http://127.0.0.1:3000/node/ 里面的 node 路径丢失了 )
 
其它示例：
 
location ~ ^/smx/(test|production) {
    rewrite ^/smx/(?:test|production)/(.*)$ /cxf/$1 break;
    proxy_pass http://localhost:8181;
}
  
location ~ ^/es/(test|production) {
    rewrite ^/es/(?:test|production)/(.*)$ /$1 break;
    proxy_pass http://localhost:9200;
}
4、更多
在github上看到的这本小书 :arrow_down:
 
(参考资料)[ https://xuexb.github.io/learn... ]
 
我的 nginx 配置
 
events {
}
http {
    # proxy_pass url 只是 host
    # 这时候 location 匹配的完整路径将直接透传给 url ，如：
     server {
            listen       80;
             
            location / {
                proxy_pass http://127.0.0.1:3000;
            }
  
            location /api/ {
                proxy_pass http://127.0.0.1:3000;
            }
            
             
        }
    # url 包含路径
    # 当 proxy_pass url 的 url 包含路径时，匹配时会根据 location 的匹配后的链接透传给 url ，注意匹配后就是这样：
     server {
            listen       81;
             
            location / {
                proxy_pass http://127.0.0.1:3000/;
            }
  
            location /api/ {
                proxy_pass http://127.0.0.1:3000/;
            }
            location /bpi/ {
                proxy_pass http://127.0.0.1:3000/v1;
            }
            location /cpi {
                proxy_pass http://127.0.0.1:3000/v1;
            }
        }
        # 当 location 以正则形式匹配时，proxy_pass 就不能以 / 结束了，也就是不能包含路径了， 会提示配置错误，比如错误的：
  
     server {
            listen       82;
             
            location / {
                proxy_pass http://127.0.0.1:3000/;
            }
        # nginx: [emerg] "proxy_pass" cannot have URI part in location given by regular expression, or inside named location, or inside "if" statement, or inside "limit_except" block in /test.conf:47
        #    location ~* ^/api/ {
        #         proxy_pass http://127.0.0.1:3000/;
        #     }
  
        # nginx: [emerg] "proxy_pass" cannot have URI part in location given by regular expression, or inside named location, or inside "if" statement, or inside "limit_except" block in /Users/tangdaoyuan/code/anheng/jz-bingjiang/test.conf:52
        #    location ~* ^/api/ {
        #         proxy_pass http://127.0.0.1:3000/b1;
        #     }
        }
  
    # 使用 rewrite 指令并且生效后，proxy_pass url 链接中的路径会被忽略，如：
     server {
            listen       83;
            location / {
                proxy_pass http://127.0.0.1:3000/node/;
            }
            location ^/api/ {
                rewrite ^/api/(.*) /fixpath=$1 break;
                proxy_pass http://127.0.0.1:3000/node/;
            }
        }
  
}
测试流程 ： node 运行 服务， 启动 Nginx 转发 ， 再用postman 发送请求。

　　转自：https://blog.csdn.net/justlpf/article/details/103390946

https://www.codercto.com/a/68778.html

 

 

url形式为1_11或其他形式需要在后面加上/组成1_11/，在server段中添加如下 :

rewrite ^([^.]*[^/])$ $1/ permanent;
下面这个规则将重定向所有的url包括css等，所以不合适：

rewrite ^(.*[^/])$ $1/ permanent;
也可以在伪静态规则中排除掉特定 格式，如下是当非.html结尾时才重定向

RewriteRule ^(.*?(?<!(html))$) $1/ permanent;
————————————————
版权声明：本文为CSDN博主「youcijibi」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/youcijibi/article/details/86977271

 

 

 

运行环境
nginx：1.15.1
windows： 2008

需求描述
使用 nginx 配置tomcat集群后，访问web时，无法正常打开页面，需要在test后面添加斜杠/，才能正常访问：
http://127.0.0.1/test 无法访问
http://127.0.0.1/test/ 访问正常

nginx 配置方式如下：

配置服务器集群组
upstream backend{
# server 1
server 127.0.0.1:8080 weight=1 max_fails=3 fail_timeout=30s;
# server 2
server 127.0.0.1:8180 weight=1 max_fails=3 fail_timeout=30s;
}
server {
# 其他配置项
# 映射服务器集群
location /test/{
proxy_pass http://backend;
}
}

解决办法
修订server配置，将 /test 替换为 /test/，问题解决。

server {
# 其他配置项
# 映射服务器集群
location /test/{
proxy_pass http://backend;
}
}


————————————————
版权声明：本文为CSDN博主「huryer」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/huryer/article/details/81091964

 

 

nginx 神奇的斜线，各种斜线的搭配访问结果

?
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
两台服务器，一台客户端
服务器B1：192.168.1.1
 
服务器B2 ：192.168.2.2 
 
客户端C1 ：127.0.0.1
 
1、代理模式
在客户端中请求服务器B1,请求路径为
http://192.168.1.1/test/api
B1 配置
 
location /test/ {
   proxy_pass http://192.168.2.2/;
}
服务器B2 收到的请求: //api
location /test {
  proxy_pass http://192.168.2.2/;
}
服务器B2收到的请求:  //api
location /test/ {
  proxy_pass http://192.168.2.2;
}
服务器B2收到的请求:  /test/api
location /test {
  proxy_pass http://192.168.2.2
}
服务器B2收到的请求:  /test/api
location /test/ {
  proxy_pass http://192.168.2.2/on/;
}
服务器B2收到的请求: /on/api
location /test {
  proxy_pass http://192.168.2.2/on/;
}
服务器B2收到的请求: /on//api
location /test/ {
  proxy_pass http://192.168.2.2/on;
}
服务器B2收到的请求: /onapi
location /test {
  proxy_pass http://192.168.2.2/on;
}
服务器B2收到的请求为: /on/api
 
2、本地资源模式
在客户端中请求服务器B1,请求路径为
http://192.168.1.1/test/api
http://192.168.1.1/test/api/index.html
B1配置
 
location /test/ {
  root /usr/local/;
}
服务器B1实际请求资源路径
/usr/local/test/api
/usr/local/test/api/index.html
location /test/ {
  root /usr/local;
}
服务器B1实际请求资源路径
/usr/local/test/api
/usr/local/test/api/index.html
location /test {
  root /usr/local/;
}
服务器B1实际请求资源路径
/usr/local/test/api
/usr/local/test/api/index.html
location /test {
  root /usr/local;
}
服务器B1实际请求资源路径
/usr/local/test/api
/usr/local/test/api/index.html
location /test/ {
  alias /usr/local/;
}
服务器B1实际请求资源路径
/usr/local/api
/usr/local/api/index.html
location /test {
  alias /usr/local/;
}
服务器B1实际请求资源路径
/usr/local//api
/usr/local//api/index.html
————————————————
版权声明：本文为CSDN博主「好好的浩浩」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ruihaol/article/details/79526749

　　

 

解决Nginx下二级目录斜杠问题

不少网站页面习惯于在URL中的目录名后不加斜杠“/”，这在在apache下会自动添加一个斜杠从而不会造成什么问题，但是如果URL中的二级目录名后不加斜杠的话在Nginx下就会出现403 Forbidden的问题。在网上找到的比较可靠的原因供以想深究的TX进行参考：

在某些情况下（具体可参考 wiki.nginx.org），Nginx 内部重定向规则会被启动，例如，当 URL指向一个目录并且在最后没有包含“/”时，Nginx 内部会自动的做一个 301 重定向，这时会有两种情况：

1、 server_name_in_redirect on（默认），URL 重定向为： server_name 中的第一个域名 + 目录名 + /；

2、 server_name_in_redirect off，URL 重定向为： 原 URL 中的域名 + 目录名 + /。

当你有多个 域名要指向同一个虚拟主机，并且你自己写 301 重定向规则把它们合并到某一个域名时，情况就更复杂了：首先，nginx 检查 URL，如果符合条件，就用该规则（你写的）做第一遍重定向，接着，检查新生成的URL，如果符合内部自动重定向之条件，就用前面提到的规则再做一次重定向。

至于 PHP 的 $_SERVER["SERVER_NAME"]，在 nginx 中默认是由 nginx 的变量 $server_name提供，这时它和重定向没有关系，始终是 server_name 设置中的第一个域名，但这是可以被改变的，在你的 nginx 配置中找到fastcgi_param 部分，修改
fastcgi_param SERVER_NAME $server_name; 为fastcgi_param SERVER_NAME $host; 但现在就要注意了，此时$_SERVER["SERVER_NAME"] 会受你写的和 nginx 自己的重定向规则所影响而变化。

现在就清楚了，如果 MediaWiki 是通过 $_SERVER["SERVER_NAME"] 来自己处理 URL 的话，那么在 nginx + php的默认环境下，它获得的将始终是 server_name 设置中的第一个域名，所以造成了“不管通过什么域名访问 MediaWiki首页，都会被跳转到其中的一个域名上。”，这不是 nginx 的重定向造成的，虽然默认 server_name_in_redirect 是on，但这个指令的影响范围仅仅只是 nginx 自己内部的重定向规则。

目前按照网上提供的一些主流方法，比如在 conf/nginx.conf 主配置文件里面加上

    optimize_server_names off; 
    server_name_in_redirect off;

在FreBSD+Nginx的架构下是无效的，而且optimize_server_names还对Nginx版本有限制。目前比较靠谱的方法还是使用正则来重定向：


    if (-d $request_filename){ 
    rewrite ^/(.*)([^/])$ http://$host/$1$2/ permanent; 
    }

将上面的代码放在相应虚拟主机配置文件的 location / {}里即可。这样做的缺点就是必须对每一个需要自动添加斜杠的虚拟主机都要加上相应的内容。

 

解决Nginx中location匹配不到末尾不加斜杠的URL

?
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
在Nginx中配置location的匹配规则时，相信大家都遇到过 URL 去掉末尾斜杠(/)匹配失败的情况。
我们先来举例描述一下这个问题。
example配置
假设我们配置是这样：
server {
    listen 80
    server_name xxx.com
    ...
    ...
    location /yyy {
        root /home/projects;
        index  index.html index.htm;
   }
    ...
    ...
}
复制代码那么，如果我们访问 xxx.com/yyy/ ，会匹配到服务器上/home/projects/yyy文件夹，并打开index.html或者index.htm文件。
而当我们访问 xxx.com/yyy ,你会发现，匹配失败
这种情况下，你当然可以祈祷用户能够每次输入这个 URL 的时候都带上(/)，但是说实在的，我估计你每次打开百度的时候都是直接输入 www.baidu.com 而不会加斜杠输入 www.baidu.com/ 。末尾斜杠显得如此多此一举。
那如何才能解决这个问题呢？
解决思路
既然加了斜杠可以匹配，那么，我们就可以对不加斜杠的 URL 进行重写，给它加上末尾斜杠，然后重定向，不就解决问题了。
这里，我们需要用到 Nginx 中 ngx_http_rewrite_module 这个 module。
首先，我们判断请求资源是否是请求目录类型
if ( -d $request_filename )
复制代码然后我们利用正则来匹配、替换，并用rewrite中permanent来重定向(301)
rewrite ^/(.*)([^/])$ $scheme://$host/$1$2/ permanent;
复制代码正确配置
修改配置如下
server {
    listen 80
    server_name xxx.com
    ...
    ...
    location /yyy {
        root /home/projects;
        if ( -d $request_filename ){
            rewrite ^/(.*)([^/])$ $scheme://$host/$1$2/ permanent;
        }
        index  index.html index.htm;
   }
    ...
    ...
}
复制代码然后验证配置是否有错误
$ nginx -t
复制代码如果没有语法错误，会提示
 
/nginx.conf syntax is ok
 
最后重启看效果
$ nginx -s reload
 
作者：Quenice
链接：https://juejin.im/post/5bae3afae51d450ea246a9ed
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

　　转自：https://juejin.im/post/5bae3afae51d450ea246a9ed

 

nginx 的proxy_pass 基本设置问题

曾在网上看到一些问题，比如 nginx 的proxy_pass后面的地址加“/”与不加“/”有区别。

   参看nginx英文文档后，发现：

If it is necessary to transmit URI in the unprocessed form then directive proxy_pass should be used without URI part:

location  /some/path/ {
  proxy_pass   http://127.0.0.1;
}

大概意思就是说，如果你不想nginx对你的URI请求有任何形式的修改，那么，proxy_pass的配置中就不应该有任何URI部分。

举个例子，nginx服务器IP为10.0.0.20，它的配置不含URI：

location /first/second/ {
        proxy_pass http://10.0.0.30:90;
}
那么，

原：     http://10.0.0.20/first/second/test.html
转：http://10.0.0.30:90/first/second/test.html

 割一下，如果配置成含URI：
location /first/second/ {
proxy_pass http://10.0.0.30:90/myuri;
}
那么，

原： http://10.0.0.20/first/second/test.html
转：http://10.0.0.30:90/myuri/test.html
简单地说，配置了URI之后，跳转行为可能会令你感到莫名其妙，要有充分的思想准备。

 转自：https://blog.csdn.net/rj042/article/details/7574523?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task

posted @   mofy  阅读(20725)  评论(0)  编辑  收藏  举报
编辑推荐：
· AI与.NET技术实操系列（二）：开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识（上）
· 浏览器原生「磁吸」效果！Anchor Positioning 锚点定位神器解析
阅读排行：
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布：重大改进与新特性概览！
· AI与.NET技术实操系列（二）：开始使用ML.NET
· 单线程的Redis速度为什么快？
历史上的今天：
2015-03-04 kali安装vmware tools
点击右上角即可分享
微信分享提示
AI FOR CODE 大赛