从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,都是同样的道理。

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

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

相关推荐
码农小白几秒前
linux驱动:(22)中断节点和中断函数
linux·运维·服务器
4647的码农历程2 分钟前
Linux网络编程 -- 网络基础
linux·运维·网络
醉颜凉27 分钟前
银河麒麟桌面操作系统V10 SP1:取消安装应用的安全授权认证
运维·安全·操作系统·国产化·麒麟·kylin os·安全授权认证
C++忠实粉丝1 小时前
Linux环境基础开发工具使用(2)
linux·运维·服务器
康熙38bdc2 小时前
Linux 环境变量
linux·运维·服务器
存储服务专家StorageExpert2 小时前
DELL SC compellent存储的四种访问方式
运维·服务器·存储维护·emc存储
大G哥3 小时前
记一次K8S 环境应用nginx stable-alpine 解析内部域名失败排查思路
运维·nginx·云原生·容器·kubernetes
妍妍的宝贝3 小时前
k8s 中微服务之 MetailLB 搭配 ingress-nginx 实现七层负载
nginx·微服务·kubernetes
醉颜凉3 小时前
银河麒麟桌面操作系统修改默认Shell为Bash
运维·服务器·开发语言·bash·kylin·国产化·银河麒麟操作系统
苦逼IT运维4 小时前
YUM 源与 APT 源的详解及使用指南
linux·运维·ubuntu·centos·devops