Nginx location 配置踩坑过程

原文链接：https://blog.coding.net/blog/tips-in-configuring-Nginx-location

是的，作为一个程序员，你往往发现，有的时候你花费了数小时，数天，甚至数星期来查找问题，但最终可能只花费了数秒，改动了数行，甚至几个字符就解决了问题。这次给大家分享一个困扰了我很久，我花了五个小时才查找出问题原因，最终只添加了一个字符解决了的问题。

问题描述

我们的业务系统比较复杂，但最终提供给用户的访问接口比较单一，都是使用 Nginx 来做一个代理转发，而这个代理转发，往往需要匹配很多种不同类型的 URL 转给不同的服务。这就使得我们的 Nginx 配置文件变得很复杂，粗略估计了下，我们有近20个 upstream，有近60个 location 匹配。这些配置按照模块分布在不同的文件中，虽然复杂，但是仍然在我们的努力下运行的良好。直到有一天，有位同事给我反映说偶尔有些 URL 会出现 404 的问题。一开始没太在意，因为他也说不准是哪一种 URL 才遇到这个问题。

问题查找

后来，慢慢的查找，找到了一些规律，一开始只知道是 tomcat 那边返回 404了，想到 Nginx 都代理给了 tomcat，一开始就怀疑是程序的问题，不会想到是 Nginx。

我开始查找代码的问题，我在本地的开发环境，尝试了很久，我使用 8080 端口访问，不论如何都是正确的结果，可是生产环境就是不行。然后我就听信了某坑友同事的理论，重启解决 95% 的问题，重装解决 100%的问题，我尝试重启了 tomcat 和 Nginx，依然不行，然后是重装，你猜结果如何？？？？？ ——想啥呢？当然也是不行！

后来就开始怀疑是生产环境和开发环境的差异，去服务器上访问 8080 端口，仍然是可以的。可是一经过 Nginx 代理，就不行。这个时候才开始怀疑是 Nginx 出了什么问题。

Nginx 怎么会出问题呢，业务系统中 URL 模式 /helloworld/* ,这样的 URL 我们都是统一处理的。怎么会出现一些行，一些不行呢。问题表现为 A URL （/helloworld/nn/hello/world）没问题，而 B URL(/helloworld/ii/hello/world) 有问题。

所以到目前为止，基本可以肯定是 Nginx 的 location 上出了一些问题。

问题解决

因篇幅有限，为了直面本次问题的核心，我不再贴出完整的 Nginx 配置，我简化此次问题的模型。请看如下 Nginx 配置，这是我们之前的会导致问题的错误配置模型。

worker_processes  1;
error_log  logs/error.log;
events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    log_format  main  ‘$remote_addr - $request_time - $remote_user [$time_local] "$request" ‘
                      ‘$status $body_bytes_sent "$http_referer" ‘
                      ‘"$http_user_agent" "$http_x_forwarded_for"‘;

    access_log  logs/access.log main;

    sendfile        on;
    keepalive_timeout  65;

    gzip  on;

    server {
        listen       80;
        server_name  localhost;
        location / {
            root   html;
            index  index.html index.htm;
        }
        location = /helloworld {
                return 602;
        }
        location /helloworld {
                return 603;
        }

        ## 生产环境中如下两个 location 在另外一个文件中，通过 include 包含进来
        location /ii {
                return 604;
        }
        location ~ /ii/[^\/]+/[^\/]+ {
                return 605;
        }
        ##

        location ~ ^/helloworld/(scripts|styles|images).* {
                return 606;
        }
    }
}

注意，这里有几点需要说明一下，生产环境的 Nginx 服务器配置文件比这里要复杂很多，而且是按模块分布在不同的文件中的。这里简化模型后，使用 Http 响应状态码 60x 来区分到底被哪个 location 匹配到了。
我针对当时的情况，做了大量尝试，最终的简化版本如下：

上面这些尝试支持读者自行试验，Nginx 配置文件是完整可用的，我本地 Nginx 的版本是1.6.2

问题就在这里：我这里是事后，把这些匹配 location 标记成了不同的响应码，才方便查找问题。当发现这个不符合预期后，我还是难以理解，为何我一个以 /helloworld 开头的 URL 会被匹配到 605 这个以 /ii 开头的 location 里面来。在当时的生产环境中，以 /ii 的配置统一放在另外一个文件中，这里是很难直观的察觉出来这个 /ii 跟访问的 URL 里面的 /ii 的关系。

我不得不重新编译了 Nginx ，加上了调试参数，修改配置项，看调试日志了。

这里不再讲如何给 Nginx 加调试的编译参数，可自行查看相关文档。修改配置项很简单，只需要在

error_log  logs/error.log;

后面加上 debug 就可以了。

打出详细调试日志后，访问
http://localhost/helloworld/ii/hello/world 
我得到了这样的一段日志(省略掉了前后无用的日志，只保留有意义的一段)：

2015/02/02 15:38:48 [debug] 5801#0: *60 http request line: "GET /helloworld/ii/hello/world HTTP/1.1"
2015/02/02 15:38:48 [debug] 5801#0: *60 http uri: "/helloworld/ii/hello/world"
2015/02/02 15:38:48 [debug] 5801#0: *60 http args: ""
2015/02/02 15:38:48 [debug] 5801#0: *60 http exten: ""
2015/02/02 15:38:48 [debug] 5801#0: *60 http process request header line
2015/02/02 15:38:48 [debug] 5801#0: *60 http header: "User-Agent: curl/7.37.1"
2015/02/02 15:38:48 [debug] 5801#0: *60 http header: "Host: localhost"
2015/02/02 15:38:48 [debug] 5801#0: *60 http header: "Accept: */*"
2015/02/02 15:38:48 [debug] 5801#0: *60 http header done
2015/02/02 15:38:48 [debug] 5801#0: *60 event timer del: 4: 1422862788055
2015/02/02 15:38:48 [debug] 5801#0: *60 rewrite phase: 0
2015/02/02 15:38:48 [debug] 5801#0: *60 test location: "/"
2015/02/02 15:38:48 [debug] 5801#0: *60 test location: "ii"
2015/02/02 15:38:48 [debug] 5801#0: *60 test location: "helloworld"
2015/02/02 15:38:48 [debug] 5801#0: *60 test location: ~ "/ii/[^\/]+/[^\/]+"
2015/02/02 15:38:48 [debug] 5801#0: *60 using configuration "/ii/[^\/]+/[^\/]+"
2015/02/02 15:38:48 [debug] 5801#0: *60 http cl:-1 max:1048576
2015/02/02 15:38:48 [debug] 5801#0: *60 rewrite phase: 2
2015/02/02 15:38:48 [debug] 5801#0: *60 http finalize request: 605, "/helloworld/ii/hello/world?" a:1, c:1
2015/02/02 15:38:48 [debug] 5801#0: *60 http special response: 605, "/helloworld/ii/hello/world?"
2015/02/02 15:38:48 [debug] 5801#0: *60 http set discard body
2015/02/02 15:38:48 [debug] 5801#0: *60 posix_memalign: 00007FC3BB816000:4096 @16
2015/02/02 15:38:48 [debug] 5801#0: *60 HTTP/1.1 605
Server: nginx/1.6.2
Date: Mon, 02 Feb 2015 07:38:48 GMT
Content-Length: 0
Connection: keep-alive

