news 2026/3/14 5:27:24

nginx location没学好,把自己坑了一把

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
nginx location没学好,把自己坑了一把

背景

前几天在部署一套环境的时候,涉及nginx这块,当时以为分分钟搞定,没相对还费了好些功夫,甚至以为是nginx的bug了。

我先上个图:

我们有个校企合作的项目,由于项目的参与方涉及学校学生,网络因此是单独划了一个区域,就相当于一个独立网段,里面有学生办公pc、linux服务器等等。我们这次组里开发了一个小的前后端分离项目,开发完了后,我就准备部署。

部署的话,我是通过类似于windows远程桌面的机制(实际是某厂商的VDI,相比于windows远程桌面,应该是多了更多文件进出的管控机制,比如没权限的话,远程主机里的文件默认是拷贝不出来的)。

通过远程桌面进入远程windows后,在里面再ssh连接linux服务器,在上面部署nginx、前端包,由于服务器有限,直接把后端spring boot包也是部署在了这一台机器上,架构如下。

刚开始部署完成后,应用服务器上(假设ip为1.1.1.1)的nginx,监听80端口,那么,在远程windows上的浏览器,是可以访问:http://1.1.1.1:80来打开系统的,但是,在我的办公pc上不行。

由于这种一般是需要给领导演示的,那自然要把1.1.1.1:80端口暴露出来,让办公pc网络可以访问。为了安全起见,这种一般只开放必要的端口,如上面就只开放80端口。就像我们平时系统对互联网仅开放443端口一样。

问题

由于版本刚开始不稳定,自然是会发现一些bug,发现bug就需要看日志,我们这边看日志还是比较原始的,也没搞什么elk这类。spring boot服务的日志,就在上述的1.1.1.1这台服务器的特定目录下,我就想着,通过80端口,nginx里面再配个location,把log暴露出来,方便组内同事看日志,应该更方便一些。

原始的nginx配置如下,就一个前后端分离的配置:

