前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >从nginx返回404来看http1.0和http1.1的区别

从nginx返回404来看http1.0和http1.1的区别

作者头像
SRE运维实践
发布2024-07-12 16:32:26
1090
发布2024-07-12 16:32:26
举报
文章被收录于专栏:SRE运维实践

序言

什么样的人可以称之为有智慧的人呢?如果下一个定义,你会如何来定义?

所谓智慧,就是能区分自己能改变的部分,自己无法改变的部分,努力去做自己能改变的,而不要天天想着那些无法改变的东西,不然的话,就只能越来越消极了,消极的原因大部分也在于总是关注于自己无法改变的现实。

nginx返回404问题排查

背景

大部分的人在看到nginx返回404的时候,要么就是请求了一个不存在的资源或者接口,要么就是location写的有问题,基本不会想到是协议导致的。

架构

现在的应用程序都讲究前后端分离,分离不完整的时候,就会进行修改架构,在修改之前的架构如下:

为了从统一入口进来,从而将架构修改为如下:

修改之后的好处主要是能减少客户端能接触的东西,从而减少暴露面,当有攻击的时候,排查或者封杀的面不会很多。

1 前端nginx进行重新配置

在前端nginx上面,其实只要增加一段location的配置即可,从而使用了极简的配置:

代码语言:javascript
复制
upstream backend {
   server   192.168.1.1;
   server   192.168.1.2;
}
location  /api/
 {
      proxy_pass http://backend;
      proxy_set_header X-Real_IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

在添加完成配置之后,将nginx进行reaload,让配置生效,再次进行验证请求之后,发现后端请求的接口全部变成了404.

此时的你,该如何去解决这个问题?

对,应该第一时刻进行回滚备份的配置,先让生产跑起来,再来解决问题。

2 查看前端和后端的日志

变更导致的问题,要么看配置是不是有问题,要么看日志查查问题出现的点在哪里。

在查看nginx的accesslog的时候,重要的看请求发到了哪个后端,404是不是后端返回的,如果404是nginx直接返回的,说明还没到达后端,如果是后端的返回的,那么就要看后端nginx的日志了。

在此处的问题中,查看前端nginx日志的时候,发现是后端nginx返回的404,因为upsteam_status 为404,而且能找到对应的upsteam server的ip,从而到对应的后端nginx上去查看日志。

但是,非常奇怪的是,在后端nginx上面未看到任何请求日志,在后端nginx上面,使用的是vhost的配置,也就是虚拟主机。

那么现在可以得到一个初步结论:

代码语言:javascript
复制
1 404 的确是后端nginx返回的
2 后端nginx上面没找到对应的访问日志

3 可能出现问题的地方

根据如上的结论,那么哪些地方可能出现问题呢?

首先再看了一眼加了location配置的地方,比平时的配置少一些东西:

代码语言:javascript
复制
proxy_set_header Host $host;
proxy_set_header Connection "";
proxy_http_version 1.1;

在后端的nginx对应的server段的配置的日志路径上面,没找到对应的日志信息,但是前端的nginx返回中说明是后端nginx返回的,从而找到对应的默认主机,也就是default server中,发现默认配置没有,那么就找到在vhost中第一个主机段,查看它的日志,发现了请求。

从而问题已经找到,因为在nginx的默认配置中,如果不指定http协议版本的话,那么默认是1.0版本,而对于http 1.0版本来说,默认是不会加上host头部的,从而当请求到后端nginx的时候,找不到对应server name进行处理,从而走了默认的server段进行处理,从而导致了对应的虚拟主机没有日志,而在默认的虚拟主机中找到了对应的访问日志。

从而再将host头部进行设置,然后切换,发现访问正常。

那么再尝试一下第二种方案,不加host后端,而指定http协议为1.1,因为http1.1协议默认会传输host头部,从而无需显示指定,发现也是ok的。

最后再把这三个头部加上,主要是为了让两个nginx之间保持长连接,从而减少三次握手的时间,当然upsteam之中,也要将keepalive指令打开,不然也是不能激活长连接的,因为nginx的默认值如下:

代码语言:javascript
复制
Syntax:  keepalive connections;
Default:  —
Context:  upstream

风言风语

一个东西,使用的多了,就能遇到各种各样的问题,而在一些资料上看到的东西,你会发现那都是基础中的基础,解决不了任何问题,但是却是解决问题的根基,简单的报错,但是中间就充斥着各种可能得组合原因。就像做数学,基础都是1+1,然后来个3+2,都是同样的道理。

知道并不代表能灵活运行,能猜到可能的原因和解法,对比法也是一个比较好的方法。

努力的方向也是自己能改变的东西,也是自己能掌控的东西,如果努力的方向都是不能改变的,不可控的,那么这种努力也将是一种徒劳。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2024-07-06,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 SRE运维实践 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
轻量应用服务器
轻量应用服务器(TencentCloud Lighthouse)是新一代开箱即用、面向轻量应用场景的云服务器产品,助力中小企业和开发者便捷高效的在云端构建网站、Web应用、小程序/小游戏、游戏服、电商应用、云盘/图床和开发测试环境,相比普通云服务器更加简单易用且更贴近应用,以套餐形式整体售卖云资源并提供高带宽流量包,将热门软件打包实现一键构建应用,提供极简上云体验。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档