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

序言

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

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

nginx返回404问题排查

背景

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

架构

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

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

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

1 前端nginx进行重新配置

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

properties 复制代码
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的配置,也就是虚拟主机。

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

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

3 可能出现问题的地方

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

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

nginx 复制代码
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的默认值如下:

http 复制代码
Syntax:  keepalive connections;
Default:  ---
Context:  upstream

风言风语

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

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

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

相关推荐
七夜zippoe3 小时前
CANN Runtime任务描述序列化与持久化源码深度解码
大数据·运维·服务器·cann
Fcy6484 小时前
Linux下 进程(一)(冯诺依曼体系、操作系统、进程基本概念与基本操作)
linux·运维·服务器·进程
袁袁袁袁满4 小时前
Linux怎么查看最新下载的文件
linux·运维·服务器
代码游侠4 小时前
学习笔记——设备树基础
linux·运维·开发语言·单片机·算法
Harvey9035 小时前
通过 Helm 部署 Nginx 应用的完整标准化步骤
linux·运维·nginx·k8s
珠海西格电力科技6 小时前
微电网能量平衡理论的实现条件在不同场景下有哪些差异?
运维·服务器·网络·人工智能·云计算·智慧城市
释怀不想释怀6 小时前
Linux环境变量
linux·运维·服务器
zzzsde6 小时前
【Linux】进程(4):进程优先级&&调度队列
linux·运维·服务器
聆风吟º8 小时前
CANN开源项目实战指南:使用oam-tools构建自动化故障诊断与运维可观测性体系
运维·开源·自动化·cann
NPE~8 小时前
自动化工具Drissonpage 保姆级教程(含xpath语法)
运维·后端·爬虫·自动化·网络爬虫·xpath·浏览器自动化