记一次线上接口404排查过程

发布于 / 学习

前言

今天周五美滋滋的划半天水,上个厕所回来客户群里来了一条信息,丢了一张截图,冲上来就问,这个怎么编辑不了了?

我特么一脸蒙蔽,我也想知道为什么编辑不了了啊。打开线上系统,找到编辑弹窗,按下F12,调到network,使出浑身力气按下保存按钮,心里想着,xx用户肯定是你操作不当,看我这不是好的吗。

network中血红的报错就像被一巴掌打过的脸一样,我太难了。为什么,为什么明明这个功能上线了一个多月了没有这个问题。好了不戏精了,来看问题。

排查

  • 第一步

打开network观察发现只有一个接口报了404。其他接口都是好的,想着这个破代码一个多月没动过了,应该不是代码的问题。右键将这个接口地址复制到浏览器直接打开

因为这个接口是POST请求方式,所以返回错误,但是http status还是正常的200的呀,因为还能正常走到代码逻辑里

这里暂时排除后端代码的问题

  • 第二步

因为这个需求已经上线一个多月了,而且测试环境线上环境都验证过。前端调用其他接口包括GET/POST都是正常的

这里暂时排除前端代码问题

  • 第三步

把这个接口url复制到postman,不带任何参数请求一次:

同样可以调通,也是正常的200。

这里排除是浏览器的问题

  • 第四步

我把浏览器请求体里的参数复制到postman中试一下,如下图:

这个数据好像有点多哎,心里想着是不是参数的问题呢,赶紧试试看,复制到调试中:

注意,这里我调通了,因为最后解决这个问题了,所以现在能调通,但是之前排除的时候是返回404

走到这里,犯罪嫌疑人已经锁定为POST请求的body了。初步怀疑是参数json体数据太多

  • 第五步:验证是否是参数问题

随便在线上找一个POST请求,参数少的试一下便知有没有。

发现其他的POST接口是正常的,而且参数不是很多。只有刚才有问题的那个接口包含大量的参数。我去新建个文本将参数复制进去看了一下大小

这个是成功的

这个是失败的

好了罪魁祸首大概已经确定了,就决定是你的,带着这个问题去度娘找找看有没有人遇到一样的问题

  • 第六步:原来是nginx搞的鬼

带着疑问去网上百度,关键词:

nginx http Post body过大 404

给出原文链接

发现一个很类似的问题
按照方案修改nginx配置

# Nginx分配给请求数据的Buffer大小
client_body_buffer_size  128k;
# 控制该server的所有请求报文大小
client_max_body_size   16m

重启服务,再次尝试问题就解决了。

总结

  • client_max_body_size

client_max_body_size 默认 1M,表示 客户端请求服务器最大允许大小,在“Content-Length”请求头中指定。如果请求的正文数据大于client_max_body_size,HTTP协议会报错 413 Request Entity Too Large。就是说如果请求的正文大于client_max_body_size,一定是失败的。如果需要上传大文件,一定要修改该值。

  • client_body_buffer_size

Nginx分配给请求数据的Buffer大小,如果请求的数据小于client_body_buffer_size直接将数据先在内存中存储。如果请求的值大于client_body_buffer_size小于client_max_body_size,就会将数据先存储到临时文件中

关于

本文采用 CC BY-NC-SA 3.0 Unported 协议进行许可
本文链接: https://www.ahwgs.cn/online-404-nginx.html