可以看到，Nginx 测试了几次 location 匹配，最终选择了
~ "/ii/[^\/]+/[^\/]+" 
这个作为最终的匹配项。到这里问题就完全展现出来了，我们本来的意思，是要以 /ii 开头，后面有两个或者更多的 / 分割的 URL 模型才匹配，但是这里的正则表达式匹配写的不够精准，导致了匹配错误。正则表达式没有限制必须从开头匹配，所以才会匹配到 /helloworld/ii/hello/world 这样的 URL 。

解决办法就是在这个正则表达式前面加上 ^ 来强制 URL 必须以 /ii 开头才能匹配.
由
/ii/[^\/]+/[^\/]+ 
变成
^/ii/[^\/]+/[^\/]+ 
至此，这个坑被填上了，消耗的是五个小时和一个字符。

相信很多人在写 Nginx 的location 的时候都会 location ~ /xxx 或者 location /iii 这样简单了事，但是我想说的是能尽量精确就尽量精确，否则出现问题的时候，非常难以查找。

有关 Nginx 的 location 匹配规则，可以查看: http://nginx.org/en/docs/http/ngx_http_core_module.html

问题总结

这个问题看似简单，却也隐含了不少问题，值得我们深思。

    • 计算机或者软件出的问题往往是确定的，你发现他捉摸不定的时候，往往是没有观察到问题点
    • 追踪一个问题，如果有一个必现方式，一定要紧追不舍，这就是所谓线索
    • 当你实在是找不到问题所在的时候，要怀疑一下之前被自己排除掉的可能性
    • 借助各个组件的详细调试日志来查找问题，往往能得到意想不到的效果
    • 程序员的价值不是用行数，字数，提交数衡量的！

原文地址：https://www.cnblogs.com/oskyhg/p/9327699.html

时间： 2024-10-29 19:06:30

Nginx location 配置踩坑过程的相关文章

Nginx location 配置踩坑过程分享

这是五个小时与一个字符的战斗 是的,作为一个程序员,你往往发现,有的时候你花费了数小时,数天,甚至数星期来查找问题,但最终可能只花费了数秒,改动了数行,甚至几个字符就解决了问题.这次给大家分享一个困扰了我很久,我花了五个小时才查找出问题原因,最终只添加了一个字符解决了的问题. 问题描述 我们的业务系统比较复杂,但最终提供给用户的访问接口比较单一,都是使用 Nginx 来做一个代理转发,而这个代理转发,往往需要匹配很多种不同类型的 URL 转给不同的服务.这就使得我们的 Nginx 配置文件变得很

