惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

WordPress大学
WordPress大学
A
About on SuperTechFans
小众软件
小众软件
Hugging Face - Blog
Hugging Face - Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - 叶小钗
博客园 - 聂微东
博客园 - Franky
Apple Machine Learning Research
Apple Machine Learning Research
罗磊的独立博客
量子位
博客园 - 三生石上(FineUI控件)
Recent Announcements
Recent Announcements
The GitHub Blog
The GitHub Blog
B
Blog RSS Feed
T
The Blog of Author Tim Ferriss
GbyAI
GbyAI
云风的 BLOG
云风的 BLOG
Last Week in AI
Last Week in AI
宝玉的分享
宝玉的分享
B
Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Stack Overflow Blog
Stack Overflow Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC

博客园 - 三国梦回

oracle中date类型在mybatis中查询时遇到的坑 mitmweb在linux上进行反向代理及浏览器中实时查看请求响应 codex对接智谱coding plan,我发现连cc switch也不用了 windows codex更新失败如何处理 windos上codex沙盒报错问题记录 廉颇老矣,装个EclipseMemoryAnalyzer都能卡一小时 codex windows平台中elevated sandbox机制学习 codex windows平台中unelevated sandbox机制学习 bug排查:nacos做配置管理,给服务返回的配置竟然是错的 windows安装codex desktop和cc-switch,接deepseek v4 flash windows安装ddns-go,上传动态的ipv6到自己的域名 immortalWrt路由器上抓包查看电脑联网如何获取ip 路由器刚刷的immortalWrt系统,我是如何配置ipv6的 路由器刷openwrt之ImmortalWrt过程记录--上 spring boot 项目中oracle datasource设置schema spring cloud项目中,在bootstrap.yml中指定了active的profile,结果不生效 线上服务重启后,从nacos取不到配置了,怎么回事 技术问题记录20260125 最近遇到的两个技术问题记录 linux服务器文件上传失败 线上遇到的redis和数据库数据未同步问题、redisson内部实现问题 复杂业务系统线上问题排查过程 nacos中配了一个数字,springboot取回来怎么变了 一个java空指针异常的解决过程 简单记录下最近2个月完成的线上系统迁移工作 centos停服,迁移centos7.3系统到新搭建的openEuler 端口telnet不通排查过程 https证书中的subject alternative name字段作用及如何生成含该字段的证书 linux中如何判断一个rpm是手动安装还是通过yum安装的 对接服务升级后仅支持tls1.2,jdk1.7默认使用tls1.0,导致调用失败
nginx location没学好,把自己坑了一把
三国梦回 · 2026-02-01 · via 博客园 - 三国梦回

背景

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

我先上个图:

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

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

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

image-20260201104040556

刚开始部署完成后,应用服务器上(假设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配置如下,就一个前后端分离的配置:

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

image-20260201105400498

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

    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,也花了不少时间,要不要加/之类的)

image-20260201105622188

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

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

image-20260201105804252

这个问题把我折腾的够呛,我一直以为是我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.

image-20260201110908710

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

image-20260201110108269

然后网上一顿乱搜,看看是不是中划线导致的问题啥的,或者是因为含有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:

image-20260201111403498

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

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

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

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

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的。

image-20260201111900000

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

image-20260201112049861

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

    add_header mylocation 2 always;

image-20260201112228298

增加日志

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

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

image-20260201112452079

    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 ...

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