/* by 01022.hk - online tools website : 01022.hk/zh/formatfilter.html */ server { listen 80; server_name localhost; location / { root /usr/local/nginx/html/quantify-trade-platform-frontend/dist; index index.html index.htm; try_files $uri $uri/ /index.html; } location ~ /quantify-trade-platform-admin { proxy_pass http://localhost:8093; } }

我们java服务呢,日志是在:

/opt/quantify-trade-platform-admin/quantify-trade-platform-admin-0.1-SNAPSHOT/logs

所以,我就加了一段配置:

/* by 01022.hk - online tools website : 01022.hk/zh/formatfilter.html */ location /mylog/ { alias /opt/quantify-trade-platform-admin/quantify-trade-platform-admin-0.1-SNAPSHOT/logs/; autoindex on; }

完整如下:

server { listen 80; server_name localhost; location / { root /usr/local/nginx/html/quantify-trade-platform-frontend/dist; index index.html index.htm; try_files $uri $uri/ /index.html; } location ~ /quantify-trade-platform-admin { proxy_pass http://localhost:8093; } -- 新增如下: location /mylog/ { alias /opt/quantify-trade-platform-admin/quantify-trade-platform-admin-0.1-SNAPSHOT/logs/; autoindex on; } }

加好后,我试了下, http://1.1.1.1/mylog/,可以正常访问:(实际上,折腾这个autoindex这个location,也花了不少时间,要不要加/之类的)

但是呢,我在点击里面的文件的时候,发现报404:

http://1.1.1.1/mylog/quantify-trade-platform-admin.log

这个问题把我折腾的够呛,我一直以为是我autoindex这块,是不是哪里配置没对,就这个地方,反复折腾,反复折腾:

location /mylog/ { alias /opt/quantify-trade-platform-admin/quantify-trade-platform-admin-0.1-SNAPSHOT/logs/; autoindex on; }

快下班的时候,我发现如果我把admin改成amin、adin,就拼错一两个字母,就能下载下来了。当时以为,是autoindex这种静态文件机制,会不会是为了安全考虑,文件名匹配到admin这个关键字啥的,就404.

但后面,我把log拷贝一下,去掉中间的中划线,也可以下载下来:

然后网上一顿乱搜,看看是不是中划线导致的问题啥的,或者是因为含有admin关键字导致的,结果都没查到有人遇到这种问题。

一顿搜索猛如虎,以为是nginx的什么小bug(当时感觉autoindex这种静态文件机制,可能用的人少,是不是有啥小bug正好被我撞见了)

次日排查

第二天早上来了后,找了台服务器,新搭建,结果发现admin.txt可以正常下载,为啥在那台机器上就不行呢?

我想起来strace命令,那就看看有没有线索吧:

strace -p 121920 -s 1000 -t -e trace=network,file,desc,process

结果请求http://1.1.1.1/mylog/quantify-trade-platform-admin.log 时,发现信息显示出:发起了socket操作,请求了springboot服务的端口。

当时很奇怪,第一次还没放到心上,然后复测了一遍,发现还是这样。然后就哟tcpdump抓了个包,咦,这个日志文件的请求怎么被发到后端服务去了。

然后再一看location:

行吧,一看肯定是location中的那个的问题了,由于日志文件名和我们后端接口的前缀是一样的,所以匹配到了上图的那个location,然后又是正则匹配(这块这几个符号一直记不清楚,这下把自己坑了)

解决方法:如何知道url匹配上了哪个location

写这篇文章时,网上搜索了下,发现有这么一个技巧:

https://stackoverflow.com/questions/12703702/nginx-test-which-location-used-to-process-request#:~:text=If you just want to,3 Comments

https://stackoverflow.com/questions/12703702/nginx-test-which-location-used-to-process-request

就是在每个location中加一个语句,在返回的http header中加一个:

add_header location 1 always;

注意,这里要加always,不然像我这种404情况下,不加always是不会有这个header的。

加了always,才会像下面这样:

另外,由于location是一个http规范中预定义的header,和403重定向配合使用,我们可以换个名字:

add_header mylocation 2 always;

增加日志

另外一个方式,就是把日志多打一点,我试过两种:

error_log

error_log logs/my_error.log info;

https://nginx.org/en/docs/ngx_core_module.html#error_log

vim /usr/local/nginx/logs/my_error.log

但发现没啥用,还是没有详细日志。

access log

log_format upstream_time '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"' 'rt="$request_time" $upstream_addr uct="$upstream_connect_time" uht="$upstream_header_time" urt="$upstream_response_time"'; server { listen 80; server_name localhost; access_log logs/my.access.log upstream_time;

通过上面这类日志,也能帮我们看到,到底走到了哪个location,反向代理到了哪台后端服务器。

debug log

https://nginx.org/en/docs/debugging_log.html

这个要在编译时打开:

./configure --with-debug ...

这个我就没试了,后续有空再说。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/3/12 10:11:41

Git-RSCLIP图文匹配实战:‘输电线路走廊’专业术语精准召回

Git-RSCLIP图文匹配实战:‘输电线路走廊’专业术语精准召回 1. 为什么输电线路走廊识别需要更聪明的图文匹配? 你有没有遇到过这样的情况:手头有一张高分辨率的卫星图,里面明明有清晰的输电塔、导线和巡线通道,但用传…

作者头像 李华
网站建设 2026/3/13 7:31:53

Clawdbot实战:3步完成企业微信AI助手配置

Clawdbot实战:3步完成企业微信AI助手配置 Clawdbot 汉化版 增加企业微信入口,让企业微信真正变成你的24小时AI办公中枢。不需要开发能力、不依赖云服务、不上传任何聊天记录——所有数据留在你自己的服务器上,却能像使用ChatGPT一样自然地在…

作者头像 李华
网站建设 2026/2/27 5:43:07

Pi0机器人控制实战:通过自然语言指令操控6自由度机器人

Pi0机器人控制实战:通过自然语言指令操控6自由度机器人 1. 从“说句话就能动”开始的具身智能实践 你有没有想过,让机器人像听懂人话一样执行任务?不是写一堆代码,不是调一堆参数,而是直接说一句“把桌上的红色方块拿…

作者头像 李华
网站建设 2026/3/8 4:08:37

Pi0在ROS生态中的集成潜力:基于LeRobot框架的机器人控制新范式

Pi0在ROS生态中的集成潜力:基于LeRobot框架的机器人控制新范式 1. Pi0是什么:一个面向真实机器人的视觉-语言-动作模型 Pi0不是传统意义上的单点AI模型,而是一个专为物理世界交互设计的端到端机器人控制模型。它不只“看”图像、“听”指令…

作者头像 李华