在CentOS/Windows下配置Nginx（以及踩坑）

在CentOS/Windows下配置Nginx(以及踩坑) 1. 序言 因为这类文章网上比较多,实际操作起来也大同小异,所以我并不会着重于详细配置方面,而是将我配置时踩的坑写出来. 2. CentOS 2.1 第一步下载nginx包 我选择将包放在/usr/local下 cd /usr/local wget (nginx下载目录网址) 这里的下载目录可以根据需要选择版本从而决定 请点击nginx下载查看目录 2.2 安装nginx所需环境 yum?install?gcc-c++ yum?inst

记一次 Spring 事务配置踩坑记

记一次 Spring 事务配置踩坑记 问题描述:(SpringBoot + MyBatisPlus) 业务逻辑伪代码如下.理论上,插入数据 t1 后,xxService.getXxx() 方法的查询条件会不满足,会查询不到数据.结果事与愿违,后一次的查询,居然查到了数据. void saveXxx(){  xxService.getXxx(); // 查到一条数据 data1  xxService.insert(); // 插入一条数据 t1  xxService.getXxx(); // 查到

XXLJOB2.1.0数据源配置踩坑记录

最近在看XXLJOB,因为截至到发文时间最新的版本是2.1.0而且需要建立的数据库与Quartz解耦了,所以就用了最新的版本. 首先说一下踩坑过程: 代码开发完成之后,在定时跑的时候第一次跑的多数失败,报的错是:Communications link failure 上网搜了一下说是MySQL数据库连接时间超过八小时就会断开需要加一些配置,或者把数据库的时间延长.原先用的数据源是Druid,所以就把网上找到的代码加到数据源配置上,同时延长了MySQL的链接持续时间,问题依然没有解决. 一次偶然的

nginx location配置

nginx location配置 location在nginx中起着重要作用,对nginx接收到的请求字符串进行处理,如地址定向.数据缓存.应答控制.代理转发等 location语法 location [=|~|~*|^~] uri {...} []部分是匹配类型,可以没有,其中各项含义: (1)= 精准匹配,请求字符串必须和uri完全相同时匹配成功 (2)~ 区分大小写的正则匹配 (3)~* 不区分大小写的正则匹配 (4)^~ 注意这个不是正则匹配,表示uri以普通字符串开头, (5)空 表示

Nginx Location配置总结

http://blog.sina.com.cn/s/blog_97688f8e0100zws5.html 语法规则: location [=|~|~*|^~] /uri/ { … }= 开头表示精确匹配^~ 开头表示uri以某个常规字符串开头,理解为匹配 url路径即可.nginx不对url做编码,因此请求为/static/20%/aa,可以被规则^~ /static/ /aa匹配到(注意是空格).~ 开头表示区分大小写的正则匹配~*  开头表示不区分大小写的正则匹配!~和!~*分别为区分大小写

Nginx Location配置总结及基础最佳实践

参考来源: http://blog.zol.com.cn/1067/article_1066186.html,http://flandycheng.blog.51cto.com/855176/280121 语法规则: location [=|~|~*|^~] /uri/ { … } = 开头表示精确匹配 ^~ 开头表示uri以某个常规字符串开头,理解为匹配 url路径即可.nginx不对url做编码,因此请求为/static/20%/aa,可以被规则^~ /static/ /aa匹配到(注意是空

nginx location配置（URL）

语法规则: location [=|~|~*|^~] /uri/ { … }= 表示精确匹配,这个优先级也是最高的^~ 表示uri以某个常规字符串开头,理解为匹配 url路径即可.nginx不对url做编码,因此请求为/static/20%/aa,可以被规则^~ /static/ /aa匹配到(注意是空格).~  表示区分大小写的正则匹配~* 表示不区分大小写的正则匹配(和上面的唯一区别就是大小写)!~和!~*分别为区分大小写不匹配及不区分大小写不匹配的正则/ 通用匹配,任何请求都会匹配到,默认

nginx location配置（转）

语法规则: location [=|~|~*|^~] /uri/ { … } = 开头表示精确匹配 ^~ 开头表示uri以某个常规字符串开头,理解为匹配 url路径即可.nginx不对url做编码,因此请求为/static/20%/aa,可以被规则^~ /static/ /aa匹配到(注意是空格). ~ 开头表示区分大小写的正则匹配 ~* 开头表示不区分大小写的正则匹配 !~和!~*分别为区分大小写不匹配及不区分大小写不匹配 的正则 / 通用匹配,任何请求都会匹配到. 多个location配置的