Nginx日志分析--路径匹配篇

最新推荐文章于 2025-05-28 10:58:38 发布

yaaron

最新推荐文章于 2025-05-28 10:58:38 发布

阅读量6.2k

点赞数

CC 4.0 BY-SA版权

分类专栏： Web开发文章标签： nginx 正则表达式 server header 服务器 php

本文链接：https://blog.youkuaiyun.com/yaaron/article/details/6831813

Web开发专栏收录该内容

28 篇文章

订阅专栏

本文介绍了如何通过Nginx的错误日志分析路径匹配问题。当无法正常访问网页时，可以调整日志配置到server级别或以上。以一个具体的请求为例，展示了Nginx如何处理请求，包括URL解码、http header分析、location匹配过程，以及正则表达式的应用。最终，请求被重定向到PHP引擎处理并生成页面。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Nginx配置以后，有可能发生无法正常访问网页的情况。如果是路径匹配方面的问题，可以通过它的错误日志来分析解决。

Nginx的错误日志在nginx.conf里配置：

error_log  logs/error.log debug;

上述声明在nginx安装目录下的logs目录里生成了一个error.log，日志级别为debug级（最详细级）。注意Nginx的配置是一个层次结构体系（参见Nginx配置文件解析），因此如果该声明在HTTP结点下，则对所有http请求有效；如果在server结点下，则对该server的所有请求有效；如果在location结点下，则只对该location的请求有效。在做路径匹配错误分析时，至少要配置到server结点或者以上，而不能配置在location上。否则，一旦因conf文件书写错误而某location应该匹配而没有匹配上，就不会有任何日志输出，起不到调试的作用。

假设http://www.lotus-scent.com/blog/index.php/web技术/布署和优化/nginx错误日志分析-路径匹配篇/无法正常请求到页面，分析如下:

下载示例日志

Nginx对上述请求的处理从日志的第974行开始，这里的关键词是"http request line"。注意这一行输出的URL是编码之后的地址，接下来975行输出了解码后的地址：/blog/index.php/web鎶€鏈?javascript寮€鍙?娣卞害浣撻獙javascript-妯″潡璁捐妯″紡/"。由于地址包含中文，因此显示为乱码。

第976行，Nginx继续处理请求，解析出该请求没有http args。对于请求"GET /blog?user=aaron"，则此处会输出"user=aaron"。

接下来到989行，Nginx对该请求的http header的分析结束。这里的关键词是"http header done"。

接下来Nginx处理地址匹配，注意988行的rewrite phase 0输出。从日志输出可以看出，Nginx先后测试了5个location块，最后使用/blog块的配置对该请求进行处理：

2011/09/19 23:54:54 [debug] 27343#0: *417 test location: "/"
2011/09/19 23:54:54 [debug] 27343#0: *417 test location: "develop"
2011/09/19 23:54:54 [debug] 27343#0: *417 test location: "ckeditor"
2011/09/19 23:54:54 [debug] 27343#0: *417 test location: "blog"
2011/09/19 23:54:54 [debug] 27343#0: *417 test location: ~ "/blog/.*\.(?:ico|css|js|gif|jpe?g|png)$"
2011/09/19 23:54:54 [debug] 27343#0: *417 using configuration "/blog"

注意这里的关键词"using configuration"。

从第999行进入rewrite phase第2阶段，即在配置"/blog"块中进行处理：

第1001行，取得URI原始字符串：/usr/www/blog/index.php/web鎶€鏈?javascript寮€鍙?娣卞害浣撻獙javascript-妯″潡璁捐妯″紡/"

第1003行，此行应该是检查该URI是否直接对应服务器上的某个文件。1004行查找失败，直接进入1005行的rewrite匹配。此时匹配上正则表达式"^/blog/index.php/(.+)$"，并获取子匹配"web鎶€鏈?javascript寮€鍙?娣卞害浣撻獙javascript-妯″潡璁捐妯″紡/"。接下来就是根据已经获取的信息调用/blog/index.php?q=$1"，由此进入下一轮内部地址重定向。注意if语句块中有一个break语句，表明执行到此处后，跳过后面的处理。

1013行进入第三轮地址重定向，此轮请求的URI是”/blog/index.php?q=..”。1020行显示匹配上配置/blog。注意该配置在上一轮中就匹配上了，但此轮以不同的参数调用再次匹配。

1027行，此处结果为false，意即/usr/www/blog/index.php为服务器上存在的一个文件。这样整个if语句块被跳过，直接进入到fastcgi的部分。行1041开始获取QUERY_STRING,REQUEST_METHOD,SCRIPT_NAME等fastcgi参数，最后交php引擎处理以生成页面，返回给客户端。1120开始的几行应该是Nginx从php获得输出后填充HTTP消息响应时的日志输出。运行到此外也意味着Nginx对该http请求的处理基本